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<[email protected]> 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
