Re: [LTP] Submitting patch

[Subrata Modak <subrata@linux.vnet.ibm.com>]

On Mon, 2009-07-27 at 11:29 +0200, Michal Simek wrote: 
> Hi Garrett,
> > On Fri, Jul 24, 2009 at 11:15 PM, Michal
> > Simek<michal.simek@petalogix.com> wrote:
> >   
> >> Please fix coding style. Use tab instead of space for indentation.
> >>     
> >
> >   
> You wrote nice email and I have to react on it.
> 
> > There is nothing that states that 8-space tabs aren't appropriate in
> > the kernel.org coding / style guide:
> > http://www.kernel.org/doc/Documentation/CodingStyle
> >
> > Please stop saying that tabs are required. 8-space / tabs _are_
> > required according to the guide.
> >   
> I invest a lot of time to fix testcases/kernel/syscalls. I used there
> tabs instead of spaces.
> You can use what you want but please keep in your mind.
> There should be one coding style for all source code. (for C, C++,
> Makefile, etc)
> 
> If you want to use spaces instead of tab and you hate tab you can of course.
> I expect that if you replaced all tabs in every C code ltp code will
> grow up.
> I am not sure if only this change help anybody.
> 
> IMHO use one tab instead of 8 spaces make more sense.
> 
> > Please also thoroughly read through the document as it says 80-char
> > lines are preferred, etc. It does not say they are required.
> >   
> There is not possible to have 80-char lines for every file but if you
> can use 80-chars line -
> you should do it. For large function is not possible to do it. If your
> function is large you should
> start to think how others will read it.
> > At the same time though, these guidelines do not necessarily apply to
> > userland apps, as far as the comment:
> >
> > "The answer to that is that if you need more than 3 levels of
> > indentation, you're screwed anyway, and should fix your program."
> >
> > is concerned. Yes, that's true for kernel code. No it's not
> > necessarily true for userland apps as more than 3 levels of branches
> > may be required.
> >
> > So, in conclusion, yes -- we should try to stick to the kernel.org
> > coding guidelines, but 1) we are not kernel.org and 2) we're not
> > producing kernel code, so the coding guidelines may be more of a
> > shoehorn fit than an appropriate one. It also doesn't apply to
> > anything beyond C/C++ code.
> >   
> Really? But you should look at patches how they looks like. Code don't have
> any style. If is preferable style for Cisco - it is your problem not
> mine. Your code
> present you and your coding style too. LTP contains a lot of code and I
> thought
> that will be good to clear.
> 
> Anyway this bring me up only troubles nothing else.
> It is up to Subrata what coding style/patches wants.

We indeed need coding styles for LTP. Let take this up once and all
after the release.

Regards--
Subrata

> I won't spend my time on cleaning LTP or disturb people.
> 
> > Mike/Subrata,
> >     Can we actually write up a style guide for folks to follow that
> > applies for code, as the kernel.org guidelines don't apply that well
> > to our circumstances?
> >   
> > Thanks,
> > -Garrett
> >   
> Thanks for your email -> it save me a lot of time for future.
> 
> Enjoy your day,
> Michal
> 
> 
> >   
> >>> PATCH IS CREATED FOR ltp-full-20090630.
> >>>
> >>> I am submitting a patch to kernel/fs/fs_di
> >>>
> >>> In this file data integity is performed by creating the file at
> >>> different directory depth and then by comparing with original file.
> >>>
> >>> To this I have added one more approach to perform integrity test.
> >>> 1. Creating two fragmented files each of size DiskSize/2.
> >>> 2. Then comapring against the original file.
> >>> 3. If not equal test case fails.
> >>>
> >>> My ultimate goal in creating fragmented files is that,
> >>> 1. It creates many extents (fragments for each file)
> >>> 2. FS code may behave wrong at corner cases which may come into picture
> >>>    after many extents gets added to the file.
> >>> 3. Data corruption chances are there
> >>>      i. when file metadata updation is not proper (corner cases when fragments are more)
> >>>      ii.If write and read is not matching (write operation might have updated the block
> >>>         number some where and read may skip that block in some corner cases)
> >>> 4. In reality fragments can occur only after much usage of the disk(create/delete file)
> >>> 5. This is good test case for bigger size disk.(it can create more extents)
> >>>       
> 
> 
> -- 
> Michal Simek, Ing. (M.Eng)
> PetaLogix - Linux Solutions for a Reconfigurable World
> w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list