Submitting patch

LTP [email protected] 5 participants 9 messages Jul 24, 2009 – Aug 4, 2009 4 messages not in the archive

lore

Share & tools

lore

[email protected]

author

2009-07-24 11:00 UTC #0 lore raw

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)

To: [email protected]
Cc: [email protected]
Bcc: Jyoti <[email protected]>
Subject: Submitting patch
Reply-To: Jyoti <[email protected]>

Added one more approach for data integrity.
Data integrity is performed on two fragmented files.
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)
6. fsync() is called after every write, which makes it slow.

Signed_off_by: Jyoti Vantagodi ([email protected])

testcases/kernel/fs/fs_di/frag.c +121 -0

diff -Naurp ltp-full-20090630/testcases/kernel/fs/fs_di/frag.c ltp-full-20090630-new/testcases/kernel/fs/fs_di/frag.c
@@ -0,0 +1,121 @@
+/******************************************************************************/
+/*                                                                            */
+/* Copyright (c) International Business Machines  Corp., 2009                 */
+/*                                                                            */
+/* This program is free software;  you can redistribute it and/or modify      */
+/* it under the terms of the GNU General Public License as published by       */
+/* the Free Software Foundation; either version 2 of the License, or          */
+/* (at your option) any later version.                                        */
+/*                                                                            */
+/* This program is distributed in the hope that it will be useful,            */
+/* but WITHOUT ANY WARRANTY;  without even the implied warranty of            */
+/* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See                  */
+/* the GNU General Public License for more details.                           */
+/*                                                                            */
+/* You should have received a copy of the GNU General Public License          */
+/* along with this program;  if not, write to the Free Software               */
+/* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA    */
+/*                                                                            */
+/******************************************************************************/
+
+/******************************************************************************/
+/*                                                                            */
+/* File:        frag.c                                                        */
+/*                                                                            */
+/* Description: This piece of code creates two files, and writes 1k data to   */
+/*              each file in a loop from datafile. Loop continues till it     */
+/*              reaches EOF of data file. In a loop fclose is called, to      */
+/*              create fragmented files.                                      */
+/*                                                                            */
+/* Author:      Jyoti Vantagodi [email protected]                           */
+/*                                                                            */
+/* History:     Created - Jul 22 2009 -  Jyoti Vantagodi [email protected]  */
+/*                                                                            */
+/******************************************************************************/
+
+#include<stdio.h>
+#include<fcntl.h>
+#include<string.h>
+#include<sys/types.h>
+#include<unistd.h>
+
+FILE *fp_data = NULL;  //File pointer for data file
+FILE *fp_frag1 = NULL; //File pointer for fragmented file 1
+FILE *fp_frag2 = NULL; //File pointer for fragmented file 2
+
+int main(int argc, char *argv[])
+{
+	int bytes_read=0, bytes_written=0, fd1,fd2;
+	char buff[1024],frag_file1[100],frag_file2[100];
+
+	if (argc != 3 )
+   	{
+		printf("Needs to pass two arguments..\n");	
+      		return -1 ;
+   	}
+	fp_data = fopen(argv[1], "r");
+	if(!fp_data)
+	{
+		perror("fopen:");
+		printf("Error opening datafile \n");
+		return 1;
+	}
+	strcpy(frag_file1, argv[2]);
+	strcat(frag_file1, "/frag1");
+
+	strcpy(frag_file2, argv[2]);
+	strcat(frag_file2, "/frag2");
+	do
+	{
+	
+		fp_frag1 = fopen(frag_file1, "a+");
+    		if(!fp_frag1)
+    		{   
+        		printf("Error opening fragfile \n");
+        		return -1;
+    		}			 
+		fp_frag2 = fopen(frag_file2, "a+");
+    		if(!fp_frag2 )
+    		{   
+        		printf("Error opening fragfile \n");
+        		return -1;
+    		}		 
+
+		bytes_read = fread(buff, 1, 1024, fp_data);
+		if( bytes_read < 0)
+		{
+			printf("Error reading data file\n");
+			return -1;
+		}
+                
+		bytes_written = fwrite(buff, 1, bytes_read, fp_frag1);
+		if( bytes_read!= bytes_written)
+		{
+			printf("Error in writing data\n");
+			return -1;
+		}
+
+		bytes_written = fwrite(buff, 1, bytes_read, fp_frag2);
+		if( bytes_read!= bytes_written)
+        	{
+            		printf("Error in writing data\n");
+            		return -1;
+        	}	
+		fd1 = fileno(fp_frag1);
+		fd2 = fileno(fp_frag2);
+
+		fsync(fd1);
+		fsync(fd2);
+		fclose(fp_frag1);
+		fclose(fp_frag2);
+
+                if(bytes_read < 1024)
+		{
+			break;
+		}
+	}while(1);
+	fclose(fp_data);
+	return 0;
+}
+				
+

