From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13449 invoked by alias); 21 Jan 2014 16:46:59 -0000 Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org Received: (qmail 13436 invoked by uid 89); 21 Jan 2014 16:46:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: mail.ecoscentric.com Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 21 Jan 2014 16:46:58 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 3C58F4680002 for ; Tue, 21 Jan 2014 16:46:55 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd5V9V9ydxWA; Tue, 21 Jan 2014 16:46:28 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001656] FreeBSD: add AF_PACKET socket familiy Date: Tue, 21 Jan 2014 16:46:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: grant.b.edwards@gmail.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: high X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg00000.txt.bz2 Please do not reply to this email, use the link below. http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001656 Grant Edwards changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |grant.b.edwards@gmail.com --- Comment #15 from Grant Edwards --- First, thanks for taking the time to find/fix all these bugs. I'd like to start working on getting these committed. After a preliminary look through the patches I have a few suggestions on how to more quickly get things committed. The patches contain hundreds diffs where nothing has changed but whitespace (usually at the end of the line): diff -Nur ecos-cvs-120723/packages/io/eth/current/src/net/eth_drv.c ecos/packages/io/eth/current/src/net/eth_drv.c --- ecos-cvs-120723/packages/io/eth/current/src/net/eth_drv.c 2009-01-29 18:49:45.000000000 +0100 +++ ecos/packages/io/eth/current/src/net/eth_drv.c 2012-08-02 14:30:54.000000000 +0200 @@ -146,8 +146,8 @@ static int simulate_fail( struct eth_drv_sc *sc, int which ) { - struct simulated_failure_state *s; - + struct simulated_failure_state *s; + for ( s = &simulated_failure_states[0]; s < &simulated_failure_states[2]; s++ ) { if ( 0 == s->sc ) { Having to wade through the non-changes visually searching for the real changes makes it that much more difficult to review. Applying the patches and then using a diff tool like meld that can ignore whitespace changes is one work-around, but being able to use Bugzilla's built-in (though somewhat less intelligent) tools makes life easier for anybody reviewing the code. I realize that deleting trailing whitespace is a side-effect of using certain editors and probably wasn't done intentionally. Cleaning up whitespace from ends of lines is fine, but it it should probably be in a separate patch that does nothing but whitespace cleanup. Splitting the changes up into smaller patches would also make it much easier. A separate patch for the AF_PACKET support and for each of the 10 bugs you listed would be ideal. That way somebody reviewing the code doesn't have to try to figure out which bug a particular change is addressing. It also means that the work of reviewing and committing the changes can be divided up among multiple maintainers. Next is the question of copyright assignment. I'm not sure where the threshold is for "trivial" changes above which a copyright assignment is needed, and hopefully some other maintainers to comment on that. There's probably a good chance that for a contribution this large a copyright assignment will be needed. -- Grant -- You are receiving this mail because: You are on the CC list for the bug.