On Thu, 9 Apr 2015 21:10:19 +0000 "Wiles, Keith" <keith.wiles at intel.com> wrote:
> > > On 4/9/15, 2:38 PM, "Jay Rolette" <rolette at infiniteio.com> wrote: > > >On Thu, Apr 9, 2015 at 2:16 PM, Neil Horman <nhorman at tuxdriver.com> 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 at networkplumber.org> wrote: > >> > > >> > > On Wed, 8 Apr 2015 16:29:54 -0600 > >> > > Jay Rolette <rolette at infiniteio.com> 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.