From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id DD60A5A52 for ; Thu, 9 Apr 2015 23:29:16 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 09 Apr 2015 14:29:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,552,1422950400"; d="scan'208";a="711529290" Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by orsmga002.jf.intel.com with ESMTP; 09 Apr 2015 14:29:16 -0700 Received: from orsmsx114.amr.corp.intel.com (10.22.240.10) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 9 Apr 2015 14:29:15 -0700 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by ORSMSX114.amr.corp.intel.com (10.22.240.10) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 9 Apr 2015 14:29:15 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.111]) by FMSMSX157.amr.corp.intel.com ([10.18.116.73]) with mapi id 14.03.0224.002; Thu, 9 Apr 2015 14:29:14 -0700 From: "Wiles, Keith" To: Stephen Hemminger Thread-Topic: [dpdk-dev] tools brainstorming Thread-Index: AQHQYx11uIkL9FTheESuDxqnoTBHMp1DgO2AgAAQtACAAAkVAIAAD1iAgAAZHoCAAIMDAIAAAkYAgAEr94CAAC4wAIAABgcA///F0gCAAFeYgP//rbAA Date: Thu, 9 Apr 2015 21:29:14 +0000 Message-ID: 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> <20150409142349.5b0b3293@urahara> In-Reply-To: <20150409142349.5b0b3293@urahara> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.195.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <1F97470245388D40B39C680E3D1AE96F@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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:29:17 -0000 On 4/9/15, 4:23 PM, "Stephen Hemminger" wrote: >On Thu, 9 Apr 2015 21:10:19 +0000 >"Wiles, Keith" wrote: > >>=20 >>=20 >> On 4/9/15, 2:38 PM, "Jay Rolette" wrote: >>=20 >> >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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> Regards, >> ++Keith >> > >>=20 > >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? >