Re: [LTP] Submitting patch

Subrata Modak
2009-08-04T10:12:08Z

Hi Michal/Garret/all,

On Tue, 2009-08-04 at 10:37 +0200, Michal Simek wrote:
> Garrett Cooper wrote:
> > On Mon, Aug 3, 2009 at 7:46 AM, Michal Simek<michal.simek@petalogix.com> wrote:
> >
> >> Cyril Hrubis wrote:
> >>
> >>> Hi!
> >>>
> >>>
> >>>>> What's wrong with linux kernel coding style? Most of the decent text editors
> >>>>> that are used these days (vim, emacs...) just helps format code like this. (Eg.
> >>>>> default intendation is done by tabs and so on...) I don't like the idea
> >>>>> changing tabs to spaces before sending a patch.
> >>>>>
> >>>>>
> >>>> There is only one thing which is IMHO not good - it is 80 char line size.
> >>>> I would prefer longer lines (maybe 120 chars).
> >>>> This is for C code not for any other.
> >>>> Are you ok with it?
> >>>>
> >>>>
> >>> Well, I'm not happy with very long lines, but there are indeed circumstances
> >>> where long lines are best solution.
> >>>
> >>>
> >> I am not happy with it too but there are some cases where is really ugly
> >> to have 80chars lines.
> >>
> >
> > IMHO 95% of the time you can get away with shorter lines with
> > different constructs or more clever indentation.
> I don't want to do any clever indentation. This discuss is again and
> again the same!!!
>
> I vote for standard linux indentation - tab (size 8 chars) for whole C code.
> Follow linux kernel coding style for whole C code. As we discussed in
> this thread 80 chars line are strongly recommended.
> For checking C source code use checkpatch.pl script which is in linux
> kernel before sending patches to mailing list
> and of course checking patches before applying.
>

Yes, checkpatch.pl for C code patches.

> Cyril, Mike, Subrata and others: Can you send us your opinion? I don't
> want to spend my time with discuss about it.
>
> I am not interested in any other code that's why I don't write any
> comment to it.
> You can choose what you want. Of course if is similar utility like
> checkpatch.pl it will be good to use it and not to check
> it by hand.
>
> Subrata can we please write output from this discussion to web / doc
> somewhere?
>

I will do that soon.

> Thanks,
> Michal
>
>
> > Take for example what
> > I just did with delete_module* -- now that was a mess to cleanup, but
> > quick nonetheless and necessary:
> > http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/module/delete_module/delete_module01.c?view=log&pathrev=makefile_infra_rework
> > , http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/module/delete_module/delete_module02.c?view=log&pathrev=makefile_infra_rework
> > , http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/module/delete_module/delete_module03.c?view=log&pathrev=makefile_infra_rework
> >
> > We should aim for 80 column lines wherever possible because it's the
> > defacto standard, and where we can't do that (and there are a handful
> > of areas with shell code and Makefile code where I couldn't without
> > changing the meaning of the message I was trying to convey), we should
> > go over 80 cols.
> >
> > At least that's how every project I know has done it.
> >
> > General rules of thumb for shell / python / perl code (from dealing
> > with other projects) was 4 space indents. Perl tends to go whacky
> > though because of all of the different ways to express constructs
> > though xD.

Again, checkpatch.pl for non-C code as well. But, need to carefully
review the errors it will generate for non-C code like the Makefiles,
perl, shell, python, etc.

Garret,

Can you please come up with a list of exceptions for
1. line length,
2. tab length,
3. etc

for non-C code like the perl, Makefiles, etc. I would then document them
all.

Regards--
Subrata

> >
> > Thanks!
> > -Garrett
> >