testcases/kernel/fs/fs_di/fs_di +64 ~~-11~~

135 lines not on this page · raw message

------------------------------------------------------------------------------

_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Michal Simek

2009-07-25 06:15 UTC #1 lore raw

Please fix coding style. Use tab instead of space for indentation.

Thanks,
Michal

Quoted 40 lines

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)
To: [email protected]
Cc: [email protected]
Bcc: Jyoti <[email protected]>
Subject: Submitting patch
Reply-To: Jyoti <[email protected]>
------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Signature · 10 lines

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

Garrett Cooper

2009-07-25 16:48 UTC #2 lore raw

Quoted 1 line · Michal Simek

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

Quoted 12 lines

Quoted 12 lines
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.

Quoted 10 lines

Quoted 10 lines
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

Michal Simek

2009-07-27 09:54 UTC #3 lore raw

Hi Garrett,

Quoted 7 lines

Quoted 2 lines · Michal Simek
Please fix coding style. Use tab instead of space for indentation.

You wrote nice email and I have to react on it.

Quoted 7 lines

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.

Quoted 3 lines

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.

Quoted 10 lines

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.

Quoted 6 lines

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.

Quoted 8 lines

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

Quoted 24 lines

Quoted 24 lines
Quoted 24 lines
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)

Signature · 10 lines

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

Subrata Modak

2009-07-30 18:31 UTC #4 lore raw

Quoted 61 lines · Michal Simek

Hi Garrett,
Quoted 7 lines
Quoted 2 lines · Michal Simek
Please fix coding style. Use tab instead of space for indentation.
You wrote nice email and I have to react on it.
Quoted 7 lines
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.
Quoted 3 lines
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.
Quoted 10 lines
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.
Quoted 6 lines
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.

Quoted 2 lines

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

Quoted 29 lines

I won't spend my time on cleaning LTP or disturb people.
Quoted 8 lines
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
Quoted 13 lines
Quoted 13 lines
Quoted 13 lines
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.

Quoted 24 lines

Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
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)
Signature · 10 lines
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

Cyril Hrubis

2009-08-03 10:48 UTC #5 lore raw

Hi,

Quoted 2 lines

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

What's wrong with linux kernel coding style? Most of the decent text editors that are used these days (vim, emacs...) just helps format code like this. (Eg. default intendation is done by tabs and so on...) I don't like the idea changing tabs to spaces before sending a patch.

Signature · 12 lines

Cyril Hrubis
[email protected]

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Cyril Hrubis

2009-08-03 13:55 UTC #7 lore raw

Hi!

Quoted 9 lines

Quoted 4 lines
What's wrong with linux kernel coding style? Most of the decent text editors that are used these days (vim, emacs...) just helps format code like this. (Eg. default intendation is done by tabs and so on...) I don't like the idea changing tabs to spaces before sending a patch.
There is only one thing which is IMHO not good - it is 80 char line size. I would prefer longer lines (maybe 120 chars).
This is for C code not for any other.
Are you ok with it?

Well, I'm not happy with very long lines, but there are indeed circumstances where long lines are best solution.

So may be this should be strong recomendation rather than rule.

Quoted 1 line

P.S.: Cyril: Are you from Czech?

Sure.

Signature · 12 lines

Cyril Hrubis
[email protected]

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Subrata Modak

2009-08-04 10:12 UTC #11 lore raw

Hi Michal/Garret/all,

Quoted 33 lines · Michal Simek

Quoted 23 lines · Garrett Cooper
Quoted 21 lines · Michal Simek
Quoted 19 lines · Cyril Hrubis
Hi!
Quoted 6 lines
Quoted 6 lines
What's wrong with linux kernel coding style? Most of the decent text editors that are used these days (vim, emacs...) just helps format code like this. (Eg. default intendation is done by tabs and so on...) I don't like the idea changing tabs to spaces before sending a patch.
Quoted 6 lines
There is only one thing which is IMHO not good - it is 80 char line size. I would prefer longer lines (maybe 120 chars).
This is for C code not for any other.
Are you ok with it?
Well, I'm not happy with very long lines, but there are indeed circumstances where long lines are best solution.
Quoted 6 lines
Quoted 3 lines
I am not happy with it too but there are some cases where is really ugly to have 80chars lines.
IMHO 95% of the time you can get away with shorter lines with different constructs or more clever indentation.
I don't want to do any clever indentation. This discuss is again and again the same!!!

Quoted 7 lines

I vote for standard linux indentation - tab (size 8 chars) for whole C code. Follow linux kernel coding style for whole C code. As we discussed in this thread 80 chars line are strongly recommended.
For checking C source code use checkpatch.pl script which is in linux kernel before sending patches to mailing list
and of course checking patches before applying.

