LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* kernel guide to space
@ 2005-07-11 14:56 Michael S. Tsirkin
  2005-07-11 15:34 ` Sander
                   ` (4 more replies)
  0 siblings, 5 replies; 150+ messages in thread
From: Michael S. Tsirkin @ 2005-07-11 14:56 UTC (permalink / raw)
  To: linux-kernel

Hi!
I've been tasked with edicating some new hires on linux kernel coding style.
While we have Documentation/CodingStyle, it skips detail that is supposed to
be learned by example.

Since I've been burned by this a couple of times myself till I learned,
I've put together a short list of rules complementing Documentation/CodingStyle.
This list is attached, below.

Please cc me directly with comments, if any.

Thanks,
MST

---

kernel guide to space AKA a boring list of rules
http://www.mellanox.com/mst/boring.txt

This text deals mostly with whitespace issues, hence the name.

Whitespace -- In computer science, a whitespace (or a whitespace character) is
any character which does not display itself but does take up space.
	From Wikipedia, the free encyclopedia.

1. Read Documentation/CodingStyle. Yes, it applies to you.
   When working on a specific driver/subsystem, try to follow
   the style of the surrounding codebase.

2. The last character on a line is never a whitespace
		Get a decent editor and don't leave whitespace at the end of
		lines.
			Documentation/CodingStyle

Whitespace issues:

3. Space rules for C

3a. Binary operators
	+ - / * %
	== !=  > < >= <= && || 
	& | ^ << >> 
	= *= /= %= += -= <<= >>= &= ^= |=

	spaces around the operator
	a + b

3b. Unary operators
	! ~
	+ - *
	&

	no space between operator and operand
	*a

3c. * in types
	Leave space between name and * in types.
	Multiple * dont need additional space between them.

	struct foo **bar;

3d. Conditional
	?:
	spaces around both ? and :
	a ? b : c

3e. sizeof
	space after the operator
	sizeof a

3f. Braces etc
	() [] -> .

	no space around any of these (but see 3h)
	foo(bar)

3g. Comma
	,
	space after comma, no space before comma
	foo, bar

3h. Semicolon
	;
	no space before semicolon
	foo;

3i. if/else/do/while/for/switch
	space between if/else/do/while and following/preceeding
	statements/expressions, if any:

	if (a) {
	} else {
	}

	do {
	} while (b);

3j. Labels
	goto and case labels should have a line of their own (possibly
	with a comment).
	No space before colon in labels.

int foobar()
{
	...
foolabel: /* short comment */
	foo();
}

4. Indentation rules for C
	Use tabs, not spaces, for indentation. Tabs should be 8 characters wide.

4a. Labels
	case labels should be indented same as the switch statement.
	statements occurring after a case label are indented by one level.

	switch (foo) {
	case foo:
		bar();
	default:
		break;
	}

4b. Global scope
	Functions, type definitions/declarations, defines, global
	variables etc are global scope. Start them at the first
	character in a line (indent level 0).

static struct foo *foo_bar(struct foo *first, struct bar *second,
			   struct foobar* thirsd);

4c. Breaking long lines
		Descendants are always substantially shorter than the parent
		and are placed substantially to the right.
			Documentation/CodingStyle

	Descendant must be indented at least to the level of the innermost
	compound expression in the parent. All descendants at the same level
	are indented the same.
	if (foobar(.................................) + barbar * foobar(bar +
				     					foo *
									oof)) {
	}

5. Blank lines
	One blank line between functions.

void foo()
{
}

/* comment */
void bar()
{
}

	No more than one blank line in a row.
	Last (or first) line in a file is never blank.

Non-whitespace issues:

6. One-line statement does not need a {} block, so dont put it into one
	if (foo)
		bar;

7. Comments
	Dont use C99 // comments.

8. Return codes
	Functions that return success/failure status, should use 0 for success,
	a negative value for failure.
	Error codes are in linux/errno.h .

	if (do_something()) {
		handle_error();
		return -EINVAL;
	}

	Functions that test a condition return 1 if condition is satisfied,
	0 if its not.

	if (is_condition())
		condition_true();

9. Data types
	Standard linux types are in linux/types.h .
	See also Linux Device Drivers, Third Edition,
	Chapter 11: Data Types in the Kernel.  http://lwn.net/images/pdf/LDD3/

9a. Integer types
	int is the default integer type.
	Use unsigned type if you perform bit operations (<<,>>,&,|,~).
	Use unsigned long if you have to fit a pointer into integer.
	long long is at least 64 bit wide on all platforms.
	char is for ASCII characters and strings.
	Use u8,u16,u32,u64 if you need an integer of a specific size.

9b. typedef
	Using typedefs to hide the data type is generally discouraged.
	typedefs to function types are ok, since these can get very long.

typedef struct foo *(foo_bar_handler)(struct foo *first, struct bar *second,
				      struct foobar* thirsd);

Editor configuration:

9. The following is helpful with VIM
	set cinoptions=(0:0

Michael S. Tsirkin

-- 
MST

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-11 14:56 kernel guide to space Michael S. Tsirkin
@ 2005-07-11 15:34 ` Sander
  2005-07-12  6:52   ` Denis Vlasenko
  2005-07-11 15:44 ` Dmitry Torokhov
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 150+ messages in thread
From: Sander @ 2005-07-11 15:34 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: linux-kernel

Michael S. Tsirkin wrote (ao):
> 	Use tabs, not spaces, for indentation. Tabs should be 8
> 	characters wide.

A tab is a tab. The editor/viewer can be configured to show 2, 3, 4, 8,
any amount of characters, right?

        Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-11 14:56 kernel guide to space Michael S. Tsirkin
  2005-07-11 15:34 ` Sander
@ 2005-07-11 15:44 ` Dmitry Torokhov
  2005-07-11 17:19   ` Ingo Oeser
  2005-07-12  7:12 ` Denis Vlasenko
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 150+ messages in thread
From: Dmitry Torokhov @ 2005-07-11 15:44 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: linux-kernel

Hi,

On 7/11/05, Michael S. Tsirkin <mst@mellanox.co.il> wrote:

> 3e. sizeof
>        space after the operator
>        sizeof a

If braces are used no spaces please : sizeof(struct foo) 
 
> 
> 4c. Breaking long lines
>                Descendants are always substantially shorter than the parent
>                and are placed substantially to the right.
>                        Documentation/CodingStyle
> 
>        Descendant must be indented at least to the level of the innermost
>        compound expression in the parent. All descendants at the same level
>        are indented the same.
>        if (foobar(.................................) + barbar * foobar(bar +
>                                                                        foo *
>                                                                        oof)) {
>        }

Ugh, that's as ugly as it can get... Something like below is much
easier to read...

        if (foobar(.................................) +
            barbar * foobar(bar + foo * oof)) {
        }

-- 
Dmitry

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-11 15:44 ` Dmitry Torokhov
@ 2005-07-11 17:19   ` Ingo Oeser
  0 siblings, 0 replies; 150+ messages in thread
From: Ingo Oeser @ 2005-07-11 17:19 UTC (permalink / raw)
  To: dtor_core; +Cc: Michael S. Tsirkin, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

On Monday 11 July 2005 17:44, Dmitry Torokhov wrote:
> >        Descendant must be indented at least to the level of the innermost
> >        compound expression in the parent. All descendants at the same level
> >        are indented the same.
> >        if (foobar(.................................) + barbar * foobar(bar +
> >                                                                        foo *
> >                                                                        oof)) {
> >        }
> 
> Ugh, that's as ugly as it can get... Something like below is much
> easier to read...
> 
>         if (foobar(.................................) +
>             barbar * foobar(bar + foo * oof)) {
>         }
 
Even easier is
         if (foobar(.................................)
             + barbar * foobar(bar + foo * oof)) {
         }

since a statement cannot start with binary operators
and as such we are SURE that there must have been something before.
And this matches with old shop owner calculations like:

   1
+  2
+  3
----
   6

which we all know since early math classes.


Regards

Ingo Oeser



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-11 15:34 ` Sander
@ 2005-07-12  6:52   ` Denis Vlasenko
  2005-07-12 11:55     ` Patrick McHardy
  0 siblings, 1 reply; 150+ messages in thread
From: Denis Vlasenko @ 2005-07-12  6:52 UTC (permalink / raw)
  To: sander, Michael S. Tsirkin; +Cc: linux-kernel

On Monday 11 July 2005 18:34, Sander wrote:
> Michael S. Tsirkin wrote (ao):
> > 	Use tabs, not spaces, for indentation. Tabs should be 8
> > 	characters wide.
> 
> A tab is a tab. The editor/viewer can be configured to show 2, 3, 4, 8,
> any amount of characters, right?

text with 8-char tabs:

struct s {
        int n;          /* comment */
        unsigned int u; /* comment */
};

Same text viewed with tabs set to 4-char width:

struct s {
    int n;      /* comment */
    unsigned int u; /* comment */
};

Comments are not aligned anymore
--
vda


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-11 14:56 kernel guide to space Michael S. Tsirkin
  2005-07-11 15:34 ` Sander
  2005-07-11 15:44 ` Dmitry Torokhov
@ 2005-07-12  7:12 ` Denis Vlasenko
  2005-07-12 11:36   ` Domen Puncer
  2005-07-13  7:09 ` Paul Jackson
  2005-07-20 12:59 ` Jesper Juhl
  4 siblings, 1 reply; 150+ messages in thread
From: Denis Vlasenko @ 2005-07-12  7:12 UTC (permalink / raw)
  To: Michael S. Tsirkin, linux-kernel

> 3c. * in types
> 	Leave space between name and * in types.
> 	Multiple * dont need additional space between them.
> 
> 	struct foo **bar;

unless you declare a fuction:

int*
function_style_for_easy_grep(...)
{
	...
}

I like this style because I can grep for ^function_style_for_easy_grep
and quickly find function def.

int
*function_style_for_easy_grep(...) ..

would make it harder.

> 3e. sizeof
> 	space after the operator
> 	sizeof a

I use sizeof(a) always (both for sizeof(type) and sizeof(expr)).

> 3i. if/else/do/while/for/switch
> 	space between if/else/do/while and following/preceeding
> 	statements/expressions, if any:
> 
> 	if (a) {
> 	} else {
> 	}
> 
> 	do {
> 	} while (b);

What's wrong with if(expr) ? Rationale?

> 4c. Breaking long lines
> 		Descendants are always substantially shorter than the parent
> 		and are placed substantially to the right.
> 			Documentation/CodingStyle
> 
> 	Descendant must be indented at least to the level of the innermost
> 	compound expression in the parent. All descendants at the same level
> 	are indented the same.
> 	if (foobar(.................................) + barbar * foobar(bar +
> 				     					foo *
> 									oof)) {
> 	}

Avoid this. If needed, use a temporary. Save a few brain cells of poor reader.
 
> 6. One-line statement does not need a {} block, so dont put it into one
> 	if (foo)
> 		bar;

Disagree. Common case of hard-to-notice bug:

	if(foo)
		bar()
...after some time code evolves into:
	if(foo)
		/*
		 * Wee need to barify it, or else pagecache gets foobar'ed
		 */
		bar();
...after some more time:
	if(foo)
		/*
		 * Wee need to barify it, or else pagecache gets foobar'ed.
		 * Also we need to bazify it.
		 */
		bar();
		baz();

Thus we may be better to slighty encourage use of {}s even if they are
not needed:

	if(foo) {
		bar();
	}
 
> 9a. Integer types
> 	Use unsigned long if you have to fit a pointer into integer.

This is a porting nightmare waiting to happen.
Why dont we have ptr_t instead? 

> 	long long is at least 64 bit wide on all platforms.

hugeint or hugeint_t

And also irqflags_t for spinlock_irqsave(&lock, flags),
jiffies_t for jiffies.
 
> 9b. typedef
> 	Using typedefs to hide the data type is generally discouraged.
> 	typedefs to function types are ok, since these can get very long.
> 
> typedef struct foo *(foo_bar_handler)(struct foo *first, struct bar *second,
> 				      struct foobar* thirsd);

? did you mean struct foo (*foo_bar_handler)(... or  struct foo* foo_bar_handler(...
--
vda


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-12  7:12 ` Denis Vlasenko
@ 2005-07-12 11:36   ` Domen Puncer
  0 siblings, 0 replies; 150+ messages in thread
From: Domen Puncer @ 2005-07-12 11:36 UTC (permalink / raw)
  To: Denis Vlasenko; +Cc: Michael S. Tsirkin, linux-kernel

On 12/07/05 10:12 +0300, Denis Vlasenko wrote:
> > 3c. * in types
> > 	Leave space between name and * in types.
> > 	Multiple * dont need additional space between them.
> > 
> > 	struct foo **bar;
> 
> unless you declare a fuction:
> 
> int*
> function_style_for_easy_grep(...)
> {
> 	...
> }
> 
> I like this style because I can grep for ^function_style_for_easy_grep
> and quickly find function def.
> 

That's a pretty bad argument, since most functions aren't declared
that way, and there are much better source code navigational tools,
like cscope and ctags.

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-12  6:52   ` Denis Vlasenko
@ 2005-07-12 11:55     ` Patrick McHardy
  2005-07-12 12:17       ` Richard B. Johnson
  0 siblings, 1 reply; 150+ messages in thread
From: Patrick McHardy @ 2005-07-12 11:55 UTC (permalink / raw)
  To: Denis Vlasenko; +Cc: sander, Michael S. Tsirkin, linux-kernel

Denis Vlasenko wrote:
> text with 8-char tabs:
> 
> struct s {
>         int n;          /* comment */
>         unsigned int u; /* comment */
> };
> 
> Same text viewed with tabs set to 4-char width:
> 
> struct s {
>     int n;      /* comment */
>     unsigned int u; /* comment */
> };
> 
> Comments are not aligned anymore

Best rule IMO is to use tabs for indentation and spaces for alignment.
This way tab size can be changed without breaking alignment.

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-12 11:55     ` Patrick McHardy
@ 2005-07-12 12:17       ` Richard B. Johnson
  2005-07-13  6:58         ` Paul Jackson
  0 siblings, 1 reply; 150+ messages in thread
From: Richard B. Johnson @ 2005-07-12 12:17 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: Denis Vlasenko, sander, Michael S. Tsirkin, linux-kernel

On Tue, 12 Jul 2005, Patrick McHardy wrote:

> Denis Vlasenko wrote:
>> text with 8-char tabs:
>>
>> struct s {
>>         int n;          /* comment */
>>         unsigned int u; /* comment */
>> };
>>
>> Same text viewed with tabs set to 4-char width:
>>
>> struct s {
>>     int n;      /* comment */
>>     unsigned int u; /* comment */
>> };
>>
>> Comments are not aligned anymore
>
> Best rule IMO is to use tabs for indentation and spaces for alignment.
> This way tab size can be changed without breaking alignment.

Or just disallow tabs altogether. At Analogic we had several hundred
thousand lines of imaging code from various engineers around the world.
They would set their tabs so everything looked fine on their computers.
On other computers, it looked like hell so engineers who had to
merge code spent hundreds of wasted hours lining up the code. The
"cleanup" work never stopped! That was until, we made a rule that
all code would be run through a filter that would remove tabs and
substitute spaces (of the width the writer intended). No code that
is released contains even a single tab anymode.

The files are larger of course, but even lap-tops have gigabyte
drives now-days and the duplicate spaces give compression utilities
something to do.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-12 12:17       ` Richard B. Johnson
@ 2005-07-13  6:58         ` Paul Jackson
  2005-07-13 17:22           ` Lee Revell
  0 siblings, 1 reply; 150+ messages in thread
From: Paul Jackson @ 2005-07-13  6:58 UTC (permalink / raw)
  To: linux-os; +Cc: kaber, vda, sander, mst, linux-kernel

Dick Johnson wrote:
> Or just disallow tabs altogether. At Analogic we ...

This is the Linux kernel, not Analogic.

We use tabs for indentation.  You can set the number
of physical spaces per tab however you want in your
editor, but it had better look good (and stay within
80 columns) when the rest of us use 8 spaces per tab.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-11 14:56 kernel guide to space Michael S. Tsirkin
                   ` (2 preceding siblings ...)
  2005-07-12  7:12 ` Denis Vlasenko
@ 2005-07-13  7:09 ` Paul Jackson
  2005-07-20 12:59 ` Jesper Juhl
  4 siblings, 0 replies; 150+ messages in thread
From: Paul Jackson @ 2005-07-13  7:09 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: linux-kernel

Nice work - thanks.

A couple of possible additions:

 * Keep lines within 80 columns.

 * Be consistent in use of tabs versus spaces.  If the
   rest of a file is indented using tabs, then any change
   you make should be indented the same way, not with
   spaces.  It is easy to unknowingly introduce spaces in
   a patch by cutting and pasting something in one of the
   many desktop UI environments that dont preserve tabs
   across a cut and paste.

 * See also Documentation/kernel-doc-nano-HOWTO.txt for
   formatting the documentation for external functions
   and data to work with the kernels DocBook automatically
   extractable documentation.

 * Multiline comments are shown as:

	/*
	 * This is a big comment.  It is full of sound
	 * and fury, signifying nothing. Now is the time
	 * for all good men to come to the aid of their
	 * country.
	 */

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-13  6:58         ` Paul Jackson
@ 2005-07-13 17:22           ` Lee Revell
  2005-07-13 17:52             ` Paul Jackson
  2005-07-13 23:38             ` Marc Singer
  0 siblings, 2 replies; 150+ messages in thread
From: Lee Revell @ 2005-07-13 17:22 UTC (permalink / raw)
  To: Paul Jackson; +Cc: linux-os, kaber, vda, sander, mst, linux-kernel

On Tue, 2005-07-12 at 23:58 -0700, Paul Jackson wrote:
> Dick Johnson wrote:
> > Or just disallow tabs altogether. At Analogic we ...
> 
> This is the Linux kernel, not Analogic.
> 
> We use tabs for indentation.  You can set the number
> of physical spaces per tab however you want in your
> editor, but it had better look good (and stay within
> 80 columns)

I don't think there's a strict 80 column rule anymore.  It's 2005...

Lee


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-13 17:22           ` Lee Revell
@ 2005-07-13 17:52             ` Paul Jackson
  2005-07-13 23:38             ` Marc Singer
  1 sibling, 0 replies; 150+ messages in thread
From: Paul Jackson @ 2005-07-13 17:52 UTC (permalink / raw)
  To: Lee Revell; +Cc: linux-os, kaber, vda, sander, mst, linux-kernel

Lee wrote:
> I don't think there's a strict 80 column rule anymore.  It's 2005...

Look back through the lkml archives.  One will find repeated requests
to keep code within 80 columns.  It maybe 2005, but this is the kernel.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-13 17:22           ` Lee Revell
  2005-07-13 17:52             ` Paul Jackson
@ 2005-07-13 23:38             ` Marc Singer
  1 sibling, 0 replies; 150+ messages in thread
From: Marc Singer @ 2005-07-13 23:38 UTC (permalink / raw)
  To: Lee Revell; +Cc: linux-kernel

On Wed, Jul 13, 2005 at 01:22:04PM -0400, Lee Revell wrote:
> On Tue, 2005-07-12 at 23:58 -0700, Paul Jackson wrote:
> > Dick Johnson wrote:
> > > Or just disallow tabs altogether. At Analogic we ...
> > 
> > This is the Linux kernel, not Analogic.
> > 
> > We use tabs for indentation.  You can set the number
> > of physical spaces per tab however you want in your
> > editor, but it had better look good (and stay within
> > 80 columns)
> 
> I don't think there's a strict 80 column rule anymore.  It's 2005...

Think again.  There are a lot of people who use 80 column windows so
that we can see two code windows side-by-side.


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-11 14:56 kernel guide to space Michael S. Tsirkin
                   ` (3 preceding siblings ...)
  2005-07-13  7:09 ` Paul Jackson
@ 2005-07-20 12:59 ` Jesper Juhl
  2005-07-20 13:07   ` Michael S. Tsirkin
                     ` (3 more replies)
  4 siblings, 4 replies; 150+ messages in thread
From: Jesper Juhl @ 2005-07-20 12:59 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: linux-kernel

On 7/11/05, Michael S. Tsirkin <mst@mellanox.co.il> wrote:
> 
[snip]
> kernel guide to space AKA a boring list of rules
> http://www.mellanox.com/mst/boring.txt
> 
[snip]
> 
> 3c. * in types
>         Leave space between name and * in types.
>         Multiple * dont need additional space between them.
> 
>         struct foo **bar;
> 
Don't put spaces between `*' and the name when declaring variables,
even if it's not a double pointer.   int * foo;  is ugly. Common
convention is  int *foo;

> 3e. sizeof
>         space after the operator
>         sizeof a
> 

I don't think that's a hard rule, there's plenty of code that does 
"sizeof(type)"  and not  "sizeof (type)", and whitespace cleanup
patches I've done that change "sizeof (type)" into "sizeof(type)" have
generally been accepted.

[snip]
> 
> 4. Indentation rules for C
>         Use tabs, not spaces, for indentation. Tabs should be 8 characters wide.
> 
A tab is a tab is a tab, how it's displayed is up to the editor
showing the file.


[snip]
> 
> static struct foo *foo_bar(struct foo *first, struct bar *second,
>                            struct foobar* thirsd);
> 
In this example you are not consistently placing your *'s, "struct foo
*first" vs "struct foobar* thirsd". Common practice is "struct foo
*first".


[snip]
> 
>         No more than one blank line in a row.
>         Last (or first) line in a file is never blank.
> 
Files should end with a  newline. gcc will even warn (with -pedantic)
if this is not so.

"line<nl>
 line"

is wrong,

"line<nl>
 line<nl>
"

is right.


> Non-whitespace issues:
> 
> 6. One-line statement does not need a {} block, so dont put it into one
>         if (foo)
>                 bar;
> 

Not always so, if `bar' is a macro adding {} may be safer. Also
sometimes adding {} improves readability, which is important.


> 7. Comments
>         Dont use C99 // comments.
> 

s/Dont/Don't/


> 9a. Integer types
>         int is the default integer type.
>         Use unsigned type if you perform bit operations (<<,>>,&,|,~).
>         Use unsigned long if you have to fit a pointer into integer.
>         long long is at least 64 bit wide on all platforms.
>         char is for ASCII characters and strings.
>         Use u8,u16,u32,u64 if you need an integer of a specific size.

u8,s8,u16,s16,u32,s32,u64,s64


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-20 12:59 ` Jesper Juhl
@ 2005-07-20 13:07   ` Michael S. Tsirkin
  2005-07-20 21:05   ` Paul Jackson
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 150+ messages in thread
From: Michael S. Tsirkin @ 2005-07-20 13:07 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: linux-kernel

Quoting r. Jesper Juhl <jesper.juhl@gmail.com>:
> > static struct foo *foo_bar(struct foo *first, struct bar *second,
> >                            struct foobar* thirsd);
> > 
> In this example you are not consistently placing your *'s, "struct foo
> *first" vs "struct foobar* thirsd". Common practice is "struct foo
> *first".

Doh. Right. Thanks!

-- 
MST

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-20 12:59 ` Jesper Juhl
  2005-07-20 13:07   ` Michael S. Tsirkin
@ 2005-07-20 21:05   ` Paul Jackson
  2005-07-20 22:37   ` Krzysztof Halasa
  2005-07-21  0:20   ` Horst von Brand
  3 siblings, 0 replies; 150+ messages in thread
From: Paul Jackson @ 2005-07-20 21:05 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: mst, linux-kernel

> > 3c. * in types
> >         Leave space between name and * in types.
> >         Multiple * dont need additional space between them.
> > 
> >         struct foo **bar;
> > 
> Don't put spaces between `*' and the name when declaring variables,
> even if it's not a double pointer.   int * foo;  is ugly. Common
> convention is  int *foo;


The "Leave space between name and *" is confusing.  Does 'name'
refer to the type or variable.  I hope Michael was not recommending:

	char * p;

How about saying:

	Do not leave a space between a * and the following
	variable name, nor between multiple *, when used
	to declare pointers:

		char *p;
		struct foo **bar;


-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-20 12:59 ` Jesper Juhl
  2005-07-20 13:07   ` Michael S. Tsirkin
  2005-07-20 21:05   ` Paul Jackson
@ 2005-07-20 22:37   ` Krzysztof Halasa
  2005-07-22 17:12     ` Patrick Draper
  2005-07-21  0:20   ` Horst von Brand
  3 siblings, 1 reply; 150+ messages in thread
From: Krzysztof Halasa @ 2005-07-20 22:37 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: Michael S. Tsirkin, linux-kernel

Jesper Juhl <jesper.juhl@gmail.com> writes:

> I don't think that's a hard rule, there's plenty of code that does 
> "sizeof(type)"  and not  "sizeof (type)", and whitespace cleanup
> patches I've done that change "sizeof (type)" into "sizeof(type)" have
> generally been accepted.

Sure, the common rule is that function names and alike (including "sizeof")
are not followed by a space. Statements such as "if", "while" etc. - are.
-- 
Krzysztof Halasa

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space 
  2005-07-20 12:59 ` Jesper Juhl
                     ` (2 preceding siblings ...)
  2005-07-20 22:37   ` Krzysztof Halasa
@ 2005-07-21  0:20   ` Horst von Brand
  3 siblings, 0 replies; 150+ messages in thread
From: Horst von Brand @ 2005-07-21  0:20 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: Michael S. Tsirkin, linux-kernel

Jesper Juhl <jesper.juhl@gmail.com> wrote:
> On 7/11/05, Michael S. Tsirkin <mst@mellanox.co.il> wrote:

> [snip]

> > 3e. sizeof
> >         space after the operator
> >         sizeof a

> I don't think that's a hard rule, there's plenty of code that does 
> "sizeof(type)"  and not  "sizeof (type)", and whitespace cleanup
> patches I've done that change "sizeof (type)" into "sizeof(type)" have
> generally been accepted.

It is necessary /not/ to put space between "function name" and '(', because
if it is a function-like macro, it does matter. For uniformity, do it for
functions and operations like sizeof too.

> [snip]
> > 
> > 4. Indentation rules for C
> >         Use tabs, not spaces, for indentation. Tabs should be 8 characters wide.

> A tab is a tab is a tab, how it's displayed is up to the editor
> showing the file.

But editing a file with tab==4 and editing it later with tab==8 guarantees
a mess.

[...]

> > 6. One-line statement does not need a {} block, so dont put it into one
> >         if (foo)
> >                 bar;

> Not always so, if `bar' is a macro adding {} may be safer.

Such macros are /very/ dangerous. That's one reason why multi-line macros
must be wrapped in "do { ... } while(0)"

>                                                            Also
> sometimes adding {} improves readability, which is important.

Or leaves an old C hand wondering what is going on...

> > 7. Comments
> >         Dont use C99 // comments.
> > 
> 
> s/Dont/Don't/
> 
> 
> > 9a. Integer types
> >         int is the default integer type.
> >         Use unsigned type if you perform bit operations (<<,>>,&,|,~).
> >         Use unsigned long if you have to fit a pointer into integer.
> >         long long is at least 64 bit wide on all platforms.
> >         char is for ASCII characters and strings.
> >         Use u8,u16,u32,u64 if you need an integer of a specific size.
> 
> u8,s8,u16,s16,u32,s32,u64,s64

Plus annotations for bitwise and such. See Documentation/sparse.txt
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-20 22:37   ` Krzysztof Halasa
@ 2005-07-22 17:12     ` Patrick Draper
  2005-07-22 17:51       ` Jesper Juhl
  2005-07-22 19:21       ` Sam Ravnborg
  0 siblings, 2 replies; 150+ messages in thread
From: Patrick Draper @ 2005-07-22 17:12 UTC (permalink / raw)
  To: linux-kernel

Why isn't a code formatting program used? People could write the code
as they like to write it, then format it automatically in a standard
way before it gets put into the kernel.

Patrick

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-22 17:12     ` Patrick Draper
@ 2005-07-22 17:51       ` Jesper Juhl
  2005-07-22 19:21       ` Sam Ravnborg
  1 sibling, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2005-07-22 17:51 UTC (permalink / raw)
  To: Patrick Draper; +Cc: linux-kernel

On 7/22/05, Patrick Draper <pdraper@gmail.com> wrote:
> Why isn't a code formatting program used? 

There's  scripts/Lindent  (which is just a wrapper around indent with
appropriate options.

>People could write the code
> as they like to write it, then format it automatically in a standard
> way before it gets put into the kernel.
> 
You can do some cleanup that way, but not everything, and then if
people continue to write in their own FunkyStyle locally but what's in
the kernel has been beautified they are going to have a hell of a time
creating proper patches...   It should just be cleaned up by whoever
submits it before it gets merged (and if you want to let a tool help
you out some of the way, then noone's stopping you).

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-22 17:12     ` Patrick Draper
  2005-07-22 17:51       ` Jesper Juhl
@ 2005-07-22 19:21       ` Sam Ravnborg
  2005-07-22 20:28         ` Jesper Juhl
  1 sibling, 1 reply; 150+ messages in thread
From: Sam Ravnborg @ 2005-07-22 19:21 UTC (permalink / raw)
  To: Patrick Draper; +Cc: linux-kernel

On Fri, Jul 22, 2005 at 12:12:12PM -0500, Patrick Draper wrote:
> Why isn't a code formatting program used? People could write the code
> as they like to write it, then format it automatically in a standard
> way before it gets put into the kernel.
There is.
scripts/Lindent

But sometimes it fails to do the job properly and some hand formatting
is needed. Also much of the kernel is not new stuff but expanding or
fixing old stuff.

	Sam

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: kernel guide to space
  2005-07-22 19:21       ` Sam Ravnborg
@ 2005-07-22 20:28         ` Jesper Juhl
  0 siblings, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2005-07-22 20:28 UTC (permalink / raw)
  To: Sam Ravnborg; +Cc: Patrick Draper, linux-kernel

On 7/22/05, Sam Ravnborg <sam@ravnborg.org> wrote:
> On Fri, Jul 22, 2005 at 12:12:12PM -0500, Patrick Draper wrote:
> > Why isn't a code formatting program used? People could write the code
> > as they like to write it, then format it automatically in a standard
> > way before it gets put into the kernel.
> There is.
> scripts/Lindent
> 
> But sometimes it fails to do the job properly and some hand formatting
> is needed. Also much of the kernel is not new stuff but expanding or
> fixing old stuff.
> 
Ehh, that's exactely why I wrote "You can do some cleanup that way,
but not everything..."

        Jesper

^ permalink raw reply	[flat|nested] 150+ messages in thread

* [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c
@ 2005-08-24 19:08 ` Jesper Juhl
  2005-08-24 20:12   ` Brian Gerst
                     ` (2 more replies)
  0 siblings, 3 replies; 150+ messages in thread
From: Jesper Juhl @ 2005-08-24 19:08 UTC (permalink / raw)
  To: linux-kernel; +Cc: jgarzik

Convert strtok() use to strsep() in usr/gen_init_cpio.c

I've compile tested this patch and it compiles fine.
I build a 2.6.13-rc6-mm2 kernel with the patch applied without problems, and
the resulting kernel boots and runs just fine (using it right now).
But despite this basic testing it would still be nice if someone would 
double-check that I haven't made some silly mistake that would break some 
other setup than mine.


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 gen_init_cpio.c |   31 ++++++++++++++++++++++---------
 1 files changed, 22 insertions(+), 9 deletions(-)

--- linux-2.6.13-rc6-mm2-orig/usr/gen_init_cpio.c	2005-06-17 21:48:29.000000000 +0200
+++ linux-2.6.13-rc6-mm2/usr/gen_init_cpio.c	2005-08-24 18:58:21.000000000 +0200
@@ -438,7 +438,7 @@ struct file_handler file_handler_table[]
 int main (int argc, char *argv[])
 {
 	FILE *cpio_list;
-	char line[LINE_SIZE];
+	char *line, *ln;
 	char *args, *type;
 	int ec = 0;
 	int line_nr = 0;
@@ -455,7 +455,14 @@ int main (int argc, char *argv[])
 		exit(1);
 	}
 
-	while (fgets(line, LINE_SIZE, cpio_list)) {
+	ln = malloc(LINE_SIZE);
+	if (!ln) {
+		fprintf(stderr,
+			"ERROR: unable to allocate %d bytes of buffer\n", LINE_SIZE);
+		exit(1);
+	}
+
+	while (line = ln, fgets(line, LINE_SIZE, cpio_list)) {
 		int type_idx;
 		size_t slen = strlen(line);
 
@@ -466,14 +473,15 @@ int main (int argc, char *argv[])
 			continue;
 		}
 
-		if (! (type = strtok(line, " \t"))) {
+		if (! (type = strsep(&line, " \t"))) {
 			fprintf(stderr,
 				"ERROR: incorrect format, could not locate file type line %d: '%s'\n",
-				line_nr, line);
+				line_nr, ln);
 			ec = -1;
+			continue;
 		}
 
-		if ('\n' == *type) {
+		if (!*type || '\n' == *type) {
 			/* a blank line */
 			continue;
 		}
@@ -483,16 +491,20 @@ int main (int argc, char *argv[])
 			continue;
 		}
 
-		if (! (args = strtok(NULL, "\n"))) {
+		if (! (args = strsep(&line, "\n"))) {
 			fprintf(stderr,
 				"ERROR: incorrect format, newline required line %d: '%s'\n",
-				line_nr, line);
+				line_nr, ln);
 			ec = -1;
+			continue;
 		}
+		
+		if (!*args)
+			continue;
 
 		for (type_idx = 0; file_handler_table[type_idx].type; type_idx++) {
 			int rc;
-			if (! strcmp(line, file_handler_table[type_idx].type)) {
+			if (! strcmp(type, file_handler_table[type_idx].type)) {
 				if ((rc = file_handler_table[type_idx].handler(args))) {
 					ec = rc;
 					fprintf(stderr, " line %d\n", line_nr);
@@ -503,9 +515,10 @@ int main (int argc, char *argv[])
 
 		if (NULL == file_handler_table[type_idx].type) {
 			fprintf(stderr, "unknown file type line %d: '%s'\n",
-				line_nr, line);
+				line_nr, ln);
 		}
 	}
+	free(ln);
 	cpio_trailer();
 
 	exit(ec);



^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c
  2005-08-24 19:08 ` [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c Jesper Juhl
@ 2005-08-24 20:12   ` Brian Gerst
  2005-08-24 20:14     ` Jeff Garzik
  2005-08-24 21:06   ` Horst von Brand
  2005-08-25  5:00   ` Sam Ravnborg
  2 siblings, 1 reply; 150+ messages in thread
From: Brian Gerst @ 2005-08-24 20:12 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: linux-kernel, jgarzik

Jesper Juhl wrote:
> Convert strtok() use to strsep() in usr/gen_init_cpio.c
> 
> I've compile tested this patch and it compiles fine.
> I build a 2.6.13-rc6-mm2 kernel with the patch applied without problems, and
> the resulting kernel boots and runs just fine (using it right now).
> But despite this basic testing it would still be nice if someone would 
> double-check that I haven't made some silly mistake that would break some 
> other setup than mine.
> 
> 
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> ---
> 
>  gen_init_cpio.c |   31 ++++++++++++++++++++++---------
>  1 files changed, 22 insertions(+), 9 deletions(-)
> 
> --- linux-2.6.13-rc6-mm2-orig/usr/gen_init_cpio.c	2005-06-17 21:48:29.000000000 +0200
> +++ linux-2.6.13-rc6-mm2/usr/gen_init_cpio.c	2005-08-24 18:58:21.000000000 +0200
> @@ -438,7 +438,7 @@ struct file_handler file_handler_table[]
>  int main (int argc, char *argv[])
>  {
>  	FILE *cpio_list;
> -	char line[LINE_SIZE];
> +	char *line, *ln;
>  	char *args, *type;
>  	int ec = 0;
>  	int line_nr = 0;
> @@ -455,7 +455,14 @@ int main (int argc, char *argv[])
>  		exit(1);
>  	}
>  
> -	while (fgets(line, LINE_SIZE, cpio_list)) {
> +	ln = malloc(LINE_SIZE);

Why change to malloc()?  This is a userspace program.  It doesn't have 
the kernel stack constraints.

--
				Brian Gerst

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c
  2005-08-24 20:12   ` Brian Gerst
@ 2005-08-24 20:14     ` Jeff Garzik
  2005-08-24 20:31       ` Jesper Juhl
  0 siblings, 1 reply; 150+ messages in thread
From: Jeff Garzik @ 2005-08-24 20:14 UTC (permalink / raw)
  To: Brian Gerst; +Cc: Jesper Juhl, linux-kernel

Brian Gerst wrote:
> Jesper Juhl wrote:
> 
>> Convert strtok() use to strsep() in usr/gen_init_cpio.c
>>
>> I've compile tested this patch and it compiles fine.
>> I build a 2.6.13-rc6-mm2 kernel with the patch applied without 
>> problems, and
>> the resulting kernel boots and runs just fine (using it right now).
>> But despite this basic testing it would still be nice if someone would 
>> double-check that I haven't made some silly mistake that would break 
>> some other setup than mine.
>>
>>
>> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
>> ---
>>
>>  gen_init_cpio.c |   31 ++++++++++++++++++++++---------
>>  1 files changed, 22 insertions(+), 9 deletions(-)
>>
>> --- linux-2.6.13-rc6-mm2-orig/usr/gen_init_cpio.c    2005-06-17 
>> 21:48:29.000000000 +0200
>> +++ linux-2.6.13-rc6-mm2/usr/gen_init_cpio.c    2005-08-24 
>> 18:58:21.000000000 +0200
>> @@ -438,7 +438,7 @@ struct file_handler file_handler_table[]
>>  int main (int argc, char *argv[])
>>  {
>>      FILE *cpio_list;
>> -    char line[LINE_SIZE];
>> +    char *line, *ln;
>>      char *args, *type;
>>      int ec = 0;
>>      int line_nr = 0;
>> @@ -455,7 +455,14 @@ int main (int argc, char *argv[])
>>          exit(1);
>>      }
>>  
>> -    while (fgets(line, LINE_SIZE, cpio_list)) {
>> +    ln = malloc(LINE_SIZE);
> 
> 
> Why change to malloc()?  This is a userspace program.  It doesn't have 
> the kernel stack constraints.

Good catch, agreed.

I prefer the code as-is, with LINE_SIZE stack allocations.

	Jeff




^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c
  2005-08-24 20:14     ` Jeff Garzik
@ 2005-08-24 20:31       ` Jesper Juhl
  2005-08-24 20:39         ` Brian Gerst
  0 siblings, 1 reply; 150+ messages in thread
From: Jesper Juhl @ 2005-08-24 20:31 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: Brian Gerst, linux-kernel

On 8/24/05, Jeff Garzik <jgarzik@pobox.com> wrote:
> Brian Gerst wrote:
> > Jesper Juhl wrote:
> >
> >> Convert strtok() use to strsep() in usr/gen_init_cpio.c
> >>
> >> I've compile tested this patch and it compiles fine.
> >> I build a 2.6.13-rc6-mm2 kernel with the patch applied without
> >> problems, and
> >> the resulting kernel boots and runs just fine (using it right now).
> >> But despite this basic testing it would still be nice if someone would
> >> double-check that I haven't made some silly mistake that would break
> >> some other setup than mine.
> >>
> >>
> >> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> >> ---
> >>
> >>  gen_init_cpio.c |   31 ++++++++++++++++++++++---------
> >>  1 files changed, 22 insertions(+), 9 deletions(-)
> >>
> >> --- linux-2.6.13-rc6-mm2-orig/usr/gen_init_cpio.c    2005-06-17
> >> 21:48:29.000000000 +0200
> >> +++ linux-2.6.13-rc6-mm2/usr/gen_init_cpio.c    2005-08-24
> >> 18:58:21.000000000 +0200
> >> @@ -438,7 +438,7 @@ struct file_handler file_handler_table[]
> >>  int main (int argc, char *argv[])
> >>  {
> >>      FILE *cpio_list;
> >> -    char line[LINE_SIZE];
> >> +    char *line, *ln;
> >>      char *args, *type;
> >>      int ec = 0;
> >>      int line_nr = 0;
> >> @@ -455,7 +455,14 @@ int main (int argc, char *argv[])
> >>          exit(1);
> >>      }
> >>
> >> -    while (fgets(line, LINE_SIZE, cpio_list)) {
> >> +    ln = malloc(LINE_SIZE);
> >
> >
> > Why change to malloc()?  This is a userspace program.  It doesn't have
> > the kernel stack constraints.
> 
> Good catch, agreed.
> 
> I prefer the code as-is, with LINE_SIZE stack allocations.
> 
The reason I did it like that was that strsep takes offense at
strsep(&line, ...) when line is allocated on the stack. So I just
changed it around to being malloc()'ed and things were good.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c
  2005-08-24 20:31       ` Jesper Juhl
@ 2005-08-24 20:39         ` Brian Gerst
  2005-08-24 21:14           ` Jesper Juhl
  0 siblings, 1 reply; 150+ messages in thread
From: Brian Gerst @ 2005-08-24 20:39 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: Jeff Garzik, linux-kernel

Jesper Juhl wrote:
> On 8/24/05, Jeff Garzik <jgarzik@pobox.com> wrote:
> 
>>Brian Gerst wrote:
>>
>>>Jesper Juhl wrote:
>>>
>>>
>>>>Convert strtok() use to strsep() in usr/gen_init_cpio.c
>>>>
>>>>I've compile tested this patch and it compiles fine.
>>>>I build a 2.6.13-rc6-mm2 kernel with the patch applied without
>>>>problems, and
>>>>the resulting kernel boots and runs just fine (using it right now).
>>>>But despite this basic testing it would still be nice if someone would
>>>>double-check that I haven't made some silly mistake that would break
>>>>some other setup than mine.
>>>>
>>>>
>>>>Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
>>>>---
>>>>
>>>> gen_init_cpio.c |   31 ++++++++++++++++++++++---------
>>>> 1 files changed, 22 insertions(+), 9 deletions(-)
>>>>
>>>>--- linux-2.6.13-rc6-mm2-orig/usr/gen_init_cpio.c    2005-06-17
>>>>21:48:29.000000000 +0200
>>>>+++ linux-2.6.13-rc6-mm2/usr/gen_init_cpio.c    2005-08-24
>>>>18:58:21.000000000 +0200
>>>>@@ -438,7 +438,7 @@ struct file_handler file_handler_table[]
>>>> int main (int argc, char *argv[])
>>>> {
>>>>     FILE *cpio_list;
>>>>-    char line[LINE_SIZE];
>>>>+    char *line, *ln;
>>>>     char *args, *type;
>>>>     int ec = 0;
>>>>     int line_nr = 0;
>>>>@@ -455,7 +455,14 @@ int main (int argc, char *argv[])
>>>>         exit(1);
>>>>     }
>>>>
>>>>-    while (fgets(line, LINE_SIZE, cpio_list)) {
>>>>+    ln = malloc(LINE_SIZE);
>>>
>>>
>>>Why change to malloc()?  This is a userspace program.  It doesn't have
>>>the kernel stack constraints.
>>
>>Good catch, agreed.
>>
>>I prefer the code as-is, with LINE_SIZE stack allocations.
>>
> 
> The reason I did it like that was that strsep takes offense at
> strsep(&line, ...) when line is allocated on the stack. So I just
> changed it around to being malloc()'ed and things were good.
> 

Do this instead:
	char ln[LINE_SIZE], *line;

--
				Brian Gerst

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c 
  2005-08-24 19:08 ` [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c Jesper Juhl
  2005-08-24 20:12   ` Brian Gerst
@ 2005-08-24 21:06   ` Horst von Brand
  2005-08-24 21:15     ` Jesper Juhl
  2005-08-25  4:46     ` Paul Jackson
  2005-08-25  5:00   ` Sam Ravnborg
  2 siblings, 2 replies; 150+ messages in thread
From: Horst von Brand @ 2005-08-24 21:06 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: linux-kernel, jgarzik

Jesper Juhl <jesper.juhl@gmail.com> wrote:
> Convert strtok() use to strsep() in usr/gen_init_cpio.c

This is userland code...

No, I'm not looking it over carfully, just a fast look over.

> I've compile tested this patch and it compiles fine.

You should be able ti test it then.

> I build a 2.6.13-rc6-mm2 kernel with the patch applied without problems, and
> the resulting kernel boots and runs just fine (using it right now).
> But despite this basic testing it would still be nice if someone would 
> double-check that I haven't made some silly mistake that would break some 
> other setup than mine.
> 
> 
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> ---
> 
>  gen_init_cpio.c |   31 ++++++++++++++++++++++---------
>  1 files changed, 22 insertions(+), 9 deletions(-)
> 
> --- linux-2.6.13-rc6-mm2-orig/usr/gen_init_cpio.c	2005-06-17 21:48:29.000000000 +0200
> +++ linux-2.6.13-rc6-mm2/usr/gen_init_cpio.c	2005-08-24 18:58:21.000000000 +0200
> @@ -438,7 +438,7 @@ struct file_handler file_handler_table[]
>  int main (int argc, char *argv[])
>  {
>  	FILE *cpio_list;
> -	char line[LINE_SIZE];
> +	char *line, *ln;

No need for this, there is no particular stack frugality requirement with
user code.

>  	char *args, *type;
>  	int ec = 0;
>  	int line_nr = 0;
> @@ -455,7 +455,14 @@ int main (int argc, char *argv[])
>  		exit(1);
>  	}
>  
> -	while (fgets(line, LINE_SIZE, cpio_list)) {
> +	ln = malloc(LINE_SIZE);

Ditto.

[...]

> -		if ('\n' == *type) {
> +		if (!*type || '\n' == *type) {

Redundant. If *type == '\n', it is certainly != 0.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c
  2005-08-24 20:39         ` Brian Gerst
@ 2005-08-24 21:14           ` Jesper Juhl
  2005-08-26 15:31             ` Horst von Brand
  0 siblings, 1 reply; 150+ messages in thread
From: Jesper Juhl @ 2005-08-24 21:14 UTC (permalink / raw)
  To: Brian Gerst; +Cc: Jeff Garzik, linux-kernel, Horst von Brand

On Wednesday 24 August 2005 22:39, Brian Gerst wrote:
> 
> Do this instead:
> 	char ln[LINE_SIZE], *line;
> 
Right, now why didn't I think of that :)

Jeff: Does the patch below agree with you more?


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 usr/gen_init_cpio.c |   22 ++++++++++++++--------
 1 files changed, 14 insertions(+), 8 deletions(-)
 
 --- linux-2.6.13-rc6-mm2-orig/usr/gen_init_cpio.c	2005-06-17 21:48:29.000000000 +0200
+++ linux-2.6.13-rc6-mm2/usr/gen_init_cpio.c	2005-08-24 23:10:36.000000000 +0200
@@ -438,7 +438,8 @@ struct file_handler file_handler_table[]
 int main (int argc, char *argv[])
 {
 	FILE *cpio_list;
-	char line[LINE_SIZE];
+	char ln[LINE_SIZE];
+	char *line;
 	char *args, *type;
 	int ec = 0;
 	int line_nr = 0;
@@ -455,7 +456,7 @@ int main (int argc, char *argv[])
 		exit(1);
 	}
 
-	while (fgets(line, LINE_SIZE, cpio_list)) {
+	while (line = ln, fgets(line, LINE_SIZE, cpio_list)) {
 		int type_idx;
 		size_t slen = strlen(line);
 
@@ -466,11 +467,12 @@ int main (int argc, char *argv[])
 			continue;
 		}
 
-		if (! (type = strtok(line, " \t"))) {
+		if (! (type = strsep(&line, " \t"))) {
 			fprintf(stderr,
 				"ERROR: incorrect format, could not locate file type line %d: '%s'\n",
-				line_nr, line);
+				line_nr, ln);
 			ec = -1;
+			continue;
 		}
 
 		if ('\n' == *type) {
@@ -483,16 +485,20 @@ int main (int argc, char *argv[])
 			continue;
 		}
 
-		if (! (args = strtok(NULL, "\n"))) {
+		if (! (args = strsep(&line, "\n"))) {
 			fprintf(stderr,
 				"ERROR: incorrect format, newline required line %d: '%s'\n",
-				line_nr, line);
+				line_nr, ln);
 			ec = -1;
+			continue;
 		}
+		
+		if (!*args)
+			continue;
 
 		for (type_idx = 0; file_handler_table[type_idx].type; type_idx++) {
 			int rc;
-			if (! strcmp(line, file_handler_table[type_idx].type)) {
+			if (! strcmp(type, file_handler_table[type_idx].type)) {
 				if ((rc = file_handler_table[type_idx].handler(args))) {
 					ec = rc;
 					fprintf(stderr, " line %d\n", line_nr);
@@ -503,7 +509,7 @@ int main (int argc, char *argv[])
 
 		if (NULL == file_handler_table[type_idx].type) {
 			fprintf(stderr, "unknown file type line %d: '%s'\n",
-				line_nr, line);
+				line_nr, ln);
 		}
 	}
 	cpio_trailer();

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c
  2005-08-24 21:06   ` Horst von Brand
@ 2005-08-24 21:15     ` Jesper Juhl
  2005-08-25  4:46     ` Paul Jackson
  1 sibling, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2005-08-24 21:15 UTC (permalink / raw)
  To: Horst von Brand; +Cc: linux-kernel, jgarzik

On 8/24/05, Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> Jesper Juhl <jesper.juhl@gmail.com> wrote:
[snip]
> 
> > -             if ('\n' == *type) {
> > +             if (!*type || '\n' == *type) {
> 
> Redundant. If *type == '\n', it is certainly != 0.

Hmm, I added that since if we get past the if above it, then "type"
might be !=NULL, but *type might be, but you are right, it's still
redundant since there's a check below that'll catch it if so.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c
  2005-08-24 21:06   ` Horst von Brand
  2005-08-24 21:15     ` Jesper Juhl
@ 2005-08-25  4:46     ` Paul Jackson
  1 sibling, 0 replies; 150+ messages in thread
From: Paul Jackson @ 2005-08-25  4:46 UTC (permalink / raw)
  To: Horst von Brand; +Cc: jesper.juhl, linux-kernel, jgarzik

Horst wrote:
> > -		if ('\n' == *type) {
> > +		if (!*type || '\n' == *type) {
> 
> Redundant. If *type == '\n', it is certainly != 0.

No - I don't think redundant, at least not this change in isolation.
Perhaps redundant in light of subsequent code lines, as Jesper notes in
his followup.

But it is confusing to read - poor and inconsistent choice of code
phrasing.

If the patch had read as:
    -		if (*type == '\n') {
    +		if (*type == '\n' || *type == '\0') {

then it would be clearer to the reader in my view.  A check for newline
is changed to a check for newline or nul-byte.

(Yes - I recognize that one is not given the freedom to change the
-old- lines in a patch for the sake of clarity ;).

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c
  2005-08-24 19:08 ` [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c Jesper Juhl
  2005-08-24 20:12   ` Brian Gerst
  2005-08-24 21:06   ` Horst von Brand
@ 2005-08-25  5:00   ` Sam Ravnborg
  2 siblings, 0 replies; 150+ messages in thread
From: Sam Ravnborg @ 2005-08-25  5:00 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: linux-kernel, jgarzik

On Wed, Aug 24, 2005 at 09:08:53PM +0200, Jesper Juhl wrote:
> Convert strtok() use to strsep() in usr/gen_init_cpio.c
> 
> I've compile tested this patch and it compiles fine.
> I build a 2.6.13-rc6-mm2 kernel with the patch applied without problems, and
> the resulting kernel boots and runs just fine (using it right now).
> But despite this basic testing it would still be nice if someone would 
> double-check that I haven't made some silly mistake that would break some 
> other setup than mine.
This is userland - I see no point in uglyfying the code.

	Sam

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c 
  2005-08-24 21:14           ` Jesper Juhl
@ 2005-08-26 15:31             ` Horst von Brand
  0 siblings, 0 replies; 150+ messages in thread
From: Horst von Brand @ 2005-08-26 15:31 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: Brian Gerst, Jeff Garzik, linux-kernel, Horst von Brand

Jesper Juhl <jesper.juhl@gmail.com> wrote:
> On Wednesday 24 August 2005 22:39, Brian Gerst wrote:
> > 
> > Do this instead:
> > 	char ln[LINE_SIZE], *line;
> > 
> Right, now why didn't I think of that :)
> 
> Jeff: Does the patch below agree with you more?
> 
> 
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> ---
> 
>  usr/gen_init_cpio.c |   22 ++++++++++++++--------
>  1 files changed, 14 insertions(+), 8 deletions(-)
>  
>  --- linux-2.6.13-rc6-mm2-orig/usr/gen_init_cpio.c	2005-06-17 21:48:29.000000000 +0200
> +++ linux-2.6.13-rc6-mm2/usr/gen_init_cpio.c	2005-08-24 23:10:36.000000000 +0200
> @@ -438,7 +438,8 @@ struct file_handler file_handler_table[]
>  int main (int argc, char *argv[])
>  {
>  	FILE *cpio_list;
> -	char line[LINE_SIZE];
> +	char ln[LINE_SIZE];
> +	char *line;
>  	char *args, *type;
>  	int ec = 0;
>  	int line_nr = 0;
> @@ -455,7 +456,7 @@ int main (int argc, char *argv[])
>  		exit(1);
>  	}
>  
> -	while (fgets(line, LINE_SIZE, cpio_list)) {
> +	while (line = ln, fgets(line, LINE_SIZE, cpio_list)) {
>  		int type_idx;
>  		size_t slen = strlen(line);

The ',' in the while() isn't exactly readable... first order of bussiness
inside:

	while (fgets(line, LINE_SIZE, cpio_list)) {
	while (fgets(ln, LINE_SIZE, cpio_list)) {
		int type_idx;
		size_t slen = strlen(ln);

		line = ln;

Or just use the fact that fgets(3) returns the buffer if no error:

	while(line = fgets(ln, LINE_SIZE, cpio_list)) {

(yes, gcc will complain... wrap in () to shut it up)
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
  2005-09-04 10:12 [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver Harald Welte
@ 2005-09-03 21:27 ` Chase Venters
  2005-09-03 22:13   ` Nish Aravamudan
  2005-09-04 11:20   ` Harald Welte
  2005-09-03 21:56 ` Alexey Dobriyan
                   ` (2 subsequent siblings)
  3 siblings, 2 replies; 150+ messages in thread
From: Chase Venters @ 2005-09-03 21:27 UTC (permalink / raw)
  To: Harald Welte; +Cc: linux-kernel

> Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> Smartcard Reader.

Someone correct me if I'm wrong, but wouldn't these #defines be a problem with 
the new HZ flexibility:

#define	CCID_DRIVER_BULK_DEFAULT_TIMEOUT  	(150*HZ)
#define	CCID_DRIVER_ASYNC_POWERUP_TIMEOUT 	(35*HZ)
#define	CCID_DRIVER_MINIMUM_TIMEOUT 		(3*HZ)
#define READ_WRITE_BUFFER_SIZE 512
#define POLL_LOOP_COUNT				1000

/* how often to poll for fifo status change */
#define POLL_PERIOD 				(HZ/100)

In particular, 2.6.13 allows a HZ of 100, which would define POLL_PERIOD to 0. 
Your later calls to mod_timer would be setting cmx_poll_timer to the current 
value of jiffies. 

Also, you've got a typo in the comments:

* 	- adhere to linux kenrel coding style and policies

Forgive me if I'm way off - I'm just now getting my feet wet in kernel 
development. Just making comments based on what I (think) I know at this 
point.

Best Regards,
Chase Venters

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
  2005-09-04 10:12 [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver Harald Welte
  2005-09-03 21:27 ` Chase Venters
@ 2005-09-03 21:56 ` Alexey Dobriyan
  2005-09-04  7:10   ` Harald Welte
  2005-09-04 11:08 ` Harald Welte
  2005-09-04 12:58 ` Ingo Oeser
  3 siblings, 1 reply; 150+ messages in thread
From: Alexey Dobriyan @ 2005-09-03 21:56 UTC (permalink / raw)
  To: Harald Welte; +Cc: linux-kernel

On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote:
> Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> Smartcard Reader.  

> --- /dev/null
> +++ b/drivers/char/pcmcia/cm4040_cs.c

> +#include <linux/config.h>

Not needed.

> +static volatile char *version =

Can we lose all volatile and register keywords?

> +typedef struct reader_dev_t {
> +	dev_link_t		link;		
> +	dev_node_t		node;		
> +	wait_queue_head_t	devq;	
> +
> +	wait_queue_head_t	poll_wait;
> +	wait_queue_head_t	read_wait;
> +	wait_queue_head_t	write_wait;
> +
> +	unsigned int 	  	buffer_status;
> +                                
> +	unsigned int      	fTimerExpired;
> +	struct timer_list	timer;
> +	unsigned long     	timeout;
> +	unsigned char     	sBuf[READ_WRITE_BUFFER_SIZE];
> +	unsigned char     	rBuf[READ_WRITE_BUFFER_SIZE];
> +	struct task_struct 	*owner;	
> +} reader_dev_t;

And typedefs too.

	struct reader_dev {
	
	};

> +static ssize_t cmx_read(struct file *filp,char *buf,size_t count,loff_t *ppos)

char __user *buf

> +	ulBytesToRead = 5 + 
> +			(0x000000FF&((char)dev->rBuf[1])) + 
> +			(0x0000FF00&((char)dev->rBuf[2] << 8)) + 
> +			(0x00FF0000&((char)dev->rBuf[3] << 16)) + 
> +			(0xFF000000&((char)dev->rBuf[4] << 24));

	ulBytesToRead = 5 + le32_to_cpu(*(__le32 *)&dev->rBuf[1]);

> +	ulMin = (count < (ulBytesToRead+5))?count:(ulBytesToRead+5);

	ulMin = min(count, ulBytesToRead + 5);

> +	copy_to_user(buf, dev->rBuf, ulMin);

Can fail.

> +static ssize_t cmx_write(struct file *filp,const char *buf,size_t count,

const char __user *buf

> +			 loff_t *ppos)

> +	copy_from_user(dev->sBuf, buf, uiBytesToWrite);

Can fail.

> +static int cmx_ioctl(struct inode *inode,struct file *filp,unsigned int cmd,
> +			unsigned long arg)
> +{
> +	dev_link_t *link;
> +	int rc, size;
> +
> +	link=dev_table[MINOR(inode->i_rdev)];
> +	if (!(DEV_OK(link))) {
> +		DEBUG(4, "DEV_OK false\n");
> +		return -ENODEV;
> +	}
> +	if (_IOC_TYPE(cmd)!=CM_IOC_MAGIC) {
> +		DEBUG(4,"ioctype mismatch\n");
> +		return -EINVAL;
> +	}
> +	if (_IOC_NR(cmd)>CM_IOC_MAXNR) {
> +		DEBUG(4,"iocnr mismatch\n");
> +		return -EINVAL;
> +	} 
> +	size = _IOC_SIZE(cmd);
> +	rc = 0;
> +	DEBUG(4,"iocdir=%.4x iocr=%.4x iocw=%.4x iocsize=%d cmd=%.4x\n",
> +		_IOC_DIR(cmd),_IOC_READ,_IOC_WRITE,size,cmd);
> +
> +	if (_IOC_DIR(cmd)&_IOC_READ) {
> +		if (!access_ok(VERIFY_WRITE, (void *)arg, size))
> +			return -EFAULT;
> +	}
> +	if (_IOC_DIR(cmd)&_IOC_WRITE) {
> +		if (!access_ok(VERIFY_READ, (void *)arg, size))
> +			return -EFAULT;
> +	}
> +
> +	return rc;
> +}

Whoo, empty ioctl handler.

> +static void reader_release(u_long arg)

> +	link = (dev_link_t *)arg;

You do

	reader_release((unsigned long)link);

somewhere above and below.

> +static void reader_detach_by_devno(int devno,dev_link_t *link)

> +		reader_release((u_long)link);

Like this.


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
  2005-09-03 21:27 ` Chase Venters
@ 2005-09-03 22:13   ` Nish Aravamudan
  2005-09-03 22:23     ` Chase Venters
  2005-09-04  7:33     ` Harald Welte
  2005-09-04 11:20   ` Harald Welte
  1 sibling, 2 replies; 150+ messages in thread
From: Nish Aravamudan @ 2005-09-03 22:13 UTC (permalink / raw)
  To: Chase Venters; +Cc: Harald Welte, linux-kernel

On 9/3/05, Chase Venters <chase.venters@clientec.com> wrote:
> > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> > Smartcard Reader.
> 
> Someone correct me if I'm wrong, but wouldn't these #defines be a problem 
> with the new HZ flexibility:
> 
> #define CCID_DRIVER_BULK_DEFAULT_TIMEOUT        (150*HZ)
> #define CCID_DRIVER_ASYNC_POWERUP_TIMEOUT       (35*HZ)
> #define CCID_DRIVER_MINIMUM_TIMEOUT             (3*HZ)
> #define READ_WRITE_BUFFER_SIZE 512
> #define POLL_LOOP_COUNT                         1000

These are all fine. Although I am a bit suspicious of 150 second
timeouts; but if that is the hardware...

> /* how often to poll for fifo status change */
> #define POLL_PERIOD                             (HZ/100)

This needs to be msecs_to_jiffies(10), please.

> In particular, 2.6.13 allows a HZ of 100, which would define POLL_PERIOD to 0.

Um, 100/100 = 1, not 0?

> Your later calls to mod_timer would be setting cmx_poll_timer to the current
> value of jiffies.

Which is technically ok, because HZ=100, a
     jiffies + 0
or
     jiffies + 1
timeout request will both result in the soft-timer being expired at
the *next* timer interrupt. Regardless, you're right, and
msecs_to_jiffies() will cover it.

> Also, you've got a typo in the comments:
> 
> *       - adhere to linux kenrel coding style and policies
> 
> Forgive me if I'm way off - I'm just now getting my feet wet in kernel
> development. Just making comments based on what I (think) I know at this
> point.

Of bigger concern to me is the use of the sleep_on() family of
functions, all of which are deprecated.

Thanks,
Nish

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
  2005-09-03 22:13   ` Nish Aravamudan
@ 2005-09-03 22:23     ` Chase Venters
  2005-09-04  7:33     ` Harald Welte
  1 sibling, 0 replies; 150+ messages in thread
From: Chase Venters @ 2005-09-03 22:23 UTC (permalink / raw)
  To: nish.aravamudan; +Cc: linux-kernel

> Um, 100/100 = 1, not 0?

Oh my... it's been a long day. 

Regards,
Chase Venters

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
  2005-09-04 11:08 ` Harald Welte
@ 2005-09-03 22:27   ` Jesper Juhl
  2005-09-04 21:06     ` Horst von Brand
  2005-09-05 10:30     ` Harald Welte
  0 siblings, 2 replies; 150+ messages in thread
From: Jesper Juhl @ 2005-09-03 22:27 UTC (permalink / raw)
  To: Harald Welte; +Cc: Linux Kernel Mailinglist

On 9/4/05, Harald Welte <laforge@gnumonks.org> wrote:
> On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote:
> > Hi!
> >
> > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> > Smartcard Reader.
> 
> Sorry, the patch was missing a "cg-add" of the header file.  Please use
> the patch below.

It would be so much nicer if the patch actually was "below" - that is
"inline in the email as opposed to as an attachment". Having to first
save an attachment and then cut'n'paste from it is a pain.

Anyway, a few comments below :

+#define DEBUG(n, x, args...) do { if (pc_debug >= (n)) 			    \


line longer than 80 chars. Please adhere to CodingStyle and keep lines
<80 chars.
There's more than one occourance of this.

+static inline int cmx_waitForBulkOutReady(reader_dev_t *dev)


Why TheStudlyCaps ?  Please keep function names lowercase. There are
more instances of this, only pointing out one.

+        register int i;

+	register int iobase = dev->link.io.BasePort1;


Please use only tabs for indentation (line 1 of the above is indented
with spaces).

+	for (i=0; i < POLL_LOOP_COUNT; i++) {


for (i = 0; i < POLL_LOOP_COUNT; i++) {

+        if (rc != 1)


Again spaces used for indentation, please fix all that up to use tabs.

+	unsigned long ulBytesToRead;


lowercase prefered also for variables.

+	for (i=0; i<5; i++) {


for (i = 0; i < 5; i++) {

+			DEBUG(5,"cmx_waitForBulkInReady rc=%.2x\n",rc);


Space after ","s please : DEBUG(5, "cmx_waitForBulkInReady rc=%.2x\n", rc);

+	ulMin = (count < (ulBytesToRead+5))?count:(ulBytesToRead+5);


needs spaces : 
ulMin = (count < (ulBytesToRead + 5)) ? count : (ulBytesToRead + 5);

+	reader_dev_t *dev=(reader_dev_t *)filp->private_data;


reader_dev_t *dev = (reader_dev_t *)filp->private_data;


+static int cmx_open (struct inode *inode, struct file *filp)


get rid of the space before the opening paren : 
static int cmx_open(struct inode *inode, struct file *filp)


+	for (rc = pcmcia_get_first_tuple(handle, &tuple);

+	     rc == CS_SUCCESS;

+	     rc = pcmcia_get_next_tuple(handle, &tuple)) {

...
+		if (parse.cftable_entry.io.nwin) {

+			link->io.BasePort1 = parse.cftable_entry.io.win[0].base;

+			link->io.NumPorts1 = parse.cftable_entry.io.win[0].len;

+			link->io.Attributes1 = IO_DATA_PATH_WIDTH_AUTO;

+			if(!(parse.cftable_entry.io.flags & CISTPL_IO_8BIT))

+				link->io.Attributes1 = IO_DATA_PATH_WIDTH_16;

...
+		}
+	}

How about not having to indent so deep by rewriting that as

	for (rc = pcmcia_get_first_tuple(handle, &tuple);
	     rc == CS_SUCCESS;
	     rc = pcmcia_get_next_tuple(handle, &tuple)) {
...
		if (!parse.cftable_entry.io.nwin)
			continue;

		link->io.BasePort1 = parse.cftable_entry.io.win[0].base;
		link->io.NumPorts1 = parse.cftable_entry.io.win[0].len;
		link->io.Attributes1 = IO_DATA_PATH_WIDTH_AUTO;
		if(!(parse.cftable_entry.io.flags & CISTPL_IO_8BIT))
			link->io.Attributes1 = IO_DATA_PATH_WIDTH_16;
...
	}


+        link->conf.IntType = 00000002;


more spaces used for indentation. Not going to point out any more of these.

+	cmx_poll_timer.function = &cmx_do_poll;


shouldn't this be 
	 cmx_poll_timer.function = cmx_do_poll;
???

+	int i;

+	DEBUG(3, "-> reader_detach(link=%p\n", link);


please have a blank line between variable declarations and other statements.



-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
  2005-09-03 21:56 ` Alexey Dobriyan
@ 2005-09-04  7:10   ` Harald Welte
  0 siblings, 0 replies; 150+ messages in thread
From: Harald Welte @ 2005-09-04  7:10 UTC (permalink / raw)
  To: Alexey Dobriyan; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

Thanks for your comments, Alexey.

I've now incorprorated all of the requested changes and am testing the
driver.  If everything is still  fine, I'll repost later today.

-- 
- Harald Welte <laforge@gnumonks.org>          	        http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
  2005-09-03 22:13   ` Nish Aravamudan
  2005-09-03 22:23     ` Chase Venters
@ 2005-09-04  7:33     ` Harald Welte
  1 sibling, 0 replies; 150+ messages in thread
From: Harald Welte @ 2005-09-04  7:33 UTC (permalink / raw)
  To: Nish Aravamudan; +Cc: Chase Venters, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

Hi Nish, 

thanks for your comments.

On Sat, Sep 03, 2005 at 03:13:43PM -0700, Nish Aravamudan wrote:
> On 9/3/05, Chase Venters <chase.venters@clientec.com> wrote:
> > > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> > > Smartcard Reader.
> > 
> > #define CCID_DRIVER_BULK_DEFAULT_TIMEOUT        (150*HZ)
> 
> These are all fine. Although I am a bit suspicious of 150 second
> timeouts; but if that is the hardware...

That's a definition from the original vendor-supplied driver.
Unfortunately there's no hardware documentation, so I can't verify it.
But generally speaking, serial smart cards can really be slow, so I
think it could make sense.

> > /* how often to poll for fifo status change */
> > #define POLL_PERIOD                             (HZ/100)
> 
> This needs to be msecs_to_jiffies(10), please.

thanks, changed in my local tree now.

> Of bigger concern to me is the use of the sleep_on() family of
> functions, all of which are deprecated.

Ok, I'm working on replacing the respective code with
wait_event_interruptible_timeout().

-- 
- Harald Welte <laforge@gnumonks.org>          	        http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 150+ messages in thread

* [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
@ 2005-09-04 10:12 Harald Welte
  2005-09-03 21:27 ` Chase Venters
                   ` (3 more replies)
  0 siblings, 4 replies; 150+ messages in thread
From: Harald Welte @ 2005-09-04 10:12 UTC (permalink / raw)
  To: Linux Kernel Mailinglist


[-- Attachment #1.1: Type: text/plain, Size: 815 bytes --]

Hi!

Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
Smartcard Reader.  

It's based on some source code originally made available by the vendor
(as BSD/GPL dual licensed code), but has undergone significant changes
to make it more compliant with the general kernel community coding
practise.

As this is the first PCMCIA driver that I'm involved in, please let me
know if I missed something.

If there are no objections, I'd like to see it included in mainline.
Thanks!

-- 
- Harald Welte <laforge@gnumonks.org>          	        http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

[-- Attachment #1.2: cm4040-driver.patch --]
[-- Type: text/plain, Size: 25952 bytes --]

Omnikey CardMan 4040 PCMCIA Smartcard reader driver

Signed-off-by: Harald Welte <laforge@netfilter.org>

---
commit 04ec3ca3e3c6fd6d88c508b6ebe32726ef109367
tree e27a5ccafbcebda6ebfe90036016f0e76dd93137
parent c4ab879b6ef599bf88d19b9b145878ef73400ce7
author Harald Welte <laforge@netfilter.org> So, 04 Sep 2005 11:59:37 +0200
committer Harald Welte <laforge@netfilter.org> So, 04 Sep 2005 11:59:37 +0200

 MAINTAINERS                     |    5 
 drivers/char/pcmcia/Kconfig     |   13 +
 drivers/char/pcmcia/Makefile    |    1 
 drivers/char/pcmcia/cm4040_cs.c |  900 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 919 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1737,6 +1737,11 @@ L:	linux-tr@linuxtr.net
 W:	http://www.linuxtr.net
 S:	Maintained
 
+OMNIKEY CARDMAN 4040 DRIVER
+P:	Harald Welte
+M:	laforge@gnumonks.org
+S:	Maintained
+
 ONSTREAM SCSI TAPE DRIVER
 P:	Willem Riede
 M:	osst@riede.org
diff --git a/drivers/char/pcmcia/Kconfig b/drivers/char/pcmcia/Kconfig
--- a/drivers/char/pcmcia/Kconfig
+++ b/drivers/char/pcmcia/Kconfig
@@ -18,5 +18,18 @@ config SYNCLINK_CS
 	  The module will be called synclinkmp.  If you want to do that, say M
 	  here.
 
+config CARDMAN_4040
+	tristate "Omnikey CardMan 4040 support"
+	depends on PCMCIA
+	help
+	  Enable support for the Omnikey CardMan 4040 PCMCIA Smartcard
+	  reader.
+	  
+	  This card is basically a USB CCID device connected to a FIFO
+	  in I/O space.  To use the kernel driver, you will need either the
+	  PC/SC ifdhandler provided from the Omnikey homepage
+	  (http://www.omnikey.com/), or a current development version of OpenCT
+	  (http://www.opensc.org/).
+
 endmenu
 
diff --git a/drivers/char/pcmcia/Makefile b/drivers/char/pcmcia/Makefile
--- a/drivers/char/pcmcia/Makefile
+++ b/drivers/char/pcmcia/Makefile
@@ -5,3 +5,4 @@
 #
 
 obj-$(CONFIG_SYNCLINK_CS) += synclink_cs.o
+obj-$(CONFIG_CARDMAN_4040) += cm4040_cs.o
diff --git a/drivers/char/pcmcia/cm4040_cs.c b/drivers/char/pcmcia/cm4040_cs.c
new file mode 100644
--- /dev/null
+++ b/drivers/char/pcmcia/cm4040_cs.c
@@ -0,0 +1,900 @@
+ /*
+ * A driver for the Omnikey PCMCIA smartcard reader CardMan 4040
+ *
+ * (c) 2000-2004 Omnikey AG (http://www.omnikey.com/)
+ *
+ * (C) 2005 Harald Welte <laforge@gnumonks.org>
+ * 	- add support for poll()
+ * 	- driver cleanup
+ * 	- add waitqueues
+ * 	- adhere to linux kenrel coding style and policies
+ * 	- support 2.6.13 "new style" pcmcia interface
+ *
+ * All rights reserved, Dual BSD/GPL Licensed.
+ */
+
+/* #define PCMCIA_DEBUG 6 */
+
+#include <linux/config.h>
+#include <linux/version.h>
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/fs.h>
+#include <linux/delay.h>
+#include <linux/poll.h>
+#include <asm/uaccess.h>
+#include <asm/io.h>
+
+#include <pcmcia/version.h>
+#include <pcmcia/cs_types.h>
+#include <pcmcia/cs.h>
+#include <pcmcia/cistpl.h>
+#include <pcmcia/cisreg.h>
+#include <pcmcia/ciscode.h>
+#include <pcmcia/ds.h>
+
+#include "cm4040_cs.h"
+
+static atomic_t cmx_num_devices_open;
+
+#ifdef PCMCIA_DEBUG
+static int pc_debug = PCMCIA_DEBUG;
+module_param(pc_debug, int, 0600);
+#define DEBUG(n, x, args...) do { if (pc_debug >= (n)) 			    \
+				  printk(KERN_DEBUG "%s:%s:" x, MODULE_NAME, \
+					 __FUNCTION__, ##args); } while (0)
+#else
+#define DEBUG(n, args...)
+#endif
+
+static volatile char *version =
+"OMNIKEY CardMan 4040 v1.1.0gm3 - All bugs added by Harald Welte";
+
+#define	CCID_DRIVER_BULK_DEFAULT_TIMEOUT  	(150*HZ)
+#define	CCID_DRIVER_ASYNC_POWERUP_TIMEOUT 	(35*HZ)
+#define	CCID_DRIVER_MINIMUM_TIMEOUT 		(3*HZ)
+#define READ_WRITE_BUFFER_SIZE 512
+#define POLL_LOOP_COUNT				1000
+
+/* how often to poll for fifo status change */
+#define POLL_PERIOD 				(HZ/100)
+
+static void reader_release(u_long arg);
+static void reader_detach(dev_link_t *link);
+
+static int major;	
+
+#define		BS_READABLE	0x01
+#define		BS_WRITABLE	0x02
+
+typedef struct reader_dev_t {
+	dev_link_t		link;		
+	dev_node_t		node;		
+	wait_queue_head_t	devq;	
+
+	wait_queue_head_t	poll_wait;
+	wait_queue_head_t	read_wait;
+	wait_queue_head_t	write_wait;
+
+	unsigned int 	  	buffer_status;
+                                
+	unsigned int      	fTimerExpired;
+	struct timer_list	timer;
+	unsigned long     	timeout;
+	unsigned char     	sBuf[READ_WRITE_BUFFER_SIZE];
+	unsigned char     	rBuf[READ_WRITE_BUFFER_SIZE];
+	struct task_struct 	*owner;	
+} reader_dev_t;
+
+static dev_info_t dev_info = MODULE_NAME;
+static dev_link_t *dev_table[CM_MAX_DEV] = { NULL, };
+
+static struct timer_list cmx_poll_timer;
+
+#if (!defined PCMCIA_DEBUG) || (PCMCIA_DEBUG < 7)
+#define	xoutb	outb
+#define	xinb	inb
+#else
+static inline void xoutb(unsigned char val,unsigned short port)
+{
+	DEBUG(7, "outb(val=%.2x,port=%.4x)\n", val, port);
+	outb(val,port);
+}
+
+static unsigned char xinb(unsigned short port)
+{
+	unsigned char val;
+
+	val = inb(port);
+	DEBUG(7, "%.2x=inb(%.4x)\n", val, port);
+	return val;
+}
+#endif
+
+/* poll the device fifo status register.  not to be confused with
+ * the poll syscall. */
+static void cmx_do_poll(unsigned long dummy)
+{
+	unsigned int i;
+	/* walk through all devices */	
+	for (i = 0; dev_table[i]; i++) {
+		dev_link_t *dl = dev_table[i];
+		reader_dev_t *dev = dl->priv;
+		unsigned int obs = xinb(dl->io.BasePort1
+					+ REG_OFFSET_BUFFER_STATUS);
+
+		dev->buffer_status = 0;
+
+		if ((obs & BSR_BULK_IN_FULL) == BSR_BULK_IN_FULL) {
+			dev->buffer_status |= BS_READABLE;
+			DEBUG(4, "waking up read_wait\n");
+			wake_up_interruptible(&dev->read_wait);
+		}
+
+		if ((obs & BSR_BULK_OUT_FULL) == 0) {
+			dev->buffer_status |= BS_WRITABLE;
+			DEBUG(4, "waking up write_wait\n");
+			wake_up_interruptible(&dev->write_wait);
+		}
+
+		if (dev->buffer_status)
+			wake_up_interruptible(&dev->poll_wait);
+	}
+
+	if (atomic_read(&cmx_num_devices_open))
+		mod_timer(&cmx_poll_timer, jiffies + POLL_PERIOD);
+}
+
+static loff_t cmx_llseek(struct file * filp, loff_t off, int whence)
+{
+	return -ESPIPE;
+}
+
+static inline int cmx_waitForBulkOutReady(reader_dev_t *dev)
+{
+        register int i;
+	register int iobase = dev->link.io.BasePort1;
+
+	for (i=0; i < POLL_LOOP_COUNT; i++) {
+		if ((xinb(iobase + REG_OFFSET_BUFFER_STATUS)
+		    & BSR_BULK_OUT_FULL) == 0) {
+			DEBUG(4, "BulkOut empty\n");
+			return 1;
+		}
+	}
+
+	interruptible_sleep_on_timeout(&dev->write_wait, dev->timeout);
+	if (dev->buffer_status & BS_WRITABLE) {
+		DEBUG(4, "woke up: BulkOut empty\n");
+		return 1;
+	}
+
+	DEBUG(4, "woke up: BulkOut full, returning 0 :(\n");
+	return 0;
+}
+
+/* Write to Sync Control Register */
+static inline int cmx_writeSync(unsigned char val,reader_dev_t *dev)
+{
+	register int iobase = dev->link.io.BasePort1;
+	int rc;
+
+	rc = cmx_waitForBulkOutReady(dev);
+        if (rc != 1)
+		return 0;
+
+	xoutb(val,iobase + REG_OFFSET_SYNC_CONTROL);
+	rc = cmx_waitForBulkOutReady(dev);
+        if (rc != 1)
+		return 0;
+
+	return 1;
+}
+
+static inline int cmx_waitForBulkInReady(reader_dev_t *dev)
+{
+        register int i;
+	register int iobase = dev->link.io.BasePort1;
+
+	for (i=0; i < POLL_LOOP_COUNT; i++) {
+		if ((xinb(iobase + REG_OFFSET_BUFFER_STATUS)
+		    & BSR_BULK_IN_FULL) == BSR_BULK_IN_FULL) {
+			DEBUG(3, "BulkIn full\n");
+			return 1;
+		}
+	}
+
+	DEBUG(4, "interruptible_sleep_on_timeout(read_wait, timeout=%ld\n", dev->timeout);
+	interruptible_sleep_on_timeout(&dev->read_wait, dev->timeout);
+	if (dev->buffer_status & BS_READABLE) {
+		DEBUG(4, "woke up: BulkIn full\n");
+		return 1;
+	}
+
+	DEBUG(4, "woke up: BulkIn not full, returning 0 :(\n");
+	return 0;
+}
+
+static ssize_t cmx_read(struct file *filp,char *buf,size_t count,loff_t *ppos)
+{
+	register reader_dev_t *dev=(reader_dev_t *)filp->private_data;
+	register int iobase=dev->link.io.BasePort1;
+	unsigned long ulBytesToRead;
+	unsigned long i;
+	unsigned long ulMin;
+	int rc;
+	unsigned char uc;
+
+	DEBUG(2, "-> cmx_read(%s,%d)\n", current->comm,current->pid);
+
+	if (count==0)
+		return 0;
+
+        if (count < 10)
+		return -EFAULT;
+
+	if (filp->f_flags & O_NONBLOCK) { 
+		DEBUG(4, "filep->f_flags O_NONBLOCK set\n");
+		DEBUG(4, "<- cmx_read (failure)\n");
+		return -EAGAIN;
+	}
+
+	if ((dev->link.state & DEV_PRESENT)==0)	
+		return -ENODEV;
+
+	for (i=0; i<5; i++) {
+		rc = cmx_waitForBulkInReady(dev);
+		if (rc != 1) {
+			DEBUG(5,"cmx_waitForBulkInReady rc=%.2x\n",rc);
+			DEBUG(2, "<- cmx_read (failed)\n");
+			return -EIO;
+		}
+	  	dev->rBuf[i] = xinb(iobase + REG_OFFSET_BULK_IN);
+#ifdef PCMCIA_DEBUG
+		if (pc_debug >= 6)
+			printk(KERN_DEBUG "%lu:%2x ", i, dev->rBuf[i]);
+	}
+	printk("\n");
+#else
+	}
+#endif
+
+	ulBytesToRead = 5 + 
+			(0x000000FF&((char)dev->rBuf[1])) + 
+			(0x0000FF00&((char)dev->rBuf[2] << 8)) + 
+			(0x00FF0000&((char)dev->rBuf[3] << 16)) + 
+			(0xFF000000&((char)dev->rBuf[4] << 24));
+
+	DEBUG(6, "BytesToRead=%lu\n", ulBytesToRead);
+
+	ulMin = (count < (ulBytesToRead+5))?count:(ulBytesToRead+5);
+
+	DEBUG(6, "Min=%lu\n", ulMin);
+
+	for (i=0; i < (ulMin-5); i++) {
+		rc = cmx_waitForBulkInReady(dev);
+		if (rc != 1) {
+			DEBUG(5,"cmx_waitForBulkInReady rc=%.2x\n",rc);
+			DEBUG(2, "<- cmx_read (failed)\n");
+			return -EIO;
+		}
+		dev->rBuf[i+5] = xinb(iobase + REG_OFFSET_BULK_IN);
+		DEBUG(6, "%lu:%2x ", i, dev->rBuf[i]);
+	}
+	DEBUG(6, "\n");
+
+	*ppos = ulMin;
+	copy_to_user(buf, dev->rBuf, ulMin);
+
+
+	rc = cmx_waitForBulkInReady(dev);
+	if (rc != 1) {
+		DEBUG(5,"cmx_waitForBulkInReady rc=%.2x\n",rc);
+		DEBUG(2, "<- cmx_read (failed)\n");
+		return -EIO;
+	}
+
+	rc = cmx_writeSync(SCR_READER_TO_HOST_DONE, dev);
+
+	if (rc != 1) {
+		DEBUG(5,"cmx_writeSync c=%.2x\n",rc);
+		DEBUG(2, "<- cmx_read (failed)\n");
+		return -EIO;
+	}
+
+	uc = xinb(iobase + REG_OFFSET_BULK_IN);
+
+	DEBUG(2,"<- cmx_read (successfully)\n");
+	return ulMin;
+}
+
+static ssize_t cmx_write(struct file *filp,const char *buf,size_t count,
+			 loff_t *ppos)
+{
+	register reader_dev_t *dev=(reader_dev_t *)filp->private_data;
+	register int iobase=dev->link.io.BasePort1;
+	ssize_t rc;
+	int i;
+	unsigned int uiBytesToWrite; 
+
+	DEBUG(2, "-> cmx_write(%s,%d)\n", current->comm, current->pid);
+
+	if (count == 0) {
+		DEBUG(2, "<- cmx_write nothing to do (successfully)\n");
+		return 0;
+	}
+
+	if (count < 5) {
+		DEBUG(2, "<- cmx_write buffersize=%Zd < 5\n", count);
+		return -EIO;
+	}
+
+	if (filp->f_flags & O_NONBLOCK) { 
+		DEBUG(4, "filep->f_flags O_NONBLOCK set\n");
+		DEBUG(4, "<- cmx_write (failure)\n");
+		return -EAGAIN;
+        }
+
+	if ((dev->link.state & DEV_PRESENT) == 0)	
+		return -ENODEV;
+
+	uiBytesToWrite = count;
+	copy_from_user(dev->sBuf, buf, uiBytesToWrite);
+
+	switch (dev->sBuf[0]) {
+		case CMD_PC_TO_RDR_XFRBLOCK:
+		case CMD_PC_TO_RDR_SECURE:
+		case CMD_PC_TO_RDR_TEST_SECURE:
+		case CMD_PC_TO_RDR_OK_SECURE:
+			dev->timeout = CCID_DRIVER_BULK_DEFAULT_TIMEOUT;
+			break;
+
+		case CMD_PC_TO_RDR_ICCPOWERON:
+			dev->timeout = CCID_DRIVER_ASYNC_POWERUP_TIMEOUT;
+			break;
+
+		case CMD_PC_TO_RDR_GETSLOTSTATUS:
+		case CMD_PC_TO_RDR_ICCPOWEROFF:
+		case CMD_PC_TO_RDR_GETPARAMETERS:
+		case CMD_PC_TO_RDR_RESETPARAMETERS:  
+		case CMD_PC_TO_RDR_SETPARAMETERS:
+		case CMD_PC_TO_RDR_ESCAPE:
+		case CMD_PC_TO_RDR_ICCCLOCK:
+		default:
+			dev->timeout = CCID_DRIVER_MINIMUM_TIMEOUT;
+			break;
+	}
+
+	rc = cmx_writeSync(SCR_HOST_TO_READER_START, dev);
+
+	DEBUG(4, "start \n");
+
+	for (i=0; i < uiBytesToWrite; i++) {
+		rc = cmx_waitForBulkOutReady(dev);
+		if (rc != 1) {
+			DEBUG(5, "cmx_waitForBulkOutReady rc=%.2Zx\n", rc);
+			DEBUG(2, "<- cmx_write (failed)\n");
+			return -EIO;
+          	}
+	 
+		xoutb(dev->sBuf[i],iobase + REG_OFFSET_BULK_OUT);
+		DEBUG(4, "%.2x ", dev->sBuf[i]);
+	}
+	DEBUG(4, "end\n");
+
+	rc = cmx_writeSync(SCR_HOST_TO_READER_DONE, dev);
+
+	if (rc != 1) {
+		DEBUG(5, "cmx_writeSync c=%.2Zx\n", rc);
+		DEBUG(2, "<- cmx_write (failed)\n");
+		return -EIO;
+	}
+
+	DEBUG(2, "<- cmx_write (successfully)\n");
+	return count;
+}
+
+static unsigned int cmx_poll(struct file *filp, poll_table *wait)
+{
+	reader_dev_t *dev=(reader_dev_t *)filp->private_data;
+	unsigned int mask = 0;
+
+	poll_wait(filp, &dev->poll_wait, wait);
+
+	if (dev->buffer_status & BS_READABLE)
+		mask |= POLLIN | POLLRDNORM;
+	if (dev->buffer_status & BS_WRITABLE)
+		mask |= POLLOUT | POLLWRNORM;
+
+	return mask;
+}
+
+static int cmx_ioctl(struct inode *inode,struct file *filp,unsigned int cmd,
+			unsigned long arg)
+{
+	dev_link_t *link;
+	int rc, size;
+
+	link=dev_table[MINOR(inode->i_rdev)];
+	if (!(DEV_OK(link))) {
+		DEBUG(4, "DEV_OK false\n");
+		return -ENODEV;
+	}
+	if (_IOC_TYPE(cmd)!=CM_IOC_MAGIC) {
+		DEBUG(4,"ioctype mismatch\n");
+		return -EINVAL;
+	}
+	if (_IOC_NR(cmd)>CM_IOC_MAXNR) {
+		DEBUG(4,"iocnr mismatch\n");
+		return -EINVAL;
+	} 
+	size = _IOC_SIZE(cmd);
+	rc = 0;
+	DEBUG(4,"iocdir=%.4x iocr=%.4x iocw=%.4x iocsize=%d cmd=%.4x\n",
+		_IOC_DIR(cmd),_IOC_READ,_IOC_WRITE,size,cmd);
+
+	if (_IOC_DIR(cmd)&_IOC_READ) {
+		if (!access_ok(VERIFY_WRITE, (void *)arg, size))
+			return -EFAULT;
+	}
+	if (_IOC_DIR(cmd)&_IOC_WRITE) {
+		if (!access_ok(VERIFY_READ, (void *)arg, size))
+			return -EFAULT;
+	}
+
+	return rc;
+}
+
+static int cmx_open (struct inode *inode, struct file *filp)
+{
+	reader_dev_t *dev;
+	dev_link_t *link;
+	int i;
+
+	DEBUG(2, "-> cmx_open(device=%d.%d process=%s,%d)\n",
+		MAJOR(inode->i_rdev), MINOR(inode->i_rdev),
+		current->comm, current->pid);
+
+	i = MINOR(inode->i_rdev);
+	if (i >= CM_MAX_DEV) {
+		DEBUG(4, "MAX_DEV reached\n");
+		DEBUG(4, "<- cmx_open (failure)\n");
+		return -ENODEV;
+	}
+	link = dev_table[MINOR(inode->i_rdev)];
+	if (link == NULL || !(DEV_OK(link))) {
+		DEBUG(4, "link== NULL || DEV_OK false\n");
+		DEBUG(4, "<- cmx_open (failure)\n");
+		return -ENODEV;
+	}
+	if (link->open) {
+		DEBUG(4, "DEVICE BUSY\n");
+		DEBUG(4, "<- cmx_open (failure)\n");
+		return -EBUSY;
+	}
+
+	dev = (reader_dev_t *)link->priv;
+	filp->private_data = dev;
+
+	if (filp->f_flags & O_NONBLOCK) { 
+		DEBUG(4, "filep->f_flags O_NONBLOCK set\n");
+		DEBUG(4, "<- cmx_open (failure)\n");
+		return -EAGAIN;
+        }
+
+	dev->owner = current;
+	link->open = 1;		
+
+	atomic_inc(&cmx_num_devices_open);
+	mod_timer(&cmx_poll_timer, jiffies + POLL_PERIOD);
+
+	DEBUG(2, "<- cmx_open (successfully)\n");
+	return 0;
+}
+
+static int cmx_close(struct inode *inode,struct file *filp)
+{
+	reader_dev_t *dev;
+	dev_link_t *link;
+	int i;
+
+	DEBUG(2, "-> cmx_close(maj/min=%d.%d)\n",
+		MAJOR(inode->i_rdev), MINOR(inode->i_rdev));
+
+	i = MINOR(inode->i_rdev);
+	if (i >= CM_MAX_DEV)
+		return -ENODEV;
+
+	link = dev_table[MINOR(inode->i_rdev)];
+	if (link == NULL)
+		return -ENODEV;
+
+	dev = (reader_dev_t *)link->priv;
+
+	link->open = 0;
+	wake_up(&dev->devq);	
+
+	atomic_dec(&cmx_num_devices_open);
+
+	DEBUG(2, "<- cmx_close\n");
+	return 0;
+}
+
+static void cmx_reader_release(dev_link_t *link)
+{
+	reader_dev_t *dev = (reader_dev_t *)link->priv;
+
+	DEBUG(3, "-> cmx_reader_release\n"); 
+	while (link->open) {
+		DEBUG(3, KERN_INFO MODULE_NAME ": delaying release until "
+		      "process '%s', pid %d has terminated\n",
+		      dev->owner->comm,dev->owner->pid);
+ 		wait_event(dev->devq, (link->open == 0));
+	}
+	DEBUG(3, "<- cmx_reader_release\n"); 
+	return;
+}
+
+static void reader_config(dev_link_t *link, int devno)
+{
+	client_handle_t handle;
+	reader_dev_t *dev;
+	tuple_t tuple;
+	cisparse_t parse;
+	config_info_t conf;
+	u_char buf[64];
+	int fail_fn,fail_rc;
+	int rc;
+
+	DEBUG(2, "-> reader_config\n");
+
+	handle = link->handle;
+
+	tuple.DesiredTuple = CISTPL_CONFIG;
+	tuple.Attributes = 0;
+	tuple.TupleData = buf;
+	tuple.TupleDataMax = sizeof(buf);
+ 	tuple.TupleOffset = 0;
+
+	if ((fail_rc = pcmcia_get_first_tuple(handle,&tuple)) != CS_SUCCESS) {
+		fail_fn = GetFirstTuple;
+		goto cs_failed;
+	}
+	if ((fail_rc = pcmcia_get_tuple_data(handle,&tuple)) != CS_SUCCESS) {
+		fail_fn = GetTupleData;
+		goto cs_failed;
+	}
+	if ((fail_rc = pcmcia_parse_tuple(handle,&tuple,&parse))
+							!= CS_SUCCESS) {
+		fail_fn = ParseTuple;
+		goto cs_failed;
+	}
+	if ((fail_rc = pcmcia_get_configuration_info(handle,&conf))
+							!= CS_SUCCESS) {
+		fail_fn = GetConfigurationInfo;
+		goto cs_failed;
+	}
+
+	link->state |= DEV_CONFIG;
+	link->conf.ConfigBase = parse.config.base;
+	link->conf.Present = parse.config.rmask[0];
+	link->conf.Vcc = conf.Vcc;
+	DEBUG(2, "link->conf.Vcc=%d\n", link->conf.Vcc);
+
+	link->io.BasePort2 = 0;
+	link->io.NumPorts2 = 0;
+	link->io.Attributes2 = 0;
+	tuple.DesiredTuple = CISTPL_CFTABLE_ENTRY;
+	for (rc = pcmcia_get_first_tuple(handle, &tuple);
+	     rc == CS_SUCCESS;
+	     rc = pcmcia_get_next_tuple(handle, &tuple)) {
+ 		DEBUG(2, "Examing CIS Tuple!\n");
+		rc = pcmcia_get_tuple_data(handle, &tuple);
+		if (rc != CS_SUCCESS)
+			continue;
+		rc = pcmcia_parse_tuple(handle, &tuple, &parse);
+		if (rc != CS_SUCCESS)
+			continue;
+
+		DEBUG(2, "tupleIndex=%d\n", parse.cftable_entry.index);
+		link->conf.ConfigIndex = parse.cftable_entry.index;
+		
+		if (parse.cftable_entry.io.nwin) {
+			link->io.BasePort1 = parse.cftable_entry.io.win[0].base;
+			link->io.NumPorts1 = parse.cftable_entry.io.win[0].len;
+			link->io.Attributes1 = IO_DATA_PATH_WIDTH_AUTO;
+			if(!(parse.cftable_entry.io.flags & CISTPL_IO_8BIT))
+				link->io.Attributes1 = IO_DATA_PATH_WIDTH_16;
+			if(!(parse.cftable_entry.io.flags & CISTPL_IO_16BIT))
+				link->io.Attributes1 = IO_DATA_PATH_WIDTH_8;
+			link->io.IOAddrLines = parse.cftable_entry.io.flags
+						& CISTPL_IO_LINES_MASK;
+			DEBUG(2,"io.BasePort1=%.4x\n", link->io.BasePort1);
+			DEBUG(2,"io.NumPorts1=%.4x\n", link->io.NumPorts1);
+			DEBUG(2,"io.BasePort2=%.4x\n", link->io.BasePort2);
+			DEBUG(2,"io.NumPorts2=%.4x\n", link->io.NumPorts2);
+			DEBUG(2,"io.IOAddrLines=%.4x\n", 
+			      link->io.IOAddrLines);
+			rc = pcmcia_request_io(handle, &link->io);
+			if (rc == CS_SUCCESS) {
+				DEBUG(2, "RequestIO OK\n");
+				break; 
+			} else 
+				DEBUG(2, "RequestIO failed\n");
+		}
+	}
+	if (rc != CS_SUCCESS) {
+		DEBUG(2, "Couldn't configure reader\n");
+		goto cs_release;
+	}
+
+        link->conf.IntType = 00000002;
+
+	if ((fail_rc = pcmcia_request_configuration(handle,&link->conf))
+								!=CS_SUCCESS) {
+		fail_fn = RequestConfiguration;
+		DEBUG(1, "pcmcia_request_configuration failed 0x%x\n", fail_rc);
+		goto cs_release;
+	}
+
+	DEBUG(2, "RequestConfiguration OK\n");
+
+	dev = link->priv;
+	sprintf(dev->node.dev_name, DEVICE_NAME "%d", devno);
+	dev->node.major = major;
+	dev->node.minor = devno;
+	dev->node.next = NULL;
+	link->dev = &dev->node;
+	link->state &= ~DEV_CONFIG_PENDING;
+
+	DEBUG(2, "device " DEVICE_NAME "%d at 0x%.4x-0x%.4x\n", devno,
+	      link->io.BasePort1, link->io.BasePort1+link->io.NumPorts1);
+	DEBUG(2, "<- reader_config (succ)\n");
+
+	return;
+
+cs_failed:
+	cs_error(handle, fail_fn, fail_rc);
+cs_release:
+	reader_release((u_long)link);
+	link->state &= ~DEV_CONFIG_PENDING;
+	DEBUG(2, "<- reader_config (failure)\n");
+}
+
+static int reader_event(event_t event, int priority,
+			event_callback_args_t *args)
+{
+	dev_link_t *link;
+	reader_dev_t *dev;
+	int devno;
+
+	DEBUG(3,"-> reader_event\n");
+	link = args->client_data;
+	dev = link->priv;
+	for (devno = 0; devno < CM_MAX_DEV; devno++) {
+		if (dev_table[devno]==link)
+			break;
+	}
+	if (devno == CM_MAX_DEV)
+		return CS_BAD_ADAPTER;
+
+	switch (event) {
+		case CS_EVENT_CARD_INSERTION:
+			DEBUG(5, "CS_EVENT_CARD_INSERTION\n");
+			link->state |= DEV_PRESENT | DEV_CONFIG_PENDING;
+			reader_config(link,devno);
+			break;
+		case CS_EVENT_CARD_REMOVAL:
+			DEBUG(5, "CS_EVENT_CARD_REMOVAL\n");
+			link->state &= ~DEV_PRESENT;
+			break;
+		case CS_EVENT_PM_SUSPEND:
+			DEBUG(5, "CS_EVENT_PM_SUSPEND "
+			      "(fall-through to CS_EVENT_RESET_PHYSICAL)\n");
+			link->state |= DEV_SUSPEND;
+		
+		case CS_EVENT_RESET_PHYSICAL:
+			DEBUG(5, "CS_EVENT_RESET_PHYSICAL\n");
+			if (link->state & DEV_CONFIG) {
+		  		DEBUG(5, "ReleaseConfiguration\n");
+		  		pcmcia_release_configuration(link->handle);
+			}
+			break;
+		case CS_EVENT_PM_RESUME:
+			DEBUG(5, "CS_EVENT_PM_RESUME "
+			      "(fall-through to CS_EVENT_CARD_RESET)\n");
+			link->state &= ~DEV_SUSPEND;
+		
+		case CS_EVENT_CARD_RESET:
+	        	DEBUG(5, "CS_EVENT_CARD_RESET\n");
+			if ((link->state & DEV_CONFIG)) {
+				DEBUG(5, "cmx: RequestConfiguration\n");
+		  		pcmcia_request_configuration(link->handle,
+							     &link->conf);
+			}
+			break;
+		default:
+			DEBUG(5, "reader_event: unknown event %.2x\n", event);
+			break;
+	}
+	DEBUG(3, "<- reader_event\n");
+	return CS_SUCCESS;
+}
+
+static void reader_release(u_long arg)
+{
+	dev_link_t *link;
+	int rc;
+
+	DEBUG(3, "-> reader_release\n");
+	link = (dev_link_t *)arg;
+	cmx_reader_release(link->priv); 
+	rc = pcmcia_release_configuration(link->handle);
+	if (rc != CS_SUCCESS)
+		DEBUG(5, "couldn't ReleaseConfiguration "
+		      "reasoncode=%.2x\n", rc);
+	rc = pcmcia_release_io(link->handle, &link->io);
+	if (rc != CS_SUCCESS)
+		DEBUG(5, "couldn't ReleaseIO reasoncode=%.2x\n", rc);
+
+	DEBUG(3, "<- reader_release\n");
+}
+
+static dev_link_t *reader_attach(void)
+{
+	reader_dev_t *dev;
+	dev_link_t *link;
+	client_reg_t client_reg;
+	int i;
+
+	DEBUG(3, "reader_attach\n");
+	for (i=0; i < CM_MAX_DEV; i++) {
+		if (dev_table[i] == NULL)
+			break;
+	}
+
+	if (i == CM_MAX_DEV) {
+		printk(KERN_NOTICE "all devices in use\n");
+		return NULL;
+	}
+	
+	DEBUG(5, "create reader device instance\n");
+	dev = kmalloc(sizeof(reader_dev_t), GFP_KERNEL);
+	if (dev == NULL)
+		return NULL;
+
+	memset(dev, 0, sizeof(reader_dev_t));
+	dev->timeout = CCID_DRIVER_MINIMUM_TIMEOUT;
+	dev->fTimerExpired = 0;
+
+	link = &dev->link;
+	link->priv = dev;
+
+	link->conf.IntType = INT_MEMORY_AND_IO;
+	dev_table[i] = link;
+
+	
+	DEBUG(5, "Register with Card Services\n");
+	client_reg.dev_info = &dev_info;
+	client_reg.Attributes = INFO_IO_CLIENT | INFO_CARD_SHARE;
+	client_reg.EventMask=
+		CS_EVENT_CARD_INSERTION | CS_EVENT_CARD_REMOVAL |
+		CS_EVENT_RESET_PHYSICAL | CS_EVENT_CARD_RESET |
+		CS_EVENT_PM_SUSPEND | CS_EVENT_PM_RESUME;
+	client_reg.Version = 0x0210;
+	client_reg.event_callback_args.client_data = link;
+	i = pcmcia_register_client(&link->handle, &client_reg);
+	if (i) {
+		cs_error(link->handle, RegisterClient, i);
+		reader_detach(link);
+		return NULL;
+	}
+	init_waitqueue_head(&dev->devq);
+	init_waitqueue_head(&dev->poll_wait);
+	init_waitqueue_head(&dev->read_wait);
+	init_waitqueue_head(&dev->write_wait);
+	init_timer(&cmx_poll_timer);
+	cmx_poll_timer.function = &cmx_do_poll;
+
+	return link;
+}
+
+static void reader_detach_by_devno(int devno,dev_link_t *link)
+{
+	reader_dev_t *dev=link->priv;
+
+	DEBUG(3, "-> detach_by_devno(devno=%d)\n", devno);
+	if (link->state & DEV_CONFIG) {
+		DEBUG(5, "device still configured (try to release it)\n");
+		reader_release((u_long)link);
+	}
+
+	pcmcia_deregister_client(link->handle);
+	dev_table[devno] = NULL;
+	DEBUG(5, "freeing dev=%p\n", dev);
+	kfree(dev);
+	DEBUG(3, "<- detach_by-devno\n");
+	return;
+}
+
+static void reader_detach(dev_link_t *link)
+{
+	int i;
+	DEBUG(3, "-> reader_detach(link=%p\n", link);
+	/* find device */
+	for(i=0; i < CM_MAX_DEV; i++) {
+		if (dev_table[i] == link)
+			break;
+	}
+	if (i == CM_MAX_DEV) {
+		printk(KERN_WARNING MODULE_NAME 
+			": detach for unkown device aborted\n");
+		return;
+	}
+	reader_detach_by_devno(i, link);
+	DEBUG(3, "<- reader_detach\n");
+	return;
+}
+
+static struct file_operations reader_fops = {
+	.owner		= THIS_MODULE,
+	.llseek		= cmx_llseek,
+	.read		= cmx_read,
+	.write		= cmx_write,
+	.ioctl		= cmx_ioctl,
+	.open		= cmx_open,
+	.release	= cmx_close,
+	.poll		= cmx_poll,
+};
+
+static struct pcmcia_device_id cm4040_ids[] = {
+	PCMCIA_DEVICE_MANF_CARD(0x0223, 0x0200),
+	PCMCIA_DEVICE_PROD_ID12("OMNIKEY", "CardMan 4040", 
+				0xE32CDD8C, 0x8F23318B),
+	PCMCIA_DEVICE_NULL,
+};
+MODULE_DEVICE_TABLE(pcmcia, cm4040_ids);
+
+static struct pcmcia_driver reader_driver = {
+  	.owner		= THIS_MODULE,
+  	.drv		= {
+		.name	= "cm4040_cs",
+	},
+	.attach		= reader_attach,
+	.detach		= reader_detach,
+	.event		= reader_event,
+	.id_table	= cm4040_ids,
+};
+
+static int __init cmx_init(void)
+{
+	printk(KERN_INFO "%s\n", version);
+	pcmcia_register_driver(&reader_driver);
+	major = register_chrdev(0, DEVICE_NAME, &reader_fops);
+	if (major < 0) {
+		printk(KERN_WARNING MODULE_NAME
+			": could not get major number\n");
+		return -1;
+	}
+	return 0;
+}
+
+static void __exit cmx_exit(void)
+{
+	int i;
+
+	printk(KERN_INFO MODULE_NAME ": unloading\n");
+	pcmcia_unregister_driver(&reader_driver);  
+	for (i=0; i < CM_MAX_DEV; i++) {
+		if (dev_table[i])
+			reader_detach_by_devno(i, dev_table[i]);
+	}
+	unregister_chrdev(major, DEVICE_NAME);
+}
+
+module_init(cmx_init);
+module_exit(cmx_exit);
+MODULE_LICENSE("Dual BSD/GPL");

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
  2005-09-04 10:12 [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver Harald Welte
  2005-09-03 21:27 ` Chase Venters
  2005-09-03 21:56 ` Alexey Dobriyan
@ 2005-09-04 11:08 ` Harald Welte
  2005-09-03 22:27   ` Jesper Juhl
  2005-09-04 12:58 ` Ingo Oeser
  3 siblings, 1 reply; 150+ messages in thread
From: Harald Welte @ 2005-09-04 11:08 UTC (permalink / raw)
  To: Linux Kernel Mailinglist


[-- Attachment #1.1: Type: text/plain, Size: 568 bytes --]

On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote:
> Hi!
> 
> Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> Smartcard Reader.  

Sorry, the patch was missing a "cg-add" of the header file.  Please use
the patch below.
-- 
- Harald Welte <laforge@gnumonks.org>          	        http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

[-- Attachment #1.2: cm4040-driver.patch --]
[-- Type: text/plain, Size: 27813 bytes --]

Add Omnikey CardMan 4040 Driver

Signed-off-by: Harald Welte <laforge@netfilter.org>

---
commit 0e760a5785ebb83b932d104679cc2b2b4070b1c1
tree 46d71d0c6b41b441a1a8d725b741450f1334296e
parent c4ab879b6ef599bf88d19b9b145878ef73400ce7
author Harald Welte <laforge@netfilter.org> So, 04 Sep 2005 13:05:44 +0200
committer Harald Welte <laforge@netfilter.org> So, 04 Sep 2005 13:05:44 +0200

 MAINTAINERS                     |    5 
 drivers/char/pcmcia/Kconfig     |   13 +
 drivers/char/pcmcia/Makefile    |    1 
 drivers/char/pcmcia/cm4040_cs.c |  900 +++++++++++++++++++++++++++++++++++++++
 drivers/char/pcmcia/cm4040_cs.h |   52 ++
 5 files changed, 971 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1737,6 +1737,11 @@ L:	linux-tr@linuxtr.net
 W:	http://www.linuxtr.net
 S:	Maintained
 
+OMNIKEY CARDMAN 4040 DRIVER
+P:	Harald Welte
+M:	laforge@gnumonks.org
+S:	Maintained
+
 ONSTREAM SCSI TAPE DRIVER
 P:	Willem Riede
 M:	osst@riede.org
diff --git a/drivers/char/pcmcia/Kconfig b/drivers/char/pcmcia/Kconfig
--- a/drivers/char/pcmcia/Kconfig
+++ b/drivers/char/pcmcia/Kconfig
@@ -18,5 +18,18 @@ config SYNCLINK_CS
 	  The module will be called synclinkmp.  If you want to do that, say M
 	  here.
 
+config CARDMAN_4040
+	tristate "Omnikey CardMan 4040 support"
+	depends on PCMCIA
+	help
+	  Enable support for the Omnikey CardMan 4040 PCMCIA Smartcard
+	  reader.
+	  
+	  This card is basically a USB CCID device connected to a FIFO
+	  in I/O space.  To use the kernel driver, you will need either the
+	  PC/SC ifdhandler provided from the Omnikey homepage
+	  (http://www.omnikey.com/), or a current development version of OpenCT
+	  (http://www.opensc.org/).
+
 endmenu
 
diff --git a/drivers/char/pcmcia/Makefile b/drivers/char/pcmcia/Makefile
--- a/drivers/char/pcmcia/Makefile
+++ b/drivers/char/pcmcia/Makefile
@@ -5,3 +5,4 @@
 #
 
 obj-$(CONFIG_SYNCLINK_CS) += synclink_cs.o
+obj-$(CONFIG_CARDMAN_4040) += cm4040_cs.o
diff --git a/drivers/char/pcmcia/cm4040_cs.c b/drivers/char/pcmcia/cm4040_cs.c
new file mode 100644
--- /dev/null
+++ b/drivers/char/pcmcia/cm4040_cs.c
@@ -0,0 +1,900 @@
+ /*
+ * A driver for the Omnikey PCMCIA smartcard reader CardMan 4040
+ *
+ * (c) 2000-2004 Omnikey AG (http://www.omnikey.com/)
+ *
+ * (C) 2005 Harald Welte <laforge@gnumonks.org>
+ * 	- add support for poll()
+ * 	- driver cleanup
+ * 	- add waitqueues
+ * 	- adhere to linux kenrel coding style and policies
+ * 	- support 2.6.13 "new style" pcmcia interface
+ *
+ * All rights reserved, Dual BSD/GPL Licensed.
+ */
+
+/* #define PCMCIA_DEBUG 6 */
+
+#include <linux/config.h>
+#include <linux/version.h>
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/fs.h>
+#include <linux/delay.h>
+#include <linux/poll.h>
+#include <asm/uaccess.h>
+#include <asm/io.h>
+
+#include <pcmcia/version.h>
+#include <pcmcia/cs_types.h>
+#include <pcmcia/cs.h>
+#include <pcmcia/cistpl.h>
+#include <pcmcia/cisreg.h>
+#include <pcmcia/ciscode.h>
+#include <pcmcia/ds.h>
+
+#include "cm4040_cs.h"
+
+static atomic_t cmx_num_devices_open;
+
+#ifdef PCMCIA_DEBUG
+static int pc_debug = PCMCIA_DEBUG;
+module_param(pc_debug, int, 0600);
+#define DEBUG(n, x, args...) do { if (pc_debug >= (n)) 			    \
+				  printk(KERN_DEBUG "%s:%s:" x, MODULE_NAME, \
+					 __FUNCTION__, ##args); } while (0)
+#else
+#define DEBUG(n, args...)
+#endif
+
+static volatile char *version =
+"OMNIKEY CardMan 4040 v1.1.0gm3 - All bugs added by Harald Welte";
+
+#define	CCID_DRIVER_BULK_DEFAULT_TIMEOUT  	(150*HZ)
+#define	CCID_DRIVER_ASYNC_POWERUP_TIMEOUT 	(35*HZ)
+#define	CCID_DRIVER_MINIMUM_TIMEOUT 		(3*HZ)
+#define READ_WRITE_BUFFER_SIZE 512
+#define POLL_LOOP_COUNT				1000
+
+/* how often to poll for fifo status change */
+#define POLL_PERIOD 				(HZ/100)
+
+static void reader_release(u_long arg);
+static void reader_detach(dev_link_t *link);
+
+static int major;	
+
+#define		BS_READABLE	0x01
+#define		BS_WRITABLE	0x02
+
+typedef struct reader_dev_t {
+	dev_link_t		link;		
+	dev_node_t		node;		
+	wait_queue_head_t	devq;	
+
+	wait_queue_head_t	poll_wait;
+	wait_queue_head_t	read_wait;
+	wait_queue_head_t	write_wait;
+
+	unsigned int 	  	buffer_status;
+                                
+	unsigned int      	fTimerExpired;
+	struct timer_list	timer;
+	unsigned long     	timeout;
+	unsigned char     	sBuf[READ_WRITE_BUFFER_SIZE];
+	unsigned char     	rBuf[READ_WRITE_BUFFER_SIZE];
+	struct task_struct 	*owner;	
+} reader_dev_t;
+
+static dev_info_t dev_info = MODULE_NAME;
+static dev_link_t *dev_table[CM_MAX_DEV] = { NULL, };
+
+static struct timer_list cmx_poll_timer;
+
+#if (!defined PCMCIA_DEBUG) || (PCMCIA_DEBUG < 7)
+#define	xoutb	outb
+#define	xinb	inb
+#else
+static inline void xoutb(unsigned char val,unsigned short port)
+{
+	DEBUG(7, "outb(val=%.2x,port=%.4x)\n", val, port);
+	outb(val,port);
+}
+
+static unsigned char xinb(unsigned short port)
+{
+	unsigned char val;
+
+	val = inb(port);
+	DEBUG(7, "%.2x=inb(%.4x)\n", val, port);
+	return val;
+}
+#endif
+
+/* poll the device fifo status register.  not to be confused with
+ * the poll syscall. */
+static void cmx_do_poll(unsigned long dummy)
+{
+	unsigned int i;
+	/* walk through all devices */	
+	for (i = 0; dev_table[i]; i++) {
+		dev_link_t *dl = dev_table[i];
+		reader_dev_t *dev = dl->priv;
+		unsigned int obs = xinb(dl->io.BasePort1
+					+ REG_OFFSET_BUFFER_STATUS);
+
+		dev->buffer_status = 0;
+
+		if ((obs & BSR_BULK_IN_FULL) == BSR_BULK_IN_FULL) {
+			dev->buffer_status |= BS_READABLE;
+			DEBUG(4, "waking up read_wait\n");
+			wake_up_interruptible(&dev->read_wait);
+		}
+
+		if ((obs & BSR_BULK_OUT_FULL) == 0) {
+			dev->buffer_status |= BS_WRITABLE;
+			DEBUG(4, "waking up write_wait\n");
+			wake_up_interruptible(&dev->write_wait);
+		}
+
+		if (dev->buffer_status)
+			wake_up_interruptible(&dev->poll_wait);
+	}
+
+	if (atomic_read(&cmx_num_devices_open))
+		mod_timer(&cmx_poll_timer, jiffies + POLL_PERIOD);
+}
+
+static loff_t cmx_llseek(struct file * filp, loff_t off, int whence)
+{
+	return -ESPIPE;
+}
+
+static inline int cmx_waitForBulkOutReady(reader_dev_t *dev)
+{
+        register int i;
+	register int iobase = dev->link.io.BasePort1;
+
+	for (i=0; i < POLL_LOOP_COUNT; i++) {
+		if ((xinb(iobase + REG_OFFSET_BUFFER_STATUS)
+		    & BSR_BULK_OUT_FULL) == 0) {
+			DEBUG(4, "BulkOut empty\n");
+			return 1;
+		}
+	}
+
+	interruptible_sleep_on_timeout(&dev->write_wait, dev->timeout);
+	if (dev->buffer_status & BS_WRITABLE) {
+		DEBUG(4, "woke up: BulkOut empty\n");
+		return 1;
+	}
+
+	DEBUG(4, "woke up: BulkOut full, returning 0 :(\n");
+	return 0;
+}
+
+/* Write to Sync Control Register */
+static inline int cmx_writeSync(unsigned char val,reader_dev_t *dev)
+{
+	register int iobase = dev->link.io.BasePort1;
+	int rc;
+
+	rc = cmx_waitForBulkOutReady(dev);
+        if (rc != 1)
+		return 0;
+
+	xoutb(val,iobase + REG_OFFSET_SYNC_CONTROL);
+	rc = cmx_waitForBulkOutReady(dev);
+        if (rc != 1)
+		return 0;
+
+	return 1;
+}
+
+static inline int cmx_waitForBulkInReady(reader_dev_t *dev)
+{
+        register int i;
+	register int iobase = dev->link.io.BasePort1;
+
+	for (i=0; i < POLL_LOOP_COUNT; i++) {
+		if ((xinb(iobase + REG_OFFSET_BUFFER_STATUS)
+		    & BSR_BULK_IN_FULL) == BSR_BULK_IN_FULL) {
+			DEBUG(3, "BulkIn full\n");
+			return 1;
+		}
+	}
+
+	DEBUG(4, "interruptible_sleep_on_timeout(read_wait, timeout=%ld\n", dev->timeout);
+	interruptible_sleep_on_timeout(&dev->read_wait, dev->timeout);
+	if (dev->buffer_status & BS_READABLE) {
+		DEBUG(4, "woke up: BulkIn full\n");
+		return 1;
+	}
+
+	DEBUG(4, "woke up: BulkIn not full, returning 0 :(\n");
+	return 0;
+}
+
+static ssize_t cmx_read(struct file *filp,char *buf,size_t count,loff_t *ppos)
+{
+	register reader_dev_t *dev=(reader_dev_t *)filp->private_data;
+	register int iobase=dev->link.io.BasePort1;
+	unsigned long ulBytesToRead;
+	unsigned long i;
+	unsigned long ulMin;
+	int rc;
+	unsigned char uc;
+
+	DEBUG(2, "-> cmx_read(%s,%d)\n", current->comm,current->pid);
+
+	if (count==0)
+		return 0;
+
+        if (count < 10)
+		return -EFAULT;
+
+	if (filp->f_flags & O_NONBLOCK) { 
+		DEBUG(4, "filep->f_flags O_NONBLOCK set\n");
+		DEBUG(4, "<- cmx_read (failure)\n");
+		return -EAGAIN;
+	}
+
+	if ((dev->link.state & DEV_PRESENT)==0)	
+		return -ENODEV;
+
+	for (i=0; i<5; i++) {
+		rc = cmx_waitForBulkInReady(dev);
+		if (rc != 1) {
+			DEBUG(5,"cmx_waitForBulkInReady rc=%.2x\n",rc);
+			DEBUG(2, "<- cmx_read (failed)\n");
+			return -EIO;
+		}
+	  	dev->rBuf[i] = xinb(iobase + REG_OFFSET_BULK_IN);
+#ifdef PCMCIA_DEBUG
+		if (pc_debug >= 6)
+			printk(KERN_DEBUG "%lu:%2x ", i, dev->rBuf[i]);
+	}
+	printk("\n");
+#else
+	}
+#endif
+
+	ulBytesToRead = 5 + 
+			(0x000000FF&((char)dev->rBuf[1])) + 
+			(0x0000FF00&((char)dev->rBuf[2] << 8)) + 
+			(0x00FF0000&((char)dev->rBuf[3] << 16)) + 
+			(0xFF000000&((char)dev->rBuf[4] << 24));
+
+	DEBUG(6, "BytesToRead=%lu\n", ulBytesToRead);
+
+	ulMin = (count < (ulBytesToRead+5))?count:(ulBytesToRead+5);
+
+	DEBUG(6, "Min=%lu\n", ulMin);
+
+	for (i=0; i < (ulMin-5); i++) {
+		rc = cmx_waitForBulkInReady(dev);
+		if (rc != 1) {
+			DEBUG(5,"cmx_waitForBulkInReady rc=%.2x\n",rc);
+			DEBUG(2, "<- cmx_read (failed)\n");
+			return -EIO;
+		}
+		dev->rBuf[i+5] = xinb(iobase + REG_OFFSET_BULK_IN);
+		DEBUG(6, "%lu:%2x ", i, dev->rBuf[i]);
+	}
+	DEBUG(6, "\n");
+
+	*ppos = ulMin;
+	copy_to_user(buf, dev->rBuf, ulMin);
+
+
+	rc = cmx_waitForBulkInReady(dev);
+	if (rc != 1) {
+		DEBUG(5,"cmx_waitForBulkInReady rc=%.2x\n",rc);
+		DEBUG(2, "<- cmx_read (failed)\n");
+		return -EIO;
+	}
+
+	rc = cmx_writeSync(SCR_READER_TO_HOST_DONE, dev);
+
+	if (rc != 1) {
+		DEBUG(5,"cmx_writeSync c=%.2x\n",rc);
+		DEBUG(2, "<- cmx_read (failed)\n");
+		return -EIO;
+	}
+
+	uc = xinb(iobase + REG_OFFSET_BULK_IN);
+
+	DEBUG(2,"<- cmx_read (successfully)\n");
+	return ulMin;
+}
+
+static ssize_t cmx_write(struct file *filp,const char *buf,size_t count,
+			 loff_t *ppos)
+{
+	register reader_dev_t *dev=(reader_dev_t *)filp->private_data;
+	register int iobase=dev->link.io.BasePort1;
+	ssize_t rc;
+	int i;
+	unsigned int uiBytesToWrite; 
+
+	DEBUG(2, "-> cmx_write(%s,%d)\n", current->comm, current->pid);
+
+	if (count == 0) {
+		DEBUG(2, "<- cmx_write nothing to do (successfully)\n");
+		return 0;
+	}
+
+	if (count < 5) {
+		DEBUG(2, "<- cmx_write buffersize=%Zd < 5\n", count);
+		return -EIO;
+	}
+
+	if (filp->f_flags & O_NONBLOCK) { 
+		DEBUG(4, "filep->f_flags O_NONBLOCK set\n");
+		DEBUG(4, "<- cmx_write (failure)\n");
+		return -EAGAIN;
+        }
+
+	if ((dev->link.state & DEV_PRESENT) == 0)	
+		return -ENODEV;
+
+	uiBytesToWrite = count;
+	copy_from_user(dev->sBuf, buf, uiBytesToWrite);
+
+	switch (dev->sBuf[0]) {
+		case CMD_PC_TO_RDR_XFRBLOCK:
+		case CMD_PC_TO_RDR_SECURE:
+		case CMD_PC_TO_RDR_TEST_SECURE:
+		case CMD_PC_TO_RDR_OK_SECURE:
+			dev->timeout = CCID_DRIVER_BULK_DEFAULT_TIMEOUT;
+			break;
+
+		case CMD_PC_TO_RDR_ICCPOWERON:
+			dev->timeout = CCID_DRIVER_ASYNC_POWERUP_TIMEOUT;
+			break;
+
+		case CMD_PC_TO_RDR_GETSLOTSTATUS:
+		case CMD_PC_TO_RDR_ICCPOWEROFF:
+		case CMD_PC_TO_RDR_GETPARAMETERS:
+		case CMD_PC_TO_RDR_RESETPARAMETERS:  
+		case CMD_PC_TO_RDR_SETPARAMETERS:
+		case CMD_PC_TO_RDR_ESCAPE:
+		case CMD_PC_TO_RDR_ICCCLOCK:
+		default:
+			dev->timeout = CCID_DRIVER_MINIMUM_TIMEOUT;
+			break;
+	}
+
+	rc = cmx_writeSync(SCR_HOST_TO_READER_START, dev);
+
+	DEBUG(4, "start \n");
+
+	for (i=0; i < uiBytesToWrite; i++) {
+		rc = cmx_waitForBulkOutReady(dev);
+		if (rc != 1) {
+			DEBUG(5, "cmx_waitForBulkOutReady rc=%.2Zx\n", rc);
+			DEBUG(2, "<- cmx_write (failed)\n");
+			return -EIO;
+          	}
+	 
+		xoutb(dev->sBuf[i],iobase + REG_OFFSET_BULK_OUT);
+		DEBUG(4, "%.2x ", dev->sBuf[i]);
+	}
+	DEBUG(4, "end\n");
+
+	rc = cmx_writeSync(SCR_HOST_TO_READER_DONE, dev);
+
+	if (rc != 1) {
+		DEBUG(5, "cmx_writeSync c=%.2Zx\n", rc);
+		DEBUG(2, "<- cmx_write (failed)\n");
+		return -EIO;
+	}
+
+	DEBUG(2, "<- cmx_write (successfully)\n");
+	return count;
+}
+
+static unsigned int cmx_poll(struct file *filp, poll_table *wait)
+{
+	reader_dev_t *dev=(reader_dev_t *)filp->private_data;
+	unsigned int mask = 0;
+
+	poll_wait(filp, &dev->poll_wait, wait);
+
+	if (dev->buffer_status & BS_READABLE)
+		mask |= POLLIN | POLLRDNORM;
+	if (dev->buffer_status & BS_WRITABLE)
+		mask |= POLLOUT | POLLWRNORM;
+
+	return mask;
+}
+
+static int cmx_ioctl(struct inode *inode,struct file *filp,unsigned int cmd,
+			unsigned long arg)
+{
+	dev_link_t *link;
+	int rc, size;
+
+	link=dev_table[MINOR(inode->i_rdev)];
+	if (!(DEV_OK(link))) {
+		DEBUG(4, "DEV_OK false\n");
+		return -ENODEV;
+	}
+	if (_IOC_TYPE(cmd)!=CM_IOC_MAGIC) {
+		DEBUG(4,"ioctype mismatch\n");
+		return -EINVAL;
+	}
+	if (_IOC_NR(cmd)>CM_IOC_MAXNR) {
+		DEBUG(4,"iocnr mismatch\n");
+		return -EINVAL;
+	} 
+	size = _IOC_SIZE(cmd);
+	rc = 0;
+	DEBUG(4,"iocdir=%.4x iocr=%.4x iocw=%.4x iocsize=%d cmd=%.4x\n",
+		_IOC_DIR(cmd),_IOC_READ,_IOC_WRITE,size,cmd);
+
+	if (_IOC_DIR(cmd)&_IOC_READ) {
+		if (!access_ok(VERIFY_WRITE, (void *)arg, size))
+			return -EFAULT;
+	}
+	if (_IOC_DIR(cmd)&_IOC_WRITE) {
+		if (!access_ok(VERIFY_READ, (void *)arg, size))
+			return -EFAULT;
+	}
+
+	return rc;
+}
+
+static int cmx_open (struct inode *inode, struct file *filp)
+{
+	reader_dev_t *dev;
+	dev_link_t *link;
+	int i;
+
+	DEBUG(2, "-> cmx_open(device=%d.%d process=%s,%d)\n",
+		MAJOR(inode->i_rdev), MINOR(inode->i_rdev),
+		current->comm, current->pid);
+
+	i = MINOR(inode->i_rdev);
+	if (i >= CM_MAX_DEV) {
+		DEBUG(4, "MAX_DEV reached\n");
+		DEBUG(4, "<- cmx_open (failure)\n");
+		return -ENODEV;
+	}
+	link = dev_table[MINOR(inode->i_rdev)];
+	if (link == NULL || !(DEV_OK(link))) {
+		DEBUG(4, "link== NULL || DEV_OK false\n");
+		DEBUG(4, "<- cmx_open (failure)\n");
+		return -ENODEV;
+	}
+	if (link->open) {
+		DEBUG(4, "DEVICE BUSY\n");
+		DEBUG(4, "<- cmx_open (failure)\n");
+		return -EBUSY;
+	}
+
+	dev = (reader_dev_t *)link->priv;
+	filp->private_data = dev;
+
+	if (filp->f_flags & O_NONBLOCK) { 
+		DEBUG(4, "filep->f_flags O_NONBLOCK set\n");
+		DEBUG(4, "<- cmx_open (failure)\n");
+		return -EAGAIN;
+        }
+
+	dev->owner = current;
+	link->open = 1;		
+
+	atomic_inc(&cmx_num_devices_open);
+	mod_timer(&cmx_poll_timer, jiffies + POLL_PERIOD);
+
+	DEBUG(2, "<- cmx_open (successfully)\n");
+	return 0;
+}
+
+static int cmx_close(struct inode *inode,struct file *filp)
+{
+	reader_dev_t *dev;
+	dev_link_t *link;
+	int i;
+
+	DEBUG(2, "-> cmx_close(maj/min=%d.%d)\n",
+		MAJOR(inode->i_rdev), MINOR(inode->i_rdev));
+
+	i = MINOR(inode->i_rdev);
+	if (i >= CM_MAX_DEV)
+		return -ENODEV;
+
+	link = dev_table[MINOR(inode->i_rdev)];
+	if (link == NULL)
+		return -ENODEV;
+
+	dev = (reader_dev_t *)link->priv;
+
+	link->open = 0;
+	wake_up(&dev->devq);	
+
+	atomic_dec(&cmx_num_devices_open);
+
+	DEBUG(2, "<- cmx_close\n");
+	return 0;
+}
+
+static void cmx_reader_release(dev_link_t *link)
+{
+	reader_dev_t *dev = (reader_dev_t *)link->priv;
+
+	DEBUG(3, "-> cmx_reader_release\n"); 
+	while (link->open) {
+		DEBUG(3, KERN_INFO MODULE_NAME ": delaying release until "
+		      "process '%s', pid %d has terminated\n",
+		      dev->owner->comm,dev->owner->pid);
+ 		wait_event(dev->devq, (link->open == 0));
+	}
+	DEBUG(3, "<- cmx_reader_release\n"); 
+	return;
+}
+
+static void reader_config(dev_link_t *link, int devno)
+{
+	client_handle_t handle;
+	reader_dev_t *dev;
+	tuple_t tuple;
+	cisparse_t parse;
+	config_info_t conf;
+	u_char buf[64];
+	int fail_fn,fail_rc;
+	int rc;
+
+	DEBUG(2, "-> reader_config\n");
+
+	handle = link->handle;
+
+	tuple.DesiredTuple = CISTPL_CONFIG;
+	tuple.Attributes = 0;
+	tuple.TupleData = buf;
+	tuple.TupleDataMax = sizeof(buf);
+ 	tuple.TupleOffset = 0;
+
+	if ((fail_rc = pcmcia_get_first_tuple(handle,&tuple)) != CS_SUCCESS) {
+		fail_fn = GetFirstTuple;
+		goto cs_failed;
+	}
+	if ((fail_rc = pcmcia_get_tuple_data(handle,&tuple)) != CS_SUCCESS) {
+		fail_fn = GetTupleData;
+		goto cs_failed;
+	}
+	if ((fail_rc = pcmcia_parse_tuple(handle,&tuple,&parse))
+							!= CS_SUCCESS) {
+		fail_fn = ParseTuple;
+		goto cs_failed;
+	}
+	if ((fail_rc = pcmcia_get_configuration_info(handle,&conf))
+							!= CS_SUCCESS) {
+		fail_fn = GetConfigurationInfo;
+		goto cs_failed;
+	}
+
+	link->state |= DEV_CONFIG;
+	link->conf.ConfigBase = parse.config.base;
+	link->conf.Present = parse.config.rmask[0];
+	link->conf.Vcc = conf.Vcc;
+	DEBUG(2, "link->conf.Vcc=%d\n", link->conf.Vcc);
+
+	link->io.BasePort2 = 0;
+	link->io.NumPorts2 = 0;
+	link->io.Attributes2 = 0;
+	tuple.DesiredTuple = CISTPL_CFTABLE_ENTRY;
+	for (rc = pcmcia_get_first_tuple(handle, &tuple);
+	     rc == CS_SUCCESS;
+	     rc = pcmcia_get_next_tuple(handle, &tuple)) {
+ 		DEBUG(2, "Examing CIS Tuple!\n");
+		rc = pcmcia_get_tuple_data(handle, &tuple);
+		if (rc != CS_SUCCESS)
+			continue;
+		rc = pcmcia_parse_tuple(handle, &tuple, &parse);
+		if (rc != CS_SUCCESS)
+			continue;
+
+		DEBUG(2, "tupleIndex=%d\n", parse.cftable_entry.index);
+		link->conf.ConfigIndex = parse.cftable_entry.index;
+		
+		if (parse.cftable_entry.io.nwin) {
+			link->io.BasePort1 = parse.cftable_entry.io.win[0].base;
+			link->io.NumPorts1 = parse.cftable_entry.io.win[0].len;
+			link->io.Attributes1 = IO_DATA_PATH_WIDTH_AUTO;
+			if(!(parse.cftable_entry.io.flags & CISTPL_IO_8BIT))
+				link->io.Attributes1 = IO_DATA_PATH_WIDTH_16;
+			if(!(parse.cftable_entry.io.flags & CISTPL_IO_16BIT))
+				link->io.Attributes1 = IO_DATA_PATH_WIDTH_8;
+			link->io.IOAddrLines = parse.cftable_entry.io.flags
+						& CISTPL_IO_LINES_MASK;
+			DEBUG(2,"io.BasePort1=%.4x\n", link->io.BasePort1);
+			DEBUG(2,"io.NumPorts1=%.4x\n", link->io.NumPorts1);
+			DEBUG(2,"io.BasePort2=%.4x\n", link->io.BasePort2);
+			DEBUG(2,"io.NumPorts2=%.4x\n", link->io.NumPorts2);
+			DEBUG(2,"io.IOAddrLines=%.4x\n", 
+			      link->io.IOAddrLines);
+			rc = pcmcia_request_io(handle, &link->io);
+			if (rc == CS_SUCCESS) {
+				DEBUG(2, "RequestIO OK\n");
+				break; 
+			} else 
+				DEBUG(2, "RequestIO failed\n");
+		}
+	}
+	if (rc != CS_SUCCESS) {
+		DEBUG(2, "Couldn't configure reader\n");
+		goto cs_release;
+	}
+
+        link->conf.IntType = 00000002;
+
+	if ((fail_rc = pcmcia_request_configuration(handle,&link->conf))
+								!=CS_SUCCESS) {
+		fail_fn = RequestConfiguration;
+		DEBUG(1, "pcmcia_request_configuration failed 0x%x\n", fail_rc);
+		goto cs_release;
+	}
+
+	DEBUG(2, "RequestConfiguration OK\n");
+
+	dev = link->priv;
+	sprintf(dev->node.dev_name, DEVICE_NAME "%d", devno);
+	dev->node.major = major;
+	dev->node.minor = devno;
+	dev->node.next = NULL;
+	link->dev = &dev->node;
+	link->state &= ~DEV_CONFIG_PENDING;
+
+	DEBUG(2, "device " DEVICE_NAME "%d at 0x%.4x-0x%.4x\n", devno,
+	      link->io.BasePort1, link->io.BasePort1+link->io.NumPorts1);
+	DEBUG(2, "<- reader_config (succ)\n");
+
+	return;
+
+cs_failed:
+	cs_error(handle, fail_fn, fail_rc);
+cs_release:
+	reader_release((u_long)link);
+	link->state &= ~DEV_CONFIG_PENDING;
+	DEBUG(2, "<- reader_config (failure)\n");
+}
+
+static int reader_event(event_t event, int priority,
+			event_callback_args_t *args)
+{
+	dev_link_t *link;
+	reader_dev_t *dev;
+	int devno;
+
+	DEBUG(3,"-> reader_event\n");
+	link = args->client_data;
+	dev = link->priv;
+	for (devno = 0; devno < CM_MAX_DEV; devno++) {
+		if (dev_table[devno]==link)
+			break;
+	}
+	if (devno == CM_MAX_DEV)
+		return CS_BAD_ADAPTER;
+
+	switch (event) {
+		case CS_EVENT_CARD_INSERTION:
+			DEBUG(5, "CS_EVENT_CARD_INSERTION\n");
+			link->state |= DEV_PRESENT | DEV_CONFIG_PENDING;
+			reader_config(link,devno);
+			break;
+		case CS_EVENT_CARD_REMOVAL:
+			DEBUG(5, "CS_EVENT_CARD_REMOVAL\n");
+			link->state &= ~DEV_PRESENT;
+			break;
+		case CS_EVENT_PM_SUSPEND:
+			DEBUG(5, "CS_EVENT_PM_SUSPEND "
+			      "(fall-through to CS_EVENT_RESET_PHYSICAL)\n");
+			link->state |= DEV_SUSPEND;
+		
+		case CS_EVENT_RESET_PHYSICAL:
+			DEBUG(5, "CS_EVENT_RESET_PHYSICAL\n");
+			if (link->state & DEV_CONFIG) {
+		  		DEBUG(5, "ReleaseConfiguration\n");
+		  		pcmcia_release_configuration(link->handle);
+			}
+			break;
+		case CS_EVENT_PM_RESUME:
+			DEBUG(5, "CS_EVENT_PM_RESUME "
+			      "(fall-through to CS_EVENT_CARD_RESET)\n");
+			link->state &= ~DEV_SUSPEND;
+		
+		case CS_EVENT_CARD_RESET:
+	        	DEBUG(5, "CS_EVENT_CARD_RESET\n");
+			if ((link->state & DEV_CONFIG)) {
+				DEBUG(5, "cmx: RequestConfiguration\n");
+		  		pcmcia_request_configuration(link->handle,
+							     &link->conf);
+			}
+			break;
+		default:
+			DEBUG(5, "reader_event: unknown event %.2x\n", event);
+			break;
+	}
+	DEBUG(3, "<- reader_event\n");
+	return CS_SUCCESS;
+}
+
+static void reader_release(u_long arg)
+{
+	dev_link_t *link;
+	int rc;
+
+	DEBUG(3, "-> reader_release\n");
+	link = (dev_link_t *)arg;
+	cmx_reader_release(link->priv); 
+	rc = pcmcia_release_configuration(link->handle);
+	if (rc != CS_SUCCESS)
+		DEBUG(5, "couldn't ReleaseConfiguration "
+		      "reasoncode=%.2x\n", rc);
+	rc = pcmcia_release_io(link->handle, &link->io);
+	if (rc != CS_SUCCESS)
+		DEBUG(5, "couldn't ReleaseIO reasoncode=%.2x\n", rc);
+
+	DEBUG(3, "<- reader_release\n");
+}
+
+static dev_link_t *reader_attach(void)
+{
+	reader_dev_t *dev;
+	dev_link_t *link;
+	client_reg_t client_reg;
+	int i;
+
+	DEBUG(3, "reader_attach\n");
+	for (i=0; i < CM_MAX_DEV; i++) {
+		if (dev_table[i] == NULL)
+			break;
+	}
+
+	if (i == CM_MAX_DEV) {
+		printk(KERN_NOTICE "all devices in use\n");
+		return NULL;
+	}
+	
+	DEBUG(5, "create reader device instance\n");
+	dev = kmalloc(sizeof(reader_dev_t), GFP_KERNEL);
+	if (dev == NULL)
+		return NULL;
+
+	memset(dev, 0, sizeof(reader_dev_t));
+	dev->timeout = CCID_DRIVER_MINIMUM_TIMEOUT;
+	dev->fTimerExpired = 0;
+
+	link = &dev->link;
+	link->priv = dev;
+
+	link->conf.IntType = INT_MEMORY_AND_IO;
+	dev_table[i] = link;
+
+	
+	DEBUG(5, "Register with Card Services\n");
+	client_reg.dev_info = &dev_info;
+	client_reg.Attributes = INFO_IO_CLIENT | INFO_CARD_SHARE;
+	client_reg.EventMask=
+		CS_EVENT_CARD_INSERTION | CS_EVENT_CARD_REMOVAL |
+		CS_EVENT_RESET_PHYSICAL | CS_EVENT_CARD_RESET |
+		CS_EVENT_PM_SUSPEND | CS_EVENT_PM_RESUME;
+	client_reg.Version = 0x0210;
+	client_reg.event_callback_args.client_data = link;
+	i = pcmcia_register_client(&link->handle, &client_reg);
+	if (i) {
+		cs_error(link->handle, RegisterClient, i);
+		reader_detach(link);
+		return NULL;
+	}
+	init_waitqueue_head(&dev->devq);
+	init_waitqueue_head(&dev->poll_wait);
+	init_waitqueue_head(&dev->read_wait);
+	init_waitqueue_head(&dev->write_wait);
+	init_timer(&cmx_poll_timer);
+	cmx_poll_timer.function = &cmx_do_poll;
+
+	return link;
+}
+
+static void reader_detach_by_devno(int devno,dev_link_t *link)
+{
+	reader_dev_t *dev=link->priv;
+
+	DEBUG(3, "-> detach_by_devno(devno=%d)\n", devno);
+	if (link->state & DEV_CONFIG) {
+		DEBUG(5, "device still configured (try to release it)\n");
+		reader_release((u_long)link);
+	}
+
+	pcmcia_deregister_client(link->handle);
+	dev_table[devno] = NULL;
+	DEBUG(5, "freeing dev=%p\n", dev);
+	kfree(dev);
+	DEBUG(3, "<- detach_by-devno\n");
+	return;
+}
+
+static void reader_detach(dev_link_t *link)
+{
+	int i;
+	DEBUG(3, "-> reader_detach(link=%p\n", link);
+	/* find device */
+	for(i=0; i < CM_MAX_DEV; i++) {
+		if (dev_table[i] == link)
+			break;
+	}
+	if (i == CM_MAX_DEV) {
+		printk(KERN_WARNING MODULE_NAME 
+			": detach for unkown device aborted\n");
+		return;
+	}
+	reader_detach_by_devno(i, link);
+	DEBUG(3, "<- reader_detach\n");
+	return;
+}
+
+static struct file_operations reader_fops = {
+	.owner		= THIS_MODULE,
+	.llseek		= cmx_llseek,
+	.read		= cmx_read,
+	.write		= cmx_write,
+	.ioctl		= cmx_ioctl,
+	.open		= cmx_open,
+	.release	= cmx_close,
+	.poll		= cmx_poll,
+};
+
+static struct pcmcia_device_id cm4040_ids[] = {
+	PCMCIA_DEVICE_MANF_CARD(0x0223, 0x0200),
+	PCMCIA_DEVICE_PROD_ID12("OMNIKEY", "CardMan 4040", 
+				0xE32CDD8C, 0x8F23318B),
+	PCMCIA_DEVICE_NULL,
+};
+MODULE_DEVICE_TABLE(pcmcia, cm4040_ids);
+
+static struct pcmcia_driver reader_driver = {
+  	.owner		= THIS_MODULE,
+  	.drv		= {
+		.name	= "cm4040_cs",
+	},
+	.attach		= reader_attach,
+	.detach		= reader_detach,
+	.event		= reader_event,
+	.id_table	= cm4040_ids,
+};
+
+static int __init cmx_init(void)
+{
+	printk(KERN_INFO "%s\n", version);
+	pcmcia_register_driver(&reader_driver);
+	major = register_chrdev(0, DEVICE_NAME, &reader_fops);
+	if (major < 0) {
+		printk(KERN_WARNING MODULE_NAME
+			": could not get major number\n");
+		return -1;
+	}
+	return 0;
+}
+
+static void __exit cmx_exit(void)
+{
+	int i;
+
+	printk(KERN_INFO MODULE_NAME ": unloading\n");
+	pcmcia_unregister_driver(&reader_driver);  
+	for (i=0; i < CM_MAX_DEV; i++) {
+		if (dev_table[i])
+			reader_detach_by_devno(i, dev_table[i]);
+	}
+	unregister_chrdev(major, DEVICE_NAME);
+}
+
+module_init(cmx_init);
+module_exit(cmx_exit);
+MODULE_LICENSE("Dual BSD/GPL");
diff --git a/drivers/char/pcmcia/cm4040_cs.h b/drivers/char/pcmcia/cm4040_cs.h
new file mode 100644
--- /dev/null
+++ b/drivers/char/pcmcia/cm4040_cs.h
@@ -0,0 +1,52 @@
+#ifndef	_CM4040_H_
+#define	_CM4040_H_
+
+#define	CM_MAX_DEV		4
+
+#define	CM_IOC_MAGIC		'c'
+#define	CM_IOC_MAXNR	        255
+
+#define CM_IOSDBGLVL            _IOW(CM_IOC_MAGIC, 250, int*) 
+
+#define	DEVICE_NAME		"cmx"
+#define	MODULE_NAME		"cm4040_cs"
+
+#define REG_OFFSET_BULK_OUT      0
+#define REG_OFFSET_BULK_IN       0
+#define REG_OFFSET_BUFFER_STATUS 1
+#define REG_OFFSET_SYNC_CONTROL  2
+
+#define BSR_BULK_IN_FULL  0x02
+#define BSR_BULK_OUT_FULL 0x01
+
+#define SCR_HOST_TO_READER_START 0x80
+#define SCR_ABORT                0x40
+#define SCR_EN_NOTIFY            0x20
+#define SCR_ACK_NOTIFY           0x10
+#define SCR_READER_TO_HOST_DONE  0x08
+#define SCR_HOST_TO_READER_DONE  0x04
+#define SCR_PULSE_INTERRUPT      0x02
+#define SCR_POWER_DOWN           0x01
+
+
+#define  CMD_PC_TO_RDR_ICCPOWERON       0x62
+#define  CMD_PC_TO_RDR_GETSLOTSTATUS    0x65
+#define  CMD_PC_TO_RDR_ICCPOWEROFF      0x63
+#define  CMD_PC_TO_RDR_SECURE           0x69
+#define  CMD_PC_TO_RDR_GETPARAMETERS    0x6C
+#define  CMD_PC_TO_RDR_RESETPARAMETERS  0x6D
+#define  CMD_PC_TO_RDR_SETPARAMETERS    0x61
+#define  CMD_PC_TO_RDR_XFRBLOCK         0x6F
+#define  CMD_PC_TO_RDR_ESCAPE           0x6B
+#define  CMD_PC_TO_RDR_ICCCLOCK         0x6E
+#define  CMD_PC_TO_RDR_TEST_SECURE      0x74
+#define  CMD_PC_TO_RDR_OK_SECURE        0x89
+
+
+#define  CMD_RDR_TO_PC_SLOTSTATUS         0x81
+#define  CMD_RDR_TO_PC_DATABLOCK          0x80
+#define  CMD_RDR_TO_PC_PARAMETERS         0x82
+#define  CMD_RDR_TO_PC_ESCAPE             0x83
+#define  CMD_RDR_TO_PC_OK_SECURE          0x89
+
+#endif	/* _CM4040_H_ */

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
  2005-09-03 21:27 ` Chase Venters
  2005-09-03 22:13   ` Nish Aravamudan
@ 2005-09-04 11:20   ` Harald Welte
  2005-09-06 16:15     ` Roland Dreier
  1 sibling, 1 reply; 150+ messages in thread
From: Harald Welte @ 2005-09-04 11:20 UTC (permalink / raw)
  To: Chase Venters; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

On Sat, Sep 03, 2005 at 04:27:00PM -0500, Chase Venters wrote:
> > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> > Smartcard Reader.
> 
> Someone correct me if I'm wrong, but wouldn't these #defines be a problem with 
> the new HZ flexibility:
> 
> #define	CCID_DRIVER_BULK_DEFAULT_TIMEOUT  	(150*HZ)
> #define	CCID_DRIVER_ASYNC_POWERUP_TIMEOUT 	(35*HZ)
> #define	CCID_DRIVER_MINIMUM_TIMEOUT 		(3*HZ)

The defines above certainly have no problems.  They want to wait for
multiples of seconds.

> /* how often to poll for fifo status change */
> #define POLL_PERIOD 				(HZ/100)
> 
> In particular, 2.6.13 allows a HZ of 100, which would define POLL_PERIOD to 0. 
> Your later calls to mod_timer would be setting cmx_poll_timer to the current 
> value of jiffies. 

100/100 == 1.  As far as my limited math skills go, only 0 divided by
something can give a result of zero ;)

So yes, the code would poll every 1/100th of a second, even with HZ=100.  

Obviously, if HZ would ever go below 100, the code above would provide
some problems.  I'm not sure what the future plans with HZ are, but I'll
add an #error statement in case HZ goes smaller than that.

> Also, you've got a typo in the comments:

thanks.

-- 
- Harald Welte <laforge@gnumonks.org>          	        http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
  2005-09-04 10:12 [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver Harald Welte
                   ` (2 preceding siblings ...)
  2005-09-04 11:08 ` Harald Welte
@ 2005-09-04 12:58 ` Ingo Oeser
  2005-09-05  9:14   ` Harald Welte
  3 siblings, 1 reply; 150+ messages in thread
From: Ingo Oeser @ 2005-09-04 12:58 UTC (permalink / raw)
  To: Harald Welte; +Cc: Linux Kernel Mailinglist

[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

On Sunday 04 September 2005 12:12, Harald Welte wrote:
> cmx_llseek

just use

	return nonseekable_open(inode, filp);

as your last statement in cmx_open() instead of

	return 0;

to really disable any file pointer positioning (e.g. pwrite/pread too).

Addtionally cmx_llseek() is implement already as "no_llseek()"
by the VFS, so you delete it from the driver an use no_llseek() from
the VFS instead.


Regards

Ingo Oeser


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver 
  2005-09-03 22:27   ` Jesper Juhl
@ 2005-09-04 21:06     ` Horst von Brand
  2005-09-04 22:10       ` Jesper Juhl
  2005-09-05 10:30     ` Harald Welte
  1 sibling, 1 reply; 150+ messages in thread
From: Horst von Brand @ 2005-09-04 21:06 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: Harald Welte, Linux Kernel Mailinglist

Jesper Juhl <jesper.juhl@gmail.com> wrote:
> On 9/4/05, Harald Welte <laforge@gnumonks.org> wrote:
> > On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote:
> > > Hi!
> > >
> > > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> > > Smartcard Reader.
> > 
> > Sorry, the patch was missing a "cg-add" of the header file.  Please use
> > the patch below.
> 
> It would be so much nicer if the patch actually was "below" - that is
> "inline in the email as opposed to as an attachment". Having to first
> save an attachment and then cut'n'paste from it is a pain.
> 
> Anyway, a few comments below :

[...]

> +	unsigned long ulBytesToRead;
> 
> 
> lowercase prefered also for variables.

Also, "encoding" the type (ul) into the variable name is nonsense.

[...]

> +	ulMin = (count < (ulBytesToRead+5))?count:(ulBytesToRead+5);

Again.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
  2005-09-04 21:06     ` Horst von Brand
@ 2005-09-04 22:10       ` Jesper Juhl
  0 siblings, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2005-09-04 22:10 UTC (permalink / raw)
  To: Horst von Brand; +Cc: Harald Welte, Linux Kernel Mailinglist

On 9/4/05, Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> Jesper Juhl <jesper.juhl@gmail.com> wrote:
> > On 9/4/05, Harald Welte <laforge@gnumonks.org> wrote:
> > > On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote:
> > > > Hi!
> > > >
> > > > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> > > > Smartcard Reader.
> > >
> > > Sorry, the patch was missing a "cg-add" of the header file.  Please use
> > > the patch below.
> >
> > It would be so much nicer if the patch actually was "below" - that is
> > "inline in the email as opposed to as an attachment". Having to first
> > save an attachment and then cut'n'paste from it is a pain.
> >
> > Anyway, a few comments below :
> 
> [...]
> 
> > +     unsigned long ulBytesToRead;
> >
> >
> > lowercase prefered also for variables.
> 
> Also, "encoding" the type (ul) into the variable name is nonsense.
> 
Agreed, and it's even mentioned in CodingStyle (ok, it talks about
functions, but the same goes for variables):

...
Encoding the type of a function into the name (so-called Hungarian
notation) is brain damaged - the compiler knows the types anyway and can
check those, and it only confuses the programmer.  No wonder MicroSoft
makes buggy programs.

LOCAL variable names should be short, and to the point.  If you have
some random integer loop counter, it should probably be called "i".
Calling it "loop_counter" is non-productive, if there is no chance of it
being mis-understood.  Similarly, "tmp" can be just about any type of
variable that is used to hold a temporary value.
...



-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
  2005-09-04 12:58 ` Ingo Oeser
@ 2005-09-05  9:14   ` Harald Welte
  0 siblings, 0 replies; 150+ messages in thread
From: Harald Welte @ 2005-09-05  9:14 UTC (permalink / raw)
  To: Ingo Oeser; +Cc: Linux Kernel Mailinglist

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

On Sun, Sep 04, 2005 at 02:58:27PM +0200, Ingo Oeser wrote:

> just use
> 	return nonseekable_open(inode, filp);
> 
> to really disable any file pointer positioning (e.g. pwrite/pread too).
> 
> Addtionally cmx_llseek() is implement already as "no_llseek()"
> by the VFS, so you delete it from the driver an use no_llseek() from
> the VFS instead.

great, thanks,  I've merged your suggested changes into my local tree.
Stay tuned for a re-submit later today.

-- 
- Harald Welte <laforge@gnumonks.org>          	        http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
  2005-09-03 22:27   ` Jesper Juhl
  2005-09-04 21:06     ` Horst von Brand
@ 2005-09-05 10:30     ` Harald Welte
  1 sibling, 0 replies; 150+ messages in thread
From: Harald Welte @ 2005-09-05 10:30 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: Linux Kernel Mailinglist

[-- Attachment #1: Type: text/plain, Size: 3103 bytes --]

On Sun, Sep 04, 2005 at 12:27:20AM +0200, Jesper Juhl wrote:
> On 9/4/05, Harald Welte <laforge@gnumonks.org> wrote:
> > On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote:
> > > Hi!
> > >
> > > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> > > Smartcard Reader.
> > 
> > Sorry, the patch was missing a "cg-add" of the header file.  Please use
> > the patch below.
> 
> It would be so much nicer if the patch actually was "below" - that is
> "inline in the email as opposed to as an attachment". Having to first
> save an attachment and then cut'n'paste from it is a pain.

This is a neverending discussion.  A number of kernel develpoers I know
prefer attachements these days.  It's a matter of your email client, and
why it doesn't just append a "plaintext" attachment at the bottom of
your mail and rather display you the "save as" icon/button/whatever.

> Anyway, a few comments below :
> 
> +#define DEBUG(n, x, args...) do { if (pc_debug >= (n)) 			    \
> 
> 
> line longer than 80 chars. Please adhere to CodingStyle and keep lines
> <80 chars.

The line is _not_ longer than 80 chars, at least not if you remove the
"+" from the beginning of the patch and you hve 8 chars wide

> There's more than one occourance of this.

there was one occurrence in the file which I have missed, thanks.

> +static inline int cmx_waitForBulkOutReady(reader_dev_t *dev)
> 
> 
> Why TheStudlyCaps ?  Please keep function names lowercase. There are
> more instances of this, only pointing out one.

Yes, there are.  My initial idea was to diverge as little as possible
from the original vendor driver, making it easy to pull in changes from
their tree in the future, should it be neccessarry.

However, it has diverged that much now, it doesn't really matter whether
I also rename the functions, too.  Please stay tuned for the next
revision of the patch.

> Please use only tabs for indentation (line 1 of the above is indented
> with spaces).

thanks, should have catched all of them now.

> lowercase prefered also for variables.

done

> Space after ","s please : DEBUG(5, "cmx_waitForBulkInReady rc=%.2x\n", rc);

done

> get rid of the space before the opening paren : 
> static int cmx_open(struct inode *inode, struct file *filp)

done

> How about not having to indent so deep by rewriting that as

done

> +	cmx_poll_timer.function = &cmx_do_poll;
> 
> shouldn't this be 
> 	 cmx_poll_timer.function = cmx_do_poll;
> ???

I don't really know what difference it would make.  My understanding of
'c' is that both cases would take the address of the function.

My personal taste is rather to explicitly indicate this with an '&' than
let the compiler implicitly take the address.

-- 
- Harald Welte <laforge@gnumonks.org>          	        http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
  2005-09-04 11:20   ` Harald Welte
@ 2005-09-06 16:15     ` Roland Dreier
  2005-09-06 17:11       ` Harald Welte
  0 siblings, 1 reply; 150+ messages in thread
From: Roland Dreier @ 2005-09-06 16:15 UTC (permalink / raw)
  To: Harald Welte; +Cc: Chase Venters, linux-kernel

    Harald> Obviously, if HZ would ever go below 100, the code above
    Harald> would provide some problems.  I'm not sure what the future
    Harald> plans with HZ are, but I'll add an #error statement in
    Harald> case HZ goes smaller than that.

It might be simpler just to define it to msecs_to_jiffies(10).

 - R.

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
  2005-09-06 16:15     ` Roland Dreier
@ 2005-09-06 17:11       ` Harald Welte
  0 siblings, 0 replies; 150+ messages in thread
From: Harald Welte @ 2005-09-06 17:11 UTC (permalink / raw)
  To: Roland Dreier; +Cc: Chase Venters, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 778 bytes --]

On Tue, Sep 06, 2005 at 09:15:10AM -0700, Roland Dreier wrote:
>     Harald> Obviously, if HZ would ever go below 100, the code above
>     Harald> would provide some problems.  I'm not sure what the future
>     Harald> plans with HZ are, but I'll add an #error statement in
>     Harald> case HZ goes smaller than that.
> 
> It might be simpler just to define it to msecs_to_jiffies(10).

That's what I did in the last version that was posted to lkml ;)

-- 
- Harald Welte <laforge@gnumonks.org>          	        http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 150+ messages in thread

* GPL issues
@ 2006-04-11  6:31 Ramakanth Gunuganti
  2006-04-11  8:42 ` Jesper Juhl
                   ` (3 more replies)
  0 siblings, 4 replies; 150+ messages in thread
From: Ramakanth Gunuganti @ 2006-04-11  6:31 UTC (permalink / raw)
  To: linux-kernel

I am trying to understand the GPL boundaries for
Linux, any clarification provided on the following
issues below would be great:

As part of a project, I would like to extend the Linux
kernel to support some additional features needed for
the project, the changes will include:
  o  Modification to Linux kernel.
  o  Adding new kernel modules.
  o  New system calls/IOCTLs to use the kernel
modifications/LKMs.

All kernel changes including LKMs will be released
under GPL.

Questions:

(Any reference to GPL license while answering these
questions would be great)

1. If an application is built on top of this modified
kernel, should the application be released under GPL?
Do system calls provide a bounday for GPL? How does
this work with LKMs, all the code for LKMs will be
released but would a userspace application using the
LKMs choose not to use GPL?

2. If the application has to be packaged with the
Linux kernel, example: tarball that includes kernel +
application, can this application be released without
GPL. (The changes to Linux kernel are already released
under GPL).

3. How does this work if this application + kernel has
to run on a proprietary system on a seperate interface
card? Can I assume that once there is a clear hardware
boundary rest of the software for the system does not
have to be released under GPL? The software for the
interface card will be built and distributed
seperately from the rest of the software.

4. Can the GPL code and non-GPL code exist under the
same source tree?

5. In case of litigation, will there be pressure to
open up other parts of the software (non-GPL) running
on the same system but on other hardware components
interacting with this new package on a different
interface card?

Anyone trying to build a new application to work on
Linux must have these issues clarified, if you can
share your experiences that would be great too.

Thanks,
Ram


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-11  6:31 GPL issues Ramakanth Gunuganti
@ 2006-04-11  8:42 ` Jesper Juhl
  2006-04-11 10:51   ` Martin Mares
  2006-04-11 17:46   ` Horst von Brand
  2006-04-11 13:49 ` Kyle Moffett
                   ` (2 subsequent siblings)
  3 siblings, 2 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-04-11  8:42 UTC (permalink / raw)
  To: Ramakanth Gunuganti; +Cc: linux-kernel

On 4/11/06, Ramakanth Gunuganti <rgunugan@yahoo.com> wrote:
> I am trying to understand the GPL boundaries for
> Linux, any clarification provided on the following
> issues below would be great:
>
> As part of a project, I would like to extend the Linux
> kernel to support some additional features needed for
> the project, the changes will include:
>   o  Modification to Linux kernel.
>   o  Adding new kernel modules.
>   o  New system calls/IOCTLs to use the kernel
> modifications/LKMs.
>
> All kernel changes including LKMs will be released
> under GPL.
>
> Questions:
>

Note: The answers to the questions below are based on my own personal
understanding of the GPL and the policies of the Linux kernel.
Also contacting a lawyer would probably not be a bad idea.


> (Any reference to GPL license while answering these
> questions would be great)
>
> 1. If an application is built on top of this modified
> kernel, should the application be released under GPL?

No. Applications that merely use the services the kernel provides need
not be GPL.


> Do system calls provide a bounday for GPL? How does
> this work with LKMs, all the code for LKMs will be
> released but would a userspace application using the
> LKMs choose not to use GPL?
>
Again, a userspace application that merely use kernel services need not be GPL.


> 2. If the application has to be packaged with the
> Linux kernel, example: tarball that includes kernel +
> application, can this application be released without
> GPL. (The changes to Linux kernel are already released
> under GPL).
>
If the application is to be included in the mainline kernel tarball
and distributed from kernel.org, then I would say it would need to be
GPL.
If it's a tarball you provide with a modified kernel with all kernel
modifications released under GPL, then a userspace application bundled
in the tarball would not nessesarily need to be GPL.


> 3. How does this work if this application + kernel has
> to run on a proprietary system on a seperate interface
> card? Can I assume that once there is a clear hardware
> boundary rest of the software for the system does not
> have to be released under GPL? The software for the
> interface card will be built and distributed
> seperately from the rest of the software.
>
> 4. Can the GPL code and non-GPL code exist under the
> same source tree?
>
Not in the mainline kernel.


> 5. In case of litigation, will there be pressure to
> open up other parts of the software (non-GPL) running
> on the same system but on other hardware components
> interacting with this new package on a different
> interface card?
>
No idea.

> Anyone trying to build a new application to work on
> Linux must have these issues clarified, if you can
> share your experiences that would be great too.
>
> Thanks,
> Ram
>


--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-11  8:42 ` Jesper Juhl
@ 2006-04-11 10:51   ` Martin Mares
  2006-04-11 17:46   ` Horst von Brand
  1 sibling, 0 replies; 150+ messages in thread
From: Martin Mares @ 2006-04-11 10:51 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: Ramakanth Gunuganti, linux-kernel

Hello!

> > 1. If an application is built on top of this modified
> > kernel, should the application be released under GPL?
> 
> No. Applications that merely use the services the kernel provides need
> not be GPL.

However, this doesn't necessarily apply to cases where the kernel
modifications just export internal kernel stuff to userspace. In such
cases, the userspace application is very likely to be a derived work
of the kernel, so GPL applies there as well.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"I don't give a damn for a man that can only spell a word one way." -- M. Twain

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-11  6:31 GPL issues Ramakanth Gunuganti
  2006-04-11  8:42 ` Jesper Juhl
@ 2006-04-11 13:49 ` Kyle Moffett
  2006-04-11 15:49   ` Ramakanth Gunuganti
  2006-04-11 15:49   ` Ramakanth Gunuganti
  2006-04-11 23:06 ` David Weinehall
  2006-04-11 23:12 ` Alan Cox
  3 siblings, 2 replies; 150+ messages in thread
From: Kyle Moffett @ 2006-04-11 13:49 UTC (permalink / raw)
  To: Ramakanth Gunuganti; +Cc: linux-kernel

On Apr 11, 2006, at 02:31:27, Ramakanth Gunuganti wrote:
> I am trying to understand the GPL boundaries for Linux, any  
> clarification provided on the following issues below would be great:
> [...]
> Anyone trying to build a new application to work on Linux must have  
> these issues clarified, if you can share your experiences that  
> would be great too.

If you're planning to make money off of any code developed based in  
part off of the Linux Kernel, you should definitely contact a lawyer  
familiar with the linux kernel and ask them.  Any advice you get from  
this list should probably come prefixed with "IANAL", and as such  
isn't worth terribly much.

Cheers,
Kyle Moffett


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-11 13:49 ` Kyle Moffett
@ 2006-04-11 15:49   ` Ramakanth Gunuganti
  2006-04-11 16:07     ` linux-os (Dick Johnson)
                       ` (4 more replies)
  2006-04-11 15:49   ` Ramakanth Gunuganti
  1 sibling, 5 replies; 150+ messages in thread
From: Ramakanth Gunuganti @ 2006-04-11 15:49 UTC (permalink / raw)
  To: Kyle Moffett; +Cc: linux-kernel


Thanks for the replies, talking to a lawyer seems to
be too stringent a requirement to even evaluate Linux.
Who would be the ultimate authority to give definitive
answers to these questions? 

Since it's the Linux kernel that's under GPLv2, any
work done here should be released under GPLv2. That
part seems to be clear, however any product would
include other things that could be proprietary. If
Linux kernel is made part of this proprietary package,
how does the distribution work. Can we just claim that
part of the package is under GPL and only release the
source code for the kernel portions. 

-Ram

--- Kyle Moffett <mrmacman_g4@mac.com> wrote:

> On Apr 11, 2006, at 02:31:27, Ramakanth Gunuganti
> wrote:
> > I am trying to understand the GPL boundaries for
> Linux, any  
> > clarification provided on the following issues
> below would be great:
> > [...]
> > Anyone trying to build a new application to work
> on Linux must have  
> > these issues clarified, if you can share your
> experiences that  
> > would be great too.
> 
> If you're planning to make money off of any code
> developed based in  
> part off of the Linux Kernel, you should definitely
> contact a lawyer  
> familiar with the linux kernel and ask them.  Any
> advice you get from  
> this list should probably come prefixed with
> "IANAL", and as such  
> isn't worth terribly much.
> 
> Cheers,
> Kyle Moffett
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-11 13:49 ` Kyle Moffett
  2006-04-11 15:49   ` Ramakanth Gunuganti
@ 2006-04-11 15:49   ` Ramakanth Gunuganti
  1 sibling, 0 replies; 150+ messages in thread
From: Ramakanth Gunuganti @ 2006-04-11 15:49 UTC (permalink / raw)
  To: Kyle Moffett; +Cc: linux-kernel


Thanks for the replies, talking to a lawyer seems to
be too stringent a requirement to even evaluate Linux.
Who would be the ultimate authority to give definitive
answers to these questions? 

Since it's the Linux kernel that's under GPLv2, any
work done here should be released under GPLv2. That
part seems to be clear, however any product would
include other things that could be proprietary. If
Linux kernel is made part of this proprietary package,
how does the distribution work. Can we just claim that
part of the package is under GPL and only release the
source code for the kernel portions. 

-Ram

--- Kyle Moffett <mrmacman_g4@mac.com> wrote:

> On Apr 11, 2006, at 02:31:27, Ramakanth Gunuganti
> wrote:
> > I am trying to understand the GPL boundaries for
> Linux, any  
> > clarification provided on the following issues
> below would be great:
> > [...]
> > Anyone trying to build a new application to work
> on Linux must have  
> > these issues clarified, if you can share your
> experiences that  
> > would be great too.
> 
> If you're planning to make money off of any code
> developed based in  
> part off of the Linux Kernel, you should definitely
> contact a lawyer  
> familiar with the linux kernel and ask them.  Any
> advice you get from  
> this list should probably come prefixed with
> "IANAL", and as such  
> isn't worth terribly much.
> 
> Cheers,
> Kyle Moffett
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-11 15:49   ` Ramakanth Gunuganti
@ 2006-04-11 16:07     ` linux-os (Dick Johnson)
  2006-04-11 16:29       ` Stefan Smietanowski
  2006-04-11 16:13     ` Adrian Bunk
                       ` (3 subsequent siblings)
  4 siblings, 1 reply; 150+ messages in thread
From: linux-os (Dick Johnson) @ 2006-04-11 16:07 UTC (permalink / raw)
  To: Ramakanth Gunuganti; +Cc: Kyle Moffett, linux-kernel


On Tue, 11 Apr 2006, Ramakanth Gunuganti wrote:

>
> Thanks for the replies, talking to a lawyer seems to
> be too stringent a requirement to even evaluate Linux.
> Who would be the ultimate authority to give definitive
> answers to these questions?
>
> Since it's the Linux kernel that's under GPLv2, any
> work done here should be released under GPLv2. That
> part seems to be clear, however any product would
> include other things that could be proprietary. If
> Linux kernel is made part of this proprietary package,
> how does the distribution work. Can we just claim that
> part of the package is under GPL and only release the
> source code for the kernel portions.
>
[See bottom. Please do not top-post.]

> -Ram
>
> --- Kyle Moffett <mrmacman_g4@mac.com> wrote:
>
>> On Apr 11, 2006, at 02:31:27, Ramakanth Gunuganti
>> wrote:
>>> I am trying to understand the GPL boundaries for
>> Linux, any
>>> clarification provided on the following issues
>> below would be great:
>>> [...]
>>> Anyone trying to build a new application to work
>> on Linux must have
>>> these issues clarified, if you can share your
>> experiences that
>>> would be great too.
>>
>> If you're planning to make money off of any code
>> developed based in
>> part off of the Linux Kernel, you should definitely
>> contact a lawyer
>> familiar with the linux kernel and ask them.  Any
>> advice you get from
>> this list should probably come prefixed with
>> "IANAL", and as such
>> isn't worth terribly much.
>>
>> Cheers,
>> Kyle Moffett
>>
>>
>

Nobody can produce a definitive answer because nobody knows
what you are doing. You could be making a module that exposes
the entire contents of the kernel to user-space, then writing
user-space programs that manipulate the kernel. Such user-space
programs are then <probably> derived works and would need a GPL
License.

On the other hand, you could be making a Hexagrid-confuser(tm)
that runs a Pyrosynchrogem(tm), both proprietary items your
company manufactures for the Red Sox. You need to make a kernel
driver to interface with it, plus a whole bunch of proprietary
user-mode software to help the Red Sox win another world series.
In this case, only the driver needs to be GPL as long as it
doesn't extend or modify the established Unix/Linux API. BUT,
you imply that you need to modify the kernel in addition to
writing a driver. This means that you are extending the API,
which just __might__ require that any code that interfaces
with that extension be GPL as well. That's why you __need__
a lawyer if you are going to change the kernel to run your code.

Easiest way out is to make a conventional driver to interface
with your device. Then write proprietary code that interfaces
with it. Do not make any kernel changes, and do publish your
driver under a GPL license.

For non-US readers, the Red Sox are a baseball team.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.42 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-11 15:49   ` Ramakanth Gunuganti
  2006-04-11 16:07     ` linux-os (Dick Johnson)
@ 2006-04-11 16:13     ` Adrian Bunk
  2006-04-11 16:15     ` Kyle Moffett
                       ` (2 subsequent siblings)
  4 siblings, 0 replies; 150+ messages in thread
From: Adrian Bunk @ 2006-04-11 16:13 UTC (permalink / raw)
  To: Ramakanth Gunuganti; +Cc: Kyle Moffett, linux-kernel

On Tue, Apr 11, 2006 at 08:49:44AM -0700, Ramakanth Gunuganti wrote:
> 
> Thanks for the replies, talking to a lawyer seems to
> be too stringent a requirement to even evaluate Linux.
> Who would be the ultimate authority to give definitive
> answers to these questions? 

There is none:

The kernel has _many_ people holding a copyright on part of the kernel, 
and there's no ultimate authority except for the COPYING file shipped 
with the kernel sources.

The GPL is just a licence, and if you distribute your product to N 
countries, this means you can potentially be sued in N countries based 
on N different copyright laws.

There are things that are clear. E.g. if you'd have read the COPYING 
file shipped with the kernel sources, you could have answered at least 
one of your questions yourself.

But the exact borders of what is a "derived work" work and what is not 
are not well-defined and therefore unknown unless there have been court 
cases in all N countries you are distributing your product to.

Many things have never been challenged in court, and might never be, but 
remember that e.g. Harald Welte recently has much success with enforcing 
the GPL in cases of obvious violations at for products shipped in 
Germany at German courts.

> Since it's the Linux kernel that's under GPLv2, any
> work done here should be released under GPLv2. That
> part seems to be clear, however any product would
> include other things that could be proprietary. If
> Linux kernel is made part of this proprietary package,
> how does the distribution work. Can we just claim that
> part of the package is under GPL and only release the
> source code for the kernel portions. 

I am not a lawyer, but the distribution alone shouldn't be a problem - 
that is similar to what most Linux distributions are doing.

> -Ram

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-11 15:49   ` Ramakanth Gunuganti
  2006-04-11 16:07     ` linux-os (Dick Johnson)
  2006-04-11 16:13     ` Adrian Bunk
@ 2006-04-11 16:15     ` Kyle Moffett
  2006-04-11 16:23     ` Dave Neuer
  2006-04-11 18:58     ` Jan Engelhardt
  4 siblings, 0 replies; 150+ messages in thread
From: Kyle Moffett @ 2006-04-11 16:15 UTC (permalink / raw)
  To: Ramakanth Gunuganti; +Cc: linux-kernel

On Apr 11, 2006, at 11:49:44, Ramakanth Gunuganti wrote:
> Thanks for the replies, talking to a lawyer seems to be too  
> stringent a requirement to even evaluate Linux.  Who would be the  
> ultimate authority to give definitive answers to these questions?

Once again, as I said before, a lawyer.  There are currently very few  
GPL-related precedents, and none on that particular topic.  The best  
place to get advice is a lawyer.   Think of it as though you were  
licensing some code from another proprietary company for inclusion in  
your product; there you would _definitely_ talk to a lawyer.  The  
"ultimate authority" is your local/regional/national courts, a local  
lawyer is best able to use your particular set of laws to interpret  
what your courts are likely to decide and advise you accordingly.   
Nobody on this list can give you that kind of legal advice, at least  
not for free.

> Since it's the Linux kernel that's under GPLv2, any work done here  
> should be released under GPLv2.

Any "Derivative Work" of the Linux kernel must be licensed under the  
GPL.  The definition of "Derivative Work" is hard to resolve in  
detail.  Most kernel developers (including Linus himself) believe  
that all kernel modules are derivative works due to the unique and  
variable nature of the in-kernel APIs.  It is almost always held that  
userspace-only programs are _not_ derivative works.  On the other  
hand, if you export some kernel-internal API directly to userspace  
through a syscall, any program that uses it might be considered a  
derivative work.

> Can we just claim that part of the package is under GPL and only  
> release the source code for the kernel portions.

It really depends, which is why I suggest you contact a lawyer versed  
in this field.  Virtually none of the people on this list can give  
you any definitive answers, especially without access to the product  
itself, and even then they would most likely just tell you of their  
personal opinion which has no legal weight whatsoever.

Cheers,
Kyle Moffett

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-11 15:49   ` Ramakanth Gunuganti
                       ` (2 preceding siblings ...)
  2006-04-11 16:15     ` Kyle Moffett
@ 2006-04-11 16:23     ` Dave Neuer
  2006-04-11 18:58     ` Jan Engelhardt
  4 siblings, 0 replies; 150+ messages in thread
From: Dave Neuer @ 2006-04-11 16:23 UTC (permalink / raw)
  To: Ramakanth Gunuganti; +Cc: Kyle Moffett, linux-kernel

On 4/11/06, Ramakanth Gunuganti <rgunugan@yahoo.com> wrote:
>
> Thanks for the replies, talking to a lawyer seems to
> be too stringent a requirement to even evaluate Linux.
> Who would be the ultimate authority to give definitive
> answers to these questions?

A lawyer. The questions you are asking are inherently legal ones, and
any answer you get on this mailing list (which is a technical list,
not a legal one) is not going to be the *real* answer. The "ultimate
authority" you're asking for here is the court system, so if you're
concerned about legal liability for copyright infringement due to a
product you plan to distribute, you need to hire a lawyer.

Dave

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-11 16:07     ` linux-os (Dick Johnson)
@ 2006-04-11 16:29       ` Stefan Smietanowski
  0 siblings, 0 replies; 150+ messages in thread
From: Stefan Smietanowski @ 2006-04-11 16:29 UTC (permalink / raw)
  To: linux-os (Dick Johnson); +Cc: Ramakanth Gunuganti, Kyle Moffett, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 3277 bytes --]

linux-os (Dick Johnson) wrote:
> On Tue, 11 Apr 2006, Ramakanth Gunuganti wrote:
> 
> 
>>Thanks for the replies, talking to a lawyer seems to
>>be too stringent a requirement to even evaluate Linux.
>>Who would be the ultimate authority to give definitive
>>answers to these questions?
>>
>>Since it's the Linux kernel that's under GPLv2, any
>>work done here should be released under GPLv2. That
>>part seems to be clear, however any product would
>>include other things that could be proprietary. If
>>Linux kernel is made part of this proprietary package,
>>how does the distribution work. Can we just claim that
>>part of the package is under GPL and only release the
>>source code for the kernel portions.
>>
> 
> [See bottom. Please do not top-post.]
> 
> 
>>-Ram
>>
>>--- Kyle Moffett <mrmacman_g4@mac.com> wrote:
>>
>>
>>>On Apr 11, 2006, at 02:31:27, Ramakanth Gunuganti
>>>wrote:
>>>
>>>>I am trying to understand the GPL boundaries for
>>>
>>>Linux, any
>>>
>>>>clarification provided on the following issues
>>>
>>>below would be great:
>>>
>>>>[...]
>>>>Anyone trying to build a new application to work
>>>
>>>on Linux must have
>>>
>>>>these issues clarified, if you can share your
>>>
>>>experiences that
>>>
>>>>would be great too.
>>>
>>>If you're planning to make money off of any code
>>>developed based in
>>>part off of the Linux Kernel, you should definitely
>>>contact a lawyer
>>>familiar with the linux kernel and ask them.  Any
>>>advice you get from
>>>this list should probably come prefixed with
>>>"IANAL", and as such
>>>isn't worth terribly much.
>>>
>>>Cheers,
>>>Kyle Moffett
>>>
>>>
>>
> 
> Nobody can produce a definitive answer because nobody knows
> what you are doing. You could be making a module that exposes
> the entire contents of the kernel to user-space, then writing
> user-space programs that manipulate the kernel. Such user-space
> programs are then <probably> derived works and would need a GPL
> License.
> 
> On the other hand, you could be making a Hexagrid-confuser(tm)
> that runs a Pyrosynchrogem(tm), both proprietary items your
> company manufactures for the Red Sox. You need to make a kernel
> driver to interface with it, plus a whole bunch of proprietary
> user-mode software to help the Red Sox win another world series.
> In this case, only the driver needs to be GPL as long as it
> doesn't extend or modify the established Unix/Linux API. BUT,
> you imply that you need to modify the kernel in addition to
> writing a driver. This means that you are extending the API,
> which just __might__ require that any code that interfaces
> with that extension be GPL as well. That's why you __need__
> a lawyer if you are going to change the kernel to run your code.
> 
> Easiest way out is to make a conventional driver to interface
> with your device. Then write proprietary code that interfaces
> with it. Do not make any kernel changes, and do publish your
> driver under a GPL license.

Might be worth mentioning that if you intend to write a driver
that interfaces with any kernel under any license (bar any
kernel that you write yourself), be it Windows, Linux, *BSD,
etc you SHOULD talk to a lawyer as every license has it's
quirks and gotchas.

This is NOT specific to the GPL or the Linux kernel.

// Stefan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues 
  2006-04-11  8:42 ` Jesper Juhl
  2006-04-11 10:51   ` Martin Mares
@ 2006-04-11 17:46   ` Horst von Brand
  1 sibling, 0 replies; 150+ messages in thread
From: Horst von Brand @ 2006-04-11 17:46 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: Ramakanth Gunuganti, linux-kernel

Jesper Juhl <jesper.juhl@gmail.com> wrote:
> On 4/11/06, Ramakanth Gunuganti <rgunugan@yahoo.com> wrote:
> > I am trying to understand the GPL boundaries for
> > Linux, any clarification provided on the following
> > issues below would be great:
> >
> > As part of a project, I would like to extend the Linux
> > kernel to support some additional features needed for
> > the project, the changes will include:
> >   o  Modification to Linux kernel.
> >   o  Adding new kernel modules.
> >   o  New system calls/IOCTLs to use the kernel
> > modifications/LKMs.
> >
> > All kernel changes including LKMs will be released
> > under GPL.
> >
> > Questions:

> Note: The answers to the questions below are based on my own personal
> understanding of the GPL and the policies of the Linux kernel.

IANAL either.

> Also contacting a lawyer would probably not be a bad idea.

Essential, not just a good idea. Just pick one who /does/ have a grasp of
GPL and like issues.

> > (Any reference to GPL license while answering these
> > questions would be great)
> >
> > 1. If an application is built on top of this modified
> > kernel, should the application be released under GPL?
> 
> No. Applications that merely use the services the kernel provides need
> not be GPL.

But AFAIU there is a fine line here... at least /in spirit/, adding system
calls and IOCTLs and... just for the particular use of a particular closed
source application is definitely wrong. It might be legally OK (I don't
know; the opinion here is divided on that kind of matter, see f.ex. the
regularly scheduled flamefest about binary modules), but morally it is at
least suspicious.

> > Do system calls provide a bounday for GPL? How does
> > this work with LKMs, all the code for LKMs will be
> > released but would a userspace application using the
> > LKMs choose not to use GPL?

> Again, a userspace application that merely use kernel services need not
> be GPL.

As long as it uses the standard system calls. Adding special system calls
might (should?) change that...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-11 15:49   ` Ramakanth Gunuganti
                       ` (3 preceding siblings ...)
  2006-04-11 16:23     ` Dave Neuer
@ 2006-04-11 18:58     ` Jan Engelhardt
  2006-04-14 11:39       ` David Schwartz
  4 siblings, 1 reply; 150+ messages in thread
From: Jan Engelhardt @ 2006-04-11 18:58 UTC (permalink / raw)
  To: Ramakanth Gunuganti; +Cc: Kyle Moffett, linux-kernel

>Since it's the Linux kernel that's under GPLv2, any
>work done here should be released under GPLv2. That
>part seems to be clear, however any product would
>include other things that could be proprietary.

One thing that is clear in the GPL: If you link the kernel with something 
else to an executable, the resulting blob (and therefore the sources to the 
proprietary part) must be GPL.

Linking by making certain parts shared libraries is already a gray zone.

If in doubt, release everything. It also offers users the possibility to 
find your bugs.


Jan Engelhardt
-- 

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-11  6:31 GPL issues Ramakanth Gunuganti
  2006-04-11  8:42 ` Jesper Juhl
  2006-04-11 13:49 ` Kyle Moffett
@ 2006-04-11 23:06 ` David Weinehall
  2006-04-12  2:38   ` Joshua Hudson
  2006-04-11 23:12 ` Alan Cox
  3 siblings, 1 reply; 150+ messages in thread
From: David Weinehall @ 2006-04-11 23:06 UTC (permalink / raw)
  To: Ramakanth Gunuganti; +Cc: linux-kernel

OK, simplified rules; if you follow them you should generally be OK:

1. Changes to kernel --> GPL

2. Kernel driver --> GPL

3. Userspace code that uses interfaces that was not exposed to userspace
before you change the kernel --> GPL (but don't do it; there's almost
always a reason why an interface is not exported to userspace)

4. Userspace code that only uses existing interfaces --> choose
license yourself (but of course, GPL would be nice...)

5. Userspace code that depends on interfaces you added to the kernel
--> consult a lawyer (if this interface is something completely new,
you can *probably* use your own license for the userland part; if the
interface is more or less a wrapper of existing functionality, GPL)

And of course, I'm not a lawyer either...


Regards: David Weinehall
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-11  6:31 GPL issues Ramakanth Gunuganti
                   ` (2 preceding siblings ...)
  2006-04-11 23:06 ` David Weinehall
@ 2006-04-11 23:12 ` Alan Cox
  3 siblings, 0 replies; 150+ messages in thread
From: Alan Cox @ 2006-04-11 23:12 UTC (permalink / raw)
  To: Ramakanth Gunuganti; +Cc: linux-kernel

On Llu, 2006-04-10 at 23:31 -0700, Ramakanth Gunuganti wrote:
> 1. If an application is built on top of this modified
> kernel, should the application be released under GPL?
> Do system calls provide a bounday for GPL? How does
> this work with LKMs, all the code for LKMs will be
> released but would a userspace application using the
> LKMs choose not to use GPL?

The boundary of the GPL is what is called a "derivative work". This is
the basic concept in law used by copyright and essentially asks "is this
work created in such a way that it is based on the original work in some
meaningful fashion". Its a complex area of law and only a lawyer can
give definitive answers.

The usual case is releasing an application for the Linux OS. It is
unlikely that using system calls could be considered "derivative" and in
case there is doubt the copying file with the Linux kernel specifically
excludes this case because the authors don't want some peculiar legal
interpretation to suddenely try and claim rights on applications running
on Linux.

Your questions really come into the realm of lawyers not programmers
however especially the various fringe areas.

The simple "application for Linux" case is clear. The simple "kernel
modification" case is also clear. In the middle is the vague area that
is for lawyers.



^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-11 23:06 ` David Weinehall
@ 2006-04-12  2:38   ` Joshua Hudson
  2006-04-12  3:18     ` Mark Lord
  0 siblings, 1 reply; 150+ messages in thread
From: Joshua Hudson @ 2006-04-12  2:38 UTC (permalink / raw)
  To: Ramakanth Gunuganti, linux-kernel

On 4/11/06, David Weinehall <tao@acc.umu.se> wrote:
> OK, simplified rules; if you follow them you should generally be OK:
>
> 1. Changes to kernel --> GPL
>
> 2. Kernel driver --> GPL
>
> 3. Userspace code that uses interfaces that was not exposed to userspace
> before you change the kernel --> GPL (but don't do it; there's almost
> always a reason why an interface is not exported to userspace)
>
> 4. Userspace code that only uses existing interfaces --> choose
> license yourself (but of course, GPL would be nice...)
>
> 5. Userspace code that depends on interfaces you added to the kernel
> --> consult a lawyer (if this interface is something completely new,
> you can *probably* use your own license for the userland part; if the
> interface is more or less a wrapper of existing functionality, GPL)
>
> And of course, I'm not a lawyer either...
Excellent summary except for one case. Propriatary binary allowed in initramfs?
Not that I care.

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-12  2:38   ` Joshua Hudson
@ 2006-04-12  3:18     ` Mark Lord
  2006-04-12  5:00       ` Kyle Moffett
  2006-04-12  5:31       ` Arjan van de Ven
  0 siblings, 2 replies; 150+ messages in thread
From: Mark Lord @ 2006-04-12  3:18 UTC (permalink / raw)
  To: Joshua Hudson; +Cc: Ramakanth Gunuganti, linux-kernel

Joshua Hudson wrote:
> On 4/11/06, David Weinehall <tao@acc.umu.se> wrote:
>> OK, simplified rules; if you follow them you should generally be OK:
..
>> 3. Userspace code that uses interfaces that was not exposed to userspace
>> before you change the kernel --> GPL (but don't do it; there's almost
>> always a reason why an interface is not exported to userspace)
>>
>> 4. Userspace code that only uses existing interfaces --> choose
>> license yourself (but of course, GPL would be nice...)

Err.. there is ZERO difference between situations 3 and 4.
Userspace code can be any license one wants, regardless of where
or when or how the syscalls are added to the kernel.

Cheers

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-12  3:18     ` Mark Lord
@ 2006-04-12  5:00       ` Kyle Moffett
  2006-04-12  5:31       ` Arjan van de Ven
  1 sibling, 0 replies; 150+ messages in thread
From: Kyle Moffett @ 2006-04-12  5:00 UTC (permalink / raw)
  To: Mark Lord; +Cc: Joshua Hudson, Ramakanth Gunuganti, linux-kernel

On Apr 11, 2006, at 23:18:04, Mark Lord wrote:
> Joshua Hudson wrote:
>> On 4/11/06, David Weinehall <tao@acc.umu.se> wrote:
>>> OK, simplified rules; if you follow them you should generally be OK:
> ..
>>> 3. Userspace code that uses interfaces that was not exposed to  
>>> userspace before you change the kernel --> GPL (but don't do it;  
>>> there's almost always a reason why an interface is not exported  
>>> to userspace)
>>>
>>> 4. Userspace code that only uses existing interfaces --> choose  
>>> license yourself (but of course, GPL would be nice...)
>
> Err.. there is ZERO difference between situations 3 and 4.   
> Userspace code can be any license one wants, regardless of where or  
> when or how the syscalls are added to the kernel.

Not necessarily, there may be grey area.  The new splice() syscall,  
for example; does any other software have a syscall that even  
remotely resembles it?  Could a piece of software that uses the splice 
() syscall be said to stand on its own as a separate work?  Those are  
the questions you should be asking.  For that particular case, the  
answers are probably yes; _especially_ if the program in question has  
an abstraction library for file IO.  Now let's discuss a binary  
program specifically designed to read and write several sysfs files.   
Does any other operating system have anything like sysfs?  Could that  
program be said to stand on its own?  Would it work without  
linux-2.6?  It doesn't even work on linux-2.4!  Would that be  
considered a "derivative work"??  I don't know the answers to these  
questions, and I suspect it would depend a _lot_ on what the software  
did with those interfaces, how it used the functionality, etc.

A program that doesn't use more than standard SysV/UNIX/POSIX/ANSI/ 
etc functionality, or provides an abstraction layer so that it works  
on more than just Linux is definitely OK.  It stands distinct from  
the kernel; does not strictly depend on a particular version of a  
particular operating system.  A module that links directly into the  
kernel and messes with its internals is most certainly NOT ok.  The  
grey area in between is exceptionally unclear.  I don't think we can  
state for certain until a legal case comes up in the courts, but  
let's just hope it never comes to that.

Cheers,
Kyle Moffett


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-12  3:18     ` Mark Lord
  2006-04-12  5:00       ` Kyle Moffett
@ 2006-04-12  5:31       ` Arjan van de Ven
  2006-04-12  5:45         ` jdow
  2006-04-13 22:17         ` Mark Lord
  1 sibling, 2 replies; 150+ messages in thread
From: Arjan van de Ven @ 2006-04-12  5:31 UTC (permalink / raw)
  To: Mark Lord; +Cc: Joshua Hudson, Ramakanth Gunuganti, linux-kernel

On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
> Joshua Hudson wrote:
> > On 4/11/06, David Weinehall <tao@acc.umu.se> wrote:
> >> OK, simplified rules; if you follow them you should generally be OK:
> ..
> >> 3. Userspace code that uses interfaces that was not exposed to userspace
> >> before you change the kernel --> GPL (but don't do it; there's almost
> >> always a reason why an interface is not exported to userspace)
> >>
> >> 4. Userspace code that only uses existing interfaces --> choose
> >> license yourself (but of course, GPL would be nice...)
> 
> Err.. there is ZERO difference between situations 3 and 4.
> Userspace code can be any license one wants, regardless of where
> or when or how the syscalls are added to the kernel.

that is not so clear if the syscalls were added exclusively for this
application by the authors of the application....



^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-12  5:31       ` Arjan van de Ven
@ 2006-04-12  5:45         ` jdow
  2006-04-12  6:01           ` David Weinehall
  2006-04-12 14:51           ` Arjan van de Ven
  2006-04-13 22:17         ` Mark Lord
  1 sibling, 2 replies; 150+ messages in thread
From: jdow @ 2006-04-12  5:45 UTC (permalink / raw)
  To: Arjan van de Ven, Mark Lord
  Cc: Joshua Hudson, Ramakanth Gunuganti, linux-kernel

> On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
>> Joshua Hudson wrote:
>> > On 4/11/06, David Weinehall <tao@acc.umu.se> wrote:
>> >> OK, simplified rules; if you follow them you should generally be OK:
>> ..
>> >> 3. Userspace code that uses interfaces that was not exposed to userspace
>> >> before you change the kernel --> GPL (but don't do it; there's almost
>> >> always a reason why an interface is not exported to userspace)
>> >>
>> >> 4. Userspace code that only uses existing interfaces --> choose
>> >> license yourself (but of course, GPL would be nice...)
>> 
>> Err.. there is ZERO difference between situations 3 and 4.
>> Userspace code can be any license one wants, regardless of where
>> or when or how the syscalls are added to the kernel.
> 
> that is not so clear if the syscalls were added exclusively for this
> application by the authors of the application....

Consider a book. The book is GPLed. I do not have to GPL my brain when
I read the book.

I add some margin notes to the GPLed book. I still do not have to GPL
my brain when I read the book.

{^_^}   Joanne Dow

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-12  5:45         ` jdow
@ 2006-04-12  6:01           ` David Weinehall
  2006-04-12  6:26             ` jdow
  2006-04-12  9:13             ` Stefan Smietanowski
  2006-04-12 14:51           ` Arjan van de Ven
  1 sibling, 2 replies; 150+ messages in thread
From: David Weinehall @ 2006-04-12  6:01 UTC (permalink / raw)
  To: jdow
  Cc: Arjan van de Ven, Mark Lord, Joshua Hudson, Ramakanth Gunuganti,
	linux-kernel

On Tue, Apr 11, 2006 at 10:45:55PM -0700, jdow wrote:
> >On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
> >>Joshua Hudson wrote:
> >>> On 4/11/06, David Weinehall <tao@acc.umu.se> wrote:
> >>>> OK, simplified rules; if you follow them you should generally be OK:
> >>..
> >>>> 3. Userspace code that uses interfaces that was not exposed to 
> >>userspace
> >>>> before you change the kernel --> GPL (but don't do it; there's almost
> >>>> always a reason why an interface is not exported to userspace)
> >>>>
> >>>> 4. Userspace code that only uses existing interfaces --> choose
> >>>> license yourself (but of course, GPL would be nice...)
> >>
> >>Err.. there is ZERO difference between situations 3 and 4.
> >>Userspace code can be any license one wants, regardless of where
> >>or when or how the syscalls are added to the kernel.
> >
> >that is not so clear if the syscalls were added exclusively for this
> >application by the authors of the application....
> 
> Consider a book. The book is GPLed. I do not have to GPL my brain when
> I read the book.
> 
> I add some margin notes to the GPLed book. I still do not have to GPL
> my brain when I read the book.

This is possibly the worst comparison I've read in a long long time...

It's rather a case of:

Consider a book.  The book is GPLed.  You take add one chapter to the
book.  The resulting book needs to be GPLed.

Now, instead of adding to that book, you "export" parts of the book by
copying them into your book.  Your new book wouldn't work without the
copied parts.  Your resulting book needs to be GPLed.

Your "read the book"-case is only comparable to the case of building
a userspace binary for local use that only uses existing interfaces,
vs building one that uses exported private interfaces.  In both cases,
since you're not distributing your modified version, you're free to
do whatever you like.


Regards: David
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-12  6:01           ` David Weinehall
@ 2006-04-12  6:26             ` jdow
  2006-04-12  9:13             ` Stefan Smietanowski
  1 sibling, 0 replies; 150+ messages in thread
From: jdow @ 2006-04-12  6:26 UTC (permalink / raw)
  To: David Weinehall
  Cc: Arjan van de Ven, Mark Lord, Joshua Hudson, Ramakanth Gunuganti,
	linux-kernel

From: "David Weinehall" <tao@acc.umu.se>
> On Tue, Apr 11, 2006 at 10:45:55PM -0700, jdow wrote:
>> >On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
>> >>Joshua Hudson wrote:
>> >>> On 4/11/06, David Weinehall <tao@acc.umu.se> wrote:
>> >>>> OK, simplified rules; if you follow them you should generally be OK:
>> >>..
>> >>>> 3. Userspace code that uses interfaces that was not exposed to 
>> >>userspace
>> >>>> before you change the kernel --> GPL (but don't do it; there's almost
>> >>>> always a reason why an interface is not exported to userspace)
>> >>>>
>> >>>> 4. Userspace code that only uses existing interfaces --> choose
>> >>>> license yourself (but of course, GPL would be nice...)
>> >>
>> >>Err.. there is ZERO difference between situations 3 and 4.
>> >>Userspace code can be any license one wants, regardless of where
>> >>or when or how the syscalls are added to the kernel.
>> >
>> >that is not so clear if the syscalls were added exclusively for this
>> >application by the authors of the application....
>> 
>> Consider a book. The book is GPLed. I do not have to GPL my brain when
>> I read the book.
>> 
>> I add some margin notes to the GPLed book. I still do not have to GPL
>> my brain when I read the book.
> 
> This is possibly the worst comparison I've read in a long long time...
> 
> It's rather a case of:
> 
> Consider a book.  The book is GPLed.  You take add one chapter to the
> book.  The resulting book needs to be GPLed.

I am with you this far.

> Now, instead of adding to that book, you "export" parts of the book by
> copying them into your book.  Your new book wouldn't work without the
> copied parts.  Your resulting book needs to be GPLed.

Nothing is exported except to the reader's brain aka user space. It
is not exported to a new book.

Exporting a new interface is equivalent to making the marginal notes.

You can still READ the book without GPLing your brain or your
application. You can make additional temporary marginal notes,
place data into the kernel which causes the kernel to disgorge
some data.

> Your "read the book"-case is only comparable to the case of building
> a userspace binary for local use that only uses existing interfaces,
> vs building one that uses exported private interfaces.  In both cases,
> since you're not distributing your modified version, you're free to
> do whatever you like.

Either you cannot have a non-GPL program on the kernel OR you can. It
makes no difference if the kernel is modified (the modification is GPL)
or the kernel is not modified. The modified kernel must be distributed
as source if requested. The application does not unless EVERY application
must be distributed with source.

There is apparently no argument with regards to applications that are
not GPL running on LINUX. Therefore there should be no argument with
an application that uses a newly exported API being GPLed.

If you are considering the potential case that the modification is made
to the kernel and then the source for that modification is also used in
user space in an application requiring the application to be GPLed then
you must first prove it was done in that order rather than the other order.
Code can also be released dual licensed. GPL for the kernel and private
for the user space, if it is done so by the owner or creator of the code
in question. Anything else is absurd on its face.

{^_^}   Joanne Dow

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-12  6:01           ` David Weinehall
  2006-04-12  6:26             ` jdow
@ 2006-04-12  9:13             ` Stefan Smietanowski
  2006-04-12 11:33               ` Olivier Galibert
  1 sibling, 1 reply; 150+ messages in thread
From: Stefan Smietanowski @ 2006-04-12  9:13 UTC (permalink / raw)
  To: David Weinehall
  Cc: jdow, Arjan van de Ven, Mark Lord, Joshua Hudson,
	Ramakanth Gunuganti, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2811 bytes --]

David Weinehall wrote:
> On Tue, Apr 11, 2006 at 10:45:55PM -0700, jdow wrote:
> 
>>>On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
>>>
>>>>Joshua Hudson wrote:
>>>>
>>>>>On 4/11/06, David Weinehall <tao@acc.umu.se> wrote:
>>>>>
>>>>>>OK, simplified rules; if you follow them you should generally be OK:
>>>>
>>>>..
>>>>
>>>>>>3. Userspace code that uses interfaces that was not exposed to 
>>>>
>>>>userspace
>>>>
>>>>>>before you change the kernel --> GPL (but don't do it; there's almost
>>>>>>always a reason why an interface is not exported to userspace)
>>>>>>
>>>>>>4. Userspace code that only uses existing interfaces --> choose
>>>>>>license yourself (but of course, GPL would be nice...)
>>>>
>>>>Err.. there is ZERO difference between situations 3 and 4.
>>>>Userspace code can be any license one wants, regardless of where
>>>>or when or how the syscalls are added to the kernel.
>>>
>>>that is not so clear if the syscalls were added exclusively for this
>>>application by the authors of the application....
>>
>>Consider a book. The book is GPLed. I do not have to GPL my brain when
>>I read the book.
>>
>>I add some margin notes to the GPLed book. I still do not have to GPL
>>my brain when I read the book.
> 
> 
> This is possibly the worst comparison I've read in a long long time...
> 
> It's rather a case of:
> 
> Consider a book.  The book is GPLed.  You take add one chapter to the
> book.  The resulting book needs to be GPLed.
> 
> Now, instead of adding to that book, you "export" parts of the book by
> copying them into your book.  Your new book wouldn't work without the
> copied parts.  Your resulting book needs to be GPLed.
> 
> Your "read the book"-case is only comparable to the case of building
> a userspace binary for local use that only uses existing interfaces,
> vs building one that uses exported private interfaces.  In both cases,
> since you're not distributing your modified version, you're free to
> do whatever you like.
> 
> 
> Regards: David

IANAL But I don't think that makes any difference at all.

The INTERACTION between syscalls and userspace is not a topic for
discussion really. Otherwise we'd have to put the boundary at
"syscalls that the Linux Gurus added" vs "syscalls someone else added
cause they thought they were neat".

NONE of the ones in the "neat" category are ever to be used ever by
ANY non-GPL program.

That is what it boils down to. I add a syscall to the kernel, you don't
like it? Tough, it's GPL so I can distribute it, etc etc.

A program emerges that uses that syscall? You don't like that ?
Equally tough. It doesn't matter if I wrote both parts or just one,
we're not looking at INTENT here. Either programs can be non-GPL
or they can't.

Btw, no I'm not jumping at anyone here, I am just trying to show
a point.

// Stefan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-12  9:13             ` Stefan Smietanowski
@ 2006-04-12 11:33               ` Olivier Galibert
  0 siblings, 0 replies; 150+ messages in thread
From: Olivier Galibert @ 2006-04-12 11:33 UTC (permalink / raw)
  To: linux-kernel

On Wed, Apr 12, 2006 at 11:13:17AM +0200, Stefan Smietanowski wrote:
> A program emerges that uses that syscall? You don't like that ?
> Equally tough. It doesn't matter if I wrote both parts or just one,
> we're not looking at INTENT here. Either programs can be non-GPL
> or they can't.

Intent is clearly taken into account by courts.  And in any case check
the history of the objective C frontend in gcc.

  OG.

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-12  5:45         ` jdow
  2006-04-12  6:01           ` David Weinehall
@ 2006-04-12 14:51           ` Arjan van de Ven
  2006-04-13 22:07             ` Mark Lord
  1 sibling, 1 reply; 150+ messages in thread
From: Arjan van de Ven @ 2006-04-12 14:51 UTC (permalink / raw)
  To: jdow; +Cc: Mark Lord, Joshua Hudson, Ramakanth Gunuganti, linux-kernel

On Tue, 2006-04-11 at 22:45 -0700, jdow wrote:
> > On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
> >> Joshua Hudson wrote:
> >> > On 4/11/06, David Weinehall <tao@acc.umu.se> wrote:
> >> >> OK, simplified rules; if you follow them you should generally be OK:
> >> ..
> >> >> 3. Userspace code that uses interfaces that was not exposed to userspace
> >> >> before you change the kernel --> GPL (but don't do it; there's almost
> >> >> always a reason why an interface is not exported to userspace)
> >> >>
> >> >> 4. Userspace code that only uses existing interfaces --> choose
> >> >> license yourself (but of course, GPL would be nice...)
> >> 
> >> Err.. there is ZERO difference between situations 3 and 4.
> >> Userspace code can be any license one wants, regardless of where
> >> or when or how the syscalls are added to the kernel.
> > 
> > that is not so clear if the syscalls were added exclusively for this
> > application by the authors of the application....
> 
> Consider a book. The book is GPLed. I do not have to GPL my brain when
> I read the book.
> 
> I add some margin notes to the GPLed book. I still do not have to GPL
> my brain when I read the book.

wrong comparison

you have a book, book is gpl'd. You have another book with another plot.
THat other book doesn't need to be gpl'd.

you have a book, book is gpl'd. Your other book now requires the first
book to change it's plot so that the two books form a series. This is
where your lawyer will get nervous.

Think of it differently perhaps, and it's a question of "where is the
boundary of the work"

You can see the situation with the syscall change in 2 ways:

1) kernel + modification is a work
   userspace app is a separate work

or

2) kernel is a work
   userspace app and the kernel modification are together one work

in this 2nd case you have a GPL issue. The question is if your lawyer
can convince the judge that the second interpretation is unreasonable.
That may or may not be easy, depending on the exact nature of the
modification.



^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-12 14:51           ` Arjan van de Ven
@ 2006-04-13 22:07             ` Mark Lord
  2006-04-15 11:14               ` Arjan van de Ven
  0 siblings, 1 reply; 150+ messages in thread
From: Mark Lord @ 2006-04-13 22:07 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: jdow, Joshua Hudson, Ramakanth Gunuganti, linux-kernel

/usr/src/linux/COPYING:

NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-12  5:31       ` Arjan van de Ven
  2006-04-12  5:45         ` jdow
@ 2006-04-13 22:17         ` Mark Lord
  2006-04-15 11:15           ` Arjan van de Ven
  1 sibling, 1 reply; 150+ messages in thread
From: Mark Lord @ 2006-04-13 22:17 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Mark Lord, Joshua Hudson, Ramakanth Gunuganti, linux-kernel

Arjan van de Ven wrote:
> On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
>> Joshua Hudson wrote:
>>> On 4/11/06, David Weinehall <tao@acc.umu.se> wrote:
>>>> OK, simplified rules; if you follow them you should generally be OK:
>> ..
>>>> 3. Userspace code that uses interfaces that was not exposed to userspace
>>>> before you change the kernel --> GPL (but don't do it; there's almost
>>>> always a reason why an interface is not exported to userspace)
>>>>
>>>> 4. Userspace code that only uses existing interfaces --> choose
>>>> license yourself (but of course, GPL would be nice...)
>> Err.. there is ZERO difference between situations 3 and 4.
>> Userspace code can be any license one wants, regardless of where
>> or when or how the syscalls are added to the kernel.
> 
> that is not so clear if the syscalls were added exclusively for this
> application by the authors of the application....

Neither the GPL nor the kernel's COPYING file restricts anyone
from making kernel changes.  In fact, the GPL expressly permits
anyone to modify the kernel.  So how the syscalls get there is
of zero relevance here.

Now, the syscall interface itself appears to be expressly exempted
from any GPL considerations by the kernel's COPYING file:

>NOTE! This copyright does *not* cover user programs that use kernel
> services by normal system calls - this is merely considered normal use
> of the kernel, and does *not* fall under the heading of "derived work".

Heh.. but the lawyers are not completely out of their hourly fees yet,
since Linus unfortunately included that little undefined "normal" word.

Cheers

^ permalink raw reply	[flat|nested] 150+ messages in thread

* RE: GPL issues
  2006-04-11 18:58     ` Jan Engelhardt
@ 2006-04-14 11:39       ` David Schwartz
  2006-04-14 14:54         ` linux-os (Dick Johnson)
  2006-04-14 17:50         ` David Weinehall
  0 siblings, 2 replies; 150+ messages in thread
From: David Schwartz @ 2006-04-14 11:39 UTC (permalink / raw)
  To: Ramakanth Gunuganti; +Cc: Kyle Moffett, linux-kernel


> One thing that is clear in the GPL: If you link the kernel with something
> else to an executable, the resulting blob (and therefore the
> sources to the
> proprietary part) must be GPL.

	Actually, that is *far* from clear.

	First, the GPL cannot set its own scope. The GPL could say that if you
stored a program in the same room as a GPL program, the program must be GPL.
So *nothing* the GPL says will answer this question -- the question is, can
the GPL attach by linking?

	The contrary argument would be that linking two programs together is an
automated process. There is no creative input in the linking process. So it
does not legally produce a single work, but a mechanical combination of the
two original works.

	The proof that the executable is not a work for copyright purposes is this
simple -- could a person who took two object files out of the box and linked
them together claim copyright in the new derivative work he just produced? I
think the answer would be obvious -- the executable is not a new work, it's
just the two original works combined.

	Note that this does not mean that *designing* a program specifically to
link to another program can't make it a derivative work of the work you
designed it to go with. Just that the linking itself cannot always do so
automatically.

	In any event, to give my answer to the original question -- if a kernel
module and a userspace program are developed together, and are not both
derived from an API that is independent of the Linux kernel, then they are
probably going to be considered a single work.

	On the flip side, you should be okay if you develop an API for a kernel to
communicate with user space and then develop a user space program that could
work on any kernel (Linux or not, theoretically) that supported that API.
This should ensure that the user space program is derivative only from the
API and not from the Linux kernel.

	Note that you will not be okay if the API looks like what just happen to be
Linux kernel internals. The API itself must be independent of the Linux
kernel internals.

	DS



^ permalink raw reply	[flat|nested] 150+ messages in thread

* RE: GPL issues
  2006-04-14 11:39       ` David Schwartz
@ 2006-04-14 14:54         ` linux-os (Dick Johnson)
  2006-04-14 17:50         ` David Weinehall
  1 sibling, 0 replies; 150+ messages in thread
From: linux-os (Dick Johnson) @ 2006-04-14 14:54 UTC (permalink / raw)
  To: David Schwartz; +Cc: Ramakanth Gunuganti, Kyle Moffett, linux-kernel


On Fri, 14 Apr 2006, David Schwartz wrote:

>
>> One thing that is clear in the GPL: If you link the kernel with something
>> else to an executable, the resulting blob (and therefore the
>> sources to the
>> proprietary part) must be GPL.
>
> 	Actually, that is *far* from clear.
>
> 	First, the GPL cannot set its own scope. The GPL could say that if you
> stored a program in the same room as a GPL program, the program must be GPL.
> So *nothing* the GPL says will answer this question -- the question is, can
> the GPL attach by linking?
>
> 	The contrary argument would be that linking two programs together is an
> automated process. There is no creative input in the linking process. So it
> does not legally produce a single work, but a mechanical combination of the
> two original works.
>
> 	The proof that the executable is not a work for copyright purposes is this
> simple -- could a person who took two object files out of the box and linked
> them together claim copyright in the new derivative work he just produced? I
> think the answer would be obvious -- the executable is not a new work, it's
> just the two original works combined.
>
> 	Note that this does not mean that *designing* a program specifically to
> link to another program can't make it a derivative work of the work you
> designed it to go with. Just that the linking itself cannot always do so
> automatically.
>
> 	In any event, to give my answer to the original question -- if a kernel
> module and a userspace program are developed together, and are not both
> derived from an API that is independent of the Linux kernel, then they are
> probably going to be considered a single work.
>
> 	On the flip side, you should be okay if you develop an API for a kernel to
> communicate with user space and then develop a user space program that could
> work on any kernel (Linux or not, theoretically) that supported that API.
> This should ensure that the user space program is derivative only from the
> API and not from the Linux kernel.
>
> 	Note that you will not be okay if the API looks like what just happen to be
> Linux kernel internals. The API itself must be independent of the Linux
> kernel internals.
>
> 	DS
>


Unfortunately copyright law is all about books, papers,
and publishing. It has been adapted to software while,
in fact, it is not relevant to software. That's the
problem.

When attempting to adapt copyright law to software one
needs to "interpret" irrelevant law. This means, that
it means, what a certain judge thinks it means, on a
particular day after hearing some boring arguments.

But there are some things about licensing that are
perfectly clear because they are not about copyright
law at all. Let's say that because I hate Microsoft,
I decide to provide a license to some software that
reads: "This software can be used by anybody, except
Microsoft, for any purpose whatsoever."

Microsoft could use this software because the
license contains an illegal exclusion that
represents "restraint of trade." As much as
you think that excluding a particular company
from using your software is correct and proper,
it is, in fact, illegal in the United states.

It is illegal because the owner of some property
(software) cannot exclude one company from using
that property unless it excludes all companies
from using it.

This is not just about companies. If K-MART was
selling or even giving away some particular item,
they couldn't refuse to give or sell to you the
same item, no matter how badly they hated you.

So, let's say that you wrote a module that allowed
a user-mode program to perform some useful thing
that had never been done before. You are certainly
not going to publish that program or you will
lose your intellectual property and be out of
business.

Some kernel-creeper decides that they will prevent
you from installing your module unless you release
all your source-code under GPL. If you were to take
this to court, you would have two problems:

(1) Who do you sue?
(2) How do you recover damages.

Instead, you make a work-around. You patch the kernel
so your module will work and you ignore the kernel-
creeper. The kernel-creeper is powerless, even in a
suit, because he tried to use illegal restraint of
trade to prevent you from using intellectual property
that belonged to you.

But, the kernel-creeper has lots of money and invective.
He hires the best lawyers in the world, keeps postponing
discovery, gets a temporary restraining order preventing
you from using you own property, then forces you into
bankruptcy.

You lost, even though you were perfectly morally, and
legally correct!

There is a work-around for this, too. Use BSD software.
Many business decisions are all about trade offs. One
of the reasons why Linux has been slow in being accepted
by industry is because some kernel-creeper can cause
a company a lot of damage. This is something to remember
as Linux developers continue to remove essential symbols
from the kernel and continue to re-write build procedures
so that industry-standard methods will no longer work
for building modules.

BSD software might not be so "great", but it works and
we can all use it.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-14 11:39       ` David Schwartz
  2006-04-14 14:54         ` linux-os (Dick Johnson)
@ 2006-04-14 17:50         ` David Weinehall
  2006-04-14 18:56           ` David Schwartz
  1 sibling, 1 reply; 150+ messages in thread
From: David Weinehall @ 2006-04-14 17:50 UTC (permalink / raw)
  To: David Schwartz; +Cc: Ramakanth Gunuganti, Kyle Moffett, linux-kernel

On Fri, Apr 14, 2006 at 04:39:59AM -0700, David Schwartz wrote:
> 
> > One thing that is clear in the GPL: If you link the kernel with something
> > else to an executable, the resulting blob (and therefore the
> > sources to the
> > proprietary part) must be GPL.
> 
> 	Actually, that is *far* from clear.
> 
> 	First, the GPL cannot set its own scope. The GPL could say that
> 	if you stored a program in the same room as a GPL program, the
> 	program must be GPL.  So *nothing* the GPL says will answer this
> 	question -- the question is, can the GPL attach by linking?
> 
> 	The contrary argument would be that linking two programs
> 	together is an automated process. There is no creative input in
> 	the linking process. So it does not legally produce a single
> 	work, but a mechanical combination of the two original works.
> 
> 	The proof that the executable is not a work for copyright
> 	purposes is this simple -- could a person who took two object
> 	files out of the box and linked them together claim copyright in
> 	the new derivative work he just produced? I think the answer
> 	would be obvious -- the executable is not a new work, it's just
> 	the two original works combined.

[snip]

Ahhh, but you're missing the whole point of the GPL.  The GPL is
not really a normal license, it's a copyright license.  Basically,
copyright law doesn't allow you to do *anything* with someone elses
work without permission.  The GPL grants you such rights.
However, in exchange for this, you agree to follow the license when
redistributing your software that you built against the GPL:ed
software.

So, in essence, *if* you choose to redistribute your work, you must
abide by the GPL.  And the GPL tells you to GPL your work too, if it
falls within the scope that the GPL defines.  It thus have nothing
to do with whether the programs are a mechanical combination of
two original works or not.  The only point where this comes in is
where the GPL defines its scope.

Thus, if the GPL said that all programs distributed on the same CD
as a GPL:ed program needs to be licensed under the GPL, and you
redistribute your software on that CD, you must license your software
under the GPL, unless you want to be in violation with the license.

Again, I'm not a lawyer...


Regards: David
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

^ permalink raw reply	[flat|nested] 150+ messages in thread

* RE: GPL issues
  2006-04-14 17:50         ` David Weinehall
@ 2006-04-14 18:56           ` David Schwartz
  2006-04-15 11:55             ` Alan Cox
  0 siblings, 1 reply; 150+ messages in thread
From: David Schwartz @ 2006-04-14 18:56 UTC (permalink / raw)
  To: Linux-Kernel@Vger. Kernel. Org


> Ahhh, but you're missing the whole point of the GPL.  The GPL is
> not really a normal license, it's a copyright license.  Basically,
> copyright law doesn't allow you to do *anything* with someone elses
> work without permission.  The GPL grants you such rights.
> However, in exchange for this, you agree to follow the license when
> redistributing your software that you built against the GPL:ed
> software.

	Bluntly, you're just completely wrong. If this were so, I could put up a
billboard with a poem and then sue everyone who read it.

	You should read http://www.copyright.gov/circs/circ1.html

	Notice, for example, that the rights granted under copyright do *not*
include the right to restrict the *use* of a work.

	Far from copyright law starting out with the premise that you can do
nothing with a work, it basically restricts copying or distribution of a
work and the production of works based on that work other than what's
necessary for ordinary use.

	Specifically, copyright does not protect ordinary use. If you buy a CD, you
get the right to use that CD simply by virtue of the fact that you lawfully
possess a lawfully made of the music on that CD.

	DS



^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-13 22:07             ` Mark Lord
@ 2006-04-15 11:14               ` Arjan van de Ven
  0 siblings, 0 replies; 150+ messages in thread
From: Arjan van de Ven @ 2006-04-15 11:14 UTC (permalink / raw)
  To: Mark Lord; +Cc: jdow, Joshua Hudson, Ramakanth Gunuganti, linux-kernel

On Thu, 2006-04-13 at 18:07 -0400, Mark Lord wrote:
> /usr/src/linux/COPYING:
> 
> NOTE! This copyright does *not* cover user programs that use kernel
>  services by normal system calls - this is merely considered normal use
>  of the kernel, and does *not* fall under the heading of "derived work".

emphasis on "normal"



^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: GPL issues
  2006-04-13 22:17         ` Mark Lord
@ 2006-04-15 11:15           ` Arjan van de Ven
  0 siblings, 0 replies; 150+ messages in thread
From: Arjan van de Ven @ 2006-04-15 11:15 UTC (permalink / raw)
  To: Mark Lord; +Cc: Mark Lord, Joshua Hudson, Ramakanth Gunuganti, linux-kernel

On Thu, 2006-04-13 at 18:17 -0400, Mark Lord wrote:
> Arjan van de Ven wrote:
> > On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
> >> Joshua Hudson wrote:
> >>> On 4/11/06, David Weinehall <tao@acc.umu.se> wrote:
> >>>> OK, simplified rules; if you follow them you should generally be OK:
> >> ..
> >>>> 3. Userspace code that uses interfaces that was not exposed to userspace
> >>>> before you change the kernel --> GPL (but don't do it; there's almost
> >>>> always a reason why an interface is not exported to userspace)
> >>>>
> >>>> 4. Userspace code that only uses existing interfaces --> choose
> >>>> license yourself (but of course, GPL would be nice...)
> >> Err.. there is ZERO difference between situations 3 and 4.
> >> Userspace code can be any license one wants, regardless of where
> >> or when or how the syscalls are added to the kernel.
> > 
> > that is not so clear if the syscalls were added exclusively for this
> > application by the authors of the application....
> 
> Neither the GPL nor the kernel's COPYING file restricts anyone
> from making kernel changes.  In fact, the GPL expressly permits
> anyone to modify the kernel.  So how the syscalls get there is
> of zero relevance here.

it IS relevant is the change that adds them is seen as being part of the
other work. See clause 2 :)



^ permalink raw reply	[flat|nested] 150+ messages in thread

* RE: GPL issues
  2006-04-14 18:56           ` David Schwartz
@ 2006-04-15 11:55             ` Alan Cox
  2006-04-15 13:04               ` Steven Rostedt
  2006-04-15 18:49               ` David Schwartz
  0 siblings, 2 replies; 150+ messages in thread
From: Alan Cox @ 2006-04-15 11:55 UTC (permalink / raw)
  To: davids; +Cc: Linux-Kernel@Vger. Kernel. Org

On Gwe, 2006-04-14 at 11:56 -0700, David Schwartz wrote:
> 	Specifically, copyright does not protect ordinary use. If you buy a CD, you
> get the right to use that CD simply by virtue of the fact that you lawfully
> possess a lawfully made of the music on that CD.

The rights you get automatically for "use" depend a lot on the actual
thing itself and also the jurisdiction (local and national) and may even
in some ludicrous cases depend on even the size of the cark park your
building has.

To lawfully use the CD you must also not be violating the DMCA, own any
appropriate patent rights, not be using it for the purpose of committing
a crime, not using it to incite violence and on and on and on, down to
not using it loudly enough to disturb your neighbours excessively.

To "use" it for a public performance also generally falls under
copyright license restrictions (performance rights).

What you say may have been true two hundred years ago but the IPR laws
of the world have been growing ever more tangled and self contradictory
since then, like a badly maintained perl script.

Alan

--
Sick of rip off UK rail fares ? Learn how to get far cheaper fares
                http://zeniv.linux.org.uk/~alan/GTR/


^ permalink raw reply	[flat|nested] 150+ messages in thread

* RE: GPL issues
  2006-04-15 11:55             ` Alan Cox
@ 2006-04-15 13:04               ` Steven Rostedt
  2006-04-15 18:49               ` David Schwartz
  1 sibling, 0 replies; 150+ messages in thread
From: Steven Rostedt @ 2006-04-15 13:04 UTC (permalink / raw)
  To: Alan Cox; +Cc: davids, Linux-Kernel@Vger. Kernel. Org

On Sat, 2006-04-15 at 12:55 +0100, Alan Cox wrote:
> O
> What you say may have been true two hundred years ago but the IPR laws
> of the world have been growing ever more tangled and self contradictory
> since then, like a badly maintained perl script.
> 

Please don't insult perl by associating it with IPR laws ;-)
(even if it is true)

-- Steve



^ permalink raw reply	[flat|nested] 150+ messages in thread

* RE: GPL issues
  2006-04-15 11:55             ` Alan Cox
  2006-04-15 13:04               ` Steven Rostedt
@ 2006-04-15 18:49               ` David Schwartz
  1 sibling, 0 replies; 150+ messages in thread
From: David Schwartz @ 2006-04-15 18:49 UTC (permalink / raw)
  To: Linux-Kernel@Vger. Kernel. Org



> On Gwe, 2006-04-14 at 11:56 -0700, David Schwartz wrote:

> > Specifically, copyright does not protect ordinary use. If
> > you buy a CD, you
> > get the right to use that CD simply by virtue of the fact that
> > you lawfully
> > possess a lawfully made of the music on that CD.

> The rights you get automatically for "use" depend a lot on the actual
> thing itself and also the jurisdiction (local and national) and may even
> in some ludicrous cases depend on even the size of the cark park your
> building has.

	There are certainly ludicrous cases, but in most of the cases you cite, the
right to ordinary use is actually superior to the restriction. In other
words, the restriction does not apply if the use is the ordinary intended
use. (Sadly, courts don't always seem to understand this.)

> To lawfully use the CD you must also not be violating the DMCA,

	That the use is the ordinary, intended use of a lawfully-acquired work is
supposed to be a valid DMCA defense. That doesn't mean courts will always
see it that way or agree with you on what the ordinary use is.

> own any
> appropriate patent rights,

	That's true. However, that's kind of like saying you're not entitled to
ordinary use of a bat because you can't beat someone else over the head with
it. The context was restrictions imposed by copyright, not by everything
else in the world.

> not be using it for the purpose of committing
> a crime, not using it to incite violence and on and on and on, down to
> not using it loudly enough to disturb your neighbours excessively.

	Of course, but we were talking about rights to do things against rights
acquired under copyright.

> To "use" it for a public performance also generally falls under
> copyright license restrictions (performance rights).

	It's very hard to know what that means in a software context. I suppose one
could theoretically argue that using Linux to run a web server that's
accessible to the public and intended for public use is a public
performance.

> What you say may have been true two hundred years ago but the IPR laws
> of the world have been growing ever more tangled and self contradictory
> since then, like a badly maintained perl script.

	Fair enough. Your rant makes lots of good points about how absurd and
non-obvious the law can be and I certainly share a lot of the frustration
behind it -- *especially* about the DMCA. However, none of the cases you
mentioned affects the cases we were talking about here in any significant
way.

	DS



^ permalink raw reply	[flat|nested] 150+ messages in thread

* [PATCH 00/12] making the kernel -Wshadow clean - The initial step
@ 2006-07-30 16:30 Jesper Juhl
  2006-07-30 16:35 ` [PATCH 01/12] making the kernel -Wshadow clean - fix mconf Jesper Juhl
                   ` (14 more replies)
  0 siblings, 15 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 16:30 UTC (permalink / raw)
  To: linux-kernel
  Cc: Andrew Morton, Nikita Danilov, Joe Perches, Martin Waitz,
	Jan-Benedict Glaw, Christoph Hellwig, David Woodhouse,
	Arjan van de Ven, Dmitry Torokhov, Valdis Kletnieks,
	Sam Ravnborg, Russell King, Rusty Russell, Randy Dunlap,
	Jesper Juhl

Ok, here we go again...

This is a series of patches that try to be an initial step towards making
the kernel build -Wshadow clean.

Yeah, I'm persisting with this since I get the impression, from the feedback
I've been getting, that this effort is mostly looked upon favorably.

The reasons why we should do this should be obvious, but I'll list the main
reasons anyway.
In the end the compiler will help us prevent new (and hard to find bugs)
due to symbol shadowing.
It'll help us keep our namespaces separate.
We may find some bugs along the way - and even if it's just one it'll be
worth it :)

I have recieved a lot of useful feedback to the previous patches I've
posted and I've tried to incorporate all the feedback in this series.

There should be no change in behaviour from these patches and it's my hope
that they are acceptable for merging so that, going forward, I will have 
these 12 less to keep track of separately.

A patch to add -Wshadow to the toplevel Makefile is not included since it's
still a little early for that. There are still a lot of warnings that need 
to be fixed, this series is just the first step (but as I think the numbers
below will show, it's a pretty big first step).
I'm only able to work against i386 at the moment, so the results below
probably won't be as nice for other archs, but no need to worry, I do plan
to clean up other archs as well - I just need to get a bunch of
cross-compilers installed.
My plan is to keep submitting new series of patches against -mm (assuming
that these will get merged there) until we are down to less than 100 warnings
for all the standard configs for all archs and then at that point submit a
patch to add -Wshadow to the toplevel Makefile - if someone wants to help
out I'd appreciate it - there are still lots of warnings left to work on, some
of them I've just not gotten to yet, but some of them I'll definately need 
help with as well.


All of this is against 2.6.18-rc3.

Without the patches, adding -Wshadow to the makefile results in these 
warnings for a few different .config's :

allnoconfig
---
$ grep warning build.log.allno | grep shadow | wc -l
1267

allmodconfig
---
$ grep warning build.log.allmod | grep shadow | wc -l
39921

allyesconfig
---
$ grep warning build.log.allyes | grep shadow | wc -l
32477

with my normal workstation config
---
$ grep warning build.log.juhl | grep shadow | wc -l
5298


After applying the patches in this series, quite a different picture
emerges.

allnoconfig :	124 warnings	(~10%)
allmodconfig :	6508 warnings	(~16%)
allyesconfig :	6522 warnings (~20%)
my config :	958 warnings	(~18%)

So with just 12 small patches the number of -Wshadow related warnings is
reduced to between 10 and 20 percent of what they previously were. 
Personally I'd say that's a pretty good first step.

I've added a bunch of people to Cc: on this mail, trying to pick those that
have either responded to my previous attempts or whoes code I'm changing.
I may not have gotten it 100% right, so please bear with me.
I'll not be sending the actual patches to all of you guys - don't want to 
spam your inbox too much. Instead I'll send all 12 patches as a reply to
this email to LKML with just akpm cc.   I hope that's OK with everyone.


Patch series overview : 

[PATCH 00/12] making the kernel -Wshadow clean - The initial step
[PATCH 01/12] making the kernel -Wshadow clean - fix mconf
[PATCH 02/12] making the kernel -Wshadow clean - fix lxdialog
[PATCH 03/12] making the kernel -Wshadow clean - fix jiffies.h
[PATCH 04/12] making the kernel -Wshadow clean - warnings related to 'up'
[PATCH 05/12] making the kernel -Wshadow clean - warnings related to wbc and map_bh
[PATCH 06/12] making the kernel -Wshadow clean - fix checksum
[PATCH 07/12] making the kernel -Wshadow clean - fix vgacon
[PATCH 08/12] making the kernel -Wshadow clean - fix keyboard.c
[PATCH 09/12] making the kernel -Wshadow clean - neighbour.h and 'proc_handler'
[PATCH 10/12] making the kernel -Wshadow clean - mm/truncate.c
[PATCH 11/12] making the kernel -Wshadow clean - USB & completion
[PATCH 12/12] making the kernel -Wshadow clean - 'irq' shadows local and global


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html


^ permalink raw reply	[flat|nested] 150+ messages in thread

* [PATCH 01/12] making the kernel -Wshadow clean - fix mconf
  2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
@ 2006-07-30 16:35 ` Jesper Juhl
  2006-07-30 18:34   ` Paul Jackson
  2006-07-30 16:36 ` [PATCH 02/12] making the kernel -Wshadow clean - fix lxdialog Jesper Juhl
                   ` (13 subsequent siblings)
  14 siblings, 1 reply; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 16:35 UTC (permalink / raw)
  To: linux-kernel; +Cc: Jesper Juhl, Andrew Morton

Fix -Wshadow warnings in mconf


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 scripts/kconfig/mconf.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.18-rc2-orig/scripts/kconfig/mconf.c	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.18-rc2/scripts/kconfig/mconf.c	2006-07-18 23:39:51.000000000 +0200
@@ -258,7 +258,7 @@ search_help[] = N_(
 
 static char buf[4096], *bufptr = buf;
 static char input_buf[4096];
-static char filename[PATH_MAX+1] = ".config";
+static char config_filename[PATH_MAX+1] = ".config";
 static char *args[1024], **argptr = args;
 static int indent;
 static struct termios ios_org;
@@ -983,7 +983,7 @@ static void conf_load(void)
 		cprint(load_config_text);
 		cprint("11");
 		cprint("55");
-		cprint("%s", filename);
+		cprint("%s", config_filename);
 		stat = exec_conf();
 		switch(stat) {
 		case 0:
@@ -1012,7 +1012,7 @@ static void conf_save(void)
 		cprint(save_config_text);
 		cprint("11");
 		cprint("55");
-		cprint("%s", filename);
+		cprint("%s", config_filename);
 		stat = exec_conf();
 		switch(stat) {
 		case 0:




^ permalink raw reply	[flat|nested] 150+ messages in thread

* [PATCH 02/12] making the kernel -Wshadow clean - fix lxdialog
  2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
  2006-07-30 16:35 ` [PATCH 01/12] making the kernel -Wshadow clean - fix mconf Jesper Juhl
@ 2006-07-30 16:36 ` Jesper Juhl
  2006-07-30 16:37 ` [PATCH 03/12] making the kernel -Wshadow clean - fix jiffies.h Jesper Juhl
                   ` (12 subsequent siblings)
  14 siblings, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 16:36 UTC (permalink / raw)
  To: linux-kernel; +Cc: Jesper Juhl, Andrew Morton

Remove a bunch of -Wshadow warnings from scripts/kconfig/lxdialog/


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>

 scripts/kconfig/lxdialog/checklist.c |   70 ++++++++++-----------
 scripts/kconfig/lxdialog/dialog.h    |    6 -
 scripts/kconfig/lxdialog/inputbox.c  |   38 +++++------
 scripts/kconfig/lxdialog/menubox.c   |   82 ++++++++++++-------------
 scripts/kconfig/lxdialog/msgbox.c    |    4 -
 scripts/kconfig/lxdialog/util.c      |   20 +++---
 6 files changed, 110 insertions(+), 110 deletions(-)

diff -upr linux-2.6.18-rc2-orig/scripts/kconfig/lxdialog/checklist.c linux-2.6.18-rc2/scripts/kconfig/lxdialog/checklist.c
--- linux-2.6.18-rc2-orig/scripts/kconfig/lxdialog/checklist.c	2006-07-18 18:47:19.000000000 +0200
+++ linux-2.6.18-rc2/scripts/kconfig/lxdialog/checklist.c	2006-07-18 20:25:07.000000000 +0200
@@ -56,12 +56,12 @@ static void print_item(WINDOW * win, con
 /*
  * Print the scroll indicators.
  */
-static void print_arrows(WINDOW * win, int choice, int item_no, int scroll,
+static void print_arrows(WINDOW * win, int choice, int item_no, int scrolling,
 	     int y, int x, int height)
 {
 	wmove(win, y, x);
 
-	if (scroll > 0) {
+	if (scrolling > 0) {
 		wattrset(win, uarrow_attr);
 		waddch(win, ACS_UARROW);
 		waddstr(win, "(-)");
@@ -76,7 +76,7 @@ static void print_arrows(WINDOW * win, i
 	y = y + height + 1;
 	wmove(win, y, x);
 
-	if ((height < item_no) && (scroll + choice < item_no - 1)) {
+	if ((height < item_no) && (scrolling + choice < item_no - 1)) {
 		wattrset(win, darrow_attr);
 		waddch(win, ACS_DARROW);
 		waddstr(win, "(+)");
@@ -113,7 +113,7 @@ int dialog_checklist(const char *title, 
 		     const char *const *items)
 {
 	int i, x, y, box_x, box_y;
-	int key = 0, button = 0, choice = 0, scroll = 0, max_choice, *status;
+	int key = 0, button = 0, choice = 0, scrolling = 0, max_choice, *status;
 	WINDOW *dialog, *list;
 
 	/* Allocate space for storing item on/off status */
@@ -181,20 +181,20 @@ int dialog_checklist(const char *title, 
 	item_x = check_x + 4;
 
 	if (choice >= list_height) {
-		scroll = choice - list_height + 1;
-		choice -= scroll;
+		scrolling = choice - list_height + 1;
+		choice -= scrolling;
 	}
 
 	/* Print the list */
 	for (i = 0; i < max_choice; i++) {
 		if (i != choice)
-			print_item(list, items[(scroll + i) * 3 + 1],
-				   status[i + scroll], i, 0);
+			print_item(list, items[(scrolling + i) * 3 + 1],
+				   status[i + scrolling], i, 0);
 	}
-	print_item(list, items[(scroll + choice) * 3 + 1],
-		   status[choice + scroll], choice, 1);
+	print_item(list, items[(scrolling + choice) * 3 + 1],
+		   status[choice + scrolling], choice, 1);
 
-	print_arrows(dialog, choice, item_no, scroll,
+	print_arrows(dialog, choice, item_no, scrolling,
 		     box_y, box_x + check_x + 5, list_height);
 
 	print_buttons(dialog, height, width, 0);
@@ -208,28 +208,28 @@ int dialog_checklist(const char *title, 
 
 		for (i = 0; i < max_choice; i++)
 			if (toupper(key) ==
-			    toupper(items[(scroll + i) * 3 + 1][0]))
+			    toupper(items[(scrolling + i) * 3 + 1][0]))
 				break;
 
 		if (i < max_choice || key == KEY_UP || key == KEY_DOWN ||
 		    key == '+' || key == '-') {
 			if (key == KEY_UP || key == '-') {
 				if (!choice) {
-					if (!scroll)
+					if (!scrolling)
 						continue;
 					/* Scroll list down */
 					if (list_height > 1) {
 						/* De-highlight current first item */
-						print_item(list, items[scroll * 3 + 1],
-							   status[scroll], 0, FALSE);
+						print_item(list, items[scrolling * 3 + 1],
+							   status[scrolling], 0, FALSE);
 						scrollok(list, TRUE);
 						wscrl(list, -1);
 						scrollok(list, FALSE);
 					}
-					scroll--;
-					print_item(list, items[scroll * 3 + 1], status[scroll], 0, TRUE);
+					scrolling--;
+					print_item(list, items[scrolling * 3 + 1], status[scrolling], 0, TRUE);
 					print_arrows(dialog, choice, item_no,
-						     scroll, box_y, box_x + check_x + 5, list_height);
+						     scrolling, box_y, box_x + check_x + 5, list_height);
 
 					wnoutrefresh(dialog);
 					wrefresh(list);
@@ -239,24 +239,24 @@ int dialog_checklist(const char *title, 
 					i = choice - 1;
 			} else if (key == KEY_DOWN || key == '+') {
 				if (choice == max_choice - 1) {
-					if (scroll + choice >= item_no - 1)
+					if (scrolling + choice >= item_no - 1)
 						continue;
 					/* Scroll list up */
 					if (list_height > 1) {
 						/* De-highlight current last item before scrolling up */
-						print_item(list, items[(scroll + max_choice - 1) * 3 + 1],
-							   status[scroll + max_choice - 1],
+						print_item(list, items[(scrolling + max_choice - 1) * 3 + 1],
+							   status[scrolling + max_choice - 1],
 							   max_choice - 1, FALSE);
 						scrollok(list, TRUE);
 						wscrl(list, 1);
 						scrollok(list, FALSE);
 					}
-					scroll++;
-					print_item(list, items[(scroll + max_choice - 1) * 3 + 1],
-						   status[scroll + max_choice - 1], max_choice - 1, TRUE);
+					scrolling++;
+					print_item(list, items[(scrolling + max_choice - 1) * 3 + 1],
+						   status[scrolling + max_choice - 1], max_choice - 1, TRUE);
 
 					print_arrows(dialog, choice, item_no,
-						     scroll, box_y, box_x + check_x + 5, list_height);
+						     scrolling, box_y, box_x + check_x + 5, list_height);
 
 					wnoutrefresh(dialog);
 					wrefresh(list);
@@ -267,12 +267,12 @@ int dialog_checklist(const char *title, 
 			}
 			if (i != choice) {
 				/* De-highlight current item */
-				print_item(list, items[(scroll + choice) * 3 + 1],
-					   status[scroll + choice], choice, FALSE);
+				print_item(list, items[(scrolling + choice) * 3 + 1],
+					   status[scrolling + choice], choice, FALSE);
 				/* Highlight new item */
 				choice = i;
-				print_item(list, items[(scroll + choice) * 3 + 1],
-					   status[scroll + choice], choice, TRUE);
+				print_item(list, items[(scrolling + choice) * 3 + 1],
+					   status[scrolling + choice], choice, TRUE);
 				wnoutrefresh(dialog);
 				wrefresh(list);
 			}
@@ -282,7 +282,7 @@ int dialog_checklist(const char *title, 
 		case 'H':
 		case 'h':
 		case '?':
-			fprintf(stderr, "%s", items[(scroll + choice) * 3]);
+			fprintf(stderr, "%s", items[(scrolling + choice) * 3]);
 			delwin(dialog);
 			free(status);
 			return 1;
@@ -300,13 +300,13 @@ int dialog_checklist(const char *title, 
 		case ' ':
 		case '\n':
 			if (!button) {
-				if (!status[scroll + choice]) {
+				if (!status[scrolling + choice]) {
 					for (i = 0; i < item_no; i++)
 						status[i] = 0;
-					status[scroll + choice] = 1;
+					status[scrolling + choice] = 1;
 					for (i = 0; i < max_choice; i++)
-						print_item(list, items[(scroll + i) * 3 + 1],
-							   status[scroll + i], i, i == choice);
+						print_item(list, items[(scrolling + i) * 3 + 1],
+							   status[scrolling + i], i, i == choice);
 				}
 				wnoutrefresh(dialog);
 				wrefresh(list);
@@ -315,7 +315,7 @@ int dialog_checklist(const char *title, 
 					if (status[i])
 						fprintf(stderr, "%s", items[i * 3]);
 			} else
-				fprintf(stderr, "%s", items[(scroll + choice) * 3]);
+				fprintf(stderr, "%s", items[(scrolling + choice) * 3]);
 			delwin(dialog);
 			free(status);
 			return button;
diff -upr linux-2.6.18-rc2-orig/scripts/kconfig/lxdialog/dialog.h linux-2.6.18-rc2/scripts/kconfig/lxdialog/dialog.h
--- linux-2.6.18-rc2-orig/scripts/kconfig/lxdialog/dialog.h	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.18-rc2/scripts/kconfig/lxdialog/dialog.h	2006-07-18 20:25:07.000000000 +0200
@@ -146,14 +146,14 @@ void color_setup(void);
 void print_autowrap(WINDOW * win, const char *prompt, int width, int y, int x);
 void print_button(WINDOW * win, const char *label, int y, int x, int selected);
 void print_title(WINDOW *dialog, const char *title, int width);
-void draw_box(WINDOW * win, int y, int x, int height, int width, chtype box,
-	      chtype border);
+void draw_box(WINDOW * win, int y, int x, int height, int width, chtype the_box,
+	      chtype the_border);
 void draw_shadow(WINDOW * win, int y, int x, int height, int width);
 
 int first_alpha(const char *string, const char *exempt);
 int dialog_yesno(const char *title, const char *prompt, int height, int width);
 int dialog_msgbox(const char *title, const char *prompt, int height,
-		  int width, int pause);
+		  int width, int delay);
 int dialog_textbox(const char *title, const char *file, int height, int width);
 int dialog_menu(const char *title, const char *prompt, int height, int width,
 		int menu_height, const char *choice, int item_no,
diff -upr linux-2.6.18-rc2-orig/scripts/kconfig/lxdialog/inputbox.c linux-2.6.18-rc2/scripts/kconfig/lxdialog/inputbox.c
--- linux-2.6.18-rc2-orig/scripts/kconfig/lxdialog/inputbox.c	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.18-rc2/scripts/kconfig/lxdialog/inputbox.c	2006-07-18 20:25:07.000000000 +0200
@@ -45,8 +45,8 @@ int dialog_inputbox(const char *title, c
                     const char *init)
 {
 	int i, x, y, box_y, box_x, box_width;
-	int input_x = 0, scroll = 0, key = 0, button = -1;
-	char *instr = dialog_input_result;
+	int input_x = 0, scrolling = 0, key = 0, button = -1;
+	char *in_str = dialog_input_result;
 	WINDOW *dialog;
 
 	/* center dialog box on screen */
@@ -85,19 +85,19 @@ int dialog_inputbox(const char *title, c
 	wattrset(dialog, inputbox_attr);
 
 	if (!init)
-		instr[0] = '\0';
+		in_str[0] = '\0';
 	else
-		strcpy(instr, init);
+		strcpy(in_str, init);
 
-	input_x = strlen(instr);
+	input_x = strlen(in_str);
 
 	if (input_x >= box_width) {
-		scroll = input_x - box_width + 1;
+		scrolling = input_x - box_width + 1;
 		input_x = box_width - 1;
 		for (i = 0; i < box_width - 1; i++)
-			waddch(dialog, instr[scroll + i]);
+			waddch(dialog, in_str[scrolling + i]);
 	} else {
-		waddstr(dialog, instr);
+		waddstr(dialog, in_str);
 	}
 
 	wmove(dialog, box_y, box_x + input_x);
@@ -119,19 +119,19 @@ int dialog_inputbox(const char *title, c
 				continue;
 			case KEY_BACKSPACE:
 			case 127:
-				if (input_x || scroll) {
+				if (input_x || scrolling) {
 					wattrset(dialog, inputbox_attr);
 					if (!input_x) {
-						scroll = scroll < box_width - 1 ? 0 : scroll - (box_width - 1);
+						scrolling = scrolling < box_width - 1 ? 0 : scrolling - (box_width - 1);
 						wmove(dialog, box_y, box_x);
 						for (i = 0; i < box_width; i++)
 							waddch(dialog,
-							       instr[scroll + input_x + i] ?
-							       instr[scroll + input_x + i] : ' ');
-						input_x = strlen(instr) - scroll;
+							       in_str[scrolling + input_x + i] ?
+							       in_str[scrolling + input_x + i] : ' ');
+						input_x = strlen(in_str) - scrolling;
 					} else
 						input_x--;
-					instr[scroll + input_x] = '\0';
+					in_str[scrolling + input_x] = '\0';
 					mvwaddch(dialog, box_y, input_x + box_x, ' ');
 					wmove(dialog, box_y, input_x + box_x);
 					wrefresh(dialog);
@@ -139,15 +139,15 @@ int dialog_inputbox(const char *title, c
 				continue;
 			default:
 				if (key < 0x100 && isprint(key)) {
-					if (scroll + input_x < MAX_LEN) {
+					if (scrolling + input_x < MAX_LEN) {
 						wattrset(dialog, inputbox_attr);
-						instr[scroll + input_x] = key;
-						instr[scroll + input_x + 1] = '\0';
+						in_str[scrolling + input_x] = key;
+						in_str[scrolling + input_x + 1] = '\0';
 						if (input_x == box_width - 1) {
-							scroll++;
+							scrolling++;
 							wmove(dialog, box_y, box_x);
 							for (i = 0; i < box_width - 1; i++)
-								waddch(dialog, instr [scroll + i]);
+								waddch(dialog, in_str[scrolling + i]);
 						} else {
 							wmove(dialog, box_y, input_x++ + box_x);
 							waddch(dialog, key);
diff -upr linux-2.6.18-rc2-orig/scripts/kconfig/lxdialog/menubox.c linux-2.6.18-rc2/scripts/kconfig/lxdialog/menubox.c
--- linux-2.6.18-rc2-orig/scripts/kconfig/lxdialog/menubox.c	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.18-rc2/scripts/kconfig/lxdialog/menubox.c	2006-07-18 20:25:07.000000000 +0200
@@ -107,7 +107,7 @@ do {\
 /*
  * Print the scroll indicators.
  */
-static void print_arrows(WINDOW * win, int item_no, int scroll, int y, int x,
+static void print_arrows(WINDOW * win, int item_no, int scrolling, int y, int x,
 			 int height)
 {
 	int cur_y, cur_x;
@@ -132,7 +132,7 @@ static void print_arrows(WINDOW * win, i
 	wmove(win, y, x);
 	wrefresh(win);
 
-	if ((height < item_no) && (scroll + height < item_no)) {
+	if ((height < item_no) && (scrolling + height < item_no)) {
 		wattrset(win, darrow_attr);
 		waddch(win, ACS_DARROW);
 		waddstr(win, "(+)");
@@ -165,13 +165,13 @@ static void print_buttons(WINDOW * win, 
 }
 
 /* scroll up n lines (n may be negative) */
-static void do_scroll(WINDOW *win, int *scroll, int n)
+static void do_scroll(WINDOW *win, int *scrolling, int n)
 {
 	/* Scroll menu up */
 	scrollok(win, TRUE);
 	wscrl(win, n);
 	scrollok(win, FALSE);
-	*scroll = *scroll + n;
+	*scrolling = *scrolling + n;
 	wrefresh(win);
 }
 
@@ -183,7 +183,7 @@ int dialog_menu(const char *title, const
                 const char *const *items)
 {
 	int i, j, x, y, box_x, box_y;
-	int key = 0, button = 0, scroll = 0, choice = 0;
+	int key = 0, button = 0, scrolling = 0, choice = 0;
 	int first_item =  0, max_choice;
 	WINDOW *dialog, *menu;
 	FILE *f;
@@ -235,14 +235,14 @@ int dialog_menu(const char *title, const
 
 	/* get the scroll info from the temp file */
 	if ((f = fopen("lxdialog.scrltmp", "r")) != NULL) {
-		if ((fscanf(f, "%d\n", &scroll) == 1) && (scroll <= choice) &&
-		    (scroll + max_choice > choice) && (scroll >= 0) &&
-		    (scroll + max_choice <= item_no)) {
-			first_item = scroll;
-			choice = choice - scroll;
+		if ((fscanf(f, "%d\n", &scrolling) == 1) && (scrolling <= choice) &&
+		    (scrolling + max_choice > choice) && (scrolling >= 0) &&
+		    (scrolling + max_choice <= item_no)) {
+			first_item = scrolling;
+			choice = choice - scrolling;
 			fclose(f);
 		} else {
-			scroll = 0;
+			scrolling = 0;
 			remove("lxdialog.scrltmp");
 			fclose(f);
 			f = NULL;
@@ -250,10 +250,10 @@ int dialog_menu(const char *title, const
 	}
 	if ((choice >= max_choice) || (f == NULL && choice >= max_choice / 2)) {
 		if (choice >= item_no - max_choice / 2)
-			scroll = first_item = item_no - max_choice;
+			scrolling = first_item = item_no - max_choice;
 		else
-			scroll = first_item = choice - max_choice / 2;
-		choice = choice - scroll;
+			scrolling = first_item = choice - max_choice / 2;
+		choice = choice - scrolling;
 	}
 
 	/* Print the menu */
@@ -263,7 +263,7 @@ int dialog_menu(const char *title, const
 
 	wnoutrefresh(menu);
 
-	print_arrows(dialog, item_no, scroll,
+	print_arrows(dialog, item_no, scrolling,
 		     box_y, box_x + item_x + 1, menu_height);
 
 	print_buttons(dialog, height, width, 0);
@@ -280,14 +280,14 @@ int dialog_menu(const char *title, const
 			i = max_choice;
 		else {
 			for (i = choice + 1; i < max_choice; i++) {
-				j = first_alpha(items[(scroll + i) * 2 + 1], "YyNnMmHh");
-				if (key == tolower(items[(scroll + i) * 2 + 1][j]))
+				j = first_alpha(items[(scrolling + i) * 2 + 1], "YyNnMmHh");
+				if (key == tolower(items[(scrolling + i) * 2 + 1][j]))
 					break;
 			}
 			if (i == max_choice)
 				for (i = 0; i < max_choice; i++) {
-					j = first_alpha(items [(scroll + i) * 2 + 1], "YyNnMmHh");
-					if (key == tolower(items[(scroll + i) * 2 + 1][j]))
+					j = first_alpha(items [(scrolling + i) * 2 + 1], "YyNnMmHh");
+					if (key == tolower(items[(scrolling + i) * 2 + 1][j]))
 						break;
 				}
 		}
@@ -297,26 +297,26 @@ int dialog_menu(const char *title, const
 		    key == '-' || key == '+' ||
 		    key == KEY_PPAGE || key == KEY_NPAGE) {
 			/* Remove highligt of current item */
-			print_item(scroll + choice, choice, FALSE);
+			print_item(scrolling + choice, choice, FALSE);
 
 			if (key == KEY_UP || key == '-') {
-				if (choice < 2 && scroll) {
+				if (choice < 2 && scrolling) {
 					/* Scroll menu down */
-					do_scroll(menu, &scroll, -1);
+					do_scroll(menu, &scrolling, -1);
 
-					print_item(scroll, 0, FALSE);
+					print_item(scrolling, 0, FALSE);
 				} else
 					choice = MAX(choice - 1, 0);
 
 			} else if (key == KEY_DOWN || key == '+') {
-				print_item(scroll+choice, choice, FALSE);
+				print_item(scrolling+choice, choice, FALSE);
 
 				if ((choice > max_choice - 3) &&
-				    (scroll + max_choice < item_no)) {
+				    (scrolling + max_choice < item_no)) {
 					/* Scroll menu up */
-					do_scroll(menu, &scroll, 1);
+					do_scroll(menu, &scrolling, 1);
 
-					print_item(scroll+max_choice - 1,
+					print_item(scrolling+max_choice - 1,
 						   max_choice - 1, FALSE);
 				} else
 					choice = MIN(choice + 1, max_choice - 1);
@@ -324,9 +324,9 @@ int dialog_menu(const char *title, const
 			} else if (key == KEY_PPAGE) {
 				scrollok(menu, TRUE);
 				for (i = 0; (i < max_choice); i++) {
-					if (scroll > 0) {
-						do_scroll(menu, &scroll, -1);
-						print_item(scroll, 0, FALSE);
+					if (scrolling > 0) {
+						do_scroll(menu, &scrolling, -1);
+						print_item(scrolling, 0, FALSE);
 					} else {
 						if (choice > 0)
 							choice--;
@@ -335,9 +335,9 @@ int dialog_menu(const char *title, const
 
 			} else if (key == KEY_NPAGE) {
 				for (i = 0; (i < max_choice); i++) {
-					if (scroll + max_choice < item_no) {
-						do_scroll(menu, &scroll, 1);
-						print_item(scroll+max_choice-1,
+					if (scrolling + max_choice < item_no) {
+						do_scroll(menu, &scrolling, 1);
+						print_item(scrolling+max_choice-1,
 							   max_choice - 1, FALSE);
 					} else {
 						if (choice + 1 < max_choice)
@@ -347,9 +347,9 @@ int dialog_menu(const char *title, const
 			} else
 				choice = i;
 
-			print_item(scroll + choice, choice, TRUE);
+			print_item(scrolling + choice, choice, TRUE);
 
-			print_arrows(dialog, item_no, scroll,
+			print_arrows(dialog, item_no, scrolling,
 				     box_y, box_x + item_x + 1, menu_height);
 
 			wnoutrefresh(dialog);
@@ -376,11 +376,11 @@ int dialog_menu(const char *title, const
 		case '/':
 			/* save scroll info */
 			if ((f = fopen("lxdialog.scrltmp", "w")) != NULL) {
-				fprintf(f, "%d\n", scroll);
+				fprintf(f, "%d\n", scrolling);
 				fclose(f);
 			}
 			delwin(dialog);
-			fprintf(stderr, "%s\n", items[(scroll + choice) * 2]);
+			fprintf(stderr, "%s\n", items[(scrolling + choice) * 2]);
 			switch (key) {
 			case 's':
 				return 3;
@@ -403,12 +403,12 @@ int dialog_menu(const char *title, const
 			delwin(dialog);
 			if (button == 2)
 				fprintf(stderr, "%s \"%s\"\n",
-					items[(scroll + choice) * 2],
-					items[(scroll + choice) * 2 + 1] +
-					first_alpha(items [(scroll + choice) * 2 + 1], ""));
+					items[(scrolling + choice) * 2],
+					items[(scrolling + choice) * 2 + 1] +
+					first_alpha(items [(scrolling + choice) * 2 + 1], ""));
 			else
 				fprintf(stderr, "%s\n",
-					items[(scroll + choice) * 2]);
+					items[(scrolling + choice) * 2]);
 
 			remove("lxdialog.scrltmp");
 			return button;
diff -upr linux-2.6.18-rc2-orig/scripts/kconfig/lxdialog/msgbox.c linux-2.6.18-rc2/scripts/kconfig/lxdialog/msgbox.c
--- linux-2.6.18-rc2-orig/scripts/kconfig/lxdialog/msgbox.c	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.18-rc2/scripts/kconfig/lxdialog/msgbox.c	2006-07-18 20:25:07.000000000 +0200
@@ -26,7 +26,7 @@
  * if the parameter 'pause' is non-zero.
  */
 int dialog_msgbox(const char *title, const char *prompt, int height, int width,
-                  int pause)
+                  int delay)
 {
 	int i, x, y, key = 0;
 	WINDOW *dialog;
@@ -47,7 +47,7 @@ int dialog_msgbox(const char *title, con
 	wattrset(dialog, dialog_attr);
 	print_autowrap(dialog, prompt, width - 2, 1, 2);
 
-	if (pause) {
+	if (delay) {
 		wattrset(dialog, border_attr);
 		mvwaddch(dialog, height - 3, 0, ACS_LTEE);
 		for (i = 0; i < width - 2; i++)
diff -upr linux-2.6.18-rc2-orig/scripts/kconfig/lxdialog/util.c linux-2.6.18-rc2/scripts/kconfig/lxdialog/util.c
--- linux-2.6.18-rc2-orig/scripts/kconfig/lxdialog/util.c	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.18-rc2/scripts/kconfig/lxdialog/util.c	2006-07-18 20:25:07.000000000 +0200
@@ -288,7 +288,7 @@ void print_button(WINDOW * win, const ch
  */
 void
 draw_box(WINDOW * win, int y, int x, int height, int width,
-	 chtype box, chtype border)
+	 chtype the_box, chtype the_border)
 {
 	int i, j;
 
@@ -297,23 +297,23 @@ draw_box(WINDOW * win, int y, int x, int
 		wmove(win, y + i, x);
 		for (j = 0; j < width; j++)
 			if (!i && !j)
-				waddch(win, border | ACS_ULCORNER);
+				waddch(win, the_border | ACS_ULCORNER);
 			else if (i == height - 1 && !j)
-				waddch(win, border | ACS_LLCORNER);
+				waddch(win, the_border | ACS_LLCORNER);
 			else if (!i && j == width - 1)
-				waddch(win, box | ACS_URCORNER);
+				waddch(win, the_box | ACS_URCORNER);
 			else if (i == height - 1 && j == width - 1)
-				waddch(win, box | ACS_LRCORNER);
+				waddch(win, the_box | ACS_LRCORNER);
 			else if (!i)
-				waddch(win, border | ACS_HLINE);
+				waddch(win, the_border | ACS_HLINE);
 			else if (i == height - 1)
-				waddch(win, box | ACS_HLINE);
+				waddch(win, the_box | ACS_HLINE);
 			else if (!j)
-				waddch(win, border | ACS_VLINE);
+				waddch(win, the_border | ACS_VLINE);
 			else if (j == width - 1)
-				waddch(win, box | ACS_VLINE);
+				waddch(win, the_box | ACS_VLINE);
 			else
-				waddch(win, box | ' ');
+				waddch(win, the_box | ' ');
 	}
 }
 




^ permalink raw reply	[flat|nested] 150+ messages in thread

* [PATCH 03/12] making the kernel -Wshadow clean - fix jiffies.h
  2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
  2006-07-30 16:35 ` [PATCH 01/12] making the kernel -Wshadow clean - fix mconf Jesper Juhl
  2006-07-30 16:36 ` [PATCH 02/12] making the kernel -Wshadow clean - fix lxdialog Jesper Juhl
@ 2006-07-30 16:37 ` Jesper Juhl
  2006-07-30 16:38 ` [PATCH 04/12] making the kernel -Wshadow clean - warnings related to 'up' Jesper Juhl
                   ` (11 subsequent siblings)
  14 siblings, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 16:37 UTC (permalink / raw)
  To: linux-kernel; +Cc: Jesper Juhl, linux-kernel

Fix -Wshadow warnings in include/linux/jiffies.h


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 include/linux/jiffies.h |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

--- linux-2.6.18-rc2-orig/include/linux/jiffies.h	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.18-rc2/include/linux/jiffies.h	2006-07-18 20:31:57.000000000 +0200
@@ -325,13 +325,13 @@ timespec_to_jiffies(const struct timespe
 }
 
 static __inline__ void
-jiffies_to_timespec(const unsigned long jiffies, struct timespec *value)
+jiffies_to_timespec(const unsigned long jiffy, struct timespec *value)
 {
 	/*
 	 * Convert jiffies to nanoseconds and separate with
 	 * one divide.
 	 */
-	u64 nsec = (u64)jiffies * TICK_NSEC;
+	u64 nsec = (u64)jiffy * TICK_NSEC;
 	value->tv_sec = div_long_long_rem(nsec, NSEC_PER_SEC, &value->tv_nsec);
 }
 
@@ -363,13 +363,13 @@ timeval_to_jiffies(const struct timeval 
 }
 
 static __inline__ void
-jiffies_to_timeval(const unsigned long jiffies, struct timeval *value)
+jiffies_to_timeval(const unsigned long jiffy, struct timeval *value)
 {
 	/*
 	 * Convert jiffies to nanoseconds and separate with
 	 * one divide.
 	 */
-	u64 nsec = (u64)jiffies * TICK_NSEC;
+	u64 nsec = (u64)jiffy * TICK_NSEC;
 	long tv_usec;
 
 	value->tv_sec = div_long_long_rem(nsec, NSEC_PER_SEC, &tv_usec);




^ permalink raw reply	[flat|nested] 150+ messages in thread

* [PATCH 04/12] making the kernel -Wshadow clean - warnings related to 'up'
  2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
                   ` (2 preceding siblings ...)
  2006-07-30 16:37 ` [PATCH 03/12] making the kernel -Wshadow clean - fix jiffies.h Jesper Juhl
@ 2006-07-30 16:38 ` Jesper Juhl
  2006-07-30 16:38 ` [PATCH 05/12] making the kernel -Wshadow clean - warnings related to wbc and map_bh Jesper Juhl
                   ` (10 subsequent siblings)
  14 siblings, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 16:38 UTC (permalink / raw)
  To: linux-kernel; +Cc: Jesper Juhl, Andrew Morton

Fix a few -Wshadow warnings related to variables of the name 'up' clashing 
with the global function name up() by renaming the variables.


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 drivers/char/vt_ioctl.c |   60 +++++++++++++++++++-------------------
 fs/select.c             |    6 +--
 kernel/user.c           |   36 +++++++++++-----------
 3 files changed, 51 insertions(+), 51 deletions(-)

--- linux-2.6.18-rc2-orig/drivers/char/vt_ioctl.c	2006-07-18 18:46:23.000000000 +0200
+++ linux-2.6.18-rc2/drivers/char/vt_ioctl.c	2006-07-18 21:21:39.000000000 +0200
@@ -187,7 +187,7 @@ do_kdgkb_ioctl(int cmd, struct kbsentry 
 	struct kbsentry *kbs;
 	char *p;
 	u_char *q;
-	u_char __user *up;
+	u_char __user *u;
 	int sz;
 	int delta;
 	char *first_free, *fj, *fnw;
@@ -215,15 +215,15 @@ do_kdgkb_ioctl(int cmd, struct kbsentry 
 	case KDGKBSENT:
 		sz = sizeof(kbs->kb_string) - 1; /* sz should have been
 						  a struct member */
-		up = user_kdgkb->kb_string;
+		u = user_kdgkb->kb_string;
 		p = func_table[i];
 		if(p)
 			for ( ; *p && sz; p++, sz--)
-				if (put_user(*p, up++)) {
+				if (put_user(*p, u++)) {
 					ret = -EFAULT;
 					goto reterr;
 				}
-		if (put_user('\0', up)) {
+		if (put_user('\0', u)) {
 			ret = -EFAULT;
 			goto reterr;
 		}
@@ -370,7 +370,7 @@ int vt_ioctl(struct tty_struct *tty, str
 	struct kbd_struct * kbd;
 	unsigned int console;
 	unsigned char ucval;
-	void __user *up = (void __user *)arg;
+	void __user *u = (void __user *)arg;
 	int i, perm;
 	
 	console = vc->vc_num;
@@ -454,12 +454,12 @@ int vt_ioctl(struct tty_struct *tty, str
 		if (!capable(CAP_SYS_TTY_CONFIG))
 			return -EPERM;
 
-		if (copy_from_user(&kbrep, up, sizeof(struct kbd_repeat)))
+		if (copy_from_user(&kbrep, u, sizeof(struct kbd_repeat)))
 			return -EFAULT;
 		err = kbd_rate(&kbrep);
 		if (err)
 			return err;
-		if (copy_to_user(up, &kbrep, sizeof(struct kbd_repeat)))
+		if (copy_to_user(u, &kbrep, sizeof(struct kbd_repeat)))
 			return -EFAULT;
 		return 0;
 	}
@@ -569,19 +569,19 @@ int vt_ioctl(struct tty_struct *tty, str
 	case KDSETKEYCODE:
 		if(!capable(CAP_SYS_TTY_CONFIG))
 			perm=0;
-		return do_kbkeycode_ioctl(cmd, up, perm);
+		return do_kbkeycode_ioctl(cmd, u, perm);
 
 	case KDGKBENT:
 	case KDSKBENT:
-		return do_kdsk_ioctl(cmd, up, perm, kbd);
+		return do_kdsk_ioctl(cmd, u, perm, kbd);
 
 	case KDGKBSENT:
 	case KDSKBSENT:
-		return do_kdgkb_ioctl(cmd, up, perm);
+		return do_kdgkb_ioctl(cmd, u, perm);
 
 	case KDGKBDIACR:
 	{
-		struct kbdiacrs __user *a = up;
+		struct kbdiacrs __user *a = u;
 
 		if (put_user(accent_table_size, &a->kb_cnt))
 			return -EFAULT;
@@ -592,7 +592,7 @@ int vt_ioctl(struct tty_struct *tty, str
 
 	case KDSKBDIACR:
 	{
-		struct kbdiacrs __user *a = up;
+		struct kbdiacrs __user *a = u;
 		unsigned int ct;
 
 		if (!perm)
@@ -661,7 +661,7 @@ int vt_ioctl(struct tty_struct *tty, str
 
 		if (!perm)
 			return -EPERM;
-		if (copy_from_user(&tmp, up, sizeof(struct vt_mode)))
+		if (copy_from_user(&tmp, u, sizeof(struct vt_mode)))
 			return -EFAULT;
 		if (tmp.mode != VT_AUTO && tmp.mode != VT_PROCESS)
 			return -EINVAL;
@@ -685,7 +685,7 @@ int vt_ioctl(struct tty_struct *tty, str
 		memcpy(&tmp, &vc->vt_mode, sizeof(struct vt_mode));
 		release_console_sem();
 
-		rc = copy_to_user(up, &tmp, sizeof(struct vt_mode));
+		rc = copy_to_user(u, &tmp, sizeof(struct vt_mode));
 		return rc ? -EFAULT : 0;
 	}
 
@@ -696,7 +696,7 @@ int vt_ioctl(struct tty_struct *tty, str
 	 */
 	case VT_GETSTATE:
 	{
-		struct vt_stat __user *vtstat = up;
+		struct vt_stat __user *vtstat = u;
 		unsigned short state, mask;
 
 		if (put_user(fg_console + 1, &vtstat->v_active))
@@ -840,7 +840,7 @@ int vt_ioctl(struct tty_struct *tty, str
 
 	case VT_RESIZE:
 	{
-		struct vt_sizes __user *vtsizes = up;
+		struct vt_sizes __user *vtsizes = u;
 		ushort ll,cc;
 		if (!perm)
 			return -EPERM;
@@ -857,7 +857,7 @@ int vt_ioctl(struct tty_struct *tty, str
 
 	case VT_RESIZEX:
 	{
-		struct vt_consize __user *vtconsize = up;
+		struct vt_consize __user *vtconsize = u;
 		ushort ll,cc,vlin,clin,vcol,ccol;
 		if (!perm)
 			return -EPERM;
@@ -911,7 +911,7 @@ int vt_ioctl(struct tty_struct *tty, str
 		op.width = 8;
 		op.height = 0;
 		op.charcount = 256;
-		op.data = up;
+		op.data = u;
 		return con_font_op(vc_cons[fg_console].d, &op);
 	}
 
@@ -921,21 +921,21 @@ int vt_ioctl(struct tty_struct *tty, str
 		op.width = 8;
 		op.height = 32;
 		op.charcount = 256;
-		op.data = up;
+		op.data = u;
 		return con_font_op(vc_cons[fg_console].d, &op);
 	}
 
 	case PIO_CMAP:
                 if (!perm)
 			return -EPERM;
-                return con_set_cmap(up);
+                return con_set_cmap(u);
 
 	case GIO_CMAP:
-                return con_get_cmap(up);
+                return con_get_cmap(u);
 
 	case PIO_FONTX:
 	case GIO_FONTX:
-		return do_fontx_ioctl(cmd, up, perm, &op);
+		return do_fontx_ioctl(cmd, u, perm, &op);
 
 	case PIO_FONTRESET:
 	{
@@ -960,13 +960,13 @@ int vt_ioctl(struct tty_struct *tty, str
 	}
 
 	case KDFONTOP: {
-		if (copy_from_user(&op, up, sizeof(op)))
+		if (copy_from_user(&op, u, sizeof(op)))
 			return -EFAULT;
 		if (!perm && op.op != KD_FONT_OP_GET)
 			return -EPERM;
 		i = con_font_op(vc, &op);
 		if (i) return i;
-		if (copy_to_user(up, &op, sizeof(op)))
+		if (copy_to_user(u, &op, sizeof(op)))
 			return -EFAULT;
 		return 0;
 	}
@@ -974,24 +974,24 @@ int vt_ioctl(struct tty_struct *tty, str
 	case PIO_SCRNMAP:
 		if (!perm)
 			return -EPERM;
-		return con_set_trans_old(up);
+		return con_set_trans_old(u);
 
 	case GIO_SCRNMAP:
-		return con_get_trans_old(up);
+		return con_get_trans_old(u);
 
 	case PIO_UNISCRNMAP:
 		if (!perm)
 			return -EPERM;
-		return con_set_trans_new(up);
+		return con_set_trans_new(u);
 
 	case GIO_UNISCRNMAP:
-		return con_get_trans_new(up);
+		return con_get_trans_new(u);
 
 	case PIO_UNIMAPCLR:
 	      { struct unimapinit ui;
 		if (!perm)
 			return -EPERM;
-		i = copy_from_user(&ui, up, sizeof(struct unimapinit));
+		i = copy_from_user(&ui, u, sizeof(struct unimapinit));
 		if (i) return -EFAULT;
 		con_clear_unimap(vc, &ui);
 		return 0;
@@ -999,7 +999,7 @@ int vt_ioctl(struct tty_struct *tty, str
 
 	case PIO_UNIMAP:
 	case GIO_UNIMAP:
-		return do_unimap_ioctl(cmd, up, perm, vc);
+		return do_unimap_ioctl(cmd, u, perm, vc);
 
 	case VT_LOCKSWITCH:
 		if (!capable(CAP_SYS_TTY_CONFIG))
--- linux-2.6.18-rc2-orig/fs/select.c	2006-07-18 18:46:59.000000000 +0200
+++ linux-2.6.18-rc2/fs/select.c	2006-07-18 21:23:01.000000000 +0200
@@ -524,17 +524,17 @@ asmlinkage long sys_pselect6(int n, fd_s
 	fd_set __user *exp, struct timespec __user *tsp, void __user *sig)
 {
 	size_t sigsetsize = 0;
-	sigset_t __user *up = NULL;
+	sigset_t __user *u = NULL;
 
 	if (sig) {
 		if (!access_ok(VERIFY_READ, sig, sizeof(void *)+sizeof(size_t))
-		    || __get_user(up, (sigset_t __user * __user *)sig)
+		    || __get_user(u, (sigset_t __user * __user *)sig)
 		    || __get_user(sigsetsize,
 				(size_t __user *)(sig+sizeof(void *))))
 			return -EFAULT;
 	}
 
-	return sys_pselect7(n, inp, outp, exp, tsp, up, sigsetsize);
+	return sys_pselect7(n, inp, outp, exp, tsp, u, sigsetsize);
 }
 #endif /* TIF_RESTORE_SIGMASK */
 
--- linux-2.6.18-rc2-orig/kernel/user.c	2006-07-18 18:47:16.000000000 +0200
+++ linux-2.6.18-rc2/kernel/user.c	2006-07-19 00:05:58.000000000 +0200
@@ -56,14 +56,14 @@ struct user_struct root_user = {
 /*
  * These routines must be called with the uidhash spinlock held!
  */
-static inline void uid_hash_insert(struct user_struct *up, struct list_head *hashent)
+static inline void uid_hash_insert(struct user_struct *u, struct list_head *hashent)
 {
-	list_add(&up->uidhash_list, hashent);
+	list_add(&u->uidhash_list, hashent);
 }
 
-static inline void uid_hash_remove(struct user_struct *up)
+static inline void uid_hash_remove(struct user_struct *u)
 {
-	list_del(&up->uidhash_list);
+	list_del(&u->uidhash_list);
 }
 
 static inline struct user_struct *uid_hash_find(uid_t uid, struct list_head *hashent)
@@ -101,20 +101,20 @@ struct user_struct *find_user(uid_t uid)
 	return ret;
 }
 
-void free_uid(struct user_struct *up)
+void free_uid(struct user_struct *u)
 {
 	unsigned long flags;
 
-	if (!up)
+	if (!u)
 		return;
 
 	local_irq_save(flags);
-	if (atomic_dec_and_lock(&up->__count, &uidhash_lock)) {
-		uid_hash_remove(up);
+	if (atomic_dec_and_lock(&u->__count, &uidhash_lock)) {
+		uid_hash_remove(u);
 		spin_unlock_irqrestore(&uidhash_lock, flags);
-		key_put(up->uid_keyring);
-		key_put(up->session_keyring);
-		kmem_cache_free(uid_cachep, up);
+		key_put(u->uid_keyring);
+		key_put(u->session_keyring);
+		kmem_cache_free(uid_cachep, u);
 	} else {
 		local_irq_restore(flags);
 	}
@@ -123,13 +123,13 @@ void free_uid(struct user_struct *up)
 struct user_struct * alloc_uid(uid_t uid)
 {
 	struct list_head *hashent = uidhashentry(uid);
-	struct user_struct *up;
+	struct user_struct *u;
 
 	spin_lock_irq(&uidhash_lock);
-	up = uid_hash_find(uid, hashent);
+	u = uid_hash_find(uid, hashent);
 	spin_unlock_irq(&uidhash_lock);
 
-	if (!up) {
+	if (!u) {
 		struct user_struct *new;
 
 		new = kmem_cache_alloc(uid_cachep, SLAB_KERNEL);
@@ -158,19 +158,19 @@ struct user_struct * alloc_uid(uid_t uid
 		 * on adding the same user already..
 		 */
 		spin_lock_irq(&uidhash_lock);
-		up = uid_hash_find(uid, hashent);
-		if (up) {
+		u = uid_hash_find(uid, hashent);
+		if (u) {
 			key_put(new->uid_keyring);
 			key_put(new->session_keyring);
 			kmem_cache_free(uid_cachep, new);
 		} else {
 			uid_hash_insert(new, hashent);
-			up = new;
+			u = new;
 		}
 		spin_unlock_irq(&uidhash_lock);
 
 	}
-	return up;
+	return u;
 }
 
 void switch_uid(struct user_struct *new_user)




^ permalink raw reply	[flat|nested] 150+ messages in thread

* [PATCH 05/12] making the kernel -Wshadow clean - warnings related to wbc and map_bh
  2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
                   ` (3 preceding siblings ...)
  2006-07-30 16:38 ` [PATCH 04/12] making the kernel -Wshadow clean - warnings related to 'up' Jesper Juhl
@ 2006-07-30 16:38 ` Jesper Juhl
  2006-07-30 16:39 ` [PATCH 06/12] making the kernel -Wshadow clean - fix checksum Jesper Juhl
                   ` (9 subsequent siblings)
  14 siblings, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 16:38 UTC (permalink / raw)
  To: linux-kernel; +Cc: Jesper Juhl, Andrew Morton

Fix -Wshadow warnings related to wbc and map_bh.

 
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 fs/buffer.c        |   28 +++++++-------
 fs/direct-io.c     |   24 ++++++------
 fs/ext3/dir.c      |    8 ++--
 fs/mpage.c         |   86 +++++++++++++++++++++----------------------
 include/linux/fs.h |    2 -
 5 files changed, 74 insertions(+), 74 deletions(-)

--- linux-2.6.18-rc2-orig/include/linux/fs.h	2006-07-18 18:47:10.000000000 +0200
+++ linux-2.6.18-rc2/include/linux/fs.h	2006-07-18 21:48:47.000000000 +0200
@@ -352,7 +352,7 @@ struct address_space;
 struct writeback_control;
 
 struct address_space_operations {
-	int (*writepage)(struct page *page, struct writeback_control *wbc);
+	int (*writepage)(struct page *page, struct writeback_control *wbctrl);
 	int (*readpage)(struct file *, struct page *);
 	void (*sync_page)(struct page *);
 
--- linux-2.6.18-rc2-orig/fs/mpage.c	2006-07-18 18:46:58.000000000 +0200
+++ linux-2.6.18-rc2/fs/mpage.c	2006-07-18 21:49:17.000000000 +0200
@@ -174,7 +174,7 @@ map_buffer_to_page(struct page *page, st
  */
 static struct bio *
 do_mpage_readpage(struct bio *bio, struct page *page, unsigned nr_pages,
-		sector_t *last_block_in_bio, struct buffer_head *map_bh,
+		sector_t *last_block_in_bio, struct buffer_head *bh_map,
 		unsigned long *first_logical_block, get_block_t get_block)
 {
 	struct inode *inode = page->mapping->host;
@@ -206,49 +206,49 @@ do_mpage_readpage(struct bio *bio, struc
 	/*
 	 * Map blocks using the result from the previous get_blocks call first.
 	 */
-	nblocks = map_bh->b_size >> blkbits;
-	if (buffer_mapped(map_bh) && block_in_file > *first_logical_block &&
+	nblocks = bh_map->b_size >> blkbits;
+	if (buffer_mapped(bh_map) && block_in_file > *first_logical_block &&
 			block_in_file < (*first_logical_block + nblocks)) {
 		unsigned map_offset = block_in_file - *first_logical_block;
 		unsigned last = nblocks - map_offset;
 
 		for (relative_block = 0; ; relative_block++) {
 			if (relative_block == last) {
-				clear_buffer_mapped(map_bh);
+				clear_buffer_mapped(bh_map);
 				break;
 			}
 			if (page_block == blocks_per_page)
 				break;
-			blocks[page_block] = map_bh->b_blocknr + map_offset +
+			blocks[page_block] = bh_map->b_blocknr + map_offset +
 						relative_block;
 			page_block++;
 			block_in_file++;
 		}
-		bdev = map_bh->b_bdev;
+		bdev = bh_map->b_bdev;
 	}
 
 	/*
 	 * Then do more get_blocks calls until we are done with this page.
 	 */
-	map_bh->b_page = page;
+	bh_map->b_page = page;
 	while (page_block < blocks_per_page) {
-		map_bh->b_state = 0;
-		map_bh->b_size = 0;
+		bh_map->b_state = 0;
+		bh_map->b_size = 0;
 
 		if (block_in_file < last_block) {
-			map_bh->b_size = (last_block-block_in_file) << blkbits;
-			if (get_block(inode, block_in_file, map_bh, 0))
+			bh_map->b_size = (last_block-block_in_file) << blkbits;
+			if (get_block(inode, block_in_file, bh_map, 0))
 				goto confused;
 			*first_logical_block = block_in_file;
 		}
 
-		if (!buffer_mapped(map_bh)) {
+		if (!buffer_mapped(bh_map)) {
 			fully_mapped = 0;
 			if (first_hole == blocks_per_page)
 				first_hole = page_block;
 			page_block++;
 			block_in_file++;
-			clear_buffer_mapped(map_bh);
+			clear_buffer_mapped(bh_map);
 			continue;
 		}
 
@@ -258,8 +258,8 @@ do_mpage_readpage(struct bio *bio, struc
 		 * we just collected from get_block into the page's buffers
 		 * so readpage doesn't have to repeat the get_block call
 		 */
-		if (buffer_uptodate(map_bh)) {
-			map_buffer_to_page(page, map_bh, page_block);
+		if (buffer_uptodate(bh_map)) {
+			map_buffer_to_page(page, bh_map, page_block);
 			goto confused;
 		}
 	
@@ -267,20 +267,20 @@ do_mpage_readpage(struct bio *bio, struc
 			goto confused;		/* hole -> non-hole */
 
 		/* Contiguous blocks? */
-		if (page_block && blocks[page_block-1] != map_bh->b_blocknr-1)
+		if (page_block && blocks[page_block-1] != bh_map->b_blocknr-1)
 			goto confused;
-		nblocks = map_bh->b_size >> blkbits;
+		nblocks = bh_map->b_size >> blkbits;
 		for (relative_block = 0; ; relative_block++) {
 			if (relative_block == nblocks) {
-				clear_buffer_mapped(map_bh);
+				clear_buffer_mapped(bh_map);
 				break;
 			} else if (page_block == blocks_per_page)
 				break;
-			blocks[page_block] = map_bh->b_blocknr+relative_block;
+			blocks[page_block] = bh_map->b_blocknr+relative_block;
 			page_block++;
 			block_in_file++;
 		}
-		bdev = map_bh->b_bdev;
+		bdev = bh_map->b_bdev;
 	}
 
 	if (first_hole != blocks_per_page) {
@@ -319,7 +319,7 @@ alloc_new:
 		goto alloc_new;
 	}
 
-	if (buffer_boundary(map_bh) || (first_hole != blocks_per_page))
+	if (buffer_boundary(bh_map) || (first_hole != blocks_per_page))
 		bio = mpage_bio_submit(READ, bio);
 	else
 		*last_block_in_bio = blocks[blocks_per_page - 1];
@@ -390,10 +390,10 @@ mpage_readpages(struct address_space *ma
 	unsigned page_idx;
 	sector_t last_block_in_bio = 0;
 	struct pagevec lru_pvec;
-	struct buffer_head map_bh;
+	struct buffer_head bh_map;
 	unsigned long first_logical_block = 0;
 
-	clear_buffer_mapped(&map_bh);
+	clear_buffer_mapped(&bh_map);
 	pagevec_init(&lru_pvec, 0);
 	for (page_idx = 0; page_idx < nr_pages; page_idx++) {
 		struct page *page = list_entry(pages->prev, struct page, lru);
@@ -404,7 +404,7 @@ mpage_readpages(struct address_space *ma
 					page->index, GFP_KERNEL)) {
 			bio = do_mpage_readpage(bio, page,
 					nr_pages - page_idx,
-					&last_block_in_bio, &map_bh,
+					&last_block_in_bio, &bh_map,
 					&first_logical_block,
 					get_block);
 			if (!pagevec_add(&lru_pvec, page))
@@ -428,12 +428,12 @@ int mpage_readpage(struct page *page, ge
 {
 	struct bio *bio = NULL;
 	sector_t last_block_in_bio = 0;
-	struct buffer_head map_bh;
+	struct buffer_head bh_map;
 	unsigned long first_logical_block = 0;
 
-	clear_buffer_mapped(&map_bh);
+	clear_buffer_mapped(&bh_map);
 	bio = do_mpage_readpage(bio, page, 1, &last_block_in_bio,
-			&map_bh, &first_logical_block, get_block);
+			&bh_map, &first_logical_block, get_block);
 	if (bio)
 		mpage_bio_submit(READ, bio);
 	return 0;
@@ -476,7 +476,7 @@ __mpage_writepage(struct bio *bio, struc
 	sector_t boundary_block = 0;
 	struct block_device *boundary_bdev = NULL;
 	int length;
-	struct buffer_head map_bh;
+	struct buffer_head bh_map;
 	loff_t i_size = i_size_read(inode);
 
 	if (page_has_buffers(page)) {
@@ -535,27 +535,27 @@ __mpage_writepage(struct bio *bio, struc
 	BUG_ON(!PageUptodate(page));
 	block_in_file = (sector_t)page->index << (PAGE_CACHE_SHIFT - blkbits);
 	last_block = (i_size - 1) >> blkbits;
-	map_bh.b_page = page;
+	bh_map.b_page = page;
 	for (page_block = 0; page_block < blocks_per_page; ) {
 
-		map_bh.b_state = 0;
-		map_bh.b_size = 1 << blkbits;
-		if (get_block(inode, block_in_file, &map_bh, 1))
+		bh_map.b_state = 0;
+		bh_map.b_size = 1 << blkbits;
+		if (get_block(inode, block_in_file, &bh_map, 1))
 			goto confused;
-		if (buffer_new(&map_bh))
-			unmap_underlying_metadata(map_bh.b_bdev,
-						map_bh.b_blocknr);
-		if (buffer_boundary(&map_bh)) {
-			boundary_block = map_bh.b_blocknr;
-			boundary_bdev = map_bh.b_bdev;
+		if (buffer_new(&bh_map))
+			unmap_underlying_metadata(bh_map.b_bdev,
+						bh_map.b_blocknr);
+		if (buffer_boundary(&bh_map)) {
+			boundary_block = bh_map.b_blocknr;
+			boundary_bdev = bh_map.b_bdev;
 		}
 		if (page_block) {
-			if (map_bh.b_blocknr != blocks[page_block-1] + 1)
+			if (bh_map.b_blocknr != blocks[page_block-1] + 1)
 				goto confused;
 		}
-		blocks[page_block++] = map_bh.b_blocknr;
-		boundary = buffer_boundary(&map_bh);
-		bdev = map_bh.b_bdev;
+		blocks[page_block++] = bh_map.b_blocknr;
+		boundary = buffer_boundary(&bh_map);
+		bdev = bh_map.b_bdev;
 		if (block_in_file == last_block)
 			break;
 		block_in_file++;
@@ -703,7 +703,7 @@ mpage_writepages(struct address_space *m
 	sector_t last_block_in_bio = 0;
 	int ret = 0;
 	int done = 0;
-	int (*writepage)(struct page *page, struct writeback_control *wbc);
+	int (*writepage)(struct page *page, struct writeback_control *wbctrl);
 	struct pagevec pvec;
 	int nr_pages;
 	pgoff_t index;
--- linux-2.6.18-rc2-orig/fs/buffer.c	2006-07-18 18:46:57.000000000 +0200
+++ linux-2.6.18-rc2/fs/buffer.c	2006-07-18 21:53:24.000000000 +0200
@@ -2374,7 +2374,7 @@ int nobh_prepare_write(struct page *page
 	struct inode *inode = page->mapping->host;
 	const unsigned blkbits = inode->i_blkbits;
 	const unsigned blocksize = 1 << blkbits;
-	struct buffer_head map_bh;
+	struct buffer_head bh_map;
 	struct buffer_head *read_bh[MAX_BUF_PER_PAGE];
 	unsigned block_in_page;
 	unsigned block_start;
@@ -2390,7 +2390,7 @@ int nobh_prepare_write(struct page *page
 		return 0;
 
 	block_in_file = (sector_t)page->index << (PAGE_CACHE_SHIFT - blkbits);
-	map_bh.b_page = page;
+	bh_map.b_page = page;
 
 	/*
 	 * We loop across all blocks in the page, whether or not they are
@@ -2403,23 +2403,23 @@ int nobh_prepare_write(struct page *page
 		unsigned block_end = block_start + blocksize;
 		int create;
 
-		map_bh.b_state = 0;
+		bh_map.b_state = 0;
 		create = 1;
 		if (block_start >= to)
 			create = 0;
-		map_bh.b_size = blocksize;
+		bh_map.b_size = blocksize;
 		ret = get_block(inode, block_in_file + block_in_page,
-					&map_bh, create);
+					&bh_map, create);
 		if (ret)
 			goto failed;
-		if (!buffer_mapped(&map_bh))
+		if (!buffer_mapped(&bh_map))
 			is_mapped_to_disk = 0;
-		if (buffer_new(&map_bh))
-			unmap_underlying_metadata(map_bh.b_bdev,
-							map_bh.b_blocknr);
+		if (buffer_new(&bh_map))
+			unmap_underlying_metadata(bh_map.b_bdev,
+							bh_map.b_blocknr);
 		if (PageUptodate(page))
 			continue;
-		if (buffer_new(&map_bh) || !buffer_mapped(&map_bh)) {
+		if (buffer_new(&bh_map) || !buffer_mapped(&bh_map)) {
 			kaddr = kmap_atomic(page, KM_USER0);
 			if (block_start < from) {
 				memset(kaddr+block_start, 0, from-block_start);
@@ -2433,7 +2433,7 @@ int nobh_prepare_write(struct page *page
 			kunmap_atomic(kaddr, KM_USER0);
 			continue;
 		}
-		if (buffer_uptodate(&map_bh))
+		if (buffer_uptodate(&bh_map))
 			continue;	/* reiserfs does this */
 		if (block_start < from || block_end > to) {
 			struct buffer_head *bh = alloc_buffer_head(GFP_NOFS);
@@ -2442,14 +2442,14 @@ int nobh_prepare_write(struct page *page
 				ret = -ENOMEM;
 				goto failed;
 			}
-			bh->b_state = map_bh.b_state;
+			bh->b_state = bh_map.b_state;
 			atomic_set(&bh->b_count, 0);
 			bh->b_this_page = NULL;
 			bh->b_page = page;
-			bh->b_blocknr = map_bh.b_blocknr;
+			bh->b_blocknr = bh_map.b_blocknr;
 			bh->b_size = blocksize;
 			bh->b_data = (char *)(long)block_start;
-			bh->b_bdev = map_bh.b_bdev;
+			bh->b_bdev = bh_map.b_bdev;
 			bh->b_private = NULL;
 			read_bh[nr_reads++] = bh;
 		}
--- linux-2.6.18-rc2-orig/fs/direct-io.c	2006-07-18 18:46:57.000000000 +0200
+++ linux-2.6.18-rc2/fs/direct-io.c	2006-07-18 21:55:58.000000000 +0200
@@ -512,7 +512,7 @@ static int dio_bio_reap(struct dio *dio)
 static int get_more_blocks(struct dio *dio)
 {
 	int ret;
-	struct buffer_head *map_bh = &dio->map_bh;
+	struct buffer_head *bh_map = &dio->map_bh;
 	sector_t fs_startblk;	/* Into file, in filesystem-sized blocks */
 	unsigned long fs_count;	/* Number of filesystem-sized blocks */
 	unsigned long dio_count;/* Number of dio_block-sized blocks */
@@ -533,8 +533,8 @@ static int get_more_blocks(struct dio *d
 		if (dio_count & blkmask)	
 			fs_count++;
 
-		map_bh->b_state = 0;
-		map_bh->b_size = fs_count << dio->inode->i_blkbits;
+		bh_map->b_state = 0;
+		bh_map->b_size = fs_count << dio->inode->i_blkbits;
 
 		create = dio->rw & WRITE;
 		if (dio->lock_type == DIO_LOCKING) {
@@ -552,7 +552,7 @@ static int get_more_blocks(struct dio *d
 		 * writes.
 		 */
 		ret = (*dio->get_block)(dio->inode, fs_startblk,
-						map_bh, create);
+						bh_map, create);
 	}
 	return ret;
 }
@@ -799,7 +799,7 @@ static int do_direct_IO(struct dio *dio)
 	const unsigned blocks_per_page = PAGE_SIZE >> blkbits;
 	struct page *page;
 	unsigned block_in_page;
-	struct buffer_head *map_bh = &dio->map_bh;
+	struct buffer_head *bh_map = &dio->map_bh;
 	int ret = 0;
 
 	/* The I/O can start at any block offset within the first page */
@@ -830,14 +830,14 @@ static int do_direct_IO(struct dio *dio)
 					page_cache_release(page);
 					goto out;
 				}
-				if (!buffer_mapped(map_bh))
+				if (!buffer_mapped(bh_map))
 					goto do_holes;
 
 				dio->blocks_available =
-						map_bh->b_size >> dio->blkbits;
+						bh_map->b_size >> dio->blkbits;
 				dio->next_block_for_io =
-					map_bh->b_blocknr << dio->blkfactor;
-				if (buffer_new(map_bh))
+					bh_map->b_blocknr << dio->blkfactor;
+				if (buffer_new(bh_map))
 					clean_blockdev_aliases(dio);
 
 				if (!dio->blkfactor)
@@ -857,13 +857,13 @@ static int do_direct_IO(struct dio *dio)
 				 * the start of the fs block must be zeroed out
 				 * on-disk
 				 */
-				if (!buffer_new(map_bh))
+				if (!buffer_new(bh_map))
 					dio->next_block_for_io += dio_remainder;
 				dio->blocks_available -= dio_remainder;
 			}
 do_holes:
 			/* Handle holes */
-			if (!buffer_mapped(map_bh)) {
+			if (!buffer_mapped(bh_map)) {
 				char *kaddr;
 				loff_t i_size_aligned;
 
@@ -917,7 +917,7 @@ do_holes:
 			this_chunk_bytes = this_chunk_blocks << blkbits;
 			BUG_ON(this_chunk_bytes == 0);
 
-			dio->boundary = buffer_boundary(map_bh);
+			dio->boundary = buffer_boundary(bh_map);
 			ret = submit_page_section(dio, page, offset_in_page,
 				this_chunk_bytes, dio->next_block_for_io);
 			if (ret) {
--- linux-2.6.18-rc2-orig/fs/ext3/dir.c	2006-07-18 18:46:57.000000000 +0200
+++ linux-2.6.18-rc2/fs/ext3/dir.c	2006-07-18 21:57:29.000000000 +0200
@@ -127,17 +127,17 @@ static int ext3_readdir(struct file * fi
 
 	while (!error && !stored && filp->f_pos < inode->i_size) {
 		unsigned long blk = filp->f_pos >> EXT3_BLOCK_SIZE_BITS(sb);
-		struct buffer_head map_bh;
+		struct buffer_head bh_map;
 		struct buffer_head *bh = NULL;
 
-		map_bh.b_state = 0;
+		bh_map.b_state = 0;
 		err = ext3_get_blocks_handle(NULL, inode, blk, 1,
-						&map_bh, 0, 0);
+						&bh_map, 0, 0);
 		if (err > 0) {
 			page_cache_readahead(sb->s_bdev->bd_inode->i_mapping,
 				&filp->f_ra,
 				filp,
-				map_bh.b_blocknr >>
+				bh_map.b_blocknr >>
 					(PAGE_CACHE_SHIFT - inode->i_blkbits),
 				1);
 			bh = ext3_bread(NULL, inode, blk, 0, &err);




^ permalink raw reply	[flat|nested] 150+ messages in thread

* [PATCH 06/12] making the kernel -Wshadow clean - fix checksum
  2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
                   ` (4 preceding siblings ...)
  2006-07-30 16:38 ` [PATCH 05/12] making the kernel -Wshadow clean - warnings related to wbc and map_bh Jesper Juhl
@ 2006-07-30 16:39 ` Jesper Juhl
  2006-07-30 16:40 ` [PATCH 07/12] making the kernel -Wshadow clean - fix vgacon Jesper Juhl
                   ` (8 subsequent siblings)
  14 siblings, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 16:39 UTC (permalink / raw)
  To: linux-kernel; +Cc: Jesper Juhl, Andrew Morton

Some -Wshadow fixes for include/[asm-i386|net]/checksum.h

 include/asm/checksum.h:185: warning: declaration of 'sum' shadows a parameter
 include/asm/checksum.h:181: warning: shadowed declaration is here
 include/net/checksum.h:33: warning: declaration of 'sum' shadows a parameter
 include/net/checksum.h:31: warning: shadowed declaration is here

these show up several times each.


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 include/asm-i386/checksum.h |    4 ++--
 include/net/checksum.h      |   12 ++++++------
 2 files changed, 8 insertions(+), 8 deletions(-)

--- linux-2.6.18-rc2-orig/include/asm-i386/checksum.h	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.18-rc2/include/asm-i386/checksum.h	2006-07-18 22:03:59.000000000 +0200
@@ -178,12 +178,12 @@ static __inline__ unsigned short int csu
 #define HAVE_CSUM_COPY_USER
 static __inline__ unsigned int csum_and_copy_to_user(const unsigned char *src,
 						     unsigned char __user *dst,
-						     int len, int sum, 
+						     int len, int csum,
 						     int *err_ptr)
 {
 	might_sleep();
 	if (access_ok(VERIFY_WRITE, dst, len))
-		return csum_partial_copy_generic(src, (__force unsigned char *)dst, len, sum, NULL, err_ptr);
+		return csum_partial_copy_generic(src, (__force unsigned char *)dst, len, csum, NULL, err_ptr);
 
 	if (len)
 		*err_ptr = -EFAULT;
--- linux-2.6.18-rc2-orig/include/net/checksum.h	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.18-rc2/include/net/checksum.h	2006-07-18 22:03:59.000000000 +0200
@@ -28,27 +28,27 @@
 #ifndef _HAVE_ARCH_COPY_AND_CSUM_FROM_USER
 static inline
 unsigned int csum_and_copy_from_user (const unsigned char __user *src, unsigned char *dst,
-				      int len, int sum, int *err_ptr)
+				      int len, int csum, int *err_ptr)
 {
 	if (access_ok(VERIFY_READ, src, len))
-		return csum_partial_copy_from_user(src, dst, len, sum, err_ptr);
+		return csum_partial_copy_from_user(src, dst, len, csum, err_ptr);
 
 	if (len)
 		*err_ptr = -EFAULT;
 
-	return sum;
+	return csum;
 }
 #endif
 
 #ifndef HAVE_CSUM_COPY_USER
 static __inline__ unsigned int csum_and_copy_to_user
-(const unsigned char *src, unsigned char __user *dst, int len, unsigned int sum, int *err_ptr)
+(const unsigned char *src, unsigned char __user *dst, int len, unsigned int csum, int *err_ptr)
 {
-	sum = csum_partial(src, len, sum);
+	sum = csum_partial(src, len, csum);
 
 	if (access_ok(VERIFY_WRITE, dst, len)) {
 		if (copy_to_user(dst, src, len) == 0)
-			return sum;
+			return csum;
 	}
 	if (len)
 		*err_ptr = -EFAULT;




^ permalink raw reply	[flat|nested] 150+ messages in thread

* [PATCH 07/12] making the kernel -Wshadow clean - fix vgacon
  2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
                   ` (5 preceding siblings ...)
  2006-07-30 16:39 ` [PATCH 06/12] making the kernel -Wshadow clean - fix checksum Jesper Juhl
@ 2006-07-30 16:40 ` Jesper Juhl
  2006-07-30 16:41 ` [PATCH 08/12] making the kernel -Wshadow clean - fix keyboard.c Jesper Juhl
                   ` (7 subsequent siblings)
  14 siblings, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 16:40 UTC (permalink / raw)
  To: linux-kernel; +Cc: Jesper Juhl, Andrew Morton

Fix a few -Wshadow warnings in drivers/video/console/vgacon.c


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 drivers/video/console/vgacon.c |   72 +++++++++++++++----------------
 1 files changed, 35 insertions(+), 37 deletions(-)

--- linux-2.6.18-rc2-orig/drivers/video/console/vgacon.c	2006-07-18 18:46:50.000000000 +0200
+++ linux-2.6.18-rc2/drivers/video/console/vgacon.c	2006-07-19 00:32:19.000000000 +0200
@@ -855,14 +855,14 @@ static struct {
 	unsigned char ClockingMode;	/* Seq-Controller:01h */
 } vga_state;
 
-static void vga_vesa_blank(struct vgastate *state, int mode)
+static void vga_vesa_blank(struct vgastate *condition, int mode)
 {
 	/* save original values of VGA controller registers */
 	if (!vga_vesa_blanked) {
 		spin_lock_irq(&vga_lock);
-		vga_state.SeqCtrlIndex = vga_r(state->vgabase, VGA_SEQ_I);
+		vga_state.SeqCtrlIndex = vga_r(condition->vgabase, VGA_SEQ_I);
 		vga_state.CrtCtrlIndex = inb_p(vga_video_port_reg);
-		vga_state.CrtMiscIO = vga_r(state->vgabase, VGA_MIS_R);
+		vga_state.CrtMiscIO = vga_r(condition->vgabase, VGA_MIS_R);
 		spin_unlock_irq(&vga_lock);
 
 		outb_p(0x00, vga_video_port_reg);	/* HorizontalTotal */
@@ -881,17 +881,17 @@ static void vga_vesa_blank(struct vgasta
 		vga_state.EndVertRetrace = inb_p(vga_video_port_val);
 		outb_p(0x17, vga_video_port_reg);	/* ModeControl */
 		vga_state.ModeControl = inb_p(vga_video_port_val);
-		vga_state.ClockingMode = vga_rseq(state->vgabase, VGA_SEQ_CLOCK_MODE);
+		vga_state.ClockingMode = vga_rseq(condition->vgabase, VGA_SEQ_CLOCK_MODE);
 	}
 
 	/* assure that video is enabled */
 	/* "0x20" is VIDEO_ENABLE_bit in register 01 of sequencer */
 	spin_lock_irq(&vga_lock);
-	vga_wseq(state->vgabase, VGA_SEQ_CLOCK_MODE, vga_state.ClockingMode | 0x20);
+	vga_wseq(condition->vgabase, VGA_SEQ_CLOCK_MODE, vga_state.ClockingMode | 0x20);
 
 	/* test for vertical retrace in process.... */
 	if ((vga_state.CrtMiscIO & 0x80) == 0x80)
-		vga_w(state->vgabase, VGA_MIS_W, vga_state.CrtMiscIO & 0xEF);
+		vga_w(condition->vgabase, VGA_MIS_W, vga_state.CrtMiscIO & 0xEF);
 
 	/*
 	 * Set <End of vertical retrace> to minimum (0) and
@@ -920,16 +920,16 @@ static void vga_vesa_blank(struct vgasta
 	}
 
 	/* restore both index registers */
-	vga_w(state->vgabase, VGA_SEQ_I, vga_state.SeqCtrlIndex);
+	vga_w(condition->vgabase, VGA_SEQ_I, vga_state.SeqCtrlIndex);
 	outb_p(vga_state.CrtCtrlIndex, vga_video_port_reg);
 	spin_unlock_irq(&vga_lock);
 }
 
-static void vga_vesa_unblank(struct vgastate *state)
+static void vga_vesa_unblank(struct vgastate *condition)
 {
 	/* restore original values of VGA controller registers */
 	spin_lock_irq(&vga_lock);
-	vga_w(state->vgabase, VGA_MIS_W, vga_state.CrtMiscIO);
+	vga_w(condition->vgabase, VGA_MIS_W, vga_state.CrtMiscIO);
 
 	outb_p(0x00, vga_video_port_reg);	/* HorizontalTotal */
 	outb_p(vga_state.HorizontalTotal, vga_video_port_val);
@@ -948,24 +948,24 @@ static void vga_vesa_unblank(struct vgas
 	outb_p(0x17, vga_video_port_reg);	/* ModeControl */
 	outb_p(vga_state.ModeControl, vga_video_port_val);
 	/* ClockingMode */
-	vga_wseq(state->vgabase, VGA_SEQ_CLOCK_MODE, vga_state.ClockingMode);
+	vga_wseq(condition->vgabase, VGA_SEQ_CLOCK_MODE, vga_state.ClockingMode);
 
 	/* restore index/control registers */
-	vga_w(state->vgabase, VGA_SEQ_I, vga_state.SeqCtrlIndex);
+	vga_w(condition->vgabase, VGA_SEQ_I, vga_state.SeqCtrlIndex);
 	outb_p(vga_state.CrtCtrlIndex, vga_video_port_reg);
 	spin_unlock_irq(&vga_lock);
 }
 
-static void vga_pal_blank(struct vgastate *state)
+static void vga_pal_blank(struct vgastate *condition)
 {
 	int i;
 
-	vga_w(state->vgabase, VGA_PEL_MSK, 0xff);
+	vga_w(condition->vgabase, VGA_PEL_MSK, 0xff);
 	for (i = 0; i < 16; i++) {
-		vga_w(state->vgabase, VGA_PEL_IW, i);
-		vga_w(state->vgabase, VGA_PEL_D, 0);
-		vga_w(state->vgabase, VGA_PEL_D, 0);
-		vga_w(state->vgabase, VGA_PEL_D, 0);
+		vga_w(condition->vgabase, VGA_PEL_IW, i);
+		vga_w(condition->vgabase, VGA_PEL_D, 0);
+		vga_w(condition->vgabase, VGA_PEL_D, 0);
+		vga_w(condition->vgabase, VGA_PEL_D, 0);
 	}
 }
 
@@ -1027,7 +1027,7 @@ static int vgacon_blank(struct vc_data *
 #define blackwmap 0xa0000
 #define cmapsz 8192
 
-static int vgacon_do_font_op(struct vgastate *state,char *arg,int set,int ch512)
+static int vgacon_do_font_op(struct vgastate *condition,char *arg,int set,int ch512)
 {
 	unsigned short video_port_status = vga_video_port_reg + 6;
 	int font_select = 0x00, beg, i;
@@ -1075,20 +1075,20 @@ static int vgacon_do_font_op(struct vgas
 	unlock_kernel();
 	spin_lock_irq(&vga_lock);
 	/* First, the Sequencer */
-	vga_wseq(state->vgabase, VGA_SEQ_RESET, 0x1);
+	vga_wseq(condition->vgabase, VGA_SEQ_RESET, 0x1);
 	/* CPU writes only to map 2 */
-	vga_wseq(state->vgabase, VGA_SEQ_PLANE_WRITE, 0x04);	
+	vga_wseq(condition->vgabase, VGA_SEQ_PLANE_WRITE, 0x04);	
 	/* Sequential addressing */
-	vga_wseq(state->vgabase, VGA_SEQ_MEMORY_MODE, 0x07);	
+	vga_wseq(condition->vgabase, VGA_SEQ_MEMORY_MODE, 0x07);	
 	/* Clear synchronous reset */
-	vga_wseq(state->vgabase, VGA_SEQ_RESET, 0x03);
+	vga_wseq(condition->vgabase, VGA_SEQ_RESET, 0x03);
 
 	/* Now, the graphics controller, select map 2 */
-	vga_wgfx(state->vgabase, VGA_GFX_PLANE_READ, 0x02);		
+	vga_wgfx(condition->vgabase, VGA_GFX_PLANE_READ, 0x02);		
 	/* disable odd-even addressing */
-	vga_wgfx(state->vgabase, VGA_GFX_MODE, 0x00);
+	vga_wgfx(condition->vgabase, VGA_GFX_MODE, 0x00);
 	/* map start at A000:0000 */
-	vga_wgfx(state->vgabase, VGA_GFX_MISC, 0x00);
+	vga_wgfx(condition->vgabase, VGA_GFX_MISC, 0x00);
 	spin_unlock_irq(&vga_lock);
 
 	if (arg) {
@@ -1118,28 +1118,26 @@ static int vgacon_do_font_op(struct vgas
 
 	spin_lock_irq(&vga_lock);
 	/* First, the sequencer, Synchronous reset */
-	vga_wseq(state->vgabase, VGA_SEQ_RESET, 0x01);	
+	vga_wseq(condition->vgabase, VGA_SEQ_RESET, 0x01);	
 	/* CPU writes to maps 0 and 1 */
-	vga_wseq(state->vgabase, VGA_SEQ_PLANE_WRITE, 0x03);
+	vga_wseq(condition->vgabase, VGA_SEQ_PLANE_WRITE, 0x03);
 	/* odd-even addressing */
-	vga_wseq(state->vgabase, VGA_SEQ_MEMORY_MODE, 0x03);
+	vga_wseq(condition->vgabase, VGA_SEQ_MEMORY_MODE, 0x03);
 	/* Character Map Select */
 	if (set)
-		vga_wseq(state->vgabase, VGA_SEQ_CHARACTER_MAP, font_select);
+		vga_wseq(condition->vgabase, VGA_SEQ_CHARACTER_MAP, font_select);
 	/* clear synchronous reset */
-	vga_wseq(state->vgabase, VGA_SEQ_RESET, 0x03);
+	vga_wseq(condition->vgabase, VGA_SEQ_RESET, 0x03);
 
 	/* Now, the graphics controller, select map 0 for CPU */
-	vga_wgfx(state->vgabase, VGA_GFX_PLANE_READ, 0x00);
+	vga_wgfx(condition->vgabase, VGA_GFX_PLANE_READ, 0x00);
 	/* enable even-odd addressing */
-	vga_wgfx(state->vgabase, VGA_GFX_MODE, 0x10);
+	vga_wgfx(condition->vgabase, VGA_GFX_MODE, 0x10);
 	/* map starts at b800:0 or b000:0 */
-	vga_wgfx(state->vgabase, VGA_GFX_MISC, beg);
+	vga_wgfx(condition->vgabase, VGA_GFX_MISC, beg);
 
 	/* if 512 char mode is already enabled don't re-enable it. */
 	if ((set) && (ch512 != vga_512_chars)) {
-		int i;	
-		
 		/* attribute controller */
 		for (i = 0; i < MAX_NR_CONSOLES; i++) {
 			struct vc_data *c = vc_cons[i].d;
@@ -1151,11 +1149,11 @@ static int vgacon_do_font_op(struct vgas
 		   512-char: disable intensity bit */
 		inb_p(video_port_status);	/* clear address flip-flop */
 		/* color plane enable register */
-		vga_wattr(state->vgabase, VGA_ATC_PLANE_ENABLE, ch512 ? 0x07 : 0x0f);
+		vga_wattr(condition->vgabase, VGA_ATC_PLANE_ENABLE, ch512 ? 0x07 : 0x0f);
 		/* Wilton (1987) mentions the following; I don't know what
 		   it means, but it works, and it appears necessary */
 		inb_p(video_port_status);
-		vga_wattr(state->vgabase, VGA_AR_ENABLE_DISPLAY, 0);	
+		vga_wattr(condition->vgabase, VGA_AR_ENABLE_DISPLAY, 0);	
 	}
 	spin_unlock_irq(&vga_lock);
 	lock_kernel();



^ permalink raw reply	[flat|nested] 150+ messages in thread

* [PATCH 08/12] making the kernel -Wshadow clean - fix keyboard.c
  2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
                   ` (6 preceding siblings ...)
  2006-07-30 16:40 ` [PATCH 07/12] making the kernel -Wshadow clean - fix vgacon Jesper Juhl
@ 2006-07-30 16:41 ` Jesper Juhl
  2006-07-30 16:42 ` [PATCH 09/12] making the kernel -Wshadow clean - neighbour.h and 'proc_handler' Jesper Juhl
                   ` (6 subsequent siblings)
  14 siblings, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 16:41 UTC (permalink / raw)
  To: linux-kernel; +Cc: Jesper Juhl, Andrew Morton

Fix -Wshadow warnings in drivers/char/keyboard.c


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 drivers/char/keyboard.c |   58 +++++++++++++++++++-------------------
 1 files changed, 29 insertions(+), 29 deletions(-)

--- linux-2.6.18-rc2-orig/drivers/char/keyboard.c	2006-07-18 18:46:22.000000000 +0200
+++ linux-2.6.18-rc2/drivers/char/keyboard.c	2006-07-18 23:34:53.000000000 +0200
@@ -266,7 +266,7 @@ void kd_mksound(unsigned int hz, unsigne
  * Setting the keyboard rate.
  */
 
-int kbd_rate(struct kbd_repeat *rep)
+int kbd_rate(struct kbd_repeat *repeat)
 {
 	struct list_head *node;
 	unsigned int d = 0;
@@ -277,16 +277,16 @@ int kbd_rate(struct kbd_repeat *rep)
 		struct input_dev *dev = handle->dev;
 
 		if (test_bit(EV_REP, dev->evbit)) {
-			if (rep->delay > 0)
-				input_event(dev, EV_REP, REP_DELAY, rep->delay);
-			if (rep->period > 0)
-				input_event(dev, EV_REP, REP_PERIOD, rep->period);
+			if (repeat->delay > 0)
+				input_event(dev, EV_REP, REP_DELAY, repeat->delay);
+			if (repeat->period > 0)
+				input_event(dev, EV_REP, REP_PERIOD, repeat->period);
 			d = dev->rep[REP_DELAY];
 			p = dev->rep[REP_PERIOD];
 		}
 	}
-	rep->delay  = d;
-	rep->period = p;
+	repeat->delay  = d;
+	repeat->period = p;
 	return 0;
 }
 
@@ -944,28 +944,28 @@ unsigned char getledstate(void)
 	return ledstate;
 }
 
-void setledstate(struct kbd_struct *kbd, unsigned int led)
+void setledstate(struct kbd_struct *kbrd, unsigned int led)
 {
 	if (!(led & ~7)) {
 		ledioctl = led;
-		kbd->ledmode = LED_SHOW_IOCTL;
+		kbrd->ledmode = LED_SHOW_IOCTL;
 	} else
-		kbd->ledmode = LED_SHOW_FLAGS;
+		kbrd->ledmode = LED_SHOW_FLAGS;
 	set_leds();
 }
 
 static inline unsigned char getleds(void)
 {
-	struct kbd_struct *kbd = kbd_table + fg_console;
+	struct kbd_struct *kbrd = kbd_table + fg_console;
 	unsigned char leds;
 	int i;
 
-	if (kbd->ledmode == LED_SHOW_IOCTL)
+	if (kbrd->ledmode == LED_SHOW_IOCTL)
 		return ledioctl;
 
-	leds = kbd->ledflagstate;
+	leds = kbrd->ledflagstate;
 
-	if (kbd->ledmode == LED_SHOW_MEM) {
+	if (kbrd->ledmode == LED_SHOW_MEM) {
 		for (i = 0; i < 3; i++)
 			if (ledptrs[i].valid) {
 				if (*ledptrs[i].addr & ledptrs[i].mask)
@@ -1126,7 +1126,7 @@ static void kbd_rawcode(unsigned char da
 		put_queue(vc, data);
 }
 
-static void kbd_keycode(unsigned int keycode, int down,
+static void kbd_keycode(unsigned int keycode, int down_key,
 			int hw_raw, struct pt_regs *regs)
 {
 	struct vc_data *vc = vc_cons[fg_console].d;
@@ -1145,35 +1145,35 @@ static void kbd_keycode(unsigned int key
 	kbd = kbd_table + fg_console;
 
 	if (keycode == KEY_LEFTALT || keycode == KEY_RIGHTALT)
-		sysrq_alt = down ? keycode : 0;
+		sysrq_alt = down_key ? keycode : 0;
 #ifdef CONFIG_SPARC
 	if (keycode == KEY_STOP)
-		sparc_l1_a_state = down;
+		sparc_l1_a_state = down_key;
 #endif
 
-	rep = (down == 2);
+	rep = (down_key == 2);
 
 #ifdef CONFIG_MAC_EMUMOUSEBTN
-	if (mac_hid_mouse_emulate_buttons(1, keycode, down))
+	if (mac_hid_mouse_emulate_buttons(1, keycode, down_key))
 		return;
 #endif /* CONFIG_MAC_EMUMOUSEBTN */
 
 	if ((raw_mode = (kbd->kbdmode == VC_RAW)) && !hw_raw)
-		if (emulate_raw(vc, keycode, !down << 7))
+		if (emulate_raw(vc, keycode, !down_key << 7))
 			if (keycode < BTN_MISC)
 				printk(KERN_WARNING "keyboard.c: can't emulate rawmode for keycode %d\n", keycode);
 
 #ifdef CONFIG_MAGIC_SYSRQ	       /* Handle the SysRq Hack */
-	if (keycode == KEY_SYSRQ && (sysrq_down || (down == 1 && sysrq_alt))) {
+	if (keycode == KEY_SYSRQ && (sysrq_down || (down_key == 1 && sysrq_alt))) {
 		if (!sysrq_down) {
-			sysrq_down = down;
+			sysrq_down = down_key;
 			sysrq_alt_use = sysrq_alt;
 		}
 		return;
 	}
-	if (sysrq_down && !down && keycode == sysrq_alt_use)
+	if (sysrq_down && !down_key && keycode == sysrq_alt_use)
 		sysrq_down = 0;
-	if (sysrq_down && down && !rep) {
+	if (sysrq_down && down_key && !rep) {
 		handle_sysrq(kbd_sysrq_xlate[keycode], regs, tty);
 		return;
 	}
@@ -1196,16 +1196,16 @@ static void kbd_keycode(unsigned int key
 		 * which should be enough.
 		 */
 		if (keycode < 128) {
-			put_queue(vc, keycode | (!down << 7));
+			put_queue(vc, keycode | (!down_key << 7));
 		} else {
-			put_queue(vc, !down << 7);
+			put_queue(vc, !down_key << 7);
 			put_queue(vc, (keycode >> 7) | 0x80);
 			put_queue(vc, keycode | 0x80);
 		}
 		raw_mode = 1;
 	}
 
-	if (down)
+	if (down_key)
 		set_bit(keycode, key_down);
 	else
 		clear_bit(keycode, key_down);
@@ -1241,7 +1241,7 @@ static void kbd_keycode(unsigned int key
 	type = KTYP(keysym);
 
 	if (type < 0xf0) {
-		if (down && !raw_mode)
+		if (down_key && !raw_mode)
 			to_utf8(vc, keysym);
 		return;
 	}
@@ -1260,7 +1260,7 @@ static void kbd_keycode(unsigned int key
 		}
 	}
 
-	(*k_handler[type])(vc, keysym & 0xff, !down, regs);
+	(*k_handler[type])(vc, keysym & 0xff, !down_key, regs);
 
 	if (type != KT_SLOCK)
 		kbd->slockstate = 0;




^ permalink raw reply	[flat|nested] 150+ messages in thread

* [PATCH 09/12] making the kernel -Wshadow clean - neighbour.h and 'proc_handler'
  2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
                   ` (7 preceding siblings ...)
  2006-07-30 16:41 ` [PATCH 08/12] making the kernel -Wshadow clean - fix keyboard.c Jesper Juhl
@ 2006-07-30 16:42 ` Jesper Juhl
  2006-07-30 16:42 ` [PATCH 10/12] making the kernel -Wshadow clean - mm/truncate.c Jesper Juhl
                   ` (5 subsequent siblings)
  14 siblings, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 16:42 UTC (permalink / raw)
  To: linux-kernel; +Cc: Jesper Juhl, Andrew Morton

Fix several hundred -Wshadow warnings, caused by include/net/neighbour.h,
by renaming the 'proc_handler' argument in the neigh_sysctl_register() 
prototype to 'handler', just like it is named in net/core/neighbour.c


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 include/net/neighbour.h |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.18-rc2-git7-orig/include/net/neighbour.h	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.18-rc2-git7/include/net/neighbour.h	2006-07-30 06:37:28.000000000 +0200
@@ -276,7 +276,7 @@ extern int			neigh_sysctl_register(struc
 						      struct neigh_parms *p,
 						      int p_id, int pdev_id,
 						      char *p_name,
-						      proc_handler *proc_handler,
+						      proc_handler *handler,
 						      ctl_handler *strategy);
 extern void			neigh_sysctl_unregister(struct neigh_parms *p);
 



^ permalink raw reply	[flat|nested] 150+ messages in thread

* [PATCH 10/12] making the kernel -Wshadow clean - mm/truncate.c
  2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
                   ` (8 preceding siblings ...)
  2006-07-30 16:42 ` [PATCH 09/12] making the kernel -Wshadow clean - neighbour.h and 'proc_handler' Jesper Juhl
@ 2006-07-30 16:42 ` Jesper Juhl
  2006-07-30 16:43 ` [PATCH 11/12] making the kernel -Wshadow clean - USB & completion Jesper Juhl
                   ` (4 subsequent siblings)
  14 siblings, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 16:42 UTC (permalink / raw)
  To: linux-kernel; +Cc: Jesper Juhl, Andrew Morton

Fix -Wshadow warnings in mm/truncate.c


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 mm/truncate.c |   24 ++++++++++++------------
 1 files changed, 12 insertions(+), 12 deletions(-)

--- linux-2.6.18-rc2-git7-orig/mm/truncate.c	2006-07-29 14:57:27.000000000 +0200
+++ linux-2.6.18-rc2-git7/mm/truncate.c	2006-07-30 06:48:27.000000000 +0200
@@ -127,15 +127,15 @@ void truncate_inode_pages_range(struct a
 	       pagevec_lookup(&pvec, mapping, next, PAGEVEC_SIZE)) {
 		for (i = 0; i < pagevec_count(&pvec); i++) {
 			struct page *page = pvec.pages[i];
-			pgoff_t page_index = page->index;
+			pgoff_t page_idx = page->index;
 
-			if (page_index > end) {
-				next = page_index;
+			if (page_idx > end) {
+				next = page_idx;
 				break;
 			}
 
-			if (page_index > next)
-				next = page_index;
+			if (page_idx > next)
+				next = page_idx;
 			next++;
 			if (TestSetPageLocked(page))
 				continue;
@@ -298,7 +298,7 @@ int invalidate_inode_pages2_range(struct
 			min(end - next, (pgoff_t)PAGEVEC_SIZE - 1) + 1)) {
 		for (i = 0; !ret && i < pagevec_count(&pvec); i++) {
 			struct page *page = pvec.pages[i];
-			pgoff_t page_index;
+			pgoff_t page_idx;
 			int was_dirty;
 
 			lock_page(page);
@@ -306,11 +306,11 @@ int invalidate_inode_pages2_range(struct
 				unlock_page(page);
 				continue;
 			}
-			page_index = page->index;
-			next = page_index + 1;
+			page_idx = page->index;
+			next = page_idx + 1;
 			if (next == 0)
 				wrapped = 1;
-			if (page_index > end) {
+			if (page_idx > end) {
 				unlock_page(page);
 				break;
 			}
@@ -321,8 +321,8 @@ int invalidate_inode_pages2_range(struct
 					 * Zap the rest of the file in one hit.
 					 */
 					unmap_mapping_range(mapping,
-					   (loff_t)page_index<<PAGE_CACHE_SHIFT,
-					   (loff_t)(end - page_index + 1)
+					   (loff_t)page_idx<<PAGE_CACHE_SHIFT,
+					   (loff_t)(end - page_idx + 1)
 							<< PAGE_CACHE_SHIFT,
 					    0);
 					did_range_unmap = 1;
@@ -331,7 +331,7 @@ int invalidate_inode_pages2_range(struct
 					 * Just zap this page
 					 */
 					unmap_mapping_range(mapping,
-					  (loff_t)page_index<<PAGE_CACHE_SHIFT,
+					  (loff_t)page_idx<<PAGE_CACHE_SHIFT,
 					  PAGE_CACHE_SIZE, 0);
 				}
 			}




^ permalink raw reply	[flat|nested] 150+ messages in thread

* [PATCH 11/12] making the kernel -Wshadow clean - USB & completion
  2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
                   ` (9 preceding siblings ...)
  2006-07-30 16:42 ` [PATCH 10/12] making the kernel -Wshadow clean - mm/truncate.c Jesper Juhl
@ 2006-07-30 16:43 ` Jesper Juhl
  2006-07-30 16:44 ` [PATCH 12/12] making the kernel -Wshadow clean - 'irq' shadows local and global Jesper Juhl
                   ` (3 subsequent siblings)
  14 siblings, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 16:43 UTC (permalink / raw)
  To: linux-kernel; +Cc: Jesper Juhl, Andrew Morton

include/linux/usb.h causes a lot of -Wshadow warnings - fix them.

  include/linux/usb.h:901: warning: declaration of 'complete' shadows a global declaration
  include/linux/completion.h:52: warning: shadowed declaration is here
  include/linux/usb.h:932: warning: declaration of 'complete' shadows a global declaration
  include/linux/completion.h:52: warning: shadowed declaration is here
  include/linux/usb.h:967: warning: declaration of 'complete' shadows a global declaration
  include/linux/completion.h:52: warning: shadowed declaration is here


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 include/linux/usb.h |   18 +++++++++---------
 1 files changed, 9 insertions(+), 9 deletions(-)

--- linux-2.6.18-rc2-git7-orig/include/linux/usb.h	2006-07-29 14:57:26.000000000 +0200
+++ linux-2.6.18-rc2-git7/include/linux/usb.h	2006-07-30 06:55:24.000000000 +0200
@@ -886,7 +886,7 @@ struct urb
  * @setup_packet: pointer to the setup_packet buffer
  * @transfer_buffer: pointer to the transfer buffer
  * @buffer_length: length of the transfer buffer
- * @complete: pointer to the usb_complete_t function
+ * @complete_fn: pointer to the usb_complete_t function
  * @context: what to set the urb context to.
  *
  * Initializes a control urb with the proper information needed to submit
@@ -898,7 +898,7 @@ static inline void usb_fill_control_urb 
 					 unsigned char *setup_packet,
 					 void *transfer_buffer,
 					 int buffer_length,
-					 usb_complete_t complete,
+					 usb_complete_t complete_fn,
 					 void *context)
 {
 	spin_lock_init(&urb->lock);
@@ -907,7 +907,7 @@ static inline void usb_fill_control_urb 
 	urb->setup_packet = setup_packet;
 	urb->transfer_buffer = transfer_buffer;
 	urb->transfer_buffer_length = buffer_length;
-	urb->complete = complete;
+	urb->complete = complete_fn;
 	urb->context = context;
 }
 
@@ -918,7 +918,7 @@ static inline void usb_fill_control_urb 
  * @pipe: the endpoint pipe
  * @transfer_buffer: pointer to the transfer buffer
  * @buffer_length: length of the transfer buffer
- * @complete: pointer to the usb_complete_t function
+ * @complete_fn: pointer to the usb_complete_t function
  * @context: what to set the urb context to.
  *
  * Initializes a bulk urb with the proper information needed to submit it
@@ -929,7 +929,7 @@ static inline void usb_fill_bulk_urb (st
 				      unsigned int pipe,
 				      void *transfer_buffer,
 				      int buffer_length,
-				      usb_complete_t complete,
+				      usb_complete_t complete_fn,
 				      void *context)
 {
 	spin_lock_init(&urb->lock);
@@ -937,7 +937,7 @@ static inline void usb_fill_bulk_urb (st
 	urb->pipe = pipe;
 	urb->transfer_buffer = transfer_buffer;
 	urb->transfer_buffer_length = buffer_length;
-	urb->complete = complete;
+	urb->complete = complete_fn;
 	urb->context = context;
 }
 
@@ -948,7 +948,7 @@ static inline void usb_fill_bulk_urb (st
  * @pipe: the endpoint pipe
  * @transfer_buffer: pointer to the transfer buffer
  * @buffer_length: length of the transfer buffer
- * @complete: pointer to the usb_complete_t function
+ * @complete_fn: pointer to the usb_complete_t function
  * @context: what to set the urb context to.
  * @interval: what to set the urb interval to, encoded like
  *	the endpoint descriptor's bInterval value.
@@ -964,7 +964,7 @@ static inline void usb_fill_int_urb (str
 				     unsigned int pipe,
 				     void *transfer_buffer,
 				     int buffer_length,
-				     usb_complete_t complete,
+				     usb_complete_t complete_fn,
 				     void *context,
 				     int interval)
 {
@@ -973,7 +973,7 @@ static inline void usb_fill_int_urb (str
 	urb->pipe = pipe;
 	urb->transfer_buffer = transfer_buffer;
 	urb->transfer_buffer_length = buffer_length;
-	urb->complete = complete;
+	urb->complete = complete_fn;
 	urb->context = context;
 	if (dev->speed == USB_SPEED_HIGH)
 		urb->interval = 1 << (interval - 1);



^ permalink raw reply	[flat|nested] 150+ messages in thread

* [PATCH 12/12] making the kernel -Wshadow clean - 'irq' shadows local and global
  2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
                   ` (10 preceding siblings ...)
  2006-07-30 16:43 ` [PATCH 11/12] making the kernel -Wshadow clean - USB & completion Jesper Juhl
@ 2006-07-30 16:44 ` Jesper Juhl
  2006-07-30 16:54 ` [PATCH 00/12] making the kernel -Wshadow clean - The initial step Krzysztof Halasa
                   ` (2 subsequent siblings)
  14 siblings, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 16:44 UTC (permalink / raw)
  To: linux-kernel; +Cc: Jesper Juhl, Andrew Morton

Get rid of various -Wshadow warnings related to 'irq' shadowing a local or
global.


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 arch/i386/kernel/acpi/boot.c        |    2
 drivers/cdrom/mcdx.c                |    7 -
 drivers/char/cyclades.c             |   18 +--
 drivers/char/esp.c                  |    4
 drivers/char/synclink.c             |   10 +-
 drivers/char/watchdog/eurotechwdt.c |    2
 drivers/char/watchdog/wdt.c         |    2
 drivers/char/watchdog/wdt_pci.c     |    2
 drivers/isdn/pcbit/drv.c            |   10 +-
 drivers/isdn/pcbit/module.c         |    2
 drivers/mmc/wbsd.c                  |   32 +++---
 drivers/net/seeq8005.c              |    2
 include/linux/interrupt.h           |   28 ++---
 include/linux/irq.h                 |  128 +++++++++++++-------------
 include/linux/random.h              |    4
 sound/isa/gus/interwave.c           |    3
 16 files changed, 129 insertions(+), 127 deletions(-)

--- linux-2.6.18-rc2-git7-orig/arch/i386/kernel/acpi/boot.c	2006-07-29 14:56:45.000000000 +0200
+++ linux-2.6.18-rc2-git7/arch/i386/kernel/acpi/boot.c	2006-07-30 07:34:25.000000000 +0200
@@ -482,7 +482,7 @@ int acpi_register_gsi(u32 gsi, int trigg
 	 * Make sure all (legacy) PCI IRQs are set as level-triggered.
 	 */
 	if (acpi_irq_model == ACPI_IRQ_MODEL_PIC) {
-		extern void eisa_set_level_irq(unsigned int irq);
+		extern void eisa_set_level_irq(unsigned int);
 
 		if (triggering == ACPI_LEVEL_SENSITIVE)
 			eisa_set_level_irq(gsi);
--- linux-2.6.18-rc2-git7-orig/drivers/cdrom/mcdx.c	2006-07-29 14:56:54.000000000 +0200
+++ linux-2.6.18-rc2-git7/drivers/cdrom/mcdx.c	2006-07-30 07:39:35.000000000 +0200
@@ -265,7 +265,7 @@ static unsigned int msf2log(const struct
 static unsigned int uint2bcd(unsigned int);
 static unsigned int bcd2uint(unsigned char);
 static unsigned port(int *);
-static int irq(int *);
+static int get_irq(int *);
 static void mcdx_delay(struct s_drive_stuff *, long jifs);
 static int mcdx_transfer(struct s_drive_stuff *, char *buf, int sector,
 			 int nr_sectors);
@@ -1104,7 +1104,7 @@ static int __init mcdx_init_drive(int dr
 	stuffp->toc = NULL;	/* this should be NULL already */
 
 	/* setup our irq and i/o addresses */
-	stuffp->irq = irq(mcdx_drive_map[drive]);
+	stuffp->irq = get_irq(mcdx_drive_map[drive]);
 	stuffp->wreg_data = stuffp->rreg_data = port(mcdx_drive_map[drive]);
 	stuffp->wreg_reset = stuffp->rreg_status = stuffp->wreg_data + 1;
 	stuffp->wreg_hcon = stuffp->wreg_reset + 1;
@@ -1492,7 +1492,8 @@ static unsigned port(int *ip)
 {
 	return ip[0];
 }
-static int irq(int *ip)
+
+static int get_irq(int *ip)
 {
 	return ip[1];
 }
--- linux-2.6.18-rc2-git7-orig/drivers/char/cyclades.c	2006-07-29 14:56:54.000000000 +0200
+++ linux-2.6.18-rc2-git7/drivers/char/cyclades.c	2006-07-30 07:46:07.000000000 +0200
@@ -1017,13 +1017,13 @@ cyy_issue_cmd(void __iomem *base_addr, u
 static unsigned 
 detect_isa_irq(void __iomem *address)
 {
-  int irq;
+  int intr;
   unsigned long irqs, flags;
   int save_xir, save_car;
   int index = 0; /* IRQ probing is only for ISA */
 
     /* forget possible initially masked and pending IRQ */
-    irq = probe_irq_off(probe_irq_on());
+    intr = probe_irq_off(probe_irq_on());
 
     /* Clear interrupts on the board first */
     cy_writeb(address + (Cy_ClrIntr<<index), 0);
@@ -1047,7 +1047,7 @@ detect_isa_irq(void __iomem *address)
     udelay(5000L);
 
     /* Check which interrupt is in use */
-    irq = probe_irq_off(irqs);
+    intr = probe_irq_off(irqs);
 
     /* Clean up */
     save_xir = (u_char) cy_readb(address + (CyTIR<<index));
@@ -1060,7 +1060,7 @@ detect_isa_irq(void __iomem *address)
     cy_writeb(address + (Cy_ClrIntr<<index), 0);
 			      /* Cy_ClrIntr is 0x1800 */
 
-    return (irq > 0)? irq : 0;
+    return (intr > 0) ? intr : 0;
 }
 #endif /* CONFIG_ISA */
 
@@ -1069,7 +1069,7 @@ detect_isa_irq(void __iomem *address)
    received, out buffer empty, modem change, etc.
  */
 static irqreturn_t
-cyy_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+cyy_interrupt(int intr, void *dev_id, struct pt_regs *regs)
 {
   struct tty_struct *tty;
   int status;
@@ -1089,7 +1089,7 @@ cyy_interrupt(int irq, void *dev_id, str
   int len;
     if((cinfo = (struct cyclades_card *)dev_id) == 0){
 #ifdef CY_DEBUG_INTERRUPTS
-	printk("cyy_interrupt: spurious interrupt %d\n\r", irq);
+	printk("cyy_interrupt: spurious interrupt %d\n\r", intr);
 #endif
         return IRQ_NONE; /* spurious interrupt */
     }
@@ -1814,20 +1814,20 @@ cyz_handle_cmd(struct cyclades_card *cin
 
 #ifdef CONFIG_CYZ_INTR
 static irqreturn_t
-cyz_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+cyz_interrupt(int intr, void *dev_id, struct pt_regs *regs)
 {
   struct cyclades_card *cinfo;
 
     if((cinfo = (struct cyclades_card *)dev_id) == 0){
 #ifdef CY_DEBUG_INTERRUPTS
-	printk("cyz_interrupt: spurious interrupt %d\n\r", irq);
+	printk("cyz_interrupt: spurious interrupt %d\n\r", intr);
 #endif
         return IRQ_NONE; /* spurious interrupt */
     }
 
     if (!ISZLOADED(*cinfo)) {
 #ifdef CY_DEBUG_INTERRUPTS
-	printk("cyz_interrupt: board not yet loaded (IRQ%d).\n\r", irq);
+	printk("cyz_interrupt: board not yet loaded (IRQ%d).\n\r", intr);
 #endif
 	return IRQ_NONE;
     }
--- linux-2.6.18-rc2-git7-orig/drivers/char/esp.c	2006-07-29 14:56:54.000000000 +0200
+++ linux-2.6.18-rc2-git7/drivers/char/esp.c	2006-07-30 07:48:01.000000000 +0200
@@ -615,7 +615,7 @@ static inline void check_modem_status(st
 /*
  * This is the serial driver's interrupt routine
  */
-static irqreturn_t rs_interrupt_single(int irq, void *dev_id,
+static irqreturn_t rs_interrupt_single(int intr, void *dev_id,
 					struct pt_regs *regs)
 {
 	struct esp_struct * info;
@@ -623,7 +623,7 @@ static irqreturn_t rs_interrupt_single(i
 	unsigned int scratch;
 
 #ifdef SERIAL_DEBUG_INTR
-	printk("rs_interrupt_single(%d)...", irq);
+	printk("rs_interrupt_single(%d)...", intr);
 #endif
 	info = (struct esp_struct *)dev_id;
 	err_status = 0;
--- linux-2.6.18-rc2-git7-orig/drivers/char/synclink.c	2006-07-29 14:58:35.000000000 +0200
+++ linux-2.6.18-rc2-git7/drivers/char/synclink.c	2006-07-30 07:51:20.000000000 +0200
@@ -1698,13 +1698,13 @@ static void mgsl_isr_transmit_dma( struc
  * 	
  * Arguments:
  * 
- * 	irq		interrupt number that caused interrupt
+ * 	intr		interrupt number that caused interrupt
  * 	dev_id		device ID supplied during interrupt registration
  * 	regs		interrupted processor context
  * 	
  * Return Value: None
  */
-static irqreturn_t mgsl_interrupt(int irq, void *dev_id, struct pt_regs * regs)
+static irqreturn_t mgsl_interrupt(int intr, void *dev_id, struct pt_regs *regs)
 {
 	struct mgsl_struct * info;
 	u16 UscVector;
@@ -1712,7 +1712,7 @@ static irqreturn_t mgsl_interrupt(int ir
 
 	if ( debug_level >= DEBUG_LEVEL_ISR )	
 		printk("%s(%d):mgsl_interrupt(%d)entry.\n",
-			__FILE__,__LINE__,irq);
+			__FILE__,__LINE__,intr);
 
 	info = (struct mgsl_struct *)dev_id;	
 	if (!info)
@@ -1742,7 +1742,7 @@ static irqreturn_t mgsl_interrupt(int ir
 
 		if ( info->isr_overflow ) {
 			printk(KERN_ERR"%s(%d):%s isr overflow irq=%d\n",
-				__FILE__,__LINE__,info->device_name, irq);
+				__FILE__,__LINE__,info->device_name, intr);
 			usc_DisableMasterIrqBit(info);
 			usc_DisableDmaInterrupts(info,DICR_MASTER);
 			break;
@@ -1765,7 +1765,7 @@ static irqreturn_t mgsl_interrupt(int ir
 	
 	if ( debug_level >= DEBUG_LEVEL_ISR )	
 		printk("%s(%d):mgsl_interrupt(%d)exit.\n",
-			__FILE__,__LINE__,irq);
+			__FILE__,__LINE__,intr);
 	return IRQ_HANDLED;
 }	/* end of mgsl_interrupt() */
 
--- linux-2.6.18-rc2-git7-orig/drivers/char/watchdog/eurotechwdt.c	2006-07-29 14:56:54.000000000 +0200
+++ linux-2.6.18-rc2-git7/drivers/char/watchdog/eurotechwdt.c	2006-07-30 07:52:22.000000000 +0200
@@ -153,7 +153,7 @@ static void eurwdt_activate_timer(void)
  * Kernel methods.
  */
 
-static irqreturn_t eurwdt_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+static irqreturn_t eurwdt_interrupt(int intr, void *dev_id, struct pt_regs *regs)
 {
 	printk(KERN_CRIT "timeout WDT timeout\n");
 
--- linux-2.6.18-rc2-git7-orig/drivers/char/watchdog/wdt.c	2006-07-29 14:56:54.000000000 +0200
+++ linux-2.6.18-rc2-git7/drivers/char/watchdog/wdt.c	2006-07-30 07:53:26.000000000 +0200
@@ -232,7 +232,7 @@ static int wdt_get_temperature(int *temp
  *	a failure condition occurring.
  */
 
-static irqreturn_t wdt_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+static irqreturn_t wdt_interrupt(int intr, void *dev_id, struct pt_regs *regs)
 {
 	/*
 	 *	Read the status register see what is up and
--- linux-2.6.18-rc2-git7-orig/drivers/char/watchdog/wdt_pci.c	2006-07-29 14:56:54.000000000 +0200
+++ linux-2.6.18-rc2-git7/drivers/char/watchdog/wdt_pci.c	2006-07-30 07:54:03.000000000 +0200
@@ -277,7 +277,7 @@ static int wdtpci_get_temperature(int *t
  *	a failure condition occurring.
  */
 
-static irqreturn_t wdtpci_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+static irqreturn_t wdtpci_interrupt(int intr, void *dev_id, struct pt_regs *regs)
 {
 	/*
 	 *	Read the status register see what is up and
--- linux-2.6.18-rc2-git7-orig/drivers/isdn/pcbit/module.c	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.18-rc2-git7/drivers/isdn/pcbit/module.c	2006-07-30 07:56:14.000000000 +0200
@@ -33,7 +33,7 @@ static int num_boards;
 struct pcbit_dev * dev_pcbit[MAX_PCBIT_CARDS];
 
 extern void pcbit_terminate(int board);
-extern int pcbit_init_dev(int board, int mem_base, int irq);
+extern int pcbit_init_dev(int board, int mem_base, int intr);
 
 static int __init pcbit_init(void)
 {
--- linux-2.6.18-rc2-git7-orig/drivers/isdn/pcbit/drv.c	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.18-rc2-git7/drivers/isdn/pcbit/drv.c	2006-07-30 07:57:59.000000000 +0200
@@ -70,7 +70,7 @@ static int pcbit_check_msn(struct pcbit_
 
 extern void pcbit_deliver(void * data);
 
-int pcbit_init_dev(int board, int mem_base, int irq)
+int pcbit_init_dev(int board, int mem_base, int intr)
 {
 	struct pcbit_dev *dev;
 	isdn_if *dev_if;
@@ -135,7 +135,7 @@ int pcbit_init_dev(int board, int mem_ba
 	 *  interrupts
 	 */
 
-	if (request_irq(irq, &pcbit_irq_handler, 0, pcbit_devname[board], dev) != 0) 
+	if (request_irq(intr, &pcbit_irq_handler, 0, pcbit_devname[board], dev) != 0) 
 	{
 		kfree(dev->b1);
 		kfree(dev->b2);
@@ -146,7 +146,7 @@ int pcbit_init_dev(int board, int mem_ba
 		return -EIO;
 	}
 
-	dev->irq = irq;
+	dev->irq = intr;
 
 	/* next frame to be received */
 	dev->rcv_seq = 0;
@@ -158,7 +158,7 @@ int pcbit_init_dev(int board, int mem_ba
 	dev_if = kmalloc(sizeof(isdn_if), GFP_KERNEL);
 
 	if (!dev_if) {
-		free_irq(irq, dev);
+		free_irq(intr, dev);
 		kfree(dev->b1);
 		kfree(dev->b2);
 		iounmap(dev->sh_mem);
@@ -190,7 +190,7 @@ int pcbit_init_dev(int board, int mem_ba
 	strcpy(dev_if->id, pcbit_devname[board]);
 
 	if (!register_isdn(dev_if)) {
-		free_irq(irq, dev);
+		free_irq(intr, dev);
 		kfree(dev->b1);
 		kfree(dev->b2);
 		iounmap(dev->sh_mem);
--- linux-2.6.18-rc2-git7-orig/drivers/mmc/wbsd.c	2006-07-29 14:57:01.000000000 +0200
+++ linux-2.6.18-rc2-git7/drivers/mmc/wbsd.c	2006-07-30 08:30:27.000000000 +0200
@@ -1255,7 +1255,7 @@ end:
  * Interrupt handling
  */
 
-static irqreturn_t wbsd_irq(int irq, void *dev_id, struct pt_regs *regs)
+static irqreturn_t wbsd_irq(int intr, void *dev_id, struct pt_regs *regs)
 {
 	struct wbsd_host *host = dev_id;
 	int isr;
@@ -1545,7 +1545,7 @@ static void __devexit wbsd_release_dma(s
  * Allocate/free IRQ.
  */
 
-static int __devinit wbsd_request_irq(struct wbsd_host *host, int irq)
+static int __devinit wbsd_request_irq(struct wbsd_host *host, int intr)
 {
 	int ret;
 
@@ -1553,11 +1553,11 @@ static int __devinit wbsd_request_irq(st
 	 * Allocate interrupt.
 	 */
 
-	ret = request_irq(irq, wbsd_irq, IRQF_SHARED, DRIVER_NAME, host);
+	ret = request_irq(intr, wbsd_irq, IRQF_SHARED, DRIVER_NAME, host);
 	if (ret)
 		return ret;
 
-	host->irq = irq;
+	host->irq = intr;
 
 	/*
 	 * Set up tasklets.
@@ -1600,7 +1600,7 @@ static void __devexit wbsd_release_irq(s
  */
 
 static int __devinit wbsd_request_resources(struct wbsd_host *host,
-	int base, int irq, int dma)
+	int base, int intr, int dma)
 {
 	int ret;
 
@@ -1614,7 +1614,7 @@ static int __devinit wbsd_request_resour
 	/*
 	 * Allocate interrupt.
 	 */
-	ret = wbsd_request_irq(host, irq);
+	ret = wbsd_request_irq(host, intr);
 	if (ret)
 		return ret;
 
@@ -1687,7 +1687,7 @@ static void wbsd_chip_config(struct wbsd
 
 static int wbsd_chip_validate(struct wbsd_host *host)
 {
-	int base, irq, dma;
+	int base, intr, dma;
 
 	wbsd_unlock_config(host);
 
@@ -1702,7 +1702,7 @@ static int wbsd_chip_validate(struct wbs
 	base = wbsd_read_config(host, WBSD_CONF_PORT_HI) << 8;
 	base |= wbsd_read_config(host, WBSD_CONF_PORT_LO);
 
-	irq = wbsd_read_config(host, WBSD_CONF_IRQ);
+	intr = wbsd_read_config(host, WBSD_CONF_IRQ);
 
 	dma = wbsd_read_config(host, WBSD_CONF_DRQ);
 
@@ -1713,7 +1713,7 @@ static int wbsd_chip_validate(struct wbs
 	 */
 	if (base != host->base)
 		return 0;
-	if (irq != host->irq)
+	if (intr != host->irq)
 		return 0;
 	if ((dma != host->dma) && (host->dma != -1))
 		return 0;
@@ -1741,8 +1741,8 @@ static void wbsd_chip_poweroff(struct wb
  *                                                                           *
 \*****************************************************************************/
 
-static int __devinit wbsd_init(struct device *dev, int base, int irq, int dma,
-	int pnp)
+static int __devinit wbsd_init(struct device *dev, int base, int intr,
+	int dma, int pnp)
 {
 	struct wbsd_host *host = NULL;
 	struct mmc_host *mmc = NULL;
@@ -1773,7 +1773,7 @@ static int __devinit wbsd_init(struct de
 	/*
 	 * Request resources.
 	 */
-	ret = wbsd_request_resources(host, io, irq, dma);
+	ret = wbsd_request_resources(host, io, intr, dma);
 	if (ret) {
 		wbsd_release_resources(host);
 		wbsd_free_mmc(dev);
@@ -1880,21 +1880,21 @@ static int __devexit wbsd_remove(struct 
 static int __devinit
 wbsd_pnp_probe(struct pnp_dev *pnpdev, const struct pnp_device_id *dev_id)
 {
-	int io, irq, dma;
+	int io, intr, dma;
 
 	/*
 	 * Get resources from PnP layer.
 	 */
 	io = pnp_port_start(pnpdev, 0);
-	irq = pnp_irq(pnpdev, 0);
+	intr = pnp_irq(pnpdev, 0);
 	if (pnp_dma_valid(pnpdev, 0))
 		dma = pnp_dma(pnpdev, 0);
 	else
 		dma = -1;
 
-	DBGF("PnP resources: port %3x irq %d dma %d\n", io, irq, dma);
+	DBGF("PnP resources: port %3x irq %d dma %d\n", io, intr, dma);
 
-	return wbsd_init(&pnpdev->dev, io, irq, dma, 1);
+	return wbsd_init(&pnpdev->dev, io, intr, dma, 1);
 }
 
 static void __devexit wbsd_pnp_remove(struct pnp_dev *dev)
--- linux-2.6.18-rc2-git7-orig/drivers/net/seeq8005.c	2006-07-29 14:57:02.000000000 +0200
+++ linux-2.6.18-rc2-git7/drivers/net/seeq8005.c	2006-07-30 08:32:05.000000000 +0200
@@ -437,7 +437,7 @@ inline void wait_for_buffer(struct net_d
  
 /* The typical workload of the driver:
    Handle the network interface interrupts. */
-static irqreturn_t seeq8005_interrupt(int irq, void *dev_id, struct pt_regs * regs)
+static irqreturn_t seeq8005_interrupt(int intr, void *dev_id, struct pt_regs *regs)
 {
 	struct net_device *dev = dev_id;
 	struct net_local *lp;
--- linux-2.6.18-rc2-git7-orig/include/linux/interrupt.h	2006-07-29 14:57:26.000000000 +0200
+++ linux-2.6.18-rc2-git7/include/linux/interrupt.h	2006-07-30 09:11:39.000000000 +0200
@@ -100,9 +100,9 @@ extern void free_irq(unsigned int, void 
 #endif
 
 #ifdef CONFIG_GENERIC_HARDIRQS
-extern void disable_irq_nosync(unsigned int irq);
-extern void disable_irq(unsigned int irq);
-extern void enable_irq(unsigned int irq);
+extern void disable_irq_nosync(unsigned int i);
+extern void disable_irq(unsigned int i);
+extern void enable_irq(unsigned int i);
 
 /*
  * Special lockdep variants of irq disabling/enabling.
@@ -115,41 +115,41 @@ extern void enable_irq(unsigned int irq)
  * On !CONFIG_LOCKDEP they are equivalent to the normal
  * irq disable/enable methods.
  */
-static inline void disable_irq_nosync_lockdep(unsigned int irq)
+static inline void disable_irq_nosync_lockdep(unsigned int i)
 {
-	disable_irq_nosync(irq);
+	disable_irq_nosync(i);
 #ifdef CONFIG_LOCKDEP
 	local_irq_disable();
 #endif
 }
 
-static inline void disable_irq_lockdep(unsigned int irq)
+static inline void disable_irq_lockdep(unsigned int i)
 {
-	disable_irq(irq);
+	disable_irq(i);
 #ifdef CONFIG_LOCKDEP
 	local_irq_disable();
 #endif
 }
 
-static inline void enable_irq_lockdep(unsigned int irq)
+static inline void enable_irq_lockdep(unsigned int i)
 {
 #ifdef CONFIG_LOCKDEP
 	local_irq_enable();
 #endif
-	enable_irq(irq);
+	enable_irq(i);
 }
 
 /* IRQ wakeup (PM) control: */
-extern int set_irq_wake(unsigned int irq, unsigned int on);
+extern int set_irq_wake(unsigned int i, unsigned int on);
 
-static inline int enable_irq_wake(unsigned int irq)
+static inline int enable_irq_wake(unsigned int i)
 {
-	return set_irq_wake(irq, 1);
+	return set_irq_wake(i, 1);
 }
 
-static inline int disable_irq_wake(unsigned int irq)
+static inline int disable_irq_wake(unsigned int i)
 {
-	return set_irq_wake(irq, 0);
+	return set_irq_wake(i, 0);
 }
 
 #else /* !CONFIG_GENERIC_HARDIRQS */
--- linux-2.6.18-rc2-git7-orig/include/linux/irq.h	2006-07-29 14:57:26.000000000 +0200
+++ linux-2.6.18-rc2-git7/include/linux/irq.h	2006-07-30 08:47:53.000000000 +0200
@@ -85,26 +85,26 @@ struct proc_dir_entry;
  */
 struct irq_chip {
 	const char	*name;
-	unsigned int	(*startup)(unsigned int irq);
-	void		(*shutdown)(unsigned int irq);
-	void		(*enable)(unsigned int irq);
-	void		(*disable)(unsigned int irq);
-
-	void		(*ack)(unsigned int irq);
-	void		(*mask)(unsigned int irq);
-	void		(*mask_ack)(unsigned int irq);
-	void		(*unmask)(unsigned int irq);
-	void		(*eoi)(unsigned int irq);
-
-	void		(*end)(unsigned int irq);
-	void		(*set_affinity)(unsigned int irq, cpumask_t dest);
-	int		(*retrigger)(unsigned int irq);
-	int		(*set_type)(unsigned int irq, unsigned int flow_type);
-	int		(*set_wake)(unsigned int irq, unsigned int on);
+	unsigned int	(*startup)(unsigned int intr);
+	void		(*shutdown)(unsigned int intr);
+	void		(*enable)(unsigned int intr);
+	void		(*disable)(unsigned int intr);
+
+	void		(*ack)(unsigned int intr);
+	void		(*mask)(unsigned int intr);
+	void		(*mask_ack)(unsigned int intr);
+	void		(*unmask)(unsigned int intr);
+	void		(*eoi)(unsigned int intr);
+
+	void		(*end)(unsigned int intr);
+	void		(*set_affinity)(unsigned int intr, cpumask_t dest);
+	int		(*retrigger)(unsigned int intr);
+	int		(*set_type)(unsigned int intr, unsigned int flow_type);
+	int		(*set_wake)(unsigned int intr, unsigned int on);
 
 	/* Currently used only by UML, might disappear one day.*/
 #ifdef CONFIG_IRQ_RELEASE_METHOD
-	void		(*release)(unsigned int irq, void *dev_id);
+	void		(*release)(unsigned int intr, void *dev_id);
 #endif
 	/*
 	 * For compatibility, ->typename is copied into ->name.
@@ -137,7 +137,7 @@ struct irq_chip {
  * Pad this out to 32 bytes for cache and indexing reasons.
  */
 struct irq_desc {
-	void fastcall		(*handle_irq)(unsigned int irq,
+	void fastcall		(*handle_irq)(unsigned int intr,
 					      struct irq_desc *desc,
 					      struct pt_regs *regs);
 	struct irq_chip		*chip;
@@ -178,7 +178,7 @@ typedef struct irq_desc		irq_desc_t;
  */
 #include <asm/hw_irq.h>
 
-extern int setup_irq(unsigned int irq, struct irqaction *new);
+extern int setup_irq(unsigned int intr, struct irqaction *new);
 
 #ifdef CONFIG_GENERIC_HARDIRQS
 
@@ -187,12 +187,12 @@ extern int setup_irq(unsigned int irq, s
 #endif
 
 #ifdef CONFIG_SMP
-static inline void set_native_irq_info(int irq, cpumask_t mask)
+static inline void set_native_irq_info(int intr, cpumask_t mask)
 {
-	irq_desc[irq].affinity = mask;
+	irq_desc[intr].affinity = mask;
 }
 #else
-static inline void set_native_irq_info(int irq, cpumask_t mask)
+static inline void set_native_irq_info(int intr, cpumask_t mask)
 {
 }
 #endif
@@ -201,8 +201,8 @@ static inline void set_native_irq_info(i
 
 #if defined(CONFIG_GENERIC_PENDING_IRQ) || defined(CONFIG_IRQBALANCE)
 
-void set_pending_irq(unsigned int irq, cpumask_t mask);
-void move_native_irq(int irq);
+void set_pending_irq(unsigned int intr, cpumask_t mask);
+void move_native_irq(int intr);
 
 #ifdef CONFIG_PCI_MSI
 /*
@@ -212,45 +212,45 @@ void move_native_irq(int irq);
  * this operation on the real irq, when we dont use vector, i.e when
  * pci_use_vector() is false.
  */
-static inline void move_irq(int irq)
+static inline void move_irq(int intr)
 {
 }
 
-static inline void set_irq_info(int irq, cpumask_t mask)
+static inline void set_irq_info(int intr, cpumask_t mask)
 {
 }
 
 #else /* CONFIG_PCI_MSI */
 
-static inline void move_irq(int irq)
+static inline void move_irq(int intr)
 {
-	move_native_irq(irq);
+	move_native_irq(intr);
 }
 
-static inline void set_irq_info(int irq, cpumask_t mask)
+static inline void set_irq_info(int intr, cpumask_t mask)
 {
-	set_native_irq_info(irq, mask);
+	set_native_irq_info(intr, mask);
 }
 
 #endif /* CONFIG_PCI_MSI */
 
 #else /* CONFIG_GENERIC_PENDING_IRQ || CONFIG_IRQBALANCE */
 
-static inline void move_irq(int irq)
+static inline void move_irq(int intr)
 {
 }
 
-static inline void move_native_irq(int irq)
+static inline void move_native_irq(int intr)
 {
 }
 
-static inline void set_pending_irq(unsigned int irq, cpumask_t mask)
+static inline void set_pending_irq(unsigned int intr, cpumask_t mask)
 {
 }
 
-static inline void set_irq_info(int irq, cpumask_t mask)
+static inline void set_irq_info(int intr, cpumask_t mask)
 {
-	set_native_irq_info(irq, mask);
+	set_native_irq_info(intr, mask);
 }
 
 #endif /* CONFIG_GENERIC_PENDING_IRQ */
@@ -263,17 +263,17 @@ static inline void set_irq_info(int irq,
 #endif /* CONFIG_SMP */
 
 #ifdef CONFIG_IRQBALANCE
-extern void set_balance_irq_affinity(unsigned int irq, cpumask_t mask);
+extern void set_balance_irq_affinity(unsigned int intr, cpumask_t mask);
 #else
-static inline void set_balance_irq_affinity(unsigned int irq, cpumask_t mask)
+static inline void set_balance_irq_affinity(unsigned int intr, cpumask_t mask)
 {
 }
 #endif
 
 #ifdef CONFIG_AUTO_IRQ_AFFINITY
-extern int select_smp_affinity(unsigned int irq);
+extern int select_smp_affinity(unsigned int intr);
 #else
-static inline int select_smp_affinity(unsigned int irq)
+static inline int select_smp_affinity(unsigned int intr)
 {
 	return 1;
 }
@@ -282,7 +282,7 @@ static inline int select_smp_affinity(un
 extern int no_irq_affinity;
 
 /* Handle irq action chains: */
-extern int handle_IRQ_event(unsigned int irq, struct pt_regs *regs,
+extern int handle_IRQ_event(unsigned int intr, struct pt_regs *regs,
 			    struct irqaction *action);
 
 /*
@@ -290,20 +290,20 @@ extern int handle_IRQ_event(unsigned int
  * callable via desc->chip->handle_irq()
  */
 extern void fastcall
-handle_level_irq(unsigned int irq, struct irq_desc *desc, struct pt_regs *regs);
+handle_level_irq(unsigned int intr, struct irq_desc *desc, struct pt_regs *regs);
 extern void fastcall
-handle_fasteoi_irq(unsigned int irq, struct irq_desc *desc,
+handle_fasteoi_irq(unsigned int intr, struct irq_desc *desc,
 			 struct pt_regs *regs);
 extern void fastcall
-handle_edge_irq(unsigned int irq, struct irq_desc *desc, struct pt_regs *regs);
+handle_edge_irq(unsigned int intr, struct irq_desc *desc, struct pt_regs *regs);
 extern void fastcall
-handle_simple_irq(unsigned int irq, struct irq_desc *desc,
+handle_simple_irq(unsigned int intr, struct irq_desc *desc,
 		  struct pt_regs *regs);
 extern void fastcall
-handle_percpu_irq(unsigned int irq, struct irq_desc *desc,
+handle_percpu_irq(unsigned int intr, struct irq_desc *desc,
 		  struct pt_regs *regs);
 extern void fastcall
-handle_bad_irq(unsigned int irq, struct irq_desc *desc, struct pt_regs *regs);
+handle_bad_irq(unsigned int intr, struct irq_desc *desc, struct pt_regs *regs);
 
 /*
  * Get a descriptive string for the highlevel handler, for
@@ -317,7 +317,7 @@ handle_irq_name(void fastcall (*handle)(
  * Monolithic do_IRQ implementation.
  * (is an explicit fastcall, because i386 4KSTACKS calls it from assembly)
  */
-extern fastcall unsigned int __do_IRQ(unsigned int irq, struct pt_regs *regs);
+extern fastcall unsigned int __do_IRQ(unsigned int intr, struct pt_regs *regs);
 
 /*
  * Architectures call this to let the generic IRQ layer
@@ -325,22 +325,22 @@ extern fastcall unsigned int __do_IRQ(un
  * irqchip-style controller then we call the ->handle_irq() handler,
  * and it calls __do_IRQ() if it's attached to an irqtype-style controller.
  */
-static inline void generic_handle_irq(unsigned int irq, struct pt_regs *regs)
+static inline void generic_handle_irq(unsigned int intr, struct pt_regs *regs)
 {
-	struct irq_desc *desc = irq_desc + irq;
+	struct irq_desc *desc = irq_desc + intr;
 
 	if (likely(desc->handle_irq))
-		desc->handle_irq(irq, desc, regs);
+		desc->handle_irq(intr, desc, regs);
 	else
-		__do_IRQ(irq, regs);
+		__do_IRQ(intr, regs);
 }
 
 /* Handling of unhandled and spurious interrupts: */
-extern void note_interrupt(unsigned int irq, struct irq_desc *desc,
+extern void note_interrupt(unsigned int intr, struct irq_desc *desc,
 			   int action_ret, struct pt_regs *regs);
 
 /* Resending of interrupts :*/
-void check_irq_resend(struct irq_desc *desc, unsigned int irq);
+void check_irq_resend(struct irq_desc *desc, unsigned int intr);
 
 /* Initialize /proc/irq/ */
 extern void init_irq_proc(void);
@@ -349,19 +349,19 @@ extern void init_irq_proc(void);
 extern int noirqdebug_setup(char *str);
 
 /* Checks whether the interrupt can be requested by request_irq(): */
-extern int can_request_irq(unsigned int irq, unsigned long irqflags);
+extern int can_request_irq(unsigned int intr, unsigned long irqflags);
 
 /* Dummy irq-chip implementations: */
 extern struct irq_chip no_irq_chip;
 extern struct irq_chip dummy_irq_chip;
 
 extern void
-set_irq_chip_and_handler(unsigned int irq, struct irq_chip *chip,
+set_irq_chip_and_handler(unsigned int intr, struct irq_chip *chip,
 			 void fastcall (*handle)(unsigned int,
 						 struct irq_desc *,
 						 struct pt_regs *));
 extern void
-__set_irq_handler(unsigned int irq,
+__set_irq_handler(unsigned int intr,
 		  void fastcall (*handle)(unsigned int, struct irq_desc *,
 					  struct pt_regs *),
 		  int is_chained);
@@ -370,11 +370,11 @@ __set_irq_handler(unsigned int irq,
  * Set a highlevel flow handler for a given IRQ:
  */
 static inline void
-set_irq_handler(unsigned int irq,
+set_irq_handler(unsigned int intr,
 		void fastcall (*handle)(unsigned int, struct irq_desc *,
 					struct pt_regs *))
 {
-	__set_irq_handler(irq, handle, 0);
+	__set_irq_handler(intr, handle, 0);
 }
 
 /*
@@ -383,19 +383,19 @@ set_irq_handler(unsigned int irq,
  *  IRQ_NOREQUEST and IRQ_NOPROBE)
  */
 static inline void
-set_irq_chained_handler(unsigned int irq,
+set_irq_chained_handler(unsigned int intr,
 			void fastcall (*handle)(unsigned int, struct irq_desc *,
 						struct pt_regs *))
 {
-	__set_irq_handler(irq, handle, 1);
+	__set_irq_handler(intr, handle, 1);
 }
 
 /* Set/get chip/data for an IRQ: */
 
-extern int set_irq_chip(unsigned int irq, struct irq_chip *chip);
-extern int set_irq_data(unsigned int irq, void *data);
-extern int set_irq_chip_data(unsigned int irq, void *data);
-extern int set_irq_type(unsigned int irq, unsigned int type);
+extern int set_irq_chip(unsigned int intr, struct irq_chip *chip);
+extern int set_irq_data(unsigned int intr, void *data);
+extern int set_irq_chip_data(unsigned int intr, void *data);
+extern int set_irq_type(unsigned int intr, unsigned int type);
 
 #define get_irq_chip(irq)	(irq_desc[irq].chip)
 #define get_irq_chip_data(irq)	(irq_desc[irq].chip_data)
--- linux-2.6.18-rc2-git7-orig/include/linux/random.h	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.18-rc2-git7/include/linux/random.h	2006-07-30 08:56:03.000000000 +0200
@@ -42,11 +42,11 @@ struct rand_pool_info {
 
 #ifdef __KERNEL__
 
-extern void rand_initialize_irq(int irq);
+extern void rand_initialize_irq(int intr);
 
 extern void add_input_randomness(unsigned int type, unsigned int code,
 				 unsigned int value);
-extern void add_interrupt_randomness(int irq);
+extern void add_interrupt_randomness(int intr);
 
 extern void get_random_bytes(void *buf, int nbytes);
 void generate_random_uuid(unsigned char uuid_out[16]);
--- linux-2.6.18-rc2-git7-orig/sound/isa/gus/interwave.c	2006-07-29 14:57:32.000000000 +0200
+++ linux-2.6.18-rc2-git7/sound/isa/gus/interwave.c	2006-07-30 08:57:11.000000000 +0200
@@ -299,7 +299,8 @@ static int __devinit snd_interwave_detec
 	return -ENODEV;
 }
 
-static irqreturn_t snd_interwave_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+static irqreturn_t snd_interwave_interrupt(int intr, void *dev_id,
+					   struct pt_regs *regs)
 {
 	struct snd_interwave *iwcard = (struct snd_interwave *) dev_id;
 	int loop, max = 5;




^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 00/12] making the kernel -Wshadow clean - The initial step
  2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
                   ` (11 preceding siblings ...)
  2006-07-30 16:44 ` [PATCH 12/12] making the kernel -Wshadow clean - 'irq' shadows local and global Jesper Juhl
@ 2006-07-30 16:54 ` Krzysztof Halasa
  2006-07-30 17:14   ` Jesper Juhl
  2006-07-30 19:24 ` Jesper Juhl
  2006-07-30 19:29 ` Sam Ravnborg
  14 siblings, 1 reply; 150+ messages in thread
From: Krzysztof Halasa @ 2006-07-30 16:54 UTC (permalink / raw)
  To: Jesper Juhl
  Cc: linux-kernel, Andrew Morton, Nikita Danilov, Joe Perches,
	Martin Waitz, Jan-Benedict Glaw, Christoph Hellwig,
	David Woodhouse, Arjan van de Ven, Dmitry Torokhov,
	Valdis Kletnieks, Sam Ravnborg, Russell King, Rusty Russell,
	Randy Dunlap

Hi,

Jesper Juhl <jesper.juhl@gmail.com> writes:

> This is a series of patches that try to be an initial step towards making
> the kernel build -Wshadow clean.

I'm not sure such patches improve situation.

> It'll help us keep our namespaces separate.

Nope, it's exactly opposite - now we have separate namespaces and
-Wshadow reduces that separation.

Currently you don't have to worry about the universe when you write
a piece of code, and more importantly the universe doesn't have to
worry about each function and each private variable. I'm not sure
changing that is a good idea.
-- 
Krzysztof Halasa

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 00/12] making the kernel -Wshadow clean - The initial step
  2006-07-30 16:54 ` [PATCH 00/12] making the kernel -Wshadow clean - The initial step Krzysztof Halasa
@ 2006-07-30 17:14   ` Jesper Juhl
  2006-07-30 17:27     ` Krzysztof Halasa
  0 siblings, 1 reply; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 17:14 UTC (permalink / raw)
  To: Krzysztof Halasa
  Cc: linux-kernel, Andrew Morton, Nikita Danilov, Joe Perches,
	Martin Waitz, Jan-Benedict Glaw, Christoph Hellwig,
	David Woodhouse, Arjan van de Ven, Dmitry Torokhov,
	Valdis Kletnieks, Sam Ravnborg, Russell King, Rusty Russell,
	Randy Dunlap

On 30/07/06, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> Hi,
>
Hi Krzysztof,


> Jesper Juhl <jesper.juhl@gmail.com> writes:
>
> > This is a series of patches that try to be an initial step towards making
> > the kernel build -Wshadow clean.
>
> I'm not sure such patches improve situation.
>
> > It'll help us keep our namespaces separate.
>
> Nope, it's exactly opposite - now we have separate namespaces and
> -Wshadow reduces that separation.
>

I don't agree. -Wshadow lets the compiler help you ensure that you
don't accidentally use a symbol from a local scope when you think you
are using one from an enclosing scope (global or not).
Bugs resulting from such use can be hard to track down and if we can
get the compiler to help us avoid them I think that's a win.


> Currently you don't have to worry about the universe when you write
> a piece of code, and more importantly the universe doesn't have to
> worry about each function and each private variable. I'm not sure
> changing that is a good idea.

I think it's a good thing that we have to take a little more care when
choosing global function and variable names... Take up() for example -
in my (very humble) oppinion that is a very bad name for a global
function - it clashes too easily with local function and variable
names, and a programmer who's not careful may end up calling the
global up() when he wants the local and vice versa (a much better name
would have been sem_up() - should we change that???).
I think it's a good think if we in the future name our global stuff
with more care and stick a big fat warning in the face of programmers
who introduce local stuff that shadows something else.

I don't agree with you and I don't know how to convince you, but I
still appreciate your feedback.
Thanks.

I'll leave it to people higher in the hierarchy to decide if these
patches should be applied or not ;)

Keep that feedback flowing people :-)


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 00/12] making the kernel -Wshadow clean - The initial step
  2006-07-30 17:14   ` Jesper Juhl
@ 2006-07-30 17:27     ` Krzysztof Halasa
  2006-07-30 18:29       ` Andrew Morton
  2006-08-01  6:17       ` Jan Engelhardt
  0 siblings, 2 replies; 150+ messages in thread
From: Krzysztof Halasa @ 2006-07-30 17:27 UTC (permalink / raw)
  To: Jesper Juhl
  Cc: linux-kernel, Andrew Morton, Nikita Danilov, Joe Perches,
	Martin Waitz, Jan-Benedict Glaw, Christoph Hellwig,
	David Woodhouse, Arjan van de Ven, Dmitry Torokhov,
	Valdis Kletnieks, Sam Ravnborg, Russell King, Rusty Russell,
	Randy Dunlap

"Jesper Juhl" <jesper.juhl@gmail.com> writes:

> I think it's a good thing that we have to take a little more care when
> choosing global function and variable names... Take up() for example -
> in my (very humble) oppinion that is a very bad name for a global
> function - it clashes too easily with local function and variable
> names, and a programmer who's not careful may end up calling the
> global up() when he wants the local and vice versa (a much better name
> would have been sem_up() - should we change that???).

Possibly, but it could then conflict with something else. Anytime we
add/change some global symbol, we would have to scan entire kernel
for conflicts (authors of (yet) off-tree things would hate us).
I don't think it's practical, especially with, IMHO, no real gain.

> I don't agree with you and I don't know how to convince you, but I
> still appreciate your feedback.
> Thanks.

You're welcome. I'd be more happy if I could say I like the idea :-(

> I'll leave it to people higher in the hierarchy to decide if these
> patches should be applied or not ;)

Sure.
-- 
Krzysztof Halasa

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 00/12] making the kernel -Wshadow clean - The initial step
  2006-07-30 17:27     ` Krzysztof Halasa
@ 2006-07-30 18:29       ` Andrew Morton
  2006-07-30 23:36         ` Arnd Bergmann
  2006-08-01  6:17       ` Jan Engelhardt
  1 sibling, 1 reply; 150+ messages in thread
From: Andrew Morton @ 2006-07-30 18:29 UTC (permalink / raw)
  To: Krzysztof Halasa
  Cc: jesper.juhl, linux-kernel, nikita, joe, tali, jbglaw, hch, dwmw2,
	arjan, dmitry.torokhov, Valdis.Kletnieks, sam, rmk, rusty,
	rdunlap

On Sun, 30 Jul 2006 19:27:36 +0200
Krzysztof Halasa <khc@pm.waw.pl> wrote:

> "Jesper Juhl" <jesper.juhl@gmail.com> writes:
> 
> > I think it's a good thing that we have to take a little more care when
> > choosing global function and variable names... Take up() for example -
> > in my (very humble) oppinion that is a very bad name for a global
> > function - it clashes too easily with local function and variable
> > names, and a programmer who's not careful may end up calling the
> > global up() when he wants the local and vice versa (a much better name
> > would have been sem_up() - should we change that???).
> 
> Possibly, but it could then conflict with something else. Anytime we
> add/change some global symbol, we would have to scan entire kernel
> for conflicts (authors of (yet) off-tree things would hate us).

These things happen.  And it's only a warning.

> I don't think it's practical, especially with, IMHO, no real gain.

While I don't recall any kernel bugs which -Wshadow would have saved us
from, I think it's a sensible thing to do - it _might_ save us from a bug,
and we need all the help we can get.

Plus it's often the case that if a local and a global clash, one of the
identifiers was poorly chosen.


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 01/12] making the kernel -Wshadow clean - fix mconf
  2006-07-30 16:35 ` [PATCH 01/12] making the kernel -Wshadow clean - fix mconf Jesper Juhl
@ 2006-07-30 18:34   ` Paul Jackson
  2006-07-30 18:48     ` Jesper Juhl
  0 siblings, 1 reply; 150+ messages in thread
From: Paul Jackson @ 2006-07-30 18:34 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: linux-kernel, jesper.juhl, akpm

Jesper wrote:
> -		cprint("%s", filename);
> +		cprint("%s", config_filename);

Something seems strange here to me.  It looks like you are sometimes
resolving the shadowed symbols by making the more local symbol have the
longer name.

I'd have expected that the global symbol would be the one with the
longer, more elaborate name.

In other words, I would have expected that we would avoid having global
names such as (from your other patches in this set):

    filename
    scroll
    instr
    up
    sum
    state
    rep
    complete
    irq

Perhaps I am misreading this patch set?

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 01/12] making the kernel -Wshadow clean - fix mconf
  2006-07-30 18:34   ` Paul Jackson
@ 2006-07-30 18:48     ` Jesper Juhl
  2006-07-30 19:06       ` Andrew Morton
                         ` (2 more replies)
  0 siblings, 3 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 18:48 UTC (permalink / raw)
  To: Paul Jackson; +Cc: linux-kernel, akpm

On 30/07/06, Paul Jackson <pj@sgi.com> wrote:
> Jesper wrote:
> > -             cprint("%s", filename);
> > +             cprint("%s", config_filename);
>
> Something seems strange here to me.  It looks like you are sometimes
> resolving the shadowed symbols by making the more local symbol have the
> longer name.
>
True.

> I'd have expected that the global symbol would be the one with the
> longer, more elaborate name.
>
Generally I'd agree with you, but my initial objective is to resolve
all (or at least most) of the clashes with as little pain as pssible
initially so that we can get to the point where we can add -Wshadow to
the Makefile - sometimes the path of least resistence is making the
local name longer.


> In other words, I would have expected that we would avoid having global
> names such as (from your other patches in this set):
>
>     filename

Here I changed the global to be longer - config_filename.

>     scroll

made the local longer - guilty as charged.


>     instr

I don't recall using that variable name - I believe you mean 'intr'
for interrupt that I used in place of 'irq'.


>     up

I'd *love* to change this one - and down() as well - to up_sem() &
down_sem(). But, making that change would be a pretty major and
somewhat disruptive api change, so I opted instead to change the local
variable names. I plan to introduce a sepperate patch set later on
that adds up_sem()/down_sem() wrappers around up()/down(), deprecate
the old names and add an entry to feature-removal.txt - but doing it
now as part of the -Wshadow cleanup would be too much pain.

>     sum
>     state
>     rep
>     complete
>     irq
>

Yes, here I made the local name longer. Long term that should probably
change. Short term it seemed the path of least resistance.


> Perhaps I am misreading this patch set?
>
i don't think you are. It's just that I want to take the least
intrusive route *now*, make us -Wshadow clean, get -Wshadow to be an
accepted part of the Makefile, *then* deal with the more
intrusive/controversial renamings, where I guess you'd have done
things in the opposite order - right?


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 01/12] making the kernel -Wshadow clean - fix mconf
  2006-07-30 18:48     ` Jesper Juhl
@ 2006-07-30 19:06       ` Andrew Morton
  2006-07-30 19:17         ` Jesper Juhl
  2006-07-30 19:32         ` Paul Jackson
  2006-07-30 23:41       ` Arnd Bergmann
  2006-07-31 15:41       ` Horst H. von Brand
  2 siblings, 2 replies; 150+ messages in thread
From: Andrew Morton @ 2006-07-30 19:06 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: pj, linux-kernel

On Sun, 30 Jul 2006 20:48:23 +0200
"Jesper Juhl" <jesper.juhl@gmail.com> wrote:

> > Perhaps I am misreading this patch set?
> >
> i don't think you are. It's just that I want to take the least
> intrusive route *now*, make us -Wshadow clean, get -Wshadow to be an
> accepted part of the Makefile, *then* deal with the more
> intrusive/controversial renamings, where I guess you'd have done
> things in the opposite order - right?

yup.  Experience tells us that it's better to get things right first time,
because we don't get around to doing the intended second pass (looks at
lock_cpu_hotplug())

That being said, no, we can't go and rename up().  Let us go through the
patches one-at-a-time..

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 01/12] making the kernel -Wshadow clean - fix mconf
  2006-07-30 19:06       ` Andrew Morton
@ 2006-07-30 19:17         ` Jesper Juhl
  2006-07-30 19:51           ` Andrew Morton
  2006-07-30 19:32         ` Paul Jackson
  1 sibling, 1 reply; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 19:17 UTC (permalink / raw)
  To: Andrew Morton; +Cc: pj, linux-kernel

On 30/07/06, Andrew Morton <akpm@osdl.org> wrote:
> On Sun, 30 Jul 2006 20:48:23 +0200
> "Jesper Juhl" <jesper.juhl@gmail.com> wrote:
>
> > > Perhaps I am misreading this patch set?
> > >
> > i don't think you are. It's just that I want to take the least
> > intrusive route *now*, make us -Wshadow clean, get -Wshadow to be an
> > accepted part of the Makefile, *then* deal with the more
> > intrusive/controversial renamings, where I guess you'd have done
> > things in the opposite order - right?
>
> yup.  Experience tells us that it's better to get things right first time,
> because we don't get around to doing the intended second pass

I believe my (modest) track record would show that I do follow up on
these things...
But anyway, I believe the renames I've done are not bad one way or the
other and should be acceptable (and some of the long names for local
symbols are chosen based on maintainer feedback even)... but I'll
await more feedback and change the patches if needed.

> (looks at
> lock_cpu_hotplug())
>
Hmm, I'll take a look at lock_cpu_hotplug() - can you provide
additional details?


> That being said, no, we can't go and rename up().  Let us go through the
> patches one-at-a-time..
>
i figured as much. *But* won't you agree that up_sem() (or considering
the other locking function names, sem_up() would probably be better)
would be a much better name for a global like this one?

How about a plan like this:
We introduce sem_up() and sem_down() wrapper functions now. They could
go into 2.6.19 for example - and also add a note to
feature-removal-schedule.txt that the old function names will be
removed in 1 year. Then in a few kernel versions - say 2.6.21 - we
deprecate the old names and add a big fac comment in the source as
well.
Wouldn't that be doable?   Or do we have to live with up()/down() forever?


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 00/12] making the kernel -Wshadow clean - The initial step
  2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
                   ` (12 preceding siblings ...)
  2006-07-30 16:54 ` [PATCH 00/12] making the kernel -Wshadow clean - The initial step Krzysztof Halasa
@ 2006-07-30 19:24 ` Jesper Juhl
  2006-07-30 20:09   ` Jan-Benedict Glaw
  2006-07-30 19:29 ` Sam Ravnborg
  14 siblings, 1 reply; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 19:24 UTC (permalink / raw)
  To: linux-kernel
  Cc: Andrew Morton, Nikita Danilov, Joe Perches, Martin Waitz,
	Jan-Benedict Glaw, Christoph Hellwig, David Woodhouse,
	Arjan van de Ven, Dmitry Torokhov, Valdis Kletnieks,
	Sam Ravnborg, Russell King, Rusty Russell, Randy Dunlap,
	Jesper Juhl

On 30/07/06, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> Ok, here we go again...
>
> This is a series of patches that try to be an initial step towards making
> the kernel build -Wshadow clean.
>
Replying to myself here since I forgot one little bit.

It would be great if maintainers of the various areas that my patches
touch would explicitly ack or nack patches - preferably giving reasons
for nack's as well.
That would help me a lot in updating the patch-set (if so needed).

Thanks.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 00/12] making the kernel -Wshadow clean - The initial step
  2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
                   ` (13 preceding siblings ...)
  2006-07-30 19:24 ` Jesper Juhl
@ 2006-07-30 19:29 ` Sam Ravnborg
  2006-07-30 19:39   ` Jesper Juhl
  14 siblings, 1 reply; 150+ messages in thread
From: Sam Ravnborg @ 2006-07-30 19:29 UTC (permalink / raw)
  To: Jesper Juhl
  Cc: linux-kernel, Andrew Morton, Nikita Danilov, Joe Perches,
	Martin Waitz, Jan-Benedict Glaw, Christoph Hellwig,
	David Woodhouse, Arjan van de Ven, Dmitry Torokhov,
	Valdis Kletnieks, Russell King, Rusty Russell, Randy Dunlap

On Sun, Jul 30, 2006 at 06:30:01PM +0200, Jesper Juhl wrote:
> Ok, here we go again...
> 
> This is a series of patches that try to be an initial step towards making
> the kernel build -Wshadow clean.
I will take care of warnings in scripts/*
mconf/lxdialog warnings will be fixed in my lxdialog tree which has
enough patches to make your path of no real use.
And its a trivial fix from my side.

	Sam

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 01/12] making the kernel -Wshadow clean - fix mconf
  2006-07-30 19:06       ` Andrew Morton
  2006-07-30 19:17         ` Jesper Juhl
@ 2006-07-30 19:32         ` Paul Jackson
  1 sibling, 0 replies; 150+ messages in thread
From: Paul Jackson @ 2006-07-30 19:32 UTC (permalink / raw)
  To: Andrew Morton; +Cc: jesper.juhl, linux-kernel

> we can't go and rename up()

True - quite true.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 00/12] making the kernel -Wshadow clean - The initial step
  2006-07-30 19:29 ` Sam Ravnborg
@ 2006-07-30 19:39   ` Jesper Juhl
  0 siblings, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 19:39 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: linux-kernel, Andrew Morton, Nikita Danilov, Joe Perches,
	Martin Waitz, Jan-Benedict Glaw, Christoph Hellwig,
	David Woodhouse, Arjan van de Ven, Dmitry Torokhov,
	Valdis Kletnieks, Russell King, Rusty Russell, Randy Dunlap

On 30/07/06, Sam Ravnborg <sam@ravnborg.org> wrote:
> On Sun, Jul 30, 2006 at 06:30:01PM +0200, Jesper Juhl wrote:
> > Ok, here we go again...
> >
> > This is a series of patches that try to be an initial step towards making
> > the kernel build -Wshadow clean.
> I will take care of warnings in scripts/*
> mconf/lxdialog warnings will be fixed in my lxdialog tree which has
> enough patches to make your path of no real use.
> And its a trivial fix from my side.
>
Great. I'll drop everything in scripts/ and rely on you there.
Thanks a lot for the feedback.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 01/12] making the kernel -Wshadow clean - fix mconf
  2006-07-30 19:17         ` Jesper Juhl
@ 2006-07-30 19:51           ` Andrew Morton
  2006-07-30 19:57             ` Arjan van de Ven
  2006-07-30 20:03             ` Jesper Juhl
  0 siblings, 2 replies; 150+ messages in thread
From: Andrew Morton @ 2006-07-30 19:51 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: pj, linux-kernel

On Sun, 30 Jul 2006 21:17:18 +0200
"Jesper Juhl" <jesper.juhl@gmail.com> wrote:

> > (looks at
> > lock_cpu_hotplug())
> >
> Hmm, I'll take a look at lock_cpu_hotplug() - can you provide
> additional details?
> 

eh.  We put the recursive-sem thing in there as a temp fix to cpufreq to
get 2.6.something out the door, expressing fine intentions to fix it for
real later on.  Then look what happened.  Don't go there.

> 
> > That being said, no, we can't go and rename up().  Let us go through the
> > patches one-at-a-time..
> >
> i figured as much. *But* won't you agree that up_sem() (or considering
> the other locking function names, sem_up() would probably be better)
> would be a much better name for a global like this one?
> 
> How about a plan like this:
> We introduce sem_up() and sem_down() wrapper functions now. They could
> go into 2.6.19 for example - and also add a note to
> feature-removal-schedule.txt that the old function names will be
> removed in 1 year. Then in a few kernel versions - say 2.6.21 - we
> deprecate the old names and add a big fac comment in the source as
> well.
> Wouldn't that be doable?   Or do we have to live with up()/down() forever?

Well actually when struct mutex went in we decided to remove all
non-counting uses of semaphores kernel-wide, migrating them to mutexes. 
Then to remove all the arch-specific semaphore implementations and
implement an arch-neutral version.  After that has been done would be an
appropriate time to rename things.

But it never happened.  See "fine intentions", above ;)

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 01/12] making the kernel -Wshadow clean - fix mconf
  2006-07-30 19:51           ` Andrew Morton
@ 2006-07-30 19:57             ` Arjan van de Ven
  2006-07-30 20:03             ` Jesper Juhl
  1 sibling, 0 replies; 150+ messages in thread
From: Arjan van de Ven @ 2006-07-30 19:57 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Jesper Juhl, pj, linux-kernel


> Well actually when struct mutex went in we decided to remove all
> non-counting uses of semaphores kernel-wide, migrating them to mutexes. 
> Then to remove all the arch-specific semaphore implementations and
> implement an arch-neutral version.  After that has been done would be an
> appropriate time to rename things.
> 
> But it never happened.  See "fine intentions", above ;)

it's still in progress ;)
even in 2.6.18-rc there are semaphore to mutex conversions....
the remaining ones are increasingly tricky though so speed is slowing
down


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 01/12] making the kernel -Wshadow clean - fix mconf
  2006-07-30 19:51           ` Andrew Morton
  2006-07-30 19:57             ` Arjan van de Ven
@ 2006-07-30 20:03             ` Jesper Juhl
  1 sibling, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-07-30 20:03 UTC (permalink / raw)
  To: Andrew Morton; +Cc: pj, linux-kernel

On 30/07/06, Andrew Morton <akpm@osdl.org> wrote:
> On Sun, 30 Jul 2006 21:17:18 +0200
> "Jesper Juhl" <jesper.juhl@gmail.com> wrote:
>
> > > (looks at
> > > lock_cpu_hotplug())
> > >
> > Hmm, I'll take a look at lock_cpu_hotplug() - can you provide
> > additional details?
> >
>
> eh.  We put the recursive-sem thing in there as a temp fix to cpufreq to
> get 2.6.something out the door, expressing fine intentions to fix it for
> real later on.  Then look what happened.  Don't go there.
>

Ok, that's probably way over my head, but I'll dig in none the less
and see what I can do to help. It'll probably land me in a world of
hurt, but I've taken flames before and I'm still here ;-)
Don't expect much, but I'll see if there's anything I can do at least.


> >
> > > That being said, no, we can't go and rename up().  Let us go through the
> > > patches one-at-a-time..
> > >
> > i figured as much. *But* won't you agree that up_sem() (or considering
> > the other locking function names, sem_up() would probably be better)
> > would be a much better name for a global like this one?
> >
> > How about a plan like this:
> > We introduce sem_up() and sem_down() wrapper functions now. They could
> > go into 2.6.19 for example - and also add a note to
> > feature-removal-schedule.txt that the old function names will be
> > removed in 1 year. Then in a few kernel versions - say 2.6.21 - we
> > deprecate the old names and add a big fac comment in the source as
> > well.
> > Wouldn't that be doable?   Or do we have to live with up()/down() forever?
>
> Well actually when struct mutex went in we decided to remove all
> non-counting uses of semaphores kernel-wide, migrating them to mutexes.

Makes sense.

> Then to remove all the arch-specific semaphore implementations and
> implement an arch-neutral version.  After that has been done would be an
> appropriate time to rename things.
>

Ok, that is (again) probably beyond me, but I'll still take a look at
it just for the hell of it.
If nothing else I can at least keep an eye out for when we reach the
point we want to be at and then submit renaming patches...  let's
see..


> But it never happened.  See "fine intentions", above ;)
>
Heh, The road to hell is paved with fine intentions ;-)

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 00/12] making the kernel -Wshadow clean - The initial step
  2006-07-30 19:24 ` Jesper Juhl
@ 2006-07-30 20:09   ` Jan-Benedict Glaw
  0 siblings, 0 replies; 150+ messages in thread
From: Jan-Benedict Glaw @ 2006-07-30 20:09 UTC (permalink / raw)
  To: Jesper Juhl
  Cc: linux-kernel, Andrew Morton, Nikita Danilov, Joe Perches,
	Martin Waitz, Christoph Hellwig, David Woodhouse,
	Arjan van de Ven, Dmitry Torokhov, Valdis Kletnieks,
	Sam Ravnborg, Russell King, Rusty Russell, Randy Dunlap

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

On Sun, 2006-07-30 21:24:59 +0200, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> On 30/07/06, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> > Ok, here we go again...
> >
> > This is a series of patches that try to be an initial step towards making
> > the kernel build -Wshadow clean.
> >
> It would be great if maintainers of the various areas that my patches
> touch would explicitly ack or nack patches - preferably giving reasons
> for nack's as well.

My move to a new town is basically done, so I'll give it a run for the
VAX specific bits which I care about.

MfG, JBG

-- 
       Jan-Benedict Glaw       jbglaw@lug-owl.de                +49-172-7608481
 Signature of:                               If it doesn't work, force it.
 the second  :                      If it breaks, it needed replacing anyway.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 00/12] making the kernel -Wshadow clean - The initial step
  2006-07-30 18:29       ` Andrew Morton
@ 2006-07-30 23:36         ` Arnd Bergmann
  0 siblings, 0 replies; 150+ messages in thread
From: Arnd Bergmann @ 2006-07-30 23:36 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Krzysztof Halasa, jesper.juhl, linux-kernel, nikita, joe, tali,
	jbglaw, hch, dwmw2, arjan, dmitry.torokhov, Valdis.Kletnieks,
	sam, rmk, rusty, rdunlap

Am Sunday 30 July 2006 20:29 schrieb Andrew Morton:
> While I don't recall any kernel bugs which -Wshadow would have saved us
> from, I think it's a sensible thing to do - it _might_ save us from a bug,
> and we need all the help we can get.

One case where it would have helped in the past is jiffies -- when
experimenting with tickless systems, turning the global jiffies
variable into a macro comes in handy, but that breaks all functions
that have a local variable with the same name.

	Arnd <><

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 01/12] making the kernel -Wshadow clean - fix mconf
  2006-07-30 18:48     ` Jesper Juhl
  2006-07-30 19:06       ` Andrew Morton
@ 2006-07-30 23:41       ` Arnd Bergmann
  2006-07-31 15:41       ` Horst H. von Brand
  2 siblings, 0 replies; 150+ messages in thread
From: Arnd Bergmann @ 2006-07-30 23:41 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: Paul Jackson, linux-kernel, akpm

Am Sunday 30 July 2006 20:48 schrieb Jesper Juhl:
> >     up
>
> I'd *love* to change this one - and down() as well - to up_sem() &
> down_sem(). But, making that change would be a pretty major and
> somewhat disruptive api change, so I opted instead to change the local
> variable names. I plan to introduce a sepperate patch set later on
> that adds up_sem()/down_sem() wrappers around up()/down(), deprecate
> the old names and add an entry to feature-removal.txt - but doing it
> now as part of the -Wshadow cleanup would be too much pain.

The path for getting rid of up()/down() is more along the lines
of replacing more semaphores with mutex variables. Once the only
users of up()/down() are those that really rely on counting semaphores,
it becomes much easier to do the change you proposed.

	Arnd <><

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 01/12] making the kernel -Wshadow clean - fix mconf 
  2006-07-30 18:48     ` Jesper Juhl
  2006-07-30 19:06       ` Andrew Morton
  2006-07-30 23:41       ` Arnd Bergmann
@ 2006-07-31 15:41       ` Horst H. von Brand
  2006-07-31 16:04         ` H. Peter Anvin
  2 siblings, 1 reply; 150+ messages in thread
From: Horst H. von Brand @ 2006-07-31 15:41 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: Paul Jackson, linux-kernel, akpm

Jesper Juhl <jesper.juhl@gmail.com> wrote:
> On 30/07/06, Paul Jackson <pj@sgi.com> wrote:
> > Jesper wrote:
> > > -             cprint("%s", filename);
> > > +             cprint("%s", config_filename);
> >
> > Something seems strange here to me.  It looks like you are sometimes
> > resolving the shadowed symbols by making the more local symbol have the
> > longer name.

[...]

> >     instr
> 
> I don't recall using that variable name - I believe you mean 'intr'
> for interrupt that I used in place of 'irq'.

Please don't. If people are accustomed to irq, they will start wondering
what intr is all about (or what the difference is, etc).

> >     up

> I'd *love* to change this one - and down() as well - to up_sem() &
> down_sem().

Just too bad that there aren't semaphores anymore... and I can't find up()
down() in the headers anyway?

>             But, making that change would be a pretty major and
> somewhat disruptive api change, so I opted instead to change the local
> variable names. I plan to introduce a sepperate patch set later on
> that adds up_sem()/down_sem() wrappers around up()/down(), deprecate
> the old names and add an entry to feature-removal.txt - but doing it
> now as part of the -Wshadow cleanup would be too much pain.

Why not leave them alone for the time being then, and clean up in one sweep
later on?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 01/12] making the kernel -Wshadow clean - fix mconf
  2006-07-31 15:41       ` Horst H. von Brand
@ 2006-07-31 16:04         ` H. Peter Anvin
  0 siblings, 0 replies; 150+ messages in thread
From: H. Peter Anvin @ 2006-07-31 16:04 UTC (permalink / raw)
  To: Horst H. von Brand; +Cc: Jesper Juhl, Paul Jackson, linux-kernel, akpm

Horst H. von Brand wrote:
> 
>>>     instr
>> I don't recall using that variable name - I believe you mean 'intr'
>> for interrupt that I used in place of 'irq'.
> 
> Please don't. If people are accustomed to irq, they will start wondering
> what intr is all about (or what the difference is, etc).
> 

Worse, on the x86 platform, people may very well assume that irq 0 = 
intr 32 etc.

	-hpa

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH 00/12] making the kernel -Wshadow clean - The initial step
  2006-07-30 17:27     ` Krzysztof Halasa
  2006-07-30 18:29       ` Andrew Morton
@ 2006-08-01  6:17       ` Jan Engelhardt
  1 sibling, 0 replies; 150+ messages in thread
From: Jan Engelhardt @ 2006-08-01  6:17 UTC (permalink / raw)
  To: Krzysztof Halasa
  Cc: Jesper Juhl, linux-kernel, Andrew Morton, Nikita Danilov,
	Joe Perches, Martin Waitz, Jan-Benedict Glaw, Christoph Hellwig,
	David Woodhouse, Arjan van de Ven, Dmitry Torokhov,
	Valdis Kletnieks, Sam Ravnborg, Russell King, Rusty Russell,
	Randy Dunlap

>> I think it's a good thing that we have to take a little more care when
>> choosing global function and variable names... Take up() for example -
>> in my (very humble) oppinion that is a very bad name for a global
>> function - it clashes too easily with local function and variable
>> names, and a programmer who's not careful may end up calling the
>> global up() when he wants the local and vice versa (a much better name
>> would have been sem_up() - should we change that???).
>
>(authors of (yet) off-tree things would hate us)

Mark up() as deprecated while sem_up() emerges - hey, we even have an
__attribute__(()) for that..


Jan Engelhardt
-- 

^ permalink raw reply	[flat|nested] 150+ messages in thread

* [PATCH] fix warning: no return statement in function returning non-void in kernel/audit.c
@ 2006-09-11 15:15 ` Jesper Juhl
  2006-09-11 16:03   ` Dave Jones
  2006-09-11 22:56   ` Horst H. von Brand
  0 siblings, 2 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-09-11 15:15 UTC (permalink / raw)
  To: linux-kernel; +Cc: jesper.juhl, Rickard Faith


kauditd_thread() is being used in a call to kthread_run(). kthread_run() expects
a function returning 'int' which is also how kauditd_thread() is declared. Unfortunately
kauditd_thread() neglects to return a value which results in this complaint from gcc :

  kernel/audit.c:372: warning: no return statement in function returning non-void

Easily fixed by just adding a 'return 0;' to kauditd_thread().


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 kernel/audit.c |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.18-rc6-git3-orig/kernel/audit.c	2006-09-11 10:46:11.092786000 +0200
+++ linux-2.6.18-rc6-git3/kernel/audit.c	2006-09-11 17:08:00.888216381 +0200
@@ -369,6 +369,7 @@ static int kauditd_thread(void *dummy)
 			remove_wait_queue(&kauditd_wait, &wait);
 		}
 	}
+	return 0;
 }
 
 int audit_send_list(void *_dest)




^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] fix warning: no return statement in function returning non-void in kernel/audit.c
  2006-09-11 15:15 ` [PATCH] fix warning: no return statement in function returning non-void in kernel/audit.c Jesper Juhl
@ 2006-09-11 16:03   ` Dave Jones
  2006-09-11 19:22     ` Jesper Juhl
  2006-09-11 22:56   ` Horst H. von Brand
  1 sibling, 1 reply; 150+ messages in thread
From: Dave Jones @ 2006-09-11 16:03 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: linux-kernel, Rickard Faith

On Mon, Sep 11, 2006 at 05:15:16PM +0200, Jesper Juhl wrote:
 > 
 > kauditd_thread() is being used in a call to kthread_run(). kthread_run() expects
 > a function returning 'int' which is also how kauditd_thread() is declared. Unfortunately
 > kauditd_thread() neglects to return a value which results in this complaint from gcc :
 > 
 >   kernel/audit.c:372: warning: no return statement in function returning non-void
 > 
 > Easily fixed by just adding a 'return 0;' to kauditd_thread().

Which will never be reached.  Does marking the function NORET_TYPE
also silence the warning?

	Dave

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] fix warning: no return statement in function returning non-void in kernel/audit.c
  2006-09-11 16:03   ` Dave Jones
@ 2006-09-11 19:22     ` Jesper Juhl
  2006-09-11 20:23       ` Dave Jones
  0 siblings, 1 reply; 150+ messages in thread
From: Jesper Juhl @ 2006-09-11 19:22 UTC (permalink / raw)
  To: Dave Jones, Jesper Juhl, linux-kernel, Rickard Faith

On 11/09/06, Dave Jones <davej@redhat.com> wrote:
> On Mon, Sep 11, 2006 at 05:15:16PM +0200, Jesper Juhl wrote:
>  >
>  > kauditd_thread() is being used in a call to kthread_run(). kthread_run() expects
>  > a function returning 'int' which is also how kauditd_thread() is declared. Unfortunately
>  > kauditd_thread() neglects to return a value which results in this complaint from gcc :
>  >
>  >   kernel/audit.c:372: warning: no return statement in function returning non-void
>  >
>  > Easily fixed by just adding a 'return 0;' to kauditd_thread().
>
> Which will never be reached.

True, and gcc even seems to optimize it out, since the size of audit.o
doesn't change with the patch applied... So, it does no harm and it
silences the warning - so why not?
I guess one could add a small /* never reached */ comment...


> Does marking the function NORET_TYPE
> also silence the warning?
>

Nope :(

This is with gcc 4.1.1 btw.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] fix warning: no return statement in function returning non-void in kernel/audit.c
  2006-09-11 19:22     ` Jesper Juhl
@ 2006-09-11 20:23       ` Dave Jones
  0 siblings, 0 replies; 150+ messages in thread
From: Dave Jones @ 2006-09-11 20:23 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: linux-kernel, Rickard Faith

On Mon, Sep 11, 2006 at 09:22:15PM +0200, Jesper Juhl wrote:
 > >  > kauditd_thread() is being used in a call to kthread_run(). kthread_run() expects
 > >  > a function returning 'int' which is also how kauditd_thread() is declared. Unfortunately
 > >  > kauditd_thread() neglects to return a value which results in this complaint from gcc :
 > >  >
 > >  >   kernel/audit.c:372: warning: no return statement in function returning non-void
 > >  >
 > >  > Easily fixed by just adding a 'return 0;' to kauditd_thread().
 > >
 > > Which will never be reached.
 > 
 > True, and gcc even seems to optimize it out, since the size of audit.o
 > doesn't change with the patch applied... So, it does no harm and it
 > silences the warning - so why not?

Ah well, works for me :)

 > I guess one could add a small /* never reached */ comment...

Could do for completeness, though it should seem fairly obvious.

 > > Does marking the function NORET_TYPE
 > > also silence the warning?
 > Nope :(

Bah!

	Dave


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] fix warning: no return statement in function returning non-void in kernel/audit.c 
  2006-09-11 15:15 ` [PATCH] fix warning: no return statement in function returning non-void in kernel/audit.c Jesper Juhl
  2006-09-11 16:03   ` Dave Jones
@ 2006-09-11 22:56   ` Horst H. von Brand
  2006-09-12  8:59     ` Jesper Juhl
  1 sibling, 1 reply; 150+ messages in thread
From: Horst H. von Brand @ 2006-09-11 22:56 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: linux-kernel, Rickard Faith

Jesper Juhl <jesper.juhl@gmail.com> wrote:
> kauditd_thread() is being used in a call to kthread_run(). kthread_run()
> expects a function returning 'int' which is also how kauditd_thread() is
> declared. Unfortunately kauditd_thread() neglects to return a value

It is an infinite loop...
>                                                                     which
> results in this complaint from gcc :

>   kernel/audit.c:372: warning: no return statement in function returning non-void

> Easily fixed by just adding a 'return 0;' to kauditd_thread().

How about marking it as never returning?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: [PATCH] fix warning: no return statement in function returning non-void in kernel/audit.c
  2006-09-11 22:56   ` Horst H. von Brand
@ 2006-09-12  8:59     ` Jesper Juhl
  0 siblings, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-09-12  8:59 UTC (permalink / raw)
  To: Horst H. von Brand; +Cc: linux-kernel, Rickard Faith

On 12/09/06, Horst H. von Brand <vonbrand@inf.utfsm.cl> wrote:
> Jesper Juhl <jesper.juhl@gmail.com> wrote:
> > kauditd_thread() is being used in a call to kthread_run(). kthread_run()
> > expects a function returning 'int' which is also how kauditd_thread() is
> > declared. Unfortunately kauditd_thread() neglects to return a value
>
> It is an infinite loop...

I know. I'm just trying to get gcc to shut up.


> >                                                                     which
> > results in this complaint from gcc :
>
> >   kernel/audit.c:372: warning: no return statement in function returning non-void
>
> > Easily fixed by just adding a 'return 0;' to kauditd_thread().
>
> How about marking it as never returning?

Marking it NORET_TYPE doesn't do the trick, adding a 'return 0;' does.
And gcc optimizes the return away anyway, so the object file doesn't
increase in size, so it does no harm.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* A proposal; making 2.6.20 a bugfix only version.
@ 2006-11-08 22:09 Jesper Juhl
  2006-11-08 22:22 ` Arjan van de Ven
  0 siblings, 1 reply; 150+ messages in thread
From: Jesper Juhl @ 2006-11-08 22:09 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Andrew Morton, Linux Kernel Mailing List, Adrian Bunk

Greetings,

I have a suggestion. Why don't we make 2.6.20 a "bug fixes only" kernel version?

I think it would be a good idea to dedicate just one kernel cycle to
pure bug fixes and cleanups. Why? I'll tell you :)

We keep merging new features and destabilizing things all the time,
and while that's more or less just the new 2.6 model working (and
working well) it does have some problems.

There's no shortage of issues that need fixing, but since we keep
merging new stuff, a lot of bugfixing energy gets spend on the new
cool stuff instead of fixing up any other issues we have.
Also, regressions seem to show up with every new kernel version, and
while they usually get fixed it's not always so (Adrian's list of
known regressions seems to help though).

So, what are all these bugs I'm talking about?  Well, lets see ...

Coverity has, as of this writing, identified 728 issues in the current
kernel. Sure, some of those have already been identified as false or
ignorable issues, but many are flagged as actual bugs and still more
are as yet uninspected.

The kernel bugzilla has many many entries that are real bugs, some
even have patches.

Many bugreports are made to LKML weekly and while some of the issues
get picked up and fixed, many also get lost.
(many patches also get posted and subsequently ignored - which is a shame).

Building current kernels show up tons of warnings (and sometimes
errors) that should be investigated/fixed - some of them are real
bugs.

The kernel janitors have a long list of issues that need to be
investigated and cleaned up/fixed.

Adrian Bunk has his list of known regressions and, I'll bet, also some
patches in the trivial queue for small issues.

There are many bug fixes in -mm and other trees that we ought to
dedicate some time to merging.

There are many parts of the kernel that are not documented.

I'm sure most distributions have a bunch of bug fixing patches lying
about that they could push.


What I'm trying to say is that, maybe we should resist the temptation
to merge new cool features for just a single kernel cycle and instead
dedicate it to fixing as many of our known issues as possible - we
have plenty...

Let's dedicate a cycle to bug fixing only.
Trivial bug fixes, involved bug fixes, new docs, fixes to existing
docs, obviously correct cleanups - all OK.
What's not OK is stuff that introduce new functionality/features, adds
support for new hardware (unless trivial such as just adding a new PCI
ID), breaks currently working behaviour, etc.


There are a few other reasons, besides the many lists of known bugs,
that inspired me to make this suggestion, a few are listed below.

- I've personally felt a greater and greater need to test kernel.org
kernels recently before putting them into production use, both at home
and at work. In my subjective oppinion, quality of releases seems to
be a lot more uncertain than it used to. Can't put my finger on when
this started to happen, just a subjective feeling over time (as well
as seeing my home box and servers at work have problems with new
kernels more often than they used to).

- A while back, akpm made some statements about being worried that the
2.6 kernel is getting buggier
(http://news.zdnet.com/2100-3513_22-6069363.html).

- The need for the -stable tree and the (relatively large) number of
-stable releases between each new major release clearly shows that we
are leaving lots of regressions in our wake.


In the long term I think it might be a good idea to do something like
this every once in a while (perhaps every .20, .30, .40 etc), we'll
see if that makes sense, but doing it at least once won't do any harm
(except delaying new features a few months).. Let's try it.

Let's make a public statement that 2.6.20 will be a "bug fixes and
stabilization only" release.
Let us invite all distributions to submit their internal bugfixes.
Let us encourage people to work on known issues instead of new stuff
for just this one release (there are enough bugs to choose from that
there should be something worthwhile to do for both newbie and
experienced hacker alike).
Let us comb the mailing list archives and dig up all the lost bug fix patches.
Let us get all pending bug fix patches from the various trees merged,
but just the fixes.
Let us encourage everyone to postpone new stuff to 2.6.21 and re-base
it on top of the 2.6.20 -rc kernels.

What do you say - could it hurt?
I think it would do us a lot of good.

Fixing bugs makes users happy.
Fixing bugs provides a more stable base going forward.
Fixing bugs inspires confidence in the product we provide.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-08 22:09 A proposal; making 2.6.20 a bugfix only version Jesper Juhl
@ 2006-11-08 22:22 ` Arjan van de Ven
  2006-11-08 22:40   ` Jesper Juhl
                     ` (2 more replies)
  0 siblings, 3 replies; 150+ messages in thread
From: Arjan van de Ven @ 2006-11-08 22:22 UTC (permalink / raw)
  To: Jesper Juhl
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, Adrian Bunk


> There's no shortage of issues that need fixing, but since we keep
> merging new stuff, a lot of bugfixing energy gets spend on the new
> cool stuff instead of fixing up any other issues we have.

but if you do this you just end up with a bigger backlog so that the
next one will even be more unstable due to a extreme high change rate.


> Coverity has, as of this writing, identified 728 issues in the current
> kernel. Sure, some of those have already been identified as false or
> ignorable issues, but many are flagged as actual bugs and still more
> are as yet uninspected.

most are mostly false. And the rest is getting looked at. What's the
problem?

> Adrian Bunk has his list of known regressions and, I'll bet, also some
> patches in the trivial queue for small issues.

and all this fixing is happening AS WELL as new features. What makes you
think suddenly even more fixing will happen?

> There are many parts of the kernel that are not documented.

this is where the OSDL Documentation Person will help a lot; a full time
person.



> I'm sure most distributions have a bunch of bug fixing patches lying
> about that they could push.

I doubt it; most have gotten real good at avoiding getting a huge patch
backlog since that is just incredibly expensive ;)

> - A while back, akpm made some statements about being worried that the
> 2.6 kernel is getting buggier
> (http://news.zdnet.com/2100-3513_22-6069363.html).

and at this years Kernel Summit actual data and general consensus showed
this was unfounded fear; the bugrates are more or less stable, but with
many more users.

> 
> - The need for the -stable tree and the (relatively large) number of
> -stable releases between each new major release clearly shows that we
> are leaving lots of regressions in our wake.

No it shows that bugs are getting fixed and delivered to you
IMMEDIATELY. Many many of the -stable things fixed are not in new
things. Is there anything in the -stable process that is not working for
you?





^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-08 22:22 ` Arjan van de Ven
@ 2006-11-08 22:40   ` Jesper Juhl
  2006-11-08 23:05     ` Andreas Mohr
                       ` (2 more replies)
  2006-11-08 22:51   ` Andrew Morton
  2006-11-08 23:28   ` Diego Calleja
  2 siblings, 3 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-11-08 22:40 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, Adrian Bunk

On 08/11/06, Arjan van de Ven <arjan@infradead.org> wrote:
>
> > There's no shortage of issues that need fixing, but since we keep
> > merging new stuff, a lot of bugfixing energy gets spend on the new
> > cool stuff instead of fixing up any other issues we have.
>
> but if you do this you just end up with a bigger backlog so that the
> next one will even be more unstable due to a extreme high change rate.
>
Only if people continue to work on new stuff during the "bug fixing only" cycle.
If we manage to get everyone focused on bug fixing only for the entire
cycle the backlog won't be growing (much).

>
> > Coverity has, as of this writing, identified 728 issues in the current
> > kernel. Sure, some of those have already been identified as false or
> > ignorable issues, but many are flagged as actual bugs and still more
> > are as yet uninspected.
>
> most are mostly false. And the rest is getting looked at. What's the
> problem?
>
Yes, MANY are false, and I know the rest are getting worked at, I work
on some myself when time permits.
I mentioned it simply as an indicator (one amongst many) that we have
a lot of known unfixed issues.


> > Adrian Bunk has his list of known regressions and, I'll bet, also some
> > patches in the trivial queue for small issues.
>
> and all this fixing is happening AS WELL as new features. What makes you
> think suddenly even more fixing will happen?
>
My point was "get people to suspend their work on new features and
focus entirely on bugfixes for a single cycle", so we get more
manpower working on fixing all those known issues we have before we
move on with new features.


> > There are many parts of the kernel that are not documented.
>
> this is where the OSDL Documentation Person will help a lot; a full time
> person.
>
True. I'm looking forward to that.


>
> > I'm sure most distributions have a bunch of bug fixing patches lying
> > about that they could push.
>
> I doubt it; most have gotten real good at avoiding getting a huge patch
> backlog since that is just incredibly expensive ;)
>
Ok, maybe I was wrong there.


> > - A while back, akpm made some statements about being worried that the
> > 2.6 kernel is getting buggier
> > (http://news.zdnet.com/2100-3513_22-6069363.html).
>
> and at this years Kernel Summit actual data and general consensus showed
> this was unfounded fear; the bugrates are more or less stable, but with
> many more users.
>
Ok, I may be on thin ice here, but that contradicts my personal
experience. I see a lot of very nice improvements in recent 2.6
kernels, but I also see a greater need for careful testing before
deploying on the systems I'm responsible for - I feel that I'm running
into more "whoops that kernel wasn't quite fully baked" situations
recently (and yes, I do try to report and/or fix those issues when I
encounter them).


> >
> > - The need for the -stable tree and the (relatively large) number of
> > -stable releases between each new major release clearly shows that we
> > are leaving lots of regressions in our wake.
>
> No it shows that bugs are getting fixed and delivered to you
> IMMEDIATELY. Many many of the -stable things fixed are not in new
> things. Is there anything in the -stable process that is not working for
> you?
>
Let me make one very clear statement first: -stabel is a GREAT think
and it is working VERY well.
That being said, many of the fixes I see going into -stable are
regression fixes. Maybe not the majority, but still, regression fixes
going into -stable tells me that the kernel should have seen more
testing/bugfixing before being declared a stable release.

All I'm trying to say is that we have a number of known bugs, a number
of known regressions, a number of known inefficiencies. Maybe, just
maybe, we should focus a little more on that and a little less on new
features, new hardware support etc. Not permanently - overall I think
the 2.6 model is working great - but just for a single kernel release
cycle every now and then.  And why not just try it once as an
experiment? We'll never know if it's a good idea if we don't try it at
least once.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-08 22:22 ` Arjan van de Ven
  2006-11-08 22:40   ` Jesper Juhl
@ 2006-11-08 22:51   ` Andrew Morton
  2006-11-09  9:26     ` Arjan van de Ven
  2006-11-08 23:28   ` Diego Calleja
  2 siblings, 1 reply; 150+ messages in thread
From: Andrew Morton @ 2006-11-08 22:51 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Jesper Juhl, Linus Torvalds, Linux Kernel Mailing List, Adrian Bunk

On Wed, 08 Nov 2006 23:22:11 +0100
Arjan van de Ven <arjan@infradead.org> wrote:

> > - A while back, akpm made some statements about being worried that the
> > 2.6 kernel is getting buggier
> > (http://news.zdnet.com/2100-3513_22-6069363.html).
> 
> and at this years Kernel Summit actual data

Not true.  70% of surveyed users had hit a new kernel bug.  Of those bugs,
30% remained unresolved.  I don't know what our quality targets are, but I
suggest they're a little higher than that.

> and general consensus showed
> this was unfounded fear;

There you finger the problem.

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-08 22:40   ` Jesper Juhl
@ 2006-11-08 23:05     ` Andreas Mohr
  2006-11-08 23:54       ` Jan Engelhardt
  2006-11-10 15:15     ` Pavel Machek
  2006-11-10 15:48     ` Horst H. von Brand
  2 siblings, 1 reply; 150+ messages in thread
From: Andreas Mohr @ 2006-11-08 23:05 UTC (permalink / raw)
  To: Jesper Juhl
  Cc: Arjan van de Ven, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, Adrian Bunk

Hi,

On Wed, Nov 08, 2006 at 11:40:27PM +0100, Jesper Juhl wrote:
> Let me make one very clear statement first: -stabel is a GREAT think
> and it is working VERY well.
> That being said, many of the fixes I see going into -stable are
> regression fixes. Maybe not the majority, but still, regression fixes
> going into -stable tells me that the kernel should have seen more
> testing/bugfixing before being declared a stable release.

Nice theory, but of course I'm pretty sure that it wouldn't work
(as has been said numerous time before by other people).

You cannot do endless testing/bugfixing, it's a psychological issue.
If you do that, then you end up with -preXX (or worse, -preXXX)
version numbers, which would cause too many people to wait and wait
and wait with upgrading until "that next stable" kernel version
finally becomes available.
IOW, your tester base erodes, awfully, and development progress stalls.

You *have* to release a new ""stable"" version rather fast (the .0 one)
so that people will have that "new shiny version, get it while it's hot!"
feeling and will realize rather quickly that that new version
is all crap again after all and report their unhappiness.
That will lead to lots of -stable bug fixes which will then result in
a very stable actual version once you reach x.y.z.15 or so.

Capito? :)

(well, that's at least how I'm seeing it; correct me if I'm wrong)

Andreas Mohr

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-08 22:22 ` Arjan van de Ven
  2006-11-08 22:40   ` Jesper Juhl
  2006-11-08 22:51   ` Andrew Morton
@ 2006-11-08 23:28   ` Diego Calleja
  2006-11-09  6:48     ` Arjan van de Ven
  2 siblings, 1 reply; 150+ messages in thread
From: Diego Calleja @ 2006-11-08 23:28 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Jesper Juhl, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, Adrian Bunk

El Wed, 08 Nov 2006 23:22:11 +0100,
Arjan van de Ven <arjan@infradead.org> escribió:

> > There are many parts of the kernel that are not documented.
> 
> this is where the OSDL Documentation Person will help a lot; a full time
> person.

Maybe it's just me, but wouldn't be this fixed by just asking developers
to document their code? I maintain the LinuxChanges page at kernelnewbies
and very often I see things merged with zero documentation that I can't
understand even trying to understand the code and I need some googling.
For example, in 2.6.19 there're several "UTS namespace" patches that I
just don't really know exactly what they do...

One of the biggest problems I see when looking at Documentation/ (I
tried to update and fix the sysctl documentation; someone probably feed
me some drugs) is that out-of-code documentation that tries to explain
what the code does, like sysctls, just gets outdated (and that's if the
feature is lucky enought to get documented :) 

The "in-code" documentation using kernel-doc seems to incite developers
to document their code and update it. I think that it should be possible
to document things like sysctls or sysfs. Sysfs really needs something
like that, there's a lot of things in sysfs that aren't documented at all
and the few ones that are documented in Documentation/ are documented
in separated files that _will_ get outdated just like sysctls did. Not
that a "documentation guy" is a bad idea, but I think that getting the
developers envolved in the documentation process would be a better first
step :)

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-08 23:05     ` Andreas Mohr
@ 2006-11-08 23:54       ` Jan Engelhardt
  0 siblings, 0 replies; 150+ messages in thread
From: Jan Engelhardt @ 2006-11-08 23:54 UTC (permalink / raw)
  To: Andreas Mohr
  Cc: Jesper Juhl, Arjan van de Ven, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, Adrian Bunk

>
>You *have* to release a new ""stable"" version rather fast (the .0 one)
>so that people will have that "new shiny version, get it while it's hot!"
>feeling and will realize rather quickly that that new version
>is all crap again after all and report their unhappiness.

Or they just silently revert to a kernel that worked.


	-`J'
-- 

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-08 23:28   ` Diego Calleja
@ 2006-11-09  6:48     ` Arjan van de Ven
  2006-11-09 12:45       ` Rolf Eike Beer
  0 siblings, 1 reply; 150+ messages in thread
From: Arjan van de Ven @ 2006-11-09  6:48 UTC (permalink / raw)
  To: Diego Calleja
  Cc: Jesper Juhl, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, Adrian Bunk

On Thu, 2006-11-09 at 00:28 +0100, Diego Calleja wrote:
> El Wed, 08 Nov 2006 23:22:11 +0100,
> Arjan van de Ven <arjan@infradead.org> escribió:
> 
> > > There are many parts of the kernel that are not documented.
> > 
> > this is where the OSDL Documentation Person will help a lot; a full time
> > person.
> 
> Maybe it's just me, but wouldn't be this fixed by just asking developers
> to document their code?

it's a matter of skills. Someone can be awesome at coding a feature but
his english and writing skills may be waaaaay down there.

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-08 22:51   ` Andrew Morton
@ 2006-11-09  9:26     ` Arjan van de Ven
  2006-11-09  9:36       ` Andrew Morton
  0 siblings, 1 reply; 150+ messages in thread
From: Arjan van de Ven @ 2006-11-09  9:26 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Jesper Juhl, Linus Torvalds, Linux Kernel Mailing List, Adrian Bunk

On Wed, 2006-11-08 at 14:51 -0800, Andrew Morton wrote:
> On Wed, 08 Nov 2006 23:22:11 +0100
> Arjan van de Ven <arjan@infradead.org> wrote:
> 
> > > - A while back, akpm made some statements about being worried that the
> > > 2.6 kernel is getting buggier
> > > (http://news.zdnet.com/2100-3513_22-6069363.html).
> > 
> > and at this years Kernel Summit actual data
> 
> Not true.  70% of surveyed users had hit a new kernel bug. 

70% of surveyed users hit ANY kernel bug. Not "new bugs"
Including "my new wizzbang hardware doesn't work" and "I'll try
something new, oh looky a 4 year old bug" and "this new feature isn't
quite mature yet now that I try it".

One of the things that happened was during early 2.6 udev broke left and
right ABI wise. We've gotten a lot better at that, and that's the kind
of bug that hits a really wide audience.

Statistics can be misleading ... bigtime.
83% of the people also said things were not getting less reliable in
2.6.



-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-09  9:26     ` Arjan van de Ven
@ 2006-11-09  9:36       ` Andrew Morton
  2006-11-09  9:52         ` Arjan van de Ven
  0 siblings, 1 reply; 150+ messages in thread
From: Andrew Morton @ 2006-11-09  9:36 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Jesper Juhl, Linus Torvalds, Linux Kernel Mailing List, Adrian Bunk

On Thu, 09 Nov 2006 10:26:41 +0100
Arjan van de Ven <arjan@infradead.org> wrote:

> On Wed, 2006-11-08 at 14:51 -0800, Andrew Morton wrote:
> > On Wed, 08 Nov 2006 23:22:11 +0100
> > Arjan van de Ven <arjan@infradead.org> wrote:
> > 
> > > > - A while back, akpm made some statements about being worried that the
> > > > 2.6 kernel is getting buggier
> > > > (http://news.zdnet.com/2100-3513_22-6069363.html).
> > > 
> > > and at this years Kernel Summit actual data
> > 
> > Not true.  70% of surveyed users had hit a new kernel bug. 

<funny, I could have sworn I had some additional text in here.  Where'd it go?>

> 70% of surveyed users hit ANY kernel bug. Not "new bugs"
> Including "my new wizzbang hardware doesn't work" and "I'll try
> something new, oh looky a 4 year old bug" and "this new feature isn't
> quite mature yet now that I try it".
> 
> One of the things that happened was during early 2.6 udev broke left and
> right ABI wise. We've gotten a lot better at that, and that's the kind
> of bug that hits a really wide audience.
> 
> Statistics can be misleading ... bigtime.
> 83% of the people also said things were not getting less reliable in
> 2.6.
> 

70% hit a bug
1/7th think it's deteriorating
1/4th think lkml response is inadequate
3/5ths think bugzilla response is inadequate
2/5ths think we have features-vs-stability wrong
2/3rds hit a bug.  Of those, 1/3rd remain unfixed
1/5th of users are presently impacted by a kernel bug

Happy with that?

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-09  9:36       ` Andrew Morton
@ 2006-11-09  9:52         ` Arjan van de Ven
  2006-11-09 19:12           ` Andrew Morton
  0 siblings, 1 reply; 150+ messages in thread
From: Arjan van de Ven @ 2006-11-09  9:52 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Jesper Juhl, Linus Torvalds, Linux Kernel Mailing List, Adrian Bunk


> 
> 70% hit a bug

this part I consider meaningless personally. If it was "70% hit a
regression" or even x% hit a regression I would be a lot more worried.

> 1/7th think it's deteriorating
> 1/4th think lkml response is inadequate
> 3/5ths think bugzilla response is inadequate
> 2/5ths think we have features-vs-stability wrong
after lots of press. 
> 2/3rds hit a bug.  Of those, 1/3rd remain unfixed
> 1/5th of users are presently impacted by a kernel bug
> 
> Happy with that?

I'm not saying things are perfect. Far from that.
What I care about is if things are getting worse or not. My personal
impression is that while things were flakey on the ABI front during
early 2.6 (before 2.6.12 or so), that got fixed because every single bug
is a major annoyance to a large group of people. (and most bugs in the
survey were from before that).

The counter argument to your "doom" data is that bugrates for acpi for
example have been mostly steady, while the number of users has been
increasing quite a bit. 

I don't have the impression things are getting worse personally. I do
hit bugs, in -mm and in -rc kernels, but that is because I'm testing
kernels intended for testing. (another thing that the 70% figure didn't
separate out)

We've gotten better. Adrian started tracking regressions, and that is
helping to make sure that those don't slip through the cracks as much as
they used to (some are unavoidable, especially performance ones or ones
with really obscure hardware that is showing hard to reproduce things).
The -stable series is working out well to fix security and other
annoying bugs quickly post release (because yes things don't get tested
fully until you release), but even -stable is not nearly getting massive
infloods of serious regressions. Sure they are fixing more stuff now,
but that's more a sign that the process is working, and that they are
now picking up less critical stuff as well, than that it is a sign that
things are getting worse.

I'd love if bug responses were better. At the same time, declaring
"bugfix only kernel" isn't going to improve that much; it just creates a
larger flood of stuff for the kernel after that. Do you have the
impression that high quality bug reports on lkml (with this I mean ones
where there is sufficient information, which are not a request for
support and where the reporter actually answers questions that are asked
him) are not getting reasonable attention? 

 
-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-09  6:48     ` Arjan van de Ven
@ 2006-11-09 12:45       ` Rolf Eike Beer
  0 siblings, 0 replies; 150+ messages in thread
From: Rolf Eike Beer @ 2006-11-09 12:45 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Diego Calleja, Jesper Juhl, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, Adrian Bunk

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

Arjan van de Ven wrote:
> On Thu, 2006-11-09 at 00:28 +0100, Diego Calleja wrote:
> > El Wed, 08 Nov 2006 23:22:11 +0100,
> >
> > Arjan van de Ven <arjan@infradead.org> escribió:
> > > > There are many parts of the kernel that are not documented.
> > >
> > > this is where the OSDL Documentation Person will help a lot; a full
> > > time person.
> >
> > Maybe it's just me, but wouldn't be this fixed by just asking developers
> > to document their code?
>
> it's a matter of skills. Someone can be awesome at coding a feature but
> his english and writing skills may be waaaaay down there.

Yes, that's maybe part of the problem. Nevertheless I think we should reject 
every patch that adds new functions of global use (everything that might get 
called from outside this module) without proper kerneldoc comments on it. At 
least everything that comes with EXPORT_SYMBOl_*.

I just remember that digging out all this cdev_* stuff from inside the code 
was just pain. If your new feature is _that_ cool that it has to be 
immediately merged than there will be surely someone out there to help you 
with the documentation if your English is a bit poor. Someone has to review 
that code anyway. If you can give him hints even in bad English what is going 
on it will surely help him (or her) to understand what you're doing, review 
your code and write up some nice comments to make life for the next one to 
touch it a _lot_ easier.

Eike

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-09  9:52         ` Arjan van de Ven
@ 2006-11-09 19:12           ` Andrew Morton
  2006-11-09 19:21             ` Arjan van de Ven
  0 siblings, 1 reply; 150+ messages in thread
From: Andrew Morton @ 2006-11-09 19:12 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Jesper Juhl, Linus Torvalds, Linux Kernel Mailing List, Adrian Bunk

On Thu, 09 Nov 2006 10:52:00 +0100
Arjan van de Ven <arjan@infradead.org> wrote:

> Do you have the
> impression that high quality bug reports on lkml (with this I mean ones
> where there is sufficient information, which are not a request for
> support and where the reporter actually answers questions that are asked
> him) are not getting reasonable attention? 

Yes.

And why does the report quality matter?  If there's insufficient info you
just ask for more.

But we all know that and nothing's going to happen so there's really not
much point in discussing it.  I have 270 saved-up-lkml-bug-reports to
process.


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-09 19:12           ` Andrew Morton
@ 2006-11-09 19:21             ` Arjan van de Ven
  2006-11-09 21:11               ` Adrian Bunk
  0 siblings, 1 reply; 150+ messages in thread
From: Arjan van de Ven @ 2006-11-09 19:21 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Jesper Juhl, Linus Torvalds, Linux Kernel Mailing List, Adrian Bunk

On Thu, 2006-11-09 at 11:12 -0800, Andrew Morton wrote:
> On Thu, 09 Nov 2006 10:52:00 +0100
> Arjan van de Ven <arjan@infradead.org> wrote:
> 
> > Do you have the
> > impression that high quality bug reports on lkml (with this I mean ones
> > where there is sufficient information, which are not a request for
> > support and where the reporter actually answers questions that are asked
> > him) are not getting reasonable attention? 
> 
> Yes.
> 
> And why does the report quality matter?  

because it matters where people spend their time. And if you count
bugreports that are actually distro support questions and then say "but
these aren't looked at" it's not fair either.

> If there's insufficient info you
> just ask for more.

and that does happen. And half the time people just remain silent :(
I know I look at a whole bunch of bugreports in areas that I work on. I
see a lot of other people doing something similar. That doesn't mean
nothing slips through. I'm sure stuff does slip through. I would HOPE
it's really obscure things only; but I fear it's also cases where the
reporter didn't put the right people on the CC as well ;(


> But we all know that and nothing's going to happen so there's really not
> much point in discussing it.  I have 270 saved-up-lkml-bug-reports to
> process.

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-09 19:21             ` Arjan van de Ven
@ 2006-11-09 21:11               ` Adrian Bunk
  2006-11-09 21:31                 ` Arjan van de Ven
  0 siblings, 1 reply; 150+ messages in thread
From: Adrian Bunk @ 2006-11-09 21:11 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Andrew Morton, Jesper Juhl, Linus Torvalds, Linux Kernel Mailing List

On Thu, Nov 09, 2006 at 08:21:55PM +0100, Arjan van de Ven wrote:
> On Thu, 2006-11-09 at 11:12 -0800, Andrew Morton wrote:
> > On Thu, 09 Nov 2006 10:52:00 +0100
> > Arjan van de Ven <arjan@infradead.org> wrote:
> > 
> > > Do you have the
> > > impression that high quality bug reports on lkml (with this I mean ones
> > > where there is sufficient information, which are not a request for
> > > support and where the reporter actually answers questions that are asked
> > > him) are not getting reasonable attention? 
> > 
> > Yes.
> > 
> > And why does the report quality matter?  
> 
> because it matters where people spend their time. And if you count
> bugreports that are actually distro support questions and then say "but
> these aren't looked at" it's not fair either.
> 
> > If there's insufficient info you
> > just ask for more.
> 
> and that does happen. And half the time people just remain silent :(
> I know I look at a whole bunch of bugreports in areas that I work on. I
> see a lot of other people doing something similar. That doesn't mean
> nothing slips through. I'm sure stuff does slip through. I would HOPE
> it's really obscure things only; but I fear it's also cases where the
> reporter didn't put the right people on the CC as well ;(
>...

There are bad bug reports, but not all bug reports are that bad.

What if the quality of the bug report is good and the submitter is 
responsive, and there's still zero reaction?

Let's make an example:

Since the first list I sent immediately after 2.6.19-rc1 was released, 
kernel Bugzilla #7255 is part of my list of 2.6.19-rc regressions but 
has gotten exactly zero developer responses.

What exactly were the mistakes of the submitter resulting in noone 
caring about Bugzilla #7255?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-09 21:11               ` Adrian Bunk
@ 2006-11-09 21:31                 ` Arjan van de Ven
  2006-11-09 23:56                   ` Thomas Gleixner
  0 siblings, 1 reply; 150+ messages in thread
From: Arjan van de Ven @ 2006-11-09 21:31 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Andrew Morton, Jesper Juhl, Linus Torvalds, Linux Kernel Mailing List


> What if the quality of the bug report is good and the submitter is 
> responsive, and there's still zero reaction?
> 
> Let's make an example:

> 
> Since the first list I sent immediately after 2.6.19-rc1 was released, 
> kernel Bugzilla #7255 is part of my list of 2.6.19-rc regressions but 
> has gotten exactly zero developer responses.

where was the lkml mail for this?

> 
> What exactly were the mistakes of the submitter resulting in noone 
> caring about Bugzilla #7255?

he didn't post to lkml?


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-09 21:31                 ` Arjan van de Ven
@ 2006-11-09 23:56                   ` Thomas Gleixner
  2006-11-10  0:18                     ` Andrew Morton
                                       ` (2 more replies)
  0 siblings, 3 replies; 150+ messages in thread
From: Thomas Gleixner @ 2006-11-09 23:56 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Adrian Bunk, Andrew Morton, Jesper Juhl, Linus Torvalds,
	Linux Kernel Mailing List

On Thu, 2006-11-09 at 22:31 +0100, Arjan van de Ven wrote:
> > Since the first list I sent immediately after 2.6.19-rc1 was released, 
> > kernel Bugzilla #7255 is part of my list of 2.6.19-rc regressions but 
> > has gotten exactly zero developer responses.
> 
> where was the lkml mail for this?
> 
> > 
> > What exactly were the mistakes of the submitter resulting in noone 
> > caring about Bugzilla #7255?
> 
> he didn't post to lkml?

That's no excuse, as Adrian pointed it out on LKML since weeks.

Also the kernel.org bugzilla has a real flaw:

There is no way to get informed of new entries automatically and
filtered by Category and Component. At least I did not find a way and
bugme-admin@osdl.org seems to be a black hole.

The result is that you have to go to bugzilla on a regular base instead
of getting automatic notifications of new entries. I do it once in a
while, but it is really ineffective.

	tglx



^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-09 23:56                   ` Thomas Gleixner
@ 2006-11-10  0:18                     ` Andrew Morton
  2006-11-10 17:45                     ` Stefan Richter
  2006-11-11 11:00                     ` Martin J. Bligh
  2 siblings, 0 replies; 150+ messages in thread
From: Andrew Morton @ 2006-11-10  0:18 UTC (permalink / raw)
  To: tglx
  Cc: Arjan van de Ven, Adrian Bunk, Jesper Juhl, Linus Torvalds,
	Linux Kernel Mailing List

On Fri, 10 Nov 2006 00:56:58 +0100
Thomas Gleixner <tglx@linutronix.de> wrote:

> On Thu, 2006-11-09 at 22:31 +0100, Arjan van de Ven wrote:
> > > Since the first list I sent immediately after 2.6.19-rc1 was released, 
> > > kernel Bugzilla #7255 is part of my list of 2.6.19-rc regressions but 
> > > has gotten exactly zero developer responses.
> > 
> > where was the lkml mail for this?
> > 
> > > 
> > > What exactly were the mistakes of the submitter resulting in noone 
> > > caring about Bugzilla #7255?
> > 
> > he didn't post to lkml?
> 
> That's no excuse, as Adrian pointed it out on LKML since weeks.
> 
> Also the kernel.org bugzilla has a real flaw:
> 
> There is no way to get informed of new entries automatically and
> filtered by Category and Component. At least I did not find a way and
> bugme-admin@osdl.org seems to be a black hole.
> 
> The result is that you have to go to bugzilla on a regular base instead
> of getting automatic notifications of new entries. I do it once in a
> while, but it is really ineffective.
> 

I screen all bugzilla reports and I ensure that any of them which look like
they're real and which have a breathing maintainer are brought to that
maintainer's attention.

So no, I think the number of bugs in bugzilla which the relevant maintainer
didn't hear about is vanishingly small.


^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-08 22:40   ` Jesper Juhl
  2006-11-08 23:05     ` Andreas Mohr
@ 2006-11-10 15:15     ` Pavel Machek
  2006-11-10 15:48     ` Horst H. von Brand
  2 siblings, 0 replies; 150+ messages in thread
From: Pavel Machek @ 2006-11-10 15:15 UTC (permalink / raw)
  To: Jesper Juhl
  Cc: Arjan van de Ven, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, Adrian Bunk

Hi!

> >but if you do this you just end up with a bigger 
> >backlog so that the
> >next one will even be more unstable due to a extreme 
> >high change rate.
> >
> Only if people continue to work on new stuff during the 
> "bug fixing only" cycle.
> If we manage to get everyone focused on bug fixing only 
> for the entire
> cycle the backlog won't be growing (much).

But neither you, nor andrew, nor linus has power to stop development
like that... (nor would it be good idea)

							Pavel
-- 
Thanks for all the (sleeping) penguins.

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version. 
  2006-11-08 22:40   ` Jesper Juhl
  2006-11-08 23:05     ` Andreas Mohr
  2006-11-10 15:15     ` Pavel Machek
@ 2006-11-10 15:48     ` Horst H. von Brand
  2006-11-15 21:04       ` Jesper Juhl
  2 siblings, 1 reply; 150+ messages in thread
From: Horst H. von Brand @ 2006-11-10 15:48 UTC (permalink / raw)
  To: Jesper Juhl
  Cc: Arjan van de Ven, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, Adrian Bunk

Jesper Juhl <jesper.juhl@gmail.com> wrote:
> On 08/11/06, Arjan van de Ven <arjan@infradead.org> wrote:
> > > There's no shortage of issues that need fixing, but since we keep
> > > merging new stuff, a lot of bugfixing energy gets spend on the new
> > > cool stuff instead of fixing up any other issues we have.
> >
> > but if you do this you just end up with a bigger backlog so that the
> > next one will even be more unstable due to a extreme high change rate.

> Only if people continue to work on new stuff during the "bug fixing only"
> cycle.  If we manage to get everyone focused on bug fixing only for the
> entire cycle the backlog won't be growing (much).

Sorry, won't work. People working on shiny new toys will just put off
sending in their patches for a cycle, and the usual bugfixers will likewise
just go on doing their stuff.

> > > Coverity has, as of this writing, identified 728 issues in the current
> > > kernel. Sure, some of those have already been identified as false or
> > > ignorable issues, but many are flagged as actual bugs and still more
> > > are as yet uninspected.

> > most are mostly false. And the rest is getting looked at. What's the
> > problem?

> Yes, MANY are false, and I know the rest are getting worked at, I work on
> some myself when time permits.  I mentioned it simply as an indicator
> (one amongst many) that we have a lot of known unfixed issues.

OK, lead by example: Do put off new work and work just on fixing things for
a while. Collect bug reports and make them useful for would-be-fixers. Etc.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-09 23:56                   ` Thomas Gleixner
  2006-11-10  0:18                     ` Andrew Morton
@ 2006-11-10 17:45                     ` Stefan Richter
  2006-11-11 11:00                     ` Martin J. Bligh
  2 siblings, 0 replies; 150+ messages in thread
From: Stefan Richter @ 2006-11-10 17:45 UTC (permalink / raw)
  To: tglx
  Cc: Arjan van de Ven, Adrian Bunk, Andrew Morton, Jesper Juhl,
	Linus Torvalds, Linux Kernel Mailing List

Thomas Gleixner wrote:
...
> Also the kernel.org bugzilla has a real flaw:
> 
> There is no way to get informed of new entries automatically and
> filtered by Category and Component.
...

There may be ways. I for one configured my bugzilla account to watch the
"user" drivers_ieee1394@kernel-bugs.osdl.org. That way I get notified of
bugs that are filed under category Drivers, component IEEE1394. Here is
a list of pseudo users or real users you could spy on:
http://bugzilla.kernel.org/describeallcomponents.cgi
-- 
Stefan Richter
-=====-=-==- =-== -=-=-
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-09 23:56                   ` Thomas Gleixner
  2006-11-10  0:18                     ` Andrew Morton
  2006-11-10 17:45                     ` Stefan Richter
@ 2006-11-11 11:00                     ` Martin J. Bligh
  2 siblings, 0 replies; 150+ messages in thread
From: Martin J. Bligh @ 2006-11-11 11:00 UTC (permalink / raw)
  To: tglx
  Cc: Arjan van de Ven, Adrian Bunk, Andrew Morton, Jesper Juhl,
	Linus Torvalds, Linux Kernel Mailing List


> That's no excuse, as Adrian pointed it out on LKML since weeks.
> 
> Also the kernel.org bugzilla has a real flaw:
> 
> There is no way to get informed of new entries automatically and
> filtered by Category and Component. At least I did not find a way and
> bugme-admin@osdl.org seems to be a black hole.

There is one list, bugme-new, that gets a copy of all bugs. The category
and component are broken out in headers simply so that you can filter it
yourself in whatever way you like.

Other than that, we can make each category owned by a "virtual user",
(many are already), and then multiple people can do an email watch on
that user.

bugme-admin alias should not be a black hole ... I get a copy of all
emails, as do a few other people. I don't recall seeing email from you
recently, but possibly a problem with spam filtering or something. If
you're having trouble, please send email directly to me if stuck.

M.

^ permalink raw reply	[flat|nested] 150+ messages in thread

* Re: A proposal; making 2.6.20 a bugfix only version.
  2006-11-10 15:48     ` Horst H. von Brand
@ 2006-11-15 21:04       ` Jesper Juhl
  0 siblings, 0 replies; 150+ messages in thread
From: Jesper Juhl @ 2006-11-15 21:04 UTC (permalink / raw)
  To: Horst H. von Brand
  Cc: Arjan van de Ven, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, Adrian Bunk

On 10/11/06, Horst H. von Brand <vonbrand@inf.utfsm.cl> wrote:
> Jesper Juhl <jesper.juhl@gmail.com> wrote:
> > On 08/11/06, Arjan van de Ven <arjan@infradead.org> wrote:
> > > > There's no shortage of issues that need fixing, but since we keep
> > > > merging new stuff, a lot of bugfixing energy gets spend on the new
> > > > cool stuff instead of fixing up any other issues we have.
> > >
> > > but if you do this you just end up with a bigger backlog so that the
> > > next one will even be more unstable due to a extreme high change rate.
>
> > Only if people continue to work on new stuff during the "bug fixing only"
> > cycle.  If we manage to get everyone focused on bug fixing only for the
> > entire cycle the backlog won't be growing (much).
>
> Sorry, won't work. People working on shiny new toys will just put off
> sending in their patches for a cycle, and the usual bugfixers will likewise
> just go on doing their stuff.
>
> > > > Coverity has, as of this writing, identified 728 issues in the current
> > > > kernel. Sure, some of those have already been identified as false or
> > > > ignorable issues, but many are flagged as actual bugs and still more
> > > > are as yet uninspected.
>
> > > most are mostly false. And the rest is getting looked at. What's the
> > > problem?
>
> > Yes, MANY are false, and I know the rest are getting worked at, I work on
> > some myself when time permits.  I mentioned it simply as an indicator
> > (one amongst many) that we have a lot of known unfixed issues.
>
> OK, lead by example: Do put off new work and work just on fixing things for
> a while. Collect bug reports and make them useful for would-be-fixers. Etc.

I try. Unfortunately I don't have nearly as much time as I would like,
to work on the kernel, but when I do have time I try to fix bugs. If
you look through the mailing list archives you will see that I try to
fix bugs/buglets most of the time and I find these by combing through
the coverity database, bugzilla, the mailing list, logs of test builds
of new kernels etc etc...
I don't maintain lists of unfixed bugs. I would love to do so, but I
lack the time to do it properly.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 150+ messages in thread

end of thread, other threads:[~2006-11-15 21:04 UTC | newest]

Thread overview: 150+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <jesper.juhl@gmail.com>
2005-08-24 19:08 ` [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c Jesper Juhl
2005-08-24 20:12   ` Brian Gerst
2005-08-24 20:14     ` Jeff Garzik
2005-08-24 20:31       ` Jesper Juhl
2005-08-24 20:39         ` Brian Gerst
2005-08-24 21:14           ` Jesper Juhl
2005-08-26 15:31             ` Horst von Brand
2005-08-24 21:06   ` Horst von Brand
2005-08-24 21:15     ` Jesper Juhl
2005-08-25  4:46     ` Paul Jackson
2005-08-25  5:00   ` Sam Ravnborg
2006-09-11 15:15 ` [PATCH] fix warning: no return statement in function returning non-void in kernel/audit.c Jesper Juhl
2006-09-11 16:03   ` Dave Jones
2006-09-11 19:22     ` Jesper Juhl
2006-09-11 20:23       ` Dave Jones
2006-09-11 22:56   ` Horst H. von Brand
2006-09-12  8:59     ` Jesper Juhl
2006-11-08 22:09 A proposal; making 2.6.20 a bugfix only version Jesper Juhl
2006-11-08 22:22 ` Arjan van de Ven
2006-11-08 22:40   ` Jesper Juhl
2006-11-08 23:05     ` Andreas Mohr
2006-11-08 23:54       ` Jan Engelhardt
2006-11-10 15:15     ` Pavel Machek
2006-11-10 15:48     ` Horst H. von Brand
2006-11-15 21:04       ` Jesper Juhl
2006-11-08 22:51   ` Andrew Morton
2006-11-09  9:26     ` Arjan van de Ven
2006-11-09  9:36       ` Andrew Morton
2006-11-09  9:52         ` Arjan van de Ven
2006-11-09 19:12           ` Andrew Morton
2006-11-09 19:21             ` Arjan van de Ven
2006-11-09 21:11               ` Adrian Bunk
2006-11-09 21:31                 ` Arjan van de Ven
2006-11-09 23:56                   ` Thomas Gleixner
2006-11-10  0:18                     ` Andrew Morton
2006-11-10 17:45                     ` Stefan Richter
2006-11-11 11:00                     ` Martin J. Bligh
2006-11-08 23:28   ` Diego Calleja
2006-11-09  6:48     ` Arjan van de Ven
2006-11-09 12:45       ` Rolf Eike Beer
  -- strict thread matches above, loose matches on Subject: below --
2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
2006-07-30 16:35 ` [PATCH 01/12] making the kernel -Wshadow clean - fix mconf Jesper Juhl
2006-07-30 18:34   ` Paul Jackson
2006-07-30 18:48     ` Jesper Juhl
2006-07-30 19:06       ` Andrew Morton
2006-07-30 19:17         ` Jesper Juhl
2006-07-30 19:51           ` Andrew Morton
2006-07-30 19:57             ` Arjan van de Ven
2006-07-30 20:03             ` Jesper Juhl
2006-07-30 19:32         ` Paul Jackson
2006-07-30 23:41       ` Arnd Bergmann
2006-07-31 15:41       ` Horst H. von Brand
2006-07-31 16:04         ` H. Peter Anvin
2006-07-30 16:36 ` [PATCH 02/12] making the kernel -Wshadow clean - fix lxdialog Jesper Juhl
2006-07-30 16:37 ` [PATCH 03/12] making the kernel -Wshadow clean - fix jiffies.h Jesper Juhl
2006-07-30 16:38 ` [PATCH 04/12] making the kernel -Wshadow clean - warnings related to 'up' Jesper Juhl
2006-07-30 16:38 ` [PATCH 05/12] making the kernel -Wshadow clean - warnings related to wbc and map_bh Jesper Juhl
2006-07-30 16:39 ` [PATCH 06/12] making the kernel -Wshadow clean - fix checksum Jesper Juhl
2006-07-30 16:40 ` [PATCH 07/12] making the kernel -Wshadow clean - fix vgacon Jesper Juhl
2006-07-30 16:41 ` [PATCH 08/12] making the kernel -Wshadow clean - fix keyboard.c Jesper Juhl
2006-07-30 16:42 ` [PATCH 09/12] making the kernel -Wshadow clean - neighbour.h and 'proc_handler' Jesper Juhl
2006-07-30 16:42 ` [PATCH 10/12] making the kernel -Wshadow clean - mm/truncate.c Jesper Juhl
2006-07-30 16:43 ` [PATCH 11/12] making the kernel -Wshadow clean - USB & completion Jesper Juhl
2006-07-30 16:44 ` [PATCH 12/12] making the kernel -Wshadow clean - 'irq' shadows local and global Jesper Juhl
2006-07-30 16:54 ` [PATCH 00/12] making the kernel -Wshadow clean - The initial step Krzysztof Halasa
2006-07-30 17:14   ` Jesper Juhl
2006-07-30 17:27     ` Krzysztof Halasa
2006-07-30 18:29       ` Andrew Morton
2006-07-30 23:36         ` Arnd Bergmann
2006-08-01  6:17       ` Jan Engelhardt
2006-07-30 19:24 ` Jesper Juhl
2006-07-30 20:09   ` Jan-Benedict Glaw
2006-07-30 19:29 ` Sam Ravnborg
2006-07-30 19:39   ` Jesper Juhl
2006-04-11  6:31 GPL issues Ramakanth Gunuganti
2006-04-11  8:42 ` Jesper Juhl
2006-04-11 10:51   ` Martin Mares
2006-04-11 17:46   ` Horst von Brand
2006-04-11 13:49 ` Kyle Moffett
2006-04-11 15:49   ` Ramakanth Gunuganti
2006-04-11 16:07     ` linux-os (Dick Johnson)
2006-04-11 16:29       ` Stefan Smietanowski
2006-04-11 16:13     ` Adrian Bunk
2006-04-11 16:15     ` Kyle Moffett
2006-04-11 16:23     ` Dave Neuer
2006-04-11 18:58     ` Jan Engelhardt
2006-04-14 11:39       ` David Schwartz
2006-04-14 14:54         ` linux-os (Dick Johnson)
2006-04-14 17:50         ` David Weinehall
2006-04-14 18:56           ` David Schwartz
2006-04-15 11:55             ` Alan Cox
2006-04-15 13:04               ` Steven Rostedt
2006-04-15 18:49               ` David Schwartz
2006-04-11 15:49   ` Ramakanth Gunuganti
2006-04-11 23:06 ` David Weinehall
2006-04-12  2:38   ` Joshua Hudson
2006-04-12  3:18     ` Mark Lord
2006-04-12  5:00       ` Kyle Moffett
2006-04-12  5:31       ` Arjan van de Ven
2006-04-12  5:45         ` jdow
2006-04-12  6:01           ` David Weinehall
2006-04-12  6:26             ` jdow
2006-04-12  9:13             ` Stefan Smietanowski
2006-04-12 11:33               ` Olivier Galibert
2006-04-12 14:51           ` Arjan van de Ven
2006-04-13 22:07             ` Mark Lord
2006-04-15 11:14               ` Arjan van de Ven
2006-04-13 22:17         ` Mark Lord
2006-04-15 11:15           ` Arjan van de Ven
2006-04-11 23:12 ` Alan Cox
2005-09-04 10:12 [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver Harald Welte
2005-09-03 21:27 ` Chase Venters
2005-09-03 22:13   ` Nish Aravamudan
2005-09-03 22:23     ` Chase Venters
2005-09-04  7:33     ` Harald Welte
2005-09-04 11:20   ` Harald Welte
2005-09-06 16:15     ` Roland Dreier
2005-09-06 17:11       ` Harald Welte
2005-09-03 21:56 ` Alexey Dobriyan
2005-09-04  7:10   ` Harald Welte
2005-09-04 11:08 ` Harald Welte
2005-09-03 22:27   ` Jesper Juhl
2005-09-04 21:06     ` Horst von Brand
2005-09-04 22:10       ` Jesper Juhl
2005-09-05 10:30     ` Harald Welte
2005-09-04 12:58 ` Ingo Oeser
2005-09-05  9:14   ` Harald Welte
2005-07-11 14:56 kernel guide to space Michael S. Tsirkin
2005-07-11 15:34 ` Sander
2005-07-12  6:52   ` Denis Vlasenko
2005-07-12 11:55     ` Patrick McHardy
2005-07-12 12:17       ` Richard B. Johnson
2005-07-13  6:58         ` Paul Jackson
2005-07-13 17:22           ` Lee Revell
2005-07-13 17:52             ` Paul Jackson
2005-07-13 23:38             ` Marc Singer
2005-07-11 15:44 ` Dmitry Torokhov
2005-07-11 17:19   ` Ingo Oeser
2005-07-12  7:12 ` Denis Vlasenko
2005-07-12 11:36   ` Domen Puncer
2005-07-13  7:09 ` Paul Jackson
2005-07-20 12:59 ` Jesper Juhl
2005-07-20 13:07   ` Michael S. Tsirkin
2005-07-20 21:05   ` Paul Jackson
2005-07-20 22:37   ` Krzysztof Halasa
2005-07-22 17:12     ` Patrick Draper
2005-07-22 17:51       ` Jesper Juhl
2005-07-22 19:21       ` Sam Ravnborg
2005-07-22 20:28         ` Jesper Juhl
2005-07-21  0:20   ` Horst von Brand

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).