GPLONLY kernel symbols???
I just tried to load the loop driver in 2.4.11
devel:/home/christoph/devel/bf/boot-floppies# insmod loop Using /lib/modules/2.4.11/kernel/drivers/block/loop.o /lib/modules/2.4.11/kernel/drivers/block/loop.o: unresolved symbol invalidate_bdev /lib/modules/2.4.11/kernel/drivers/block/loop.o: Note: modules without a GPL compatible license cannot use GPLONLY_ symbols
What is THAT?
Quoted 4 lines · Christoph Lameter
/lib/modules/2.4.11/kernel/drivers/block/loop.o: Note: modules without a GPL compatible license cannot useGPLONLY_symbolsWhat is THAT?
A symbol that may only be referenced by GPL code.
The solution here is to add MODULE_LICENSE("GPL") into loop.c (probably) or upgrade (assuming it's fixed later).
regards
john
p.s. upgrade anyway, 2.4.11 is a bad idea ...
Signature · 2 lines
"I hear you have four hundred and eighty six PCs for sale ?" - Some Fool
Quoted 11 lines · John Levon
Quoted 4 lines · Christoph Lameter
/lib/modules/2.4.11/kernel/drivers/block/loop.o: Note: modules without a GPL compatible license cannot useGPLONLY_symbolsWhat is THAT?
A symbol that may only be referenced by GPL code.
The solution here is to add
MODULE_LICENSE("GPL")intoloop.c(probably) or upgrade (assuming it's fixed later).
invalidate_bdev() is _not_ GPL-only. Never had been, never will.
Quoted 10 lines · Christoph Lameter
I just tried to load the loop driver in 2.4.11
devel:/home/christoph/devel/bf/boot-floppies# insmod loop Using /lib/modules/2.4.11/kernel/drivers/block/loop.o /lib/modules/2.4.11/kernel/drivers/block/loop.o: unresolved symbol invalidate_bdev /lib/modules/2.4.11/kernel/drivers/block/loop.o: Note: modules without a GPL compatible license cannot use GPLONLY_ symbolsWhat is THAT?
If a symbol has been exported with EXPORT_SYMBOL_GPL then it appears as unresolved for modules that do not have a GPL compatible MODULE_LICENCE string. So when a module without a GPL compatible MODULE_LICENCE gets an unresolved symbol, I print that message as a hint to the user. I thought the response was obvious, but looks like I need to expand the hint text even further.
Note: modules without a GPL compatible license cannot use GPLONLY_ symbols.
This may or may not be your problem, there can be other reasons for unresolved symbols.
The loop driver is not GPL compatible???
Quoted 25 lines · Keith Owens
Quoted 10 lines · Christoph Lameter
I just tried to load the loop driver in 2.4.11
devel:/home/christoph/devel/bf/boot-floppies# insmod loop Using /lib/modules/2.4.11/kernel/drivers/block/loop.o /lib/modules/2.4.11/kernel/drivers/block/loop.o: unresolved symbol invalidate_bdev /lib/modules/2.4.11/kernel/drivers/block/loop.o: Note: modules without a GPL compatible license cannot use GPLONLY_ symbolsWhat is THAT?
If a symbol has been exported with
EXPORT_SYMBOL_GPLthen it appears as unresolved for modules that do not have a GPL compatibleMODULE_LICENCEstring. So when a module without a GPL compatibleMODULE_LICENCEgets an unresolved symbol, I print that message as a hint to the user. I thought the response was obvious, but looks like I need to expand the hint text even further.Note: modules without a GPL compatible license cannot use
GPLONLY_symbols.
This may or may not be your problem, there can be other reasons for unresolved symbols.
Quoted 1 line · Christoph Lameter
The loop driver is not GPL compatible???
In 2.4.11 loop.c has no MODULE_LICENCE. It will take a while for all modules to be correctly flagged.
Quoted 6 lines · Keith Owens
Quoted 1 line · Christoph Lameter
The loop driver is not GPL compatible???
In 2.4.11
loop.chas noMODULE_LICENCE. It will take a while for all modules to be correctly flagged.
Then do not output such a message. This is not M$ windows.
Quoted 11 lines · Christoph Lameter
Quoted 6 lines · Keith Owens
Quoted 1 line · Christoph Lameter
The loop driver is not GPL compatible???
In 2.4.11
loop.chas noMODULE_LICENCE. It will take a while for all modules to be correctly flagged.Then do not output such a message. This is not M$ windows.
And how do you expect them to find all of the modules that don't have MODULE_LICENCE if they can't see an indicator in the boot messages?
Gerhard
--
Gerhard Mack
<>< As a computer I find your faith in technology amusing.
Quoted 6 lines · Gerhard Mack
Quoted 3 lines
Then do not output such a message. This is not
M$ windows.And how do you expect them to find all of the
modules that don't haveMODULE_LICENCEif they
can't see an indicator in the boot messages?
The kernel doesn't actually do anything with the "tainted" flag, insmod does. So you have to compile things as module and insmod them, and insmod will dump a message if the MODULE_LICENSE thing isn't in the module. If you compile things inside the kernel instead of modules, you will see nothing and /proc/sys/kernel/tainted will contain 0, which is wrong.
--------------------------------------
Pierre-Philippe Coupard
Senior Software Engineer, Lineo, Inc.
(801) 426-5001 x 208
--------------------------------------
Quoted 6 lines · Pierre-Philippe Coupard
The kernel doesn't actually do anything with the "tainted" flag, insmod does. So you have to compile things as module and insmod them, and insmod will dump a message if the
MODULE_LICENSEthing isn't in the module. If you compile things inside the kernel instead of modules, you will see nothing and/proc/sys/kernel/taintedwill contain 0, which is wrong.
I think the idea is that if you compile something inside the kernel, you have the source, so at least from the debugging point of view, the kernel has not been tainted by a binary-only module.
It seems like people (collectively) have two different purposes in mind for /proc/sys/kernel/tainted: ensuring that only "open source" modules are used, for debugging purposes, and ensuring that only "GPL-compatible" modules are used, for possible legal purposes. If both of these are desirable, perhaps the two purposes should be separated into two /proc files?
Cheers, Wayne
Quoted 9 lines · Gerhard Mack
Quoted 6 lines · Christoph Lameter
Quoted 4 lines · Keith Owens
Quoted 1 line · Christoph Lameter
The loop driver is not GPL compatible???
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
In 2.4.11
loop.chas noMODULE_LICENCE. It will take a while for all modules to be correctly flagged.Then do not output such a message. This is not M$ windows.
And how do you expect them to find all of the modules that don't have
MODULE_LICENCEif they can't see an indicator in the boot messages?
Can't you just make it a warning for now and give ppl a few months to clean things up? It strikes me that any code that serves no technical purpose and actively decreases functionality of the kernel is highly suspect. Or maybe even wait till 2.5...
Ben
Quoted 14 lines
Gerhard
--
Gerhard Mack<>< As a computer I find your faith in technology amusing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 3 lines
Ben Greear <[email protected]> <Ben_Greear AT excite.com> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
Quoted 5 lines · Wayne Whitney
I think the idea is that if you compile something inside the kernel, you have the source, so at least from the debugging point of view, the kernel has not been tainted by a binary-only module.
I can make a kernel driver that compiles statically and also uses a non-GPL library, even in the form of a binary .o file, and the "tainted" mechanism as it is today will miss it entirely.
Quoted 8 lines
It seems like people (collectively) have two different purposes in mind for
/proc/sys/kernel/tainted: ensuring that only "open source" modules are used, for debugging purposes, and ensuring that only "GPL-compatible" modules are used, for possible legal purposes. If both of these are desirable, perhaps the two purposes should be separated into two /proc files?
The real question is whether or not the kernel code should be encumbered with legal issues. The fact that this or that piece of code is or isn't GPL should be in a text file attached to the kernel tarball. This sort of thing has no place in the code : countless patches with useful code that should live in userland have been (rightfully) rejected as having no place inside the kernel, why should code that deals with legal issues and is pretty much dead weight from a technical standpoint be allowed in ?
////\
(@ @)------------oOOo-(_)-oOOo-------------
Pierre-Philippe Coupard
Senior Software Engineer, Lineo, Inc.
(801) 426-5001 x 208
--------------------------------------
Quoted 12 lines
The real question is whether or not the kernel code should be encumbered with legal issues. The fact that this or that piece of code is or isn't GPL should be in a text file attached to the kernel tarball. This sort of thing has no place in the code : countless patches with useful code that should live in userland have been (rightfully) rejected as having no place inside the kernel, why should code that deals with legal issues and is pretty much dead weight from a technical standpoint be allowed in ?
It's not legal issues. It's 1 integer and 1 sysctl variable that allow easy filtering of nvidia and other bugreports. THAT is the purpose of "tainted". Show in the oops that binary only modules are used. (this assumes all gpl modules to have a MODULE_LICENSE() line which doesn't result in code and isn't loaded into kernel memory; recent kernels have over 99% coverage for in-kernel drivers and lots of external drivers have it as well).
but there is a difference between a 'binary only' module and a 'GPL module'
the current process mixes the two up.
David Lang
Quoted 32 lines · Arjan van de Ven
Date: Wed, 17 Oct 2001 21:32:25 +0100
From: Arjan van de Ven <[email protected]>
To: [email protected], [email protected]
Subject: Re: GPLONLY kernel symbols???Quoted 11 lines
The real question is whether or not the kernel code should be encumbered with legal issues. The fact that this or that piece of code is or isn't GPL should be in a text file attached to the kernel tarball. This sort of thing has no place in the code : countless patches with useful code that should live in userland have been (rightfully) rejected as having no place inside the kernel, why should code that deals with legal issues and is pretty much dead weight from a technical standpoint be allowed in ?
It's not legal issues. It's 1 integer and 1 sysctl variable that allow easy filtering of nvidia and other bugreports.
THAT is the purpose of "tainted". Show in the oops that
binary only modules are used. (this assumes all gpl modules to have aMODULE_LICENSE()line which doesn't result in code
and isn't loaded into kernel memory; recent kernels have over 99% coverage for in-kernel drivers and lots of external drivers have it as well).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines · David Lang
but there is a difference between a 'binary only' module and a 'GPL module'
the current process mixes the two up.
Not really
There is a list of "known not binary only" in modutils...
Quoted 9 lines · Arjan van de Ven
Quoted 4 lines · David Lang
but there is a difference between a 'binary only' module and a 'GPL module'
the current process mixes the two up.
Not really
There is a list of "known not binary only" in modutils...
and the problem of the BSD licence, it may or may not be a binary only module, knowing the license doesn't tell you.
David Lang
Quoted 2 lines · Arjan van de Ven
It's not legal issues.
Of course it is, this is code that deals with whether or not the kernel has loaded something that's not covered under the GPL license.
Quoted 4 lines
It's 1 integer and 1 sysctl variable that allow easy filtering of nvidia and other bugreports. THAT is the purpose of "tainted". Show in the oops that binary only modules are used.
Then that's the wrong purpose : instead, oops posters should be made aware that they should post the list of loaded modules as well. If you really insist on having the kernel deal with this, make the kernel print the list of modules as well as the oops.
(this assumes all gpl modules to have a MODULE_LICENSE() line which doesn't result in code and isn't loaded into kernel memory;
Yes it is : what about the code that allows me to cat /proc/sys/kernel/tainted and echo an integer into it ? and the code that's not loaded into kernel memory sure takes storage space, even if it's not much.
But that's not the point : the point is, the kernel should contain as much non-kernel junk as possible. Kernel code, even a small amount of it, that deals with licensing is junk code. It's silly enough to have "sponsored by" strings in the kernel as it is.
////\
(@ @)------------oOOo-(_)-oOOo-------------
Pierre-Philippe Coupard
Senior Software Engineer, Lineo, Inc.
(801) 426-5001 x 208
--------------------------------------
There are many intelligent species in the universe, and they all own cats.
Quoted 5 lines
Yes it is : what about the code that allows me to cat
/proc/sys/kernel/taintedand echo an integer into it ? and the code that's not loaded into kernel memory sure takes storage space, even if it's not much.
That code is generic code already in the kernel for every other /proc file. The total impact in bytes is shorter than the email.
If you want to save space fix the page table mess and we can shave off something like 8-16 bytes per page - Ie megabytes.
* [email protected] <[email protected]> on Wed, Oct 17, 2001:
Quoted 6 lines
I can make a kernel driver that compiles statically and also uses a non-GPL library, even in the form of a binary .o file, and the "tainted" mechanism as it is today will miss it entirely.
Statically into the kernel? I don't think so. First off, if your "static" code isn't GPL'd you can't distribute the resultant kernel since you've violated the GPL. The tainted mechanism was designed for proprietary and/or binary-only modules without a supported license. The case you mention above can't even exist (at least, not in any publically-accessible code).
M. R.
* [email protected] <[email protected]> on Wed, Oct 17, 2001:
Quoted 7 lines
Quoted 2 lines
It's not legal issues.
Of course it is, this is code that deals with whether or not the kernel has loaded something that's not covered under the GPL license.
No, it isn't, the fact that a module is GPL'd or BSD'd means that the source is available, which means that any available kernel hacker can debug it. Proprietary/binary-only modules won't have such a license, the source isn't accessible, and can't be debugged by the general hacking community.
You've been reading waaaay too much into this.
Quoted 8 lines
Then that's the wrong purpose : instead, oops posters should be made aware that they should post the list of loaded modules as well. If you really insist on having the kernel deal with this, make the kernel print the list of modules as well as the oops.
Obviously that's not enough if the tainted mechanism is needed to "dismiss" those posts. And how does printing the use of active modules help determine which modules are supported and which aren't? You'd still need to label those modules as being proprietary and such, so you still end up with the tainted mechanism.
Quoted 7 lines
Yes it is : what about the code that allows me to cat
/proc/sys/kernel/taintedand echo an integer into it ? and the code that's not loaded into kernel memory sure takes storage space, even if it's not much.
What the hell are you talking about?
Quoted 6 lines
But that's not the point : the point is, the kernel should contain as much non-kernel junk as possible. Kernel code, even a small amount of it, that deals with licensing is junk code. It's silly enough to have "sponsored by" strings in the kernel as it is.
Two things. Bitching about code that you don't agree with without providing a suitable alternative won't really get you anywhere. The tainted inteface is needed to sway or halt the onslaught of bug reports for unsupported modules. You do realize that the kernel community can't support modules without source? Also, it's up to the copyright holder of a piece of code what strings are in their code, as long as it's accepted by whomever who cares if it contains "I'd like to give a shout out...".
M. R.
Quoted 6 lines · Keith Owens
If a symbol has been exported with
EXPORT_SYMBOL_GPLthen it appears as unresolved for modules that do not have a GPL compatibleMODULE_LICENCEstring. So when a module without a GPL compatibleMODULE_LICENCEgets an unresolved symbol, I print that message as a hint to the user. I thought the response was obvious, but looks like I need to expand the hint text even further.
How is the name mangled in the _GPL case ? Can't this be detected explicitly ?
richard, since ac seems OK with it ...
thanks
john
faqnew.html renamed from faq.html +35 -0
@@ -513,6 +513,10 @@ and Alan Cox's -ac series of patches?</A> </LI> +<LI> +<A HREF="#s1-22">What does it mean for a module to be tainted ?</A> +</LI> + </OL> <H4>
@@ -1794,6 +1798,37 @@ </UL> +<LI> +<A NAME="s1-22"></A><B>What does it mean for a module to be tainted?</B> +</LI> + +<UL> +<LI> +Some vendors distribute binary modules (i.e. modules without available +source code under a free software license). +As the source is not freely available, any bugs uncovered whilst such +modules are loaded cannot be investigated by the kernel hackers. All +problems discovered whilst such a module is loaded must be reported +to the vendor of that module, <I>not</I> the Linux kernel hackers and +the linux-kernel mailing list. The tainting scheme is used to identify +bug reports from kernels with binary modules loaded: such kernels are +marked as "tainted" by means of the <TT>MODULE_LICENSE</TT> tag. If a +module is loaded that does not specify an approved license, the kernel +is marked as tainted. The canonical list of approved license strings +is in <TT>linux/include/module.h</TT>.<BR> +"oops" reports marked as tainted are of no use to the kernel developers +and will be ignored. A warning is output when such a module is loaded. +Note that you may come across module source that is under a compatible +license, but does not have a suitable <TT>MODULE_LICENSE</TT> tag. If you +see a warning from <TT>modprobe</TT> or <TT>insmod</TT> for a module +under a compatible license, please report this bug to the maintainers of +the module, so that they can add the necessary tag. +<P><FONT COLOR="#0000FF">(KO)</FONT> If a symbol has been exported with +EXPORT_SYMBOL_GPL then it appears as unresolved for modules that do not +have a GPL compatible MODULE_LICENSE string, and prints a warning. +</LI> +</UL> + </OL> <H2>
Signature · 3 lines
"There are two kinds of fool. One says, 'This is old, and therefore good.' And one says, 'This is new, and therefore better'." - John Brunner
Quoted 9 lines · John Levon
Quoted 6 lines · Keith Owens
If a symbol has been exported with
EXPORT_SYMBOL_GPLthen it appears as unresolved for modules that do not have a GPL compatibleMODULE_LICENCEstring. So when a module without a GPL compatibleMODULE_LICENCEgets an unresolved symbol, I print that message as a hint to the user. I thought the response was obvious, but looks like I need to expand the hint text even further.
Quoted 3 lines
How is the name mangled in the
_GPLcase ? Can't this be detected explicitly ?richard, since ac seems OK with it ...
OK, I've applied your patch. Let's hope lusers don't start editing out the "tainted" string when emailing Oops reports.
BTW: I had to edit after applying your patch: it didn't conform to the Style[tm].
Regards, Richard.... Permanent: [email protected] Current: [email protected]
Quoted 2 lines · Richard Gooch
BTW: I had to edit after applying your patch: it didn't conform to the Style[tm].
How about running mtrr.c & devfs code through scripts/Lindent sometime btw?
regards,
Dave.
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 7 lines · Dave Jones
Quoted 2 lines · Richard Gooch
BTW: I had to edit after applying your patch: it didn't conform to the Style[tm].
How about running
mtrr.c& devfs code throughscripts/Lindentsometime btw?
That would be a step backwards: I wouldn't be able to read my own code then.
Regards, Richard.... Permanent: [email protected] Current: [email protected]
Quoted 6 lines · Richard Gooch
Quoted 2 lines · Dave Jones
How about running
mtrr.c& devfs code throughscripts/Lindentsometime btw?That would be a step backwards: I wouldn't be able to read my own code then.
You mean that you are unable to read any of the core kernel source? That would explain a lot...
Quoted 5 lines · Alexander Viro
Quoted 1 line · Richard Gooch
Dave Jones writes:
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
How about running
mtrr.c& devfs code throughscripts/Lindentsometime btw?That would be a step backwards: I wouldn't be able to read my own code then.
You mean that you are unable to read any of the core kernel source? That would explain a lot...
Were you born rude, or did you have to practice it?
Regards, Richard.... Permanent: [email protected] Current: [email protected]
Quoted 6 lines · Richard Gooch
Quoted 5 lines · Alexander Viro
Quoted 4 lines · Richard Gooch
Quoted 2 lines · Dave Jones
How about running
mtrr.c& devfs code throughscripts/Lindentsometime btw?
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
That would be a step backwards: I wouldn't be able to read my own code then.
You mean that you are unable to read any of the core kernel source? That would explain a lot...
Were you born rude, or did you have to practice it?
Excuse me? You've just stated that you are unable to read the code in style enforced by Lindent. kernel/*.c, mm/*.c, fs/*.c and large part of fs/*/*.c _are_ in that style. I've asked you a perfectly legitimate (and obvious) question: "does it imply what it seems to imply?" What's rude about that?
Quoted 13 lines · Alexander Viro
Quoted 12 lines · Richard Gooch
Quoted 10 lines · Alexander Viro
Quoted 6 lines · Richard Gooch
Quoted 2 lines · Dave Jones
How about running
mtrr.c& devfs code throughscripts/Lindentsometime btw?That would be a step backwards: I wouldn't be able to read my own code then.
You mean that you are unable to read any of the core kernel source? That would explain a lot...
Quoted 7 lines
Quoted 1 line
Were you born rude, or did you have to practice it?
Excuse me? You've just stated that you are unable to read the code in style enforced by Lindent.
kernel/*.c,mm/*.c,fs/*.cand large part offs/*/*.c_are_ in that style. I've asked you a perfectly legitimate (and obvious) question: "does it imply what it seems to imply?" What's rude about that?
Are you being deliberately obtuse? Your "that would explain a lot" comment is an obvious insult.
Al, I'm really tired of your snide comments. You've been hostile and making personal attacks for years now. You've been rude and insulting to other people on this list as well. Even if you don't care how childish it appears, just save us all the bandwidth. We don't want to play that game with you.
And I don't care to discuss this further. I know what your two possible reactions are:
- you're not being rude (uh, yeah, right)
- it doesn't matter as long as your technical points are correct (I'm just quoting you there) (BTW: you're not infallible either).
Regards, Richard.... Permanent: [email protected] Current: [email protected]
Quoted 2 lines · Richard Gooch
Are you being deliberately obtuse? Your "that would explain a lot" comment is an obvious insult.
I'm absolutely serious and yes, by now I consider the possibility that you _really_ don't bother to read the core kernel code as very probable. Style incompatibilities give a very plausible explanation - I certainly can understand why somebody used to common kernel style can have trouble reading code in your style and vice versa.
The question still stands, BTW - should your "...I would be unable to read..." be taken seriously?
Quoted 4 lines · Alexander Viro
On Mon, 12 Nov 2001, Richard Gooch wrote:
Quoted 8 lines
Quoted 2 lines
Are you being deliberately obtuse? Your "that would explain a lot" comment is an obvious insult.
I'm absolutely serious and yes, by now I consider the possibility that you _really_ don't bother to read the core kernel code as very probable. Style incompatibilities give a very plausible explanation
- I certainly can understand why somebody used to common kernel style can have trouble reading code in your style and vice versa.
[I'm going to pretend you don't wish to be rude]
Quoted 2 lines
The question still stands, BTW - should your "...I would be unable to read..." be taken seriously?
I should have put a smiley face there. Obviously, "unable to read" isn't literally true, otherwise I wouldn't have been able to write devfs in the first place (or Documentation/filesystems/vfs.txt, for that matter), since I wouldn't have been able to read the kernel sources. I do find the coding style unpleasant, though.
So, I *do* read core kernel code, and can understand it, despite the appalling coding style.
Hopefully this answers your serious questions, and the matter can be put at rest.
Regards, Richard.... Permanent: [email protected] Current: [email protected]
Hi
Quoted 4 lines · Richard Gooch
Quoted 2 lines
You mean that you are unable to read any of the core kernel source? That would explain a lot...
Were you born rude, or did you have to practice it?
I'd rather say, it's rude to ignore common practice, when contributing to a project. Linux already has quite loose rules and abusing them isn't the best style. It would be some good practice for you to get used to working in a team.
bye, Roman
Quoted 17 lines · Richard Gooch
Quoted 15 lines · Alexander Viro
Quoted 13 lines · Richard Gooch
Quoted 10 lines · Alexander Viro
Quoted 6 lines · Richard Gooch
Quoted 2 lines · Dave Jones
How about running
mtrr.c& devfs code throughscripts/Lindentsometime btw?That would be a step backwards: I wouldn't be able to read my own code then.
You mean that you are unable to read any of the core kernel source? That would explain a lot...
Were you born rude, or did you have to practice it?
Quoted 8 lines
Quoted 5 lines
Excuse me? You've just stated that you are unable to read the code in style enforced by Lindent.
kernel/*.c,mm/*.c,fs/*.cand large part offs/*/*.c_are_ in that style. I've asked you a perfectly legitimate (and obvious) question: "does it imply what it seems to imply?" What's rude about that?Are you being deliberately obtuse? Your "that would explain a lot" comment is an obvious insult.
The insult is adequate to the coding style in question. And they are right: multi statement lines and such is really crap.
Quoted 5 lines
Al, I'm really tired of your snide comments. You've been hostile and making personal attacks for years now. You've been rude and insulting to other people on this list as well. Even if you don't care how childish it appears, just save us all the bandwidth. We don't want to play that game with you.
Speak for yourself. I enyoj the comments for one.
Quoted 5 lines
And I don't care to discuss this further. I know what your two possible reactions are:
- you're not being rude (uh, yeah, right)
- it doesn't matter as long as your technical points are correct (I'm just quoting you there) (BTW: you're not infallible either).
Just the frequency is somehow lower...
Quoted 5 lines · Richard Gooch
Quoted 4 lines · Alexander Viro
Quoted 3 lines · Richard Gooch
Quoted 2 lines · Dave Jones
How about running
mtrr.c& devfs code throughscripts/Lindentsometime btw?
Go ahead and Lindent mtrr.c, it hasn't been touched by rgooch in a while...
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
That would be a step backwards: I wouldn't be able to read my own code then.
You mean that you are unable to read any of the core kernel source? That would explain a lot...
Were you born rude, or did you have to practice it?
I would argue both ;-) He is a Usenet denizen after all. (takes one to know one... I'm one as well :))
He and davej still have a point. Your code formatting is non-standard, and is difficult to read. A document exists CodingStyle which explains a good style, and further -why- it is a good style.
Among other reasons, because of long term maintenance.
How do you expect others in the Linux kernel community to review your code, if it is widely considered difficult to read? How do you expect people to maintain your code when are no longer around? The Linux kernel will be around long after you and I and others leave kernel development. Others need to read and maintain this code.
Jeff
Signature · 3 lines
Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and one tongue. MandrakeSoft | - nomeansno
Quoted 9 lines · Jeff Garzik
Quoted 5 lines · Richard Gooch
Quoted 4 lines · Alexander Viro
Quoted 3 lines · Richard Gooch
Quoted 2 lines · Dave Jones
How about running
mtrr.c& devfs code throughscripts/Lindentsometime btw?Go ahead and Lindent
mtrr.c, it hasn't been touched by rgooch in a while...
Hey!
Quoted 10 lines
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
That would be a step backwards: I wouldn't be able to read my own code then.
You mean that you are unable to read any of the core kernel source? That would explain a lot...
Were you born rude, or did you have to practice it?
I would argue both ;-) He is a Usenet denizen after all. (takes one to know one... I'm one as well :))
I gave up Usenet years ago, about when the signal to noise ratio fell under 0.1% and I got tired of wasting time wading through the flames.
Now, on to your points about coding style. I'll say this once only. I don't want to waste time with an argument about this.
Quoted 4 lines
He and davej still have a point. Your code formatting is non-standard, and is difficult to read. A document exists CodingStyle which explains a good style, and further -why- it is a good style.
And one of the very first things that document says that coding style is very personal and he doesn't want to force his views on others. So, as a symbolic gesture, I printed out and burned that document.
Quoted 7 lines
Among other reasons, because of long term maintenance.
How do you expect others in the Linux kernel community to review your code, if it is widely considered difficult to read? How do you expect people to maintain your code when are no longer around? The Linux kernel will be around long after you and I and others leave kernel development. Others need to read and maintain this code.
If and when I step down as maintainer (if I do so, I'll publically pass the baton to the new maintainer), the new maintainer can indent to their preference. Until that time, *I'm* the maintainer, and *I* need to be able to read the code efficiently. It's the part of the kernel I spend the most time in, after all.
And the coding style used elsewhere in the kernel is revolting to me. More importantly, it's harder for me to parse than my own style. I shouldn't have to constantly stumble over an appalling coding style in my own code!
"He who writes the code gets to choose".
Regards, Richard.... Permanent: [email protected] Current: [email protected]
Quoted 2 lines · Richard Gooch
And the coding style used elsewhere in the kernel is revolting to me. More importantly, it's harder for me to parse than my own style.
And you consider my comment as a personal attack? Wow.
Quoted 2 lines
I shouldn't have to constantly stumble over an appalling coding style in my own code!
No, you shouldn't. For those of us who have similar problems with reviewing your code patch (later - CVS or RCS) will appear on ftp.math.psu.edu/pub/viro/ tommorrow. End of story.
Quoted 6 lines · Alexander Viro
Quoted 2 lines · Richard Gooch
And the coding style used elsewhere in the kernel is revolting to me. More importantly, it's harder for me to parse than my own style.
And you consider my comment as a personal attack? Wow.
It fits a pattern.
Quoted 6 lines
Quoted 2 lines
I shouldn't have to constantly stumble over an appalling coding style in my own code!
No, you shouldn't. For those of us who have similar problems with reviewing your code patch (later - CVS or RCS) will appear on ftp.math.psu.edu/pub/viro/ tommorrow. End of story.
So is this the hostile takeover you've mentioned? Even though I'm addressing the devfs races you've complained about so often, and have been releasing these patches, you still wish to pursue this hostile action?
Regards, Richard.... Permanent: [email protected] Current: [email protected]
Quoted 9 lines · Richard Gooch
Quoted 3 lines · Alexander Viro
No, you shouldn't. For those of us who have similar problems with reviewing your code patch (later - CVS or RCS) will appear on ftp.math.psu.edu/pub/viro/ tommorrow. End of story.
So is this the hostile takeover you've mentioned? Even though I'm addressing the devfs races you've complained about so often, and have been releasing these patches, you still wish to pursue this hostile action?
Oh, for crying out loud! You've very eloquently described the problems with reading code in alien style. You have said that you were tired with other folks complaining about coding style of devfs. I replied telling these people where to look for a version that will be in standard kernel style, so that they could get off your back. What's your problem with _that_, for fsck sake?
Quoted 14 lines · Alexander Viro
Quoted 9 lines · Richard Gooch
Quoted 3 lines · Alexander Viro
No, you shouldn't. For those of us who have similar problems with reviewing your code patch (later - CVS or RCS) will appear on ftp.math.psu.edu/pub/viro/ tommorrow. End of story.
So is this the hostile takeover you've mentioned? Even though I'm addressing the devfs races you've complained about so often, and have been releasing these patches, you still wish to pursue this hostile action?
Quoted 6 lines
Oh, for crying out loud! You've very eloquently described the problems with reading code in alien style. You have said that you were tired with other folks complaining about coding style of devfs. I replied telling these people where to look for a version that will be in standard kernel style, so that they could get off your back. What's your problem with _that_, for fsck sake?
Nothing at all, now that you've explained it. If all you want to do is present the code I write in a form that's more convenient for others to read, I think that's great.
I thought it might be the "hostile takeover" that you mentioned last week, along with putting up a CVS tree. If that's not your intention, that's fine. That's why I asked "is this the hostile takeover you've mentioned", because I wasn't sure.
In fact, given the other code in the tree that doesn't conform to CodingStyle, it makes sense run lindent on the whole tree and make that available. As long as people understand that they should generate patches against the real tree, and not the lindented one.
Regards, Richard.... Permanent: [email protected] Current: [email protected]
Quoted 4 lines · Richard Gooch
In fact, given the other code in the tree that doesn't conform to CodingStyle, it makes sense run lindent on the whole tree and make that available. As long as people understand that they should generate patches against the real tree, and not the lindented one.
We are slowly Lindenting the -real- tree, actually. So, no, that doesn't make sense. See my mention of long-term maintainability earlier...
WRT to other code, devfs is indeed being picked on, because devfs -clearly- needs other eyes, and devfs is so far from current CodingStyle.
Readability of devfs is IMHO far more important than the readability of drivers/scsi/random_isa_driver.c.
Signature · 3 lines
Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and one tongue. MandrakeSoft | - nomeansno
Quoted 3 lines · Richard Gooch
And one of the very first things that document says that coding style is very personal and he doesn't want to force his views on others. So, as a symbolic gesture, I printed out and burned that document.
Richard, I fully agree with you that coding style is very personal and everyone is trying to prove that one style is better than onther one is very likely dumb.
Nevertheless you've to agree that having a common coding style inside a project "helps" lesser the fatigue the brain has to sustain to "parse" the code.
Even if my "native" coding style is slight different from the lk I'm very happy to work on a project that has a common style, don't you agree ?
- Davide
Quoted 6 lines · Davide Libenzi
Quoted 3 lines · Richard Gooch
And one of the very first things that document says that coding style is very personal and he doesn't want to force his views on others. So, as a symbolic gesture, I printed out and burned that document.
Quoted 8 lines
Richard, I fully agree with you that coding style is very personal and everyone is trying to prove that one style is better than onther one is very likely dumb.
Nevertheless you've to agree that having a common coding style inside a project "helps" lesser the fatigue the brain has to sustain to "parse" the code.
Even if my "native" coding style is slight different from the lk I'm very happy to work on a project that has a common style, don't you agree ?
The best programmer I ever knew told me that if you couldn't fake and utilize another programmer's style... you were only an amateur.
john alvord
Quoted 2 lines · John Alvord
The best programmer I ever knew told me that if you couldn't fake and utilize another programmer's style... you were only an amateur.
I don't see how coding style has anything to do with the abilities of a programmer whatsoever.
Kelsey Hudson [email protected]
Software Engineer
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------
Quoted 7 lines · Dr. Kelsey Hudson
Quoted 2 lines · John Alvord
The best programmer I ever knew told me that if you couldn't fake and utilize another programmer's style... you were only an amateur.
I don't see how coding style has anything to do with the abilities of a programmer whatsoever.
It doesn't and he didn't say it did. He said the ability to
ultilize another's style... That is fundamentally different.
I've been in this business since the mid '70s, on the Internet
since the mid '80s, and involved with Linux since the 0.98 and SLS days. I've long recognized that you could often recognize who wrote something by their "style". It's like brush strokes on a painting. If you can utilize someone else's style to the extent that someone skilled would look at that an think it was done by the other. That is skill and that is both ability and adaptibility. Both admirable.
Quoted 4 lines
Kelsey Hudson [email protected]
Software Engineer
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------
Mike
Signature · 4 lines
Michael H. Warfield | (770) 985-6132 | [email protected] /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
Quoted 11 lines · Michael H. Warfield
Quoted 7 lines · Dr. Kelsey Hudson
Quoted 2 lines · John Alvord
The best programmer I ever knew told me that if you couldn't fake and utilize another programmer's style... you were only an amateur.
I don't see how coding style has anything to do with the abilities of a programmer whatsoever.
It doesn't and he didn't say it did. He said the ability to
ultilize another's style... That is fundamentally different.
amateur, n, One lacking the skill of a professional, as in an art. (thanks to dictionary.com for exact definition)
Now, if being able to utilize someone's style gives me the skill of a professional programmer, then I'm the best programmer there is, because, by god, I can imitate anyone's style there is. Granted, I am a skilled professional programmer, but I've been able to do that for years. I'd go as far as to say that when I was learning to program, I could do it. That didn't make me any better at it.
I still don't see how coding style and effectiveness/correctness/usefulness of code are related; non sequitur (it does not follow).
Quoted 7 lines
I've been in this business since the mid '70s, on the Internet
since the mid '80s, and involved with Linux since the 0.98 and SLS days. I've long recognized that you could often recognize who wrote something by their "style". It's like brush strokes on a painting. If you can utilize someone else's style to the extent that someone skilled would look at that an think it was done by the other. That is skill and that is both ability and adaptibility. Both admirable.
Anybody in my company can (and does) do that. In fact, it's a *requirement* here. We're required to use the same style as the author did in their code. In fact, there are times where I have looked at a source I wrote several years back, and glance over parts of it, not remembering that I wrote it, but nonetheless it's in my (obscure but highly readable) coding style.
all goes to say that code is just another type of art form, but as with any art form, it can be imitated, and is imitated frequently. I still don't see how ability goes with coding style.
Kelsey Hudson [email protected]
Software Engineer
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------
Quoted 5 lines
If and when I step down as maintainer (if I do so, I'll publically pass the baton to the new maintainer), the new maintainer can indent to their preference. Until that time, *I'm* the maintainer, and *I* need to be able to read the code efficiently. It's the part of the kernel I spend the most time in, after all.
I wasnt aware mtrr.c had an active maintainer.
Quoted 1 line
"He who writes the code gets to choose".
How about he who has to decipher the whole mess to add things...
Quoted 8 lines · Alan Cox
Quoted 6 lines
If and when I step down as maintainer (if I do so, I'll publically pass the baton to the new maintainer), the new maintainer can indent to their preference. Until that time, *I'm* the maintainer, and *I* need to be able to read the code efficiently. It's the part of the kernel I spend the most time in, after all.
I wasnt aware
mtrr.chad an active maintainer.
According to changelog nothing substantive since March 1999.
Quoted 3 lines
Quoted 1 line
"He who writes the code gets to choose".
How about he who has to decipher the whole mess to add things...
At least one person actually Lindent's mtrr.c, modifies, tests, and then backports changes into un-Lindent'd mtrr.c. Ug.
Jeff
Signature · 3 lines
Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and one tongue. MandrakeSoft | - nomeansno
Quoted 1 line · Alan Cox
I wasnt aware
mtrr.chad an active maintainer.
Well, hpa and myself are the only ones really maintaining it in the last two years judging from the changelog. Some others probably also contributed small changes not worthy of an entry.
Quoted 2 lines
Quoted 1 line
"He who writes the code gets to choose".
How about he who has to decipher the whole mess to add things...
It's grown to something of a monster imo. A complete rewrite for 2.5 would likely be the best thing to happen it in the last 5 years
I got the idea a while ago that splitting the various implementations (Cyrix/K6/etc) out to seperate files would be a good start. After I ripped it apart for an x86-64 version (not-yet-tested/merged), I realised it still needs more work.
Dave.
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 3 lines
Well, hpa and myself are the only ones really maintaining it in the last two years judging from the changelog. Some others probably also contributed small changes not worthy of an entry.
Or rewrote the Winchip code but didnt feel egotistical enough
Quoted 4 lines
I got the idea a while ago that splitting the various implementations (Cyrix/K6/etc) out to seperate files would be a good start. After I ripped it apart for an x86-64 version (not-yet-tested/merged), I realised it still needs more work.
I looked at that - but its hard to see the right places to split it
Quoted 4 lines · Alan Cox
Quoted 3 lines
Well, hpa and myself are the only ones really maintaining it in the last two years judging from the changelog. Some others probably also contributed small changes not worthy of an entry.
Or rewrote the Winchip code but didnt feel egotistical enough
It's not so much an ego thing imo. It's a useful pointer to find out who changed something, and why. If nothing else, useful to find the guilty party when something breaks 8)
/me hides*
Quoted 3 lines
Quoted 2 lines
I got the idea a while ago that splitting the various implementations (Cyrix/K6/etc) out to seperate files would be a good start.
I looked at that - but its hard to see the right places to split it
Agreed, it's one reason I've been putting it off until a better time (Ie, 2.5)
regards,
Dave.
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
PATCH 1/1 mtrr (was Re: GPLONLY kernel symbols???)
In reply to Dave JonesQuoted 8 lines · Dave Jones
Quoted 1 line · Alan Cox
I wasnt aware
mtrr.chad an active maintainer.Well, hpa and myself are the only ones really maintaining it in the last two years judging from the changelog. Some others probably also contributed small changes not worthy of an entry.
Another SCNWOAE...
Paul.
i386/kernel/mtrr.c renamed from i386/kernel/mtrr.c~ +0 -1
@@ -489,7 +489,6 @@case MTRR_IF_INTEL :rdmsr (MTRRcap_MSR, config, dummy);return (config & (1 <<10 )); -return 1 ;case MTRR_IF_AMD_K6 :case MTRR_IF_CENTAUR_MCR :case MTRR_IF_CYRIX_ARR :
Quoted 3 lines · Jeff Garzik
He and davej still have a point. Your code formatting is non-standard, and is difficult to read. A document exists CodingStyle which explains a good style, and further -why- it is a good style.
I find the style in Doc*/CodingStyle to be hard to read as well. I code much like Richard does -- vertical whitespace is good. horizontal whitespace is good. braces have no business on the same line as an opening statement. The 'TAB' character should never be found within code. Little things like that (OK, commence flames).
I agree with the 'whatever, it's hard to maintain 20-someodd years down the road' statement, but i also think that the author of code should be able to choose his own style; those who edit that code should conform to that style the author chose when he wrote it.
anyways, enough of this, i have better things to do than get into another pissing contest about coding style.
Kelsey Hudson [email protected]
Software Engineer
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------
Quoted 8 lines · Richard Gooch
Quoted 7 lines
Among other reasons, because of long term maintenance.
How do you expect others in the Linux kernel community to review your code, if it is widely considered difficult to read? How do you expect people to maintain your code when are no longer around? The Linux kernel will be around long after you and I and others leave kernel development. Others need to read and maintain this code.
Quoted 5 lines
If and when I step down as maintainer (if I do so, I'll publically pass the baton to the new maintainer), the new maintainer can indent to their preference. Until that time, *I'm* the maintainer, and *I* need to be able to read the code efficiently. It's the part of the kernel I spend the most time in, after all.
You argue that others reviewing your code is worthless? That you are the only one reading your code?
Signature · 3 lines
Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and one tongue. MandrakeSoft | - nomeansno
Quoted 9 lines · Jeff Garzik
Quoted 8 lines · Richard Gooch
Quoted 7 lines
Among other reasons, because of long term maintenance.
How do you expect others in the Linux kernel community to review your code, if it is widely considered difficult to read? How do you expect people to maintain your code when are no longer around? The Linux kernel will be around long after you and I and others leave kernel development. Others need to read and maintain this code.
Quoted 8 lines
Quoted 5 lines
If and when I step down as maintainer (if I do so, I'll publically pass the baton to the new maintainer), the new maintainer can indent to their preference. Until that time, *I'm* the maintainer, and *I* need to be able to read the code efficiently. It's the part of the kernel I spend the most time in, after all.
You argue that others reviewing your code is worthless? That you are the only one reading your code?
I didn't say that at all! But since I'm the one maintaining that code, it makes sense that it's easiest for me to read, since I'm the most frequent reader (and writer).
But that's beside the point. Linus has stated that he doesn't want to force coding style upon others, unless it's something that he has to maintain. Since he doesn't maintain devfs, that doesn't apply.
If Linus makes the decision to change that policy, and *force* all code into the one style, I'll have to put up with that, although I'll grumble. And I'll scream blue murder if it's just *my* code that gets changed; I note that not all of the kernel conforms to Linus' preferred style. Right now I feel picked on.
Regards, Richard.... Permanent: [email protected] Current: [email protected]
Quoted 28 lines · Richard Gooch
Quoted 9 lines · Jeff Garzik
Quoted 8 lines · Richard Gooch
Quoted 7 lines
Among other reasons, because of long term maintenance.
How do you expect others in the Linux kernel community to review your code, if it is widely considered difficult to read? How do you expect people to maintain your code when are no longer around? The Linux kernel will be around long after you and I and others leave kernel development. Others need to read and maintain this code.
Quoted 8 lines
Quoted 5 lines
If and when I step down as maintainer (if I do so, I'll publically pass the baton to the new maintainer), the new maintainer can indent to their preference. Until that time, *I'm* the maintainer, and *I* need to be able to read the code efficiently. It's the part of the kernel I spend the most time in, after all.
You argue that others reviewing your code is worthless? That you are the only one reading your code?
I didn't say that at all! But since I'm the one maintaining that code, it makes sense that it's easiest for me to read, since I'm the most frequent reader (and writer).
But that's beside the point. Linus has stated that he doesn't want to force coding style upon others, unless it's something that he has to maintain. Since he doesn't maintain devfs, that doesn't apply.
Quoted 5 lines
If Linus makes the decision to change that policy, and *force* all code into the one style, I'll have to put up with that, although I'll grumble. And I'll scream blue murder if it's just *my* code that gets changed; I note that not all of the kernel conforms to Linus' preferred style. Right now I feel picked on.
There's a difference between telling you what to think, and trying to point out why your methods are flawed. I also would never presume to tell anyone what to think or do; I am trying to emphasize here that your choice makes it difficult to review the code, and affects the long-term maintainability of the codebase overall. It wouldn't really be an issue if the code weren't so far from CodingStyle that everyone else is used to.
Is a compromise possible? Can you keep a local codebase in your own coding style, and then run Lindent before sending to Linus?
Ideally in 2.5 devfs (or some form thereof) is gonna be the centerpiece of our new and wonderful dynamic device world. It would be nice if that was what the majority consider readable code...
Jeff
Signature · 3 lines
Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and one tongue. MandrakeSoft | - nomeansno
Quoted 2 lines · Jeff Garzik
Is a compromise possible? Can you keep a local codebase in your own coding style, and then run Lindent before sending to Linus?
The problem is that I'm not the only writer of that code. Occasionally, global API changes are made, and these aren't sent to me, but go to Linus directly, unfortunately. So I do have to merge stuff back into my tree from time to time.
A few days ago I was thinking about this, and I thought how cool it would be to have a reliable utility that could convert between the two coding styles. If I had that (and it was bulletproof) then it could be used with some kind of userfs to give me two views of the kernel: the underlying one "raw" one, to which I'd apply patches and generate them from, and a "sanitised" one, that I would read and edit.
Regards, Richard.... Permanent: [email protected] Current: [email protected]
Quoted 11 lines · Richard Gooch
The problem is that I'm not the only writer of that code. Occasionally, global API changes are made, and these aren't sent to me, but go to Linus directly, unfortunately. So I do have to merge stuff back into my tree from time to time.
A few days ago I was thinking about this, and I thought how cool it would be to have a reliable utility that could convert between the two coding styles. If I had that (and it was bulletproof) then it could be used with some kind of userfs to give me two views of the kernel: the underlying one "raw" one, to which I'd apply patches and generate them from, and a "sanitised" one, that I would read and edit.
Good lord, and you would dream this up and use it before just using the same coding style as the rest of us? :)
Maybe I am biased because I find CodingStyle beautiful, but I can't understand why it is so hard to just play nicely with the rest of us. I diffed a patch for Alan against mtrr.c a week or so back to fix some compile bug, and I was confused doing a _two line_ diff.
Robert Love
Quoted 7 lines · Richard Gooch
A few days ago I was thinking about this, and I thought how cool it would be to have a reliable utility that could convert between the two coding styles. If I had that (and it was bulletproof) then it could be used with some kind of userfs to give me two views of the kernel: the underlying one "raw" one, to which I'd apply patches and generate them from, and a "sanitised" one, that I would read and edit.
If you look in scripts/Lindent you will see it calls:
indent -kr -i8 -ts8 -sob -l80 -ss -bs -psl
The GNU indent utility has tons of options to accomodate every sort of perverse coding style. I imagine some time with the indent man page will produce a working solution for you in short order,
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Quoted 9 lines · Erik Andersen
Quoted 7 lines · Richard Gooch
A few days ago I was thinking about this, and I thought how cool it would be to have a reliable utility that could convert between the two coding styles. If I had that (and it was bulletproof) then it could be used with some kind of userfs to give me two views of the kernel: the underlying one "raw" one, to which I'd apply patches and generate them from, and a "sanitised" one, that I would read and edit.
Quoted 7 lines
If you look in
scripts/Lindentyou will see it calls:indent -kr -i8 -ts8 -sob -l80 -ss -bs -pslThe GNU indent utility has tons of options to accomodate every sort of perverse coding style. I imagine some time with the indent man page will produce a working solution for you in short order,
I'll look at this. Later. Right now I'm focussing on getting the new devfs core up to snuff.
Regards, Richard.... Permanent: [email protected] Current: [email protected]
Quoted 5 lines · Richard Gooch
If and when I step down as maintainer (if I do so, I'll publically pass the baton to the new maintainer), the new maintainer can indent to their preference. Until that time, *I'm* the maintainer, and *I* need to be able to read the code efficiently. It's the part of the kernel I spend the most time in, after all.
Or you could reindent to your style befor making changes yourself as well. Consider this as an exercise in cooperation.
[OT] Coding Style (was: Re: GPLONLY kernel symbols???)
In reply to Richard GoochQuoted 3 lines · Jeff Garzik
He and davej still have a point. Your code formatting is non-standard, and is difficult to read. A document exists CodingStyle which explains a good style, and further -why- it is a good style.
Oh yes, words like
--- cut ---
but all right-thinking people know that (a) K&R are _right_ and (b) K&R are right. Besides, functions are special anyway (you can't nest them in C).
--- cut ---
Is really a satisfing descrption _why_ it is a good style. :-)
(I actually agree with 99% of the coding style but my braces will always be GNU. ;-) And K&R braces suck in Java. (ducks and runs)).
Regards
Henning
Signature · 5 lines
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected] D-91054 Buckenhof Fax.: 09131 / 50654-20
Quoted 2 lines · Richard Gooch
BTW: I had to edit after applying your patch: it didn't conform to the Style[tm].
Dude. Really. Have you actually read CodingStyle? No joke, I hear complaints about your code formatting from several [non-viro :):)] sources.
The practice of non-standard indentation and non-standard "if" formatting -really- makes the code hard to read.
Is there a good reason why your code is vehemently different from CodingStyle?
Jeff
Signature · 3 lines
Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and one tongue. MandrakeSoft | - nomeansno