Re: [LTP] Submitting patch

[Garrett Cooper <yanegomi@gmail.com>]

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.

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.

Please also thoroughly read through the document as it says 80-char
lines are preferred, etc. It does not say they are required.

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.

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

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

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list