From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by dpdk.org (Postfix) with ESMTP id 972465A52 for ; Thu, 9 Apr 2015 23:23:46 +0200 (CEST) Received: by pddn5 with SMTP id n5so39877pdd.2 for ; Thu, 09 Apr 2015 14:23:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=DqFENNS9x0SRlwGqe7PCvRrFJHUi7S7+RLfXTrMxdpk=; b=emNMP5NRDJ46S+mlWZ231FJvMQ0jYBAbpCRCkVpNKZH8xFfbrQXXuLoTHCORZgqtdG n+PwaF2dGBIW6pUkHb1vwXzOjTQHDZmGCtN0HelS0+exuOa8aJaJJyPKeIRbK0SKBxfg 8YZBJKfP1s+0ADfKSwXcPovXzNIG+rOkKpxh02vlo9+JEXAj8lz94sy3oQ7yMOjn6hif giKmuEtj8y601iHWtdyKRWICy8NWNaOYEKZYlj4Indml3RLWtaDh2coqggjsQb+PmKOK Z3Ct0fAS2YOaloQSuGeoBg9NFrFz+QTMh3fs9V/WkqV/KpJ6X8/s+LfkhEe74iKrqyPK gzAA== X-Gm-Message-State: ALoCoQlVAtF9OhcOpRgzClyZC17zkj6aexStWSAVlp3D66XWi1t6JHFI0jHoxD/nMgDVpk/IHT80 X-Received: by 10.70.136.202 with SMTP id qc10mr58518324pdb.117.1428614625787; Thu, 09 Apr 2015 14:23:45 -0700 (PDT) Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by mx.google.com with ESMTPSA id ji6sm15709449pac.30.2015.04.09.14.23.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 14:23:45 -0700 (PDT) Date: Thu, 9 Apr 2015 14:23:49 -0700 From: Stephen Hemminger To: "Wiles, Keith" Message-ID: <20150409142349.5b0b3293@urahara> In-Reply-To: References: <3571725.20GtF5MAnU@xps13> <0C5AFCA4B3408848ADF2A3073F7D8CC86D58F9C2@IRSMSX109.ger.corp.intel.com> <20150408114339.GA22959@hmsreliant.think-freely.org> <0C5AFCA4B3408848ADF2A3073F7D8CC86D58FB64@IRSMSX109.ger.corp.intel.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Thu, 09 Apr 2015 21:23:47 -0000 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.