Re: [LTP] Submitting patch

[Michal Simek <michal.simek@petalogix.com>]

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.
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