From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id E7E1F5A41 for ; Fri, 10 Apr 2015 02:16:39 +0200 (CEST) Received: from [2001:470:8:a08:215:ff:fecc:4872] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YgMcV-0006L7-WB; Thu, 09 Apr 2015 20:16:36 -0400 Date: Thu, 9 Apr 2015 20:16:13 -0400 From: Neil Horman To: "Wiles, Keith" Message-ID: <20150410001613.GA28597@neilslaptop.think-freely.org> References: <20150408131105.GD22959@hmsreliant.think-freely.org> <0C5AFCA4B3408848ADF2A3073F7D8CC86D58FDBF@IRSMSX109.ger.corp.intel.com> <0FBA33A7-A21E-426F-B44E-32E86F2B23DB@infiniteio.com> <20150408153802.2bc59227@urahara> <20150409191658.GC26201@hmsreliant.think-freely.org> <20150409142349.5b0b3293@urahara> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] tools brainstorming X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 00:16:40 -0000 On Thu, Apr 09, 2015 at 09:29:14PM +0000, Wiles, Keith wrote: > > > On 4/9/15, 4:23 PM, "Stephen Hemminger" wrote: > > >On Thu, 9 Apr 2015 21:10:19 +0000 > >"Wiles, Keith" wrote: > > > >> > >> > >> On 4/9/15, 2:38 PM, "Jay Rolette" wrote: > >> > >> >On Thu, Apr 9, 2015 at 2:16 PM, Neil Horman > >>wrote: > >> > > >> >> On Thu, Apr 09, 2015 at 11:31:39AM -0500, Jay Rolette wrote: > >> >> > On Wed, Apr 8, 2015 at 5:38 PM, Stephen Hemminger < > >> >> > stephen@networkplumber.org> wrote: > >> >> > > >> >> > > On Wed, 8 Apr 2015 16:29:54 -0600 > >> >> > > Jay Rolette wrote: > >> >> > > > >> >> > > > "C comments" includes //, right? It's been part of the C > >>standard > >> >> for a > >> >> > > long time now... > >> >> > > > >> >> > > Yes but. > >> >> > > I like to use checkpatch and checkpatch enforces kernel style > >>which > >> >> does > >> >> > > not allow // for > >> >> > > comments. > >> >> > > > >> >> > > >> >> > Fork checkpatch and disable that bit? DPDK isn't the kernel, so no > >> >> > requirement to follow all of its rules > >> >> > > >> >> > >> >> Doesn't that beg the question, why? I understand the DPDK isn't the > >> >> kernel, but > >> >> we're not talking about clarity of code, not anything functional to > >>that > >> >> code. > >> >> It seems we would be better served by just taking something that > >>works > >> >>here > >> >> rather than re-inventing the wheel and digging into the minuate of > >>what > >> >> type of > >> >> comments should be allowed (unless there is a compelling reason to > >> >>change > >> >> it > >> >> that supercedes the avilable tools). If not checkpath, then some > >>other > >> >> tool, > >> >> but It seems to me that coding style is one of those things where we > >>can > >> >> bend to > >> >> the tool rather than taking the time to make the tool do exactly > >>whats > >> >> desired, > >> >> at least until someone gets the time to modify it. > >> >> > >> > > >> >Fair question. > >> > > >> >It depends a bit on how much you want to encourage patch > >>contributions. Is > >> >it worth adding more pain for folks trying to contribute patches for > >> >things > >> >like this? > >> > > >> >Should we force someone to spend time redoing a patch because of which > >>way > >> >they do their parenthesis? What about number of spaces to indent code? > >>// > >> >vs /* */ comments? None of these matter functionally and they don't > >>affect > >> >maintenance generally. > >> > > >> >If someone is modifying existing code, then yeah, they should follow > >>the > >> >prevailing style (indention level, brace alignment, etc.) of the file > >>they > >> >are in. It helps readability, which makes maintenance easier. However, > >> >IMO, > >> >mixing // and /* */ for comments doesn't affect the readability of the > >> >source. > >> > > >> >I know if I submit a patch and the only feedback is that I should have > >> >used > >> >/* */ for comments, I'm extremely unlikely spend extra time to resubmit > >> >the > >> >patch for pedantry. > >> > >> I looked at checkpatch.pl for few minutes and the code does check for > >>C99 > >> comments and adding a command line option to allow C99 comments could > >> pretty simple. I found the code around line 3048 or search for C99, it > >>is > >> possible it could accepted back into Linux as long as the default option > >> was to not allow C99 comments. > >> > >> Allowing C99 comments would be nice and the only problem I could see if > >> some compiler has a problem with them. I believe all of the compilers we > >> support allow C99 comments. > >> > >> The only other reason to allow them is if we add some open source code > >>in > >> the future to DPDK which has C99 comments and if would be a pain to have > >> to convert that code every time the open source group released a new > >> version. It does open that path IMO. > >> > >> Regards, > >> ++Keith > >> > > >> > > > >But forking a tool means maintaining that tool. > > If the tool is pushed back into the main stream, then no you do not have > to maintain it, right? > That was my point and the change a simple one plus I would expect it > should not give anyone a problem unless Linux really wants to stay pre > C99, which is not the case today, right? This is true, but the typical attitude in the linux kernel is that a change must have a use case and a user to be considered. I don't want to dissuade you from trying to get it accepted, but my concern would be that, since the kernel folks don't allow the '//' comments, they won't be interested in maintaining the change. Neil > > > >