Yes, checkpatch.pl for C code patches.

Quoted 12 lines

Cyril, Mike, Subrata and others: Can you send us your opinion? I don't want to spend my time with discuss about it.
I am not interested in any other code that's why I don't write any comment to it.
You can choose what you want. Of course if is similar utility like checkpatch.pl it will be good to use it and not to check it by hand.
Subrata can we please write output from this discussion to web / doc somewhere?

I will do that soon.

Quoted 23 lines

Thanks,
Michal
Quoted 19 lines
Take for example what
I just did with delete_module* -- now that was a mess to cleanup, but
quick nonetheless and necessary:
http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/module/delete_module/delete_module01.c?view=log&pathrev=makefile_infra_rework
, http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/module/delete_module/delete_module02.c?view=log&pathrev=makefile_infra_rework
, http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/module/delete_module/delete_module03.c?view=log&pathrev=makefile_infra_rework
We should aim for 80 column lines wherever possible because it's the defacto standard, and where we can't do that (and there are a handful of areas with shell code and Makefile code where I couldn't without changing the meaning of the message I was trying to convey), we should go over 80 cols.
At least that's how every project I know has done it.
General rules of thumb for shell / python / perl code (from dealing with other projects) was 4 space indents. Perl tends to go whacky though because of all of the different ways to express constructs though xD.

Again, checkpatch.pl for non-C code as well. But, need to carefully review the errors it will generate for non-C code like the Makefiles, perl, shell, python, etc.

Garret,

Can you please come up with a list of exceptions for
1. line length,
2. tab length,
3. etc

for non-C code like the perl, Makefiles, etc. I would then document them all.

Regards--
Subrata

Quoted 6 lines

Quoted 4 lines
Thanks!
-Garrett

Garrett Cooper

2009-07-30 18:50 UTC #12 lore raw

In reply to Michal Simek

Hi Michal,
I want to straighten out some points before we get too deep into this topic:

Quoted 9 lines · Michal Simek

Hi Garrett,
Quoted 7 lines
Quoted 2 lines · Michal Simek
Please fix coding style. Use tab instead of space for indentation.
You wrote nice email and I have to react on it.

Thanks :). My intent wasn't to slam your idea, and I don't argue the fact that we need a standard. It's just that whatever we use should be a smart standard for what we're coding.

For instance, tabs / 8-space tabs don't make any sense for python code as the implied defacto standard is 4 spaces per indent, and python requires a certain degree of indentation.

My personal background and experience comes from the following [style(9) from FreeBSD], where readability is compromised with a respect for `space real estate' (from style(9) --
http://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=0&manpath=FreeBSD+7.2-RELEASE
):

Indentation is an 8 character tab. Second level indents are four spaces. If you have to wrap a long statement, put the operator at the end of the line.

while (cnt < 20 && this_variable_name_is_too_long &&
ep != NULL)
z = a + really + long + statement + that + needs +
two + lines + gets + indented + four + spaces + on + the + second + and + subsequent + lines;

Do not add whitespace at the end of a line, and only use tabs followed by spaces to form the indentation. Do not use more spaces than a tab will produce and do not use spaces in front of tabs.

Closing and opening braces go on the same line as the else. Braces that are not necessary may be left out.

which does conflict with the style guide from kernel.org. Then again kernel.org is maintains almost purely kernel code, in which the tabs / 8-space tabs make perfect sense as the logic and branching should be small.

Quoted 13 lines

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

Quoted 6 lines

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.

By and large, I would agree, but tab's really muck up reviewing diffs too -- so as long as it's consistent should be used.

Quoted 24 lines

Quoted 3 lines
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.
Quoted 10 lines
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.
Quoted 6 lines
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.

Quoted 6 lines

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.

Cisco code (as far as I can tell) lacks any form of style and is a bloody hodgepodge of whatever the developer thought was best without any form of structure, and I hate reading it ;)...

I'm fine matching my style to whatever the standard is, but we need to decide upon a standard before we go touting that we should do it in any particular format -- otherwise we'll confuse folks :)...

Quoted 3 lines

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.

Your energies are much appreciated, so please don't be discouraged by what I'm saying too much -- I'm just suggesting that we follow whatever Subrata / Mike decide is the standard for the project. Once that's done, we can start cleaning up big time (and I'll gladly help); style is important, along with documentation and usability... if one of these points is lacking, it's generally a pain for either the end user or a developer picking up the code later :)...

Quoted 6 lines

Quoted 5 lines
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 for your email -> it save me a lot of time for future.

No problem -- let's solve the problem once the big cheeses decide what's best :).

Quoted 12 lines

Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
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.

Quoted 10 lines

Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
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)