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?
On Tue, Oct 16, 2001 at 09:27:55AM -0700, Christoph Lameter wrote:
> /lib/modules/2.4.11/kernel/drivers/block/loop.o: Note: modules without a
> GPL compatible license cannot use GPLONLY_ symbols
>
> What 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 ...
--
"I hear you have four hundred and eighty six PCs for sale ?"
- Some Fool
On Tue, 16 Oct 2001, John Levon wrote:
> On Tue, Oct 16, 2001 at 09:27:55AM -0700, Christoph Lameter wrote:
>
> > /lib/modules/2.4.11/kernel/drivers/block/loop.o: Note: modules without a
> > GPL compatible license cannot use GPLONLY_ symbols
> >
> > What 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).
invalidate_bdev() is _not_ GPL-only. Never had been, never will.
On Tue, 16 Oct 2001 09:27:55 -0700 (PDT),
Christoph Lameter <[email protected]> wrote:
>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?
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???
On Wed, 17 Oct 2001, Keith Owens wrote:
> On Tue, 16 Oct 2001 09:27:55 -0700 (PDT),
> Christoph Lameter <[email protected]> wrote:
> >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?
>
> 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.
>
>
On Tue, 16 Oct 2001 21:59:03 -0700 (PDT),
Christoph Lameter <[email protected]> wrote:
>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.
On Wed, 17 Oct 2001, Keith Owens wrote:
> On Tue, 16 Oct 2001 21:59:03 -0700 (PDT),
> Christoph Lameter <[email protected]> wrote:
> >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.
Then do not output such a message. This is not M$ windows.
On Wed, Oct 17, 2001 at 12:17:39PM +1000, Keith Owens wrote:
> 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.
How is the name mangled in the _GPL case ? Can't this be detected explicitly ?
richard, since ac seems OK with it ...
thanks
john
--- faq.html Thu Oct 11 18:42:44 2001
+++ faqnew.html Wed Oct 17 15:22:17 2001
@@ -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>
--
"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
On Tue, 16 Oct 2001, Christoph Lameter wrote:
> On Wed, 17 Oct 2001, Keith Owens wrote:
>
> > On Tue, 16 Oct 2001 21:59:03 -0700 (PDT),
> > Christoph Lameter <[email protected]> wrote:
> > >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.
>
> 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
[email protected]
<>< As a computer I find your faith in technology amusing.
Gerhard Mack wrote:
> > 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?
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
--------------------------------------
In mailing-lists.linux-kernel, Pierre-Philippe Coupard wrote:
> 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.
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
Gerhard Mack wrote:
>
> On Tue, 16 Oct 2001, Christoph Lameter wrote:
>
> > On Wed, 17 Oct 2001, Keith Owens wrote:
> >
> > > On Tue, 16 Oct 2001 21:59:03 -0700 (PDT),
> > > Christoph Lameter <[email protected]> wrote:
> > > >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.
> >
> > 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?
>
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
> Gerhard
>
> --
> Gerhard Mack
>
> [email protected]
>
> <>< 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/
--
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
Wayne Whitney wrote:
>
> 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.
> 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
--------------------------------------
> 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
On Wed, 17 Oct 2001, Arjan van de Ven wrote:
> 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???
>
>
> > 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).
> -
> 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/
>
On Wed, Oct 17, 2001 at 12:14:34PM -0700, David Lang wrote:
> 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...
On Wed, 17 Oct 2001, Arjan van de Ven wrote:
> On Wed, Oct 17, 2001 at 12:14:34PM -0700, David Lang wrote:
> > 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
Arjan van de Ven wrote:
>
> 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.
> 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.
* [email protected] <[email protected]> on Wed, Oct 17, 2001:
>
> 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:
> >
> > 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.
>
> 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.
>
> 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.
>
What the hell are you talking about?
> 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.
> 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.
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.
John Levon writes:
> On Wed, Oct 17, 2001 at 12:17:39PM +1000, Keith Owens wrote:
>
> > 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.
>
> How is the name mangled in the _GPL case ? 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]
Dave Jones writes:
> On Mon, 12 Nov 2001, Richard Gooch wrote:
>
> > 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?
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]
On Mon, 12 Nov 2001, Richard Gooch wrote:
> 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.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Mon, 12 Nov 2001, Richard Gooch wrote:
> Dave Jones writes:
> > How about running mtrr.c & devfs code through scripts/Lindent
> > sometime 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...
Alexander Viro writes:
>
>
> On Mon, 12 Nov 2001, Richard Gooch wrote:
>
> > Dave Jones writes:
> > > How about running mtrr.c & devfs code through scripts/Lindent
> > > sometime 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]
Richard Gooch wrote:
> 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
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
On Mon, 12 Nov 2001, Richard Gooch wrote:
> Alexander Viro writes:
> > On Mon, 12 Nov 2001, Richard Gooch wrote:
> > > Dave Jones writes:
> > > > How about running mtrr.c & devfs code through scripts/Lindent
> > > > sometime 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?
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?
Richard Gooch wrote:
> Alexander Viro writes:
> > On Mon, 12 Nov 2001, Richard Gooch wrote:
> > > Dave Jones writes:
> > > > How about running mtrr.c & devfs code through scripts/Lindent
> > > > sometime btw?
Go ahead and Lindent mtrr.c, it hasn't been touched by rgooch in a
while...
> > > 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
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
Alexander Viro writes:
> On Mon, 12 Nov 2001, Richard Gooch wrote:
> > Alexander Viro writes:
> > > On Mon, 12 Nov 2001, Richard Gooch wrote:
> > > > Dave Jones writes:
> > > > > How about running mtrr.c & devfs code through scripts/Lindent
> > > > > sometime 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?
>
> 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?
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]
Jeff Garzik writes:
> Richard Gooch wrote:
> > Alexander Viro writes:
> > > On Mon, 12 Nov 2001, Richard Gooch wrote:
> > > > Dave Jones writes:
> > > > > How about running mtrr.c & devfs code through scripts/Lindent
> > > > > sometime btw?
>
> Go ahead and Lindent mtrr.c, it hasn't been touched by rgooch in a
> while...
Hey!
> > > > 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.
> 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.
> 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]
On Mon, 12 Nov 2001, Richard Gooch wrote:
> 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?
On Mon, 12 Nov 2001, Richard Gooch wrote:
> 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.
> 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.
Alexander Viro writes:
>
>
> On Mon, 12 Nov 2001, Richard Gooch wrote:
>
> > 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]
> 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]
On Mon, 12 Nov 2001, Richard Gooch wrote:
> 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
Richard Gooch wrote:
> > 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.
You argue that others reviewing your code is worthless?
That you are the only one reading your code?
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
Jeff Garzik writes:
> Richard Gooch wrote:
> > > 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.
>
> 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]
Alexander Viro writes:
> On Mon, 12 Nov 2001, Richard Gooch wrote:
>
> > 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.
> > 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]
On Mon, 12 Nov 2001 20:58:16 -0800 (PST), Davide Libenzi
<[email protected]> wrote:
>On Mon, 12 Nov 2001, Richard Gooch wrote:
>
>> 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 ?
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
Richard Gooch wrote:
>
> Jeff Garzik writes:
> > Richard Gooch wrote:
> > > > 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.
> >
> > 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.
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
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
Jeff Garzik writes:
> 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]
On Mon, 12 Nov 2001, Richard Gooch wrote:
> Alexander Viro writes:
> > 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?
On Tue, 2001-11-13 at 00:23, Richard Gooch wrote:
> 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
Alexander Viro writes:
>
>
> On Mon, 12 Nov 2001, Richard Gooch wrote:
>
> > Alexander Viro writes:
> > > 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?
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]
On Mon Nov 12, 2001 at 10:23:27PM -0700, Richard Gooch wrote:
>
> 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--
Richard Gooch wrote:
> 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.
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
Erik Andersen writes:
> On Mon Nov 12, 2001 at 10:23:27PM -0700, Richard Gooch wrote:
> >
> > 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,
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]
Hi
On Mon, 12 Nov 2001, Richard Gooch wrote:
> > 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
> 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.
> "He who writes the code gets to choose".
How about he who has to decipher the whole mess to add things...
Richard Gooch wrote:
>
> Alexander Viro writes:
> > On Mon, 12 Nov 2001, Richard Gooch wrote:
> > > Alexander Viro writes:
> > > > On Mon, 12 Nov 2001, Richard Gooch wrote:
> > > > > Dave Jones writes:
> > > > > > How about running mtrr.c & devfs code through scripts/Lindent
> > > > > > sometime 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?
> >
> > 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?
>
> 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.
> 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.
> 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...
Jeff Garzik <[email protected]> writes:
>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
--
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
Richard Gooch wrote:
> 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.
Alan Cox wrote:
>
> > 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.
According to changelog nothing substantive since March 1999.
> > "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
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
On Tue, 13 Nov 2001, Alan Cox wrote:
> I wasnt aware mtrr.c had 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.
> > "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.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
> 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
> 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
On Tue, 13 Nov 2001, Alan Cox wrote:
> > 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*
> > 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.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Dave Jones wrote:
>
> On Tue, 13 Nov 2001, Alan Cox wrote:
>
> > I wasnt aware mtrr.c had 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.
--- arch/i386/kernel/mtrr.c~ Tue Nov 6 19:14:03 2001
+++ arch/i386/kernel/mtrr.c Thu Nov 15 04:58:40 2001
@@ -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:
On Mon, 12 Nov 2001, Jeff Garzik wrote:
> 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
---------------------------------------------------------------------------
On Mon, 12 Nov 2001, John Alvord wrote:
> 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
---------------------------------------------------------------------------
On Wed, Nov 28, 2001 at 02:41:23PM -0800, Dr. Kelsey Hudson wrote:
> On Mon, 12 Nov 2001, John Alvord wrote:
> > 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.
> Kelsey Hudson [email protected]
> Software Engineer
> Compendium Technologies, Inc (619) 725-0771
> ---------------------------------------------------------------------------
Mike
--
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!
On Wed, 28 Nov 2001, Michael H. Warfield wrote:
> On Wed, Nov 28, 2001 at 02:41:23PM -0800, Dr. Kelsey Hudson wrote:
> > On Mon, 12 Nov 2001, John Alvord wrote:
>
> > > 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).
> 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
---------------------------------------------------------------------------