On Fri, Jul 24, 2009 at 11:15 PM, Michal Simek<[email protected]> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
