Coding style - a non-issue
Peter Waltenberg
"man indent"
Someone who cares, come up with an indentrc for the kernel code, and get it
into Documentation/CodingStyle
If the maintainers run all new code through indent with that indentrc
before checkin, the problem goes away.
The only one who'll incur any pain then is a code submitter who didn't
follow the rules. (Exactly the person we want to be in pain ;)).
Then we can all get on with doing useful things.
Cheers
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
>
> "man indent"
> Someone who cares, come up with an indentrc for the kernel code, and get it
> into Documentation/CodingStyle
The problem was solved years ago.
scripts/Lindent
Russell King
> Someone who cares, come up with an indentrc for the kernel code, and get it
> into Documentation/CodingStyle
> If the maintainers run all new code through indent with that indentrc
> before checkin, the problem goes away.
> The only one who'll incur any pain then is a code submitter who didn't
> follow the rules. (Exactly the person we want to be in pain ;)).
See: linux/scripts/Lindent
--
Russell King (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Robert Love
> Someone who cares, come up with an indentrc for the kernel code, and get it
> into Documentation/CodingStyle
> If the maintainers run all new code through indent with that indentrc
> before checkin, the problem goes away.
> The only one who'll incur any pain then is a code submitter who didn't
> follow the rules. (Exactly the person we want to be in pain ;)).
See scripts/lindent in your source tree ... does just this.
Robert Love
Alexander Viro
On Thu, 29 Nov 2001, Peter Waltenberg wrote:
> The problem was solved years ago.
>
> "man indent"
>
> Someone who cares, come up with an indentrc for the kernel code, and get it
> into Documentation/CodingStyle
> If the maintainers run all new code through indent with that indentrc
> before checkin, the problem goes away.
> The only one who'll incur any pain then is a code submitter who didn't
> follow the rules. (Exactly the person we want to be in pain ;)).
indent does _not_ solve the problem of:
* buggers who think that MyVariableIsBiggerThanYourVariable is a
good name
* buggers who define a function with 42 arguments and body being
return (foo == bar) ? TRUE : FALSE;
* buggers who add 1001st broken implementation of memcmp(), call it
FooTurdCompare and prepend it with 20x80 block comment.
* buggers who use typedefs like WORD, DWORD, BYTE, IMANIDIOTSHOOTME
and other crap from the same source (OK, they don't write the last one
explicitly - not that it wasn't obvious from the rest of their, ahem, code).
* buggers who use Hungarian notation for no good reason and come up
with structure fields that sound like street names from R'Lyeh
* buggers who introduce wrappers for standard kernel stuff - like,
say it, typedef int Int32; and sprinkle their crap with per-architecture
ifdefs.
* buggers who think that cpp is Just The Thing and produce turds that
would make srb cringe in disgust.
Al, -><- close to setting up a Linux Kernel Hall of Shame - one with names of
wankers (both individual and coprorat ones) responsible, their code and
commentary on said code...
Larry McVoy
> wankers (both individual and coprorat ones) responsible, their code and
> commentary on said code...
Please, please, please, I'm begging you, please do this. It's the only way
people learn quickly. Being nice is great, but nothing works faster than
a cold shower of public humiliation :-)
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Davide Libenzi
> > Al, -><- close to setting up a Linux Kernel Hall of Shame - one with names of
> > wankers (both individual and coprorat ones) responsible, their code and
> > commentary on said code...
>
> Please, please, please, I'm begging you, please do this. It's the only way
> people learn quickly. Being nice is great, but nothing works faster than
> a cold shower of public humiliation :-)
Well, I don't know about "Hall of Shame" but having an "Hall of Flame"
without you two guys is like going at the OktoberFest being abstemious :)
- Davide
David S. Miller
Date: Wed, 28 Nov 2001 19:17:42 -0500 (EST)
indent does _not_ solve the problem of:
Al, I think you just described the Intel e100 driver.
:-)
Petko Manolov
>
>>Someone who cares, come up with an indentrc for the kernel code, and get it
>>into Documentation/CodingStyle
...
> indent does _not_ solve the problem of:
...
I quite liked it, applies perfectly for some people i know... :-)
Anyway, in Lindent you'll see "-psl" (--procname-start-lines) option
which contradict with what is written in CodingStyle i.e:
int my_proc(void)
{
...
}
which I personally prefer.
Petko
Matthias Andree
> Al, -><- close to setting up a Linux Kernel Hall of Shame - one with names of
> wankers (both individual and coprorat ones) responsible, their code and
> commentary on said code...
Oh, can I vote for someone spoiling outside the Kernel? I have a
candidate for that one.
Seriously, don't waste your *p_time on that except people resist any
hints to CodingStyleIsForLameAssHackersIWantMyEDIT.COM for an extended
amount of *p_time.
--
Matthias Andree
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin
Larry McVoy
> Larry McVoy <l...@bitmover.com> writes:
>
> >> Al, -><- close to setting up a Linux Kernel Hall of Shame - one with names of
> >> wankers (both individual and coprorat ones) responsible, their code and
> >> commentary on said code...
>
> >people learn quickly. Being nice is great, but nothing works faster than
> >a cold shower of public humiliation :-)
>
> and gets publically humiliated in the "linux source code hall of
> shame". Perfect. I can hear the laughter from Redmond over here (and
> it is 12000km away).
>
> Sigh, sometimes, sometimes, I _really_ understand the BSD folks when
> they call the Linux community "a bunch of unkempt nerds that need to
> get a life".
Perhaps it would be illuminating to know that I was BSD hacker,
and that I learned the value of this particular technique from
Sun's kernel group, who once upon a time were the best BSD group
on the planet. It might also be illuminating to consider that
this technique of getting people to listen is still in use at
Sun to this day.
Perhaps Sun's professionalism is not what you'd like to see here.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Henning Schmiedehausen
Hi,
> Perhaps it would be illuminating to know that I was BSD hacker,
> and that I learned the value of this particular technique from
I know. You tell us this again and again. Please stop patronizing.
> Sun's kernel group, who once upon a time were the best BSD group
> on the planet. It might also be illuminating to consider that
> this technique of getting people to listen is still in use at
> Sun to this day.
It might be enlightening to you that a closed users group of SUN coders
is not compareable to a worldwide distributed environment of thousands
of people and companies.
>
> Perhaps Sun's professionalism is not what you'd like to see here.#
You tell me, that SUN treated _CUSTOMERS_ and companies that wanted to
support SunOS 4.1.x like that? If yes, then I definitely know why they
went SysV. Surely noone wanted BSD any longer.
I would consider the internal development groups in SUN that treated
each other like this also "in need of a change". :-)
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH h...@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 in...@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
Jeff Garzik
is often the only way to motivate vendors into fixing security
problems. Yes, even BSD security guys do this :)
A "Top 10 ugliest Linux kernel drivers" list would probably provide
similar motivation.
Jeff
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
Henning Schmiedehausen
Hi,
> The security community has shown us time and again that public shaming
> is often the only way to motivate vendors into fixing security
> problems. Yes, even BSD security guys do this :)
>
> A "Top 10 ugliest Linux kernel drivers" list would probably provide
> similar motivation.
A security issue is an universal accepted problem that most of the time
has a reason and a solution.
Coding style, however, is a very personal thing that start with "shall
we use TABs or not? (Jakarta: No. Linux: Yes ...) and goes on to "Is a
preprocessor macro a good thing or not" until variable names (Al Viro:
Names with more than five letters suck. :-) Java: Non-selfdescriptive
names suck. Microsoft: Non-hungarian names suck) and so on.
And you really want to judge code just because someone likes to wrap
code in preprocessor macros or use UPPERCASE variable names?
Come on. That's a _fundamental_ different issue than dipping vendors in
their own shit if they messed up and their box/program has a security
issue. Code that you consider ugly as hell may be seen as "easily
understandable and maintainable" by the author. If it works and has no
bugs, so what? Just because it is hard for you and me to understand (cf.
"mindboggling unwind routines in the NTFS" (I thing Jeff Merkey stated
it like this). It still seems to work quite well.
Are you willing to judge "ugliness" of kernel drivers? What is ugly? Are
Donald Beckers' drivers ugly just because they use (at least on 2.2)
their own pci helper library? Is the aic7xxx driver ugly because it
needs libdb ? Or is ugly defined as "Larry and Al don't like them"? :-)
Flaming about coding style is about as pointless as flaming someone
because he supports another sports team. There is no universal accepted
coding style. Not even in C.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH h...@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 in...@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
-
Alan Cox
> because he supports another sports team. There is no universal accepted
> coding style. Not even in C.
The kernel has an accepted coding style, both the documented and the
tradition part of it. Using that makes life a lot lot easier for maintaining
the code. Enforcing it there is a good idea, except for special cases
(headers shared with NT has been one example of that).
There are also some nice tools around that will do the first stage import of
a Hungarian NT'ese driver and linuxise it.
Alan
Larry McVoy
> On Fri, 2001-11-30 at 17:47, Jeff Garzik wrote:
> > The security community has shown us time and again that public shaming
> > is often the only way to motivate vendors into fixing security
> > problems. Yes, even BSD security guys do this :)
> >
> > A "Top 10 ugliest Linux kernel drivers" list would probably provide
> > similar motivation.
>
> A security issue is an universal accepted problem that most of the time
> has a reason and a solution.
>
> code in preprocessor macros or use UPPERCASE variable names?
Henning, in any long lived source base, coding style is crucial. People
who think that coding style is personal are just wrong. Let's compare,
shall we?
Professional: the coding style at this job looks like XYZ, ok, I will now
make my code look like XYZ.
Amateur: my coding style is better than yours.
I think that if you ask around, you'll find that the pros use a coding
style that isn't theirs, even when writing new code. They have evolved
to use the prevailing style in their environment. I know that's true for
me, my original style was 4 space tabs, curly braces on their own line,
etc. I now code the way Bill Joy codes, fondly known as Bill Joy normal
form.
Anyway, if you think any coding style is better than another, you completely
miss the point. The existing style, whatever it is, is the style you use.
I personally despise the GNU coding style but when I make changes there,
that's what I use because it is their source base, not mine.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Martin Dalecki
>
> The security community has shown us time and again that public shaming
> is often the only way to motivate vendors into fixing security
> problems. Yes, even BSD security guys do this :)
>
> A "Top 10 ugliest Linux kernel drivers" list would probably provide
> similar motivation.
Yehh.... However some of the uglinesses results from ignorance
on behalf of the overall kernel maintainers, who don't care
to apply "cosmetic" changes to drivers, just to don't
irritate the oftes so called "maintainer". Two expierences:
ftape and mcd I'm through....
BTW.> ftape (for the pascal emulation) and DAC960
(for the silly ICantReadThisCasing)
are my personal "top ranks" in regard
of the contest for the most ugly code in the kernel...
serial.c is another one for the whole multiport support which
may be used by maybe 0.1% of the Linux users thrown on them all
and some "magic" number silliness as well...
Martin Dalecki
> Flaming about coding style is about as pointless as flaming someone
> because he supports another sports team. There is no universal accepted
> coding style. Not even in C.
Bull shit: indent -kr is the way to go. It ever was...
Alan Cox
> ftape and mcd I'm through....
I timed the mcd maintainer out and tidied it anyway. I figured since it
wasnt being maintained nobody would scream too loudly - nobody has
> BTW.> ftape (for the pascal emulation) and DAC960
ftape is an awkward one. Really the newer ftape4 wants merging into the
kernel but that should have happened a long time ago
> serial.c is another one for the whole multiport support which
> may be used by maybe 0.1% of the Linux users thrown on them all
> and some "magic" number silliness as well...
serial.c is a good example of the "ugly" that actually matters more, as is
floppy.c. Clean well formatted code that is stil opaque.
Russell King
> serial.c is another one for the whole multiport support which
> may be used by maybe 0.1% of the Linux users thrown on them all
> and some "magic" number silliness as well...
Magic number silliness is something that's gone with my replacement
serial drivers. If multiport is such a problem, it can easily be
cleaned up. I'll add that to my to do list for serial stuff.
Thanks.
--
Russell King (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
Martin Dalecki
>
> > irritate the oftes so called "maintainer". Two expierences:
> > ftape and mcd I'm through....
>
> I timed the mcd maintainer out and tidied it anyway. I figured since it
> wasnt being maintained nobody would scream too loudly - nobody has
Wenn sorry for the missconception I wanted to insult *you*, my expierenc
in regard to this is even older...
> > BTW.> ftape (for the pascal emulation) and DAC960
>
> ftape is an awkward one. Really the newer ftape4 wants merging into the
> kernel but that should have happened a long time ago
It diverged too much from what's in the kernel since about already 3-4
years.
And I don't think that it's that much better in terms of implementation
style...
Fortunately all those floppy interface iomega streamers are
physically obsolete by now. Plese notice that ftape4 is using a
different storage format, well this is due to the fact that the
ftape inside the kernel wasn't up to the corresponding standard
(QIO-80)...
> > serial.c is another one for the whole multiport support which
> > may be used by maybe 0.1% of the Linux users thrown on them all
> > and some "magic" number silliness as well...
>
> serial.c is a good example of the "ugly" that actually matters more, as is
> floppy.c. Clean well formatted code that is stil opaque.
floppy.c is indeed one of the best compiler test cases around there.
But personally I would excuse floppy.c a bit becouse it's dealing with
a really awkward controller interface ;-).
serial.c should be hooked at the misc char device interface sooner or
later.
But somehow this never happened becouse nobody dared to care enough.
Henning Schmiedehausen
Larry
> I think that if you ask around, you'll find that the pros use a coding
> style that isn't theirs, even when writing new code. They have evolved
> to use the prevailing style in their environment. I know that's true for
> me, my original style was 4 space tabs, curly braces on their own line,
> etc. I now code the way Bill Joy codes, fondly known as Bill Joy normal
> form.
I don't have to ask around. You may want to know that I work in this
industry for about 15 years and write commercial code (that is "code
that ships") since about that time (and I don't run around telling
everybody each and every time about it and what I've already done). I've
written code in a good two dozen languages (including things that really
deserve to die like Comal) and I've worked in projects from "one man
show" to "lots of people in Elbonia also work on this". So, please,
please, Larry, _STOP THE FUCK PATRONIZING OTHERS_. Actually, I try to
consider myself a "pro" in some languages and a bloody amateur in others
(like Lisp or Python). That is "pro" as in "pays his bills with writing
software".
>
> Anyway, if you think any coding style is better than another, you completely
> miss the point. The existing style, whatever it is, is the style you use.
> I personally despise the GNU coding style but when I make changes there,
> that's what I use because it is their source base, not mine.
We're in violent agreement here. Unfortunatly we do not agree whether it
is good to force a driver writer (which is, IMHO, most of the time a
well defined entity of one, maybe two or three source code files that
uses a well established (though sometimes changing) API to talk to the
kernel) to convert his style to the linux kernel ("our style is better
than yours, you must convert") or allow him to continue working (and
maintaining) his driver in the kernel tree in his own style. Even if his
variable names contain Uppercase letters.
The question now is, what is "amateur behaviour": Forcing this driver
writer to change or to tolerate his style in his driver? We're still
talking about a driver, not about the VM subsystem or the networking
core.
And will "putting up a list of the ten most ugly drivers with author
names" really persuade this author to change? Or simply to drop out and
write a driver for an OS that may be more tolerant?
That the core components of a large software project must adhere to a
style guide (and the Linux style guide is pretty good, because it is
_SHORT_), there is no disagreement between you and me.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH h...@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 in...@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
-
Alexander Viro
On 30 Nov 2001, Henning Schmiedehausen wrote:
> issue. Code that you consider ugly as hell may be seen as "easily
> understandable and maintainable" by the author. If it works and has no
> bugs, so what? Just because it is hard for you and me to understand (cf.
... it goes without peer review for years. And that means bugs.
Fact of life: we all suck at reviewing our own code. You, me, Ken Thompson,
anybody - we tend to overlook bugs in the code we'd written. Depending on
the skill we can compensate - there are technics for that, but it doesn't
change the fact that review by clued people who didn't write the thing
tends to show bugs we'd missed for years.
If you really don't know that by your own experience - you don't _have_
experience. There is a damn good reason for uniform style within a
project: peer review helps. I've lost the count of bugs in the drivers
that I'd found just grepping the tree. Even on that level review catches
tons of bugs. And I have no reason to doubt that authors of respective
drivers would fix them as soon as they'd see said bugs.
"It's my code and I don't care if nobody else can read it" is an immediate
firing offense in any sane place. It may be OK in academentia, but in the
real life it's simply unacceptable.
It's all nice and dandy to shed tears for poor, abused, well-meaning company
that had made everyone happy by correct but unreadable code and now gets
humiliated by mean ingrates. Nice image, but in reality the picture is
quite different. Code _is_ buggy. That much is a given, regardless of
the origin of that code. The only question is how soon are these bugs
fixed. And that directly depends on the amount of efforts required to
read through that code.
Sigh... Ironic that _you_ recommend somebody to grow up - I would expect
the level of naivety you'd demonstrated from a CS grad who'd never worked
on anything beyond his toy project. Not from somebody adult.
Martin Dalecki
>
> On Fri, Nov 30, 2001 at 06:20:40PM +0100, Martin Dalecki wrote:
> > serial.c is another one for the whole multiport support which
> > may be used by maybe 0.1% of the Linux users thrown on them all
> > and some "magic" number silliness as well...
>
> Magic number silliness is something that's gone with my replacement
> serial drivers. If multiport is such a problem, it can easily be
> cleaned up. I'll add that to my to do list for serial stuff.
Well sombeody really cares apparently! Thank's. Any pointers
where to ahve a look at it? BTW> Did you consider ther misc device
idea? (Hooking serial at to the misc device stuff).
antirez
> The security community has shown us time and again that public shaming
> is often the only way to motivate vendors into fixing security
> problems. Yes, even BSD security guys do this :)
It's a bit different. Usually the security community uses it
when there isn't a way to fix the code (i.e. non-free code)
or when the maintaner of the code refused to fix the issue.
Also to "expose" the security problem isn't the same as
to flame.
While not a good idea, something like a long name
for a local var isn't a big problem like a completly
broken software with huge security holes used by milions of people
every day.
The quality of the code should be ensured in a different
way. If there is a standard coding-style you should either:
1) refuse to include broken code before the programmer fix it
2) fix it yourself before the inclusion
Flames aren't a good solution imho.
--
Salvatore Sanfilippo <ant...@invece.org>
http://www.kyuzz.org/antirez
finger ant...@tella.alicom.com for PGP key
28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF
Russell King
> serial.c should be hooked at the misc char device interface sooner or
> later.
Please explain. Especially contentrate on justifing why serial interfaces
aren't a tty device.
Thanks.
--
Russell King (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
Russell King
> Well sombeody really cares apparently! Thank's.
Currently its a restructuring of serial.c to allow different uart type
ports to be driven without duplicating serial.c many times over. (the
generic_serial didn't hack it either).
> Any pointers where to ahve a look at it?
I should probably put this on a web page somewhere 8)
:pserver:c...@pubcvs.arm.linux.org.uk:/mnt/src/cvsroot, module serial
(no password)
> BTW> Did you consider ther misc device idea? (Hooking serial at to the
> misc device stuff).
I just caught that comment - I'll await your reply.
--
Russell King (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
Martin Dalecki
>
> On Fri, Nov 30, 2001 at 06:42:17PM +0100, Martin Dalecki wrote:
> > serial.c should be hooked at the misc char device interface sooner or
> > later.
>
> Please explain. Especially contentrate on justifing why serial interfaces
> aren't a tty device.
No problem ;-).
There is the hardware: in esp. the serial controller itself - this
belongs
to misc, becouse a mouse for example doesn't have to interpret any tty
stuff
This animal belongs to the same cage as the PS/2 variant of it.
And then there is one abstraction level above it: the tty interface -
this belongs to a line discipline.
We have this split anyway already there /dev/ttyS0 and /dev/cua0 somehow
emulated on one level.
Understood?
Larry McVoy
"I don't do XYZ"
"XYZ"
statement?
On Fri, Nov 30, 2001 at 06:53:05PM +0100, Henning Schmiedehausen wrote:
> You may want to know that I work in this
> industry for about 15 years and write commercial code (that is "code
> that ships") since about that time (and I don't run around telling
> everybody each and every time about it and what I've already done).
That would be the "I don't do XYZ..."
> I've
> written code in a good two dozen languages (including things that really
> deserve to die like Comal) and I've worked in projects from "one man
> show" to "lots of people in Elbonia also work on this".
And this would be the "XYZ".
If you are going to yell at people for a particular behaviour, it's really
more effective if you don't show that behaviour in the midst of your yelling,
wouldn't you agree? Just a friendly thought.
> So, please, please, Larry, _STOP THE FUCK PATRONIZING OTHERS_.
It would appear that you find everything I say patronizing, regardless of
what it is or how it is said. I'm sorry about that, but I'm not going
to change how I speak to suit you. Yell all you want. I'd suggest
that if you find my emails offensive, you add me to your kill file.
> The question now is, what is "amateur behaviour": Forcing this driver
> writer to change or to tolerate his style in his driver? We're still
> talking about a driver, not about the VM subsystem or the networking
> core.
Your approach to this whole topic is a good example of why I run my own
company and I have absolute authority to fire people at will. If you
worked here and you persisted with this approach, you would be fired,
without question. I don't know how to say it more clearly, I don't
say it lightly, hiring someone, training them, all of that is a huge
investment. One which I would discard if you couldn't fit in. Coding
style is part of fitting in, it isn't optional in any code I pay for.
You may have a different view, that's cool, you're entitled. But realize
that any professional software organization is unlikely to agree with you.
For whatever that is worth.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Henning Schmiedehausen
Hi,
> On 30 Nov 2001, Henning Schmiedehausen wrote:
>
> > issue. Code that you consider ugly as hell may be seen as "easily
> > understandable and maintainable" by the author. If it works and has no
> > bugs, so what? Just because it is hard for you and me to understand (cf.
>
> ... it goes without peer review for years. And that means bugs.
That's right. And I didn't say, that _this is a good thing_. The
question was (and is IMHO), "do we put such code into a "hall of driver
writer shame" or do we either just reject the code from the kernel tree
or do we help "the poor misunderstood vendor" to convert.
Simply flaming them down will definitely not help. As someone with your
experience should know, too.
> Sigh... Ironic that _you_ recommend somebody to grow up - I would expect
> the level of naivety you'd demonstrated from a CS grad who'd never worked
> on anything beyond his toy project. Not from somebody adult.
You're welcome.
I'm willing to give you a bet: You put up such a "hall of shame" and we
will see what comes first:
a) media echo that "linux core developers start insulting code
committers"
or
b) vendors start cleaning up their code.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH h...@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 in...@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
-
Alexander Viro
On Fri, 30 Nov 2001, Daniel Phillips wrote:
> On the other hand, the idea of a coding style hall of shame - publicly
> humiliating kernel contributers - is immature and just plain silly. It's
> good to have a giggle thinking about it, but that's where it should stop.
Damnit, Daniel, are you deliberately trying to tempt me into doing that?
Larry McVoy
> On the other hand, the idea of a coding style hall of shame - publicly
> humiliating kernel contributers - is immature and just plain silly. It's
> good to have a giggle thinking about it, but that's where it should stop.
If you've got a more effective way of getting people to do the right thing,
lets hear it. Remember, the goal is to protect the source base, not your,
my, or another's ego.
I used to think Sun's approach was pretty brutal, and I still do actually.
But I haven't found anything else which works as well. I don't use that
technique at BitMover, instead I rewrite code that I find offensive. That's
less annoying to the engineers but it is also a lot more costly in terms of
my time. Since we're a small company, I can keep up. When we double in
size, I won't be able to do so and I suspect we'll revert to the Sun way.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Paul G. Allen
>
> The problem was solved years ago.
>
> "man indent"
>
> Someone who cares, come up with an indentrc for the kernel code, and get it
> into Documentation/CodingStyle
> before checkin, the problem goes away.
> The only one who'll incur any pain then is a code submitter who didn't
> follow the rules. (Exactly the person we want to be in pain ;)).
>
> Then we can all get on with doing useful things.
>
IMEO, there is but one source as reference for coding style: A book by
the name of "Code Complete". (Sorry, I can't remember the author and I
no longer have a copy. Maybe my Brother will chime in here and fill in
the blanks since he still has his copy.)
Outside of that, every place I have worked as a programmer, with a team
of programmers, had a style that was adhered to almost religiously. In
many cases the style closely followed "Code Complete". In the case of
the kernel, as Alan and others have mentioned, there IS a Linux kernel
coding style.
In 99% of the Linux code I have seen, the style does indeed "suck". Why?
Consider a new coder coming in for any given task. S/he knows nothing
about the kernel and needs to get up to speed quickly. S/he starts
browsing the source - the ONLY definitive explanation of what it does
and how it works - and finds:
- Single letter variable names that aren't simple loop counters and
must ask "What the h*** are these for?"
- No function/file comment headers explaining what the purpose of the
function/file is.
- Very few comments at all, which is not necessarily bad except...
- The code is not self documenting and without comments it takes an
hour to figure out what function Foo() does.
- Opening curly braces at the end of a the first line of a large code
block making it extremely difficult to find where the code block begins
or ends.
- Short variable/function names that someone thinks is descriptive but
really isn't.
- Inconsistent coding style from one file to the next.
- Other problems.
After all, the kernel must be maintained by a number of people and those
people will come and go. The only real way to keep bugs at a minimum,
efficiency at a maximum, and the learning curve for new coders
acceptable is consistent coding style and code that is easily
maintained. The things I note above are not a means to that end. Sure,
maybe Bob, the designer and coder of bobsdriver.o knows the code inside
and out without need of a single comment or descriptive
function/variable name, but what happens when Bob can no longer maintain
it? It's 10,000 lines of code, the kernel is useless without it, it
broke with kernel 2.6.0, and Joe, the new maintainer of bobsdriver.o, is
having a hell of a time figuring out what the damn thing does.
An extreme case? Maybe, but how many times does someone come in to
development and have to spend more hours than necessary trying to figure
out how things work (or are supposed to work) instead of actually
writing useful code?
PGA
--
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com
Dana Lacoste
I bet the guys in Redmond who were referred to
earlier are enjoying it, but it's just trash for
the rest of us....
> Henning, perhaps you can explain to me how the following isn't a
>
> "I don't do XYZ"
>
> "XYZ"
>
> statement?
This one I understood though :
Al made a personal attack. He defended against the attack,
and preluded his defence with a disclaimer.
This issue has gone beyond productivity to personal name calling
and spurious defence. Can we all just move on a bit maybe?
Thanks
--
Dana Lacoste - Linux Developer
Peregrine Systems - Ottawa, Canada
Paul G. Allen
>
> On Fri, Nov 30, 2001 at 11:47:28AM -0500, Jeff Garzik wrote:
> > The security community has shown us time and again that public shaming
> > is often the only way to motivate vendors into fixing security
> > problems. Yes, even BSD security guys do this :)
>
> It's a bit different. Usually the security community uses it
> when there isn't a way to fix the code (i.e. non-free code)
> or when the maintaner of the code refused to fix the issue.
> Also to "expose" the security problem isn't the same as
> to flame.
>
> While not a good idea, something like a long name
> for a local var isn't a big problem like a completly
> broken software with huge security holes used by milions of people
> every day.
>
A variable/function name should ALWAYS be descriptive of the
variable/function purpose. If it takes a long name, so be it. At least
the next guy looking at it will know what it is for.
PGA
--
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com
John H. Robinson, IV
>
> IMEO, there is but one source as reference for coding style: A book by
> the name of "Code Complete". (Sorry, I can't remember the author and I
> no longer have a copy. Maybe my Brother will chime in here and fill in
> the blanks since he still has his copy.)
Code Complete: A Practical Handbook of Software Construction.
Redmond, Wa.: Microsoft Press, 880 pages, 1993.
Retail price: $35.
ISBN: 1-55615-484-4.
Steve McConnell
source: http://www.construx.com/stevemcc/cc.htm
-john
Mohammad A. Haque
> This issue has gone beyond productivity to personal name calling
> and spurious defence. Can we all just move on a bit maybe?
Heh, are you kidding, This is LKML. It's gonna be beaten into the ground
and then some.
For what it's worth, most professional programmers I've interacted with
always adhere to the programming style of where they are working,
regardless of the way they personally program.
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
mha...@haque.net
"Alcohol and calculus don't mix. Developer/Project Lead
Don't drink and derive." --Unknown http://www.themes.org/
batm...@themes.org
=====================================================================
Jeff Garzik
problems. End of story.
Jeff
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
-
Paul G. Allen
>
> On Fri, Nov 30, 2001 at 10:15:41AM -0800, Paul G. Allen wrote:
> >
> > IMEO, there is but one source as reference for coding style: A book by
> > the name of "Code Complete". (Sorry, I can't remember the author and I
> > no longer have a copy. Maybe my Brother will chime in here and fill in
> > the blanks since he still has his copy.)
>
> Code Complete: A Practical Handbook of Software Construction.
> Redmond, Wa.: Microsoft Press, 880 pages, 1993.
> Retail price: $35.
> ISBN: 1-55615-484-4.
>
Thanks John. You beat my bro. to it. Of course, he's probably still in
bed since it's not even noon yet. :)
(Note to self: Order a new copy of the book. I should have done it last
night when I ordered 3 other programming books. :/)
PGA
--
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com
Nestor Florez
Author : Steve McConnell
Publisher: Microsoft Press
Nestor :-)
Maciej W. Rozycki
> > Please explain. Especially contentrate on justifing why serial interfaces
> > aren't a tty device.
>
> No problem ;-).
>
> There is the hardware: in esp. the serial controller itself - this
> belongs
> to misc, becouse a mouse for example doesn't have to interpret any tty
> stuff
The same applies to the console keyboard, which is hooked to a standard
UART on certain systems as well.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: ma...@ds2.pg.gda.pl, PGP key available +
Henning Schmiedehausen
> But I haven't found anything else which works as well. I don't use that
> technique at BitMover, instead I rewrite code that I find offensive. That's
Sounds like the thing that Mr. Gates did when Microsoft was small. Maybe
there _is_ a point in this.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH h...@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 in...@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
-
Martin Dalecki
>
> On Fri, Nov 30, 2001 at 06:49:01PM +0100, Martin Dalecki wrote:
> > Well sombeody really cares apparently! Thank's.
>
> Currently its a restructuring of serial.c to allow different uart type
> ports to be driven without duplicating serial.c many times over. (the
> generic_serial didn't hack it either).
>
> > Any pointers where to ahve a look at it?
>
> I should probably put this on a web page somewhere 8)
>
> :pserver:c...@pubcvs.arm.linux.org.uk:/mnt/src/cvsroot, module serial
> (no password)
>
> > BTW> Did you consider ther misc device idea? (Hooking serial at to the
> > misc device stuff).
>
> I just caught that comment - I'll await your reply.
I'm just right now looking at the code found above.
First of all: GREAT WORK! And then you are right a bit, I just don't
see too much code duplication between the particular drivers there.
However I still don't see the need to carrige the whole tty stuff just
to drive a mouse... but I don't see a solution right now.
I wouldn't be good to introduce a scatter heap of "micro"
driver modules like the ALSA people did as well too..
However in serial/linux/drivers/serial/serial_clps711x.c
the following wonders me a bit:
#ifdef CONFIG_DEVFS_FS
normal_name: SERIAL_CLPS711X_NAME,
callout_name: CALLOUT_CLPS711X_NAME,
#else
normal_name: SERIAL_CLPS711X_NAME,
callout_name: CALLOUT_CLPS711X_NAME,
#endif
What is the ifdef supposed to be good for?
One other suggestion serial_code.c could be just serial.c or code.c
or main.c, since _xxxx.c should distinguish between particulart devices.
It was a bit clumy to find the entry-point for me...
And then we have in uart_register_driver:
normal->open = uart_open;
normal->close = uart_close;
normal->write = uart_write;
normal->put_char = uart_put_char;
normal->flush_chars = uart_flush_chars;
normal->write_room = uart_write_room;
normal->chars_in_buffer = uart_chars_in_buffer;
normal->flush_buffer = uart_flush_buffer;
normal->ioctl = uart_ioctl;
normal->throttle = uart_throttle;
normal->unthrottle = uart_unthrottle;
normal->send_xchar = uart_send_xchar;
normal->set_termios = uart_set_termios;
normal->stop = uart_stop;
normal->start = uart_start;
normal->hangup = uart_hangup;
normal->break_ctl = uart_break_ctl;
normal->wait_until_sent = uart_wait_until_sent;
And so on....
Why not do:
{
static strcut tty_driver _normal = {
open: uart_open,
close: uart_close,
...
};
...
*normal = _normal;
}
...
for the static stuff first and only initialize the
dynamically calculated addresses dynamically later, like
the double refferences...
This would save already *quite a bit* of .text ;-).
Yeah I know I'm a bit perverse about optimizations....
You already do it for the callout device nearly this
way:
/*
* The callout device is just like the normal device except for
* the major number and the subtype code.
*/
*callout = *normal;
callout->name = drv->callout_name;
callout->major = drv->callout_major;
callout->subtype = SERIAL_TYPE_CALLOUT;
callout->read_proc = NULL;
callout->proc_entry = NULL;
Reagrds.
Russell King
> The same applies to the console keyboard, which is hooked to a standard
> UART on certain systems as well.
This particular point is up for discussion between myself and James Simmons
(and other interested parties). We're getting there...
--
Russell King (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
antirez
> antirez wrote:
> A variable/function name should ALWAYS be descriptive of the
> variable/function purpose. If it takes a long name, so be it. At least
> the next guy looking at it will know what it is for.
I agree, but descriptive != long
for (mydearcountr = 0; mydearcounter < n; mydearcounter++)
and it was just an example. Read it as "bad coding style".
--
Salvatore Sanfilippo <ant...@invece.org>
http://www.kyuzz.org/antirez
finger ant...@tella.alicom.com for PGP key
28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF
Jeff Garzik
> IMEO, there is but one source as reference for coding style: A book by
> the name of "Code Complete". (Sorry, I can't remember the author and I
> no longer have a copy. Maybe my Brother will chime in here and fill in
> the blanks since he still has his copy.)
Hungarian notation???
That was developed by programmers with apparently no skill to
see/remember how a variable is defined. IMHO in the Linux community
it's widely considered one of the worst coding styles possible.
> Outside of that, every place I have worked as a programmer, with a team
> of programmers, had a style that was adhered to almost religiously.
yes
> In 99% of the Linux code I have seen, the style does indeed "suck". Why?
> Consider a new coder coming in for any given task. S/he knows nothing
> about the kernel and needs to get up to speed quickly. S/he starts
> browsing the source - the ONLY definitive explanation of what it does
> and how it works - and finds:
99% is far and above the level of suck defined by most :)
> - Single letter variable names that aren't simple loop counters and
> must ask "What the h*** are these for?"
> - No function/file comment headers explaining what the purpose of the
> function/file is.
> - Very few comments at all, which is not necessarily bad except...
> - The code is not self documenting and without comments it takes an
> hour to figure out what function Foo() does.
We could definitely use a ton more comments... patches accepted.
> - Opening curly braces at the end of a the first line of a large code
> block making it extremely difficult to find where the code block begins
> or ends.
use a decent editor
> - Short variable/function names that someone thinks is descriptive but
> really isn't.
not all variable names need their purpose obvious to complete newbies.
sometimes it takes time to understand the code's purpose, in which case
the variable names become incredibly descriptive.
> After all, the kernel must be maintained by a number of people and those
> people will come and go. The only real way to keep bugs at a minimum,
> efficiency at a maximum, and the learning curve for new coders
> acceptable is consistent coding style and code that is easily
> maintained. The things I note above are not a means to that end. Sure,
> maybe Bob, the designer and coder of bobsdriver.o knows the code inside
> and out without need of a single comment or descriptive
> function/variable name, but what happens when Bob can no longer maintain
> it? It's 10,000 lines of code, the kernel is useless without it, it
> broke with kernel 2.6.0, and Joe, the new maintainer of bobsdriver.o, is
> having a hell of a time figuring out what the damn thing does.
yes
Jeff
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
-
Jeff Garzik
> A variable/function name should ALWAYS be descriptive of the
> variable/function purpose. If it takes a long name, so be it. At least
> the next guy looking at it will know what it is for.
That's complete crap. Human beings know and understand context, and can
use it effectively. 'idx' or 'i' or 'bh' may make perfect sense in
context. There is absolutely no need for
JournalBHThatIsStoredAndSyncedWithSuperblock.
Kernel code like DAC960 proves that long variable names -decrease- code
readability.
Jeff
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
-
Larry McVoy
> On November 30, 2001 07:13 pm, Larry McVoy wrote:
> > On Fri, Nov 30, 2001 at 06:49:11PM +0100, Daniel Phillips wrote:
> > > On the other hand, the idea of a coding style hall of shame - publicly
> > > humiliating kernel contributers - is immature and just plain silly. It's
> > > good to have a giggle thinking about it, but that's where it should stop.
> >
> > If you've got a more effective way of getting people to do the right thing,
> > lets hear it. Remember, the goal is to protect the source base, not your,
> > my, or another's ego.
>
I'd like to see some data which backs up that statement. My experience is
that that is an unsupportable statement. You'd need to know how effective
the Sun way is, have seen multiple development organizations using that
way and other ways, and have watched the progress.
I'm in a somewhat unique position in that I have a lot of ex-Sun engineers
using BitKeeper and I have a pretty good idea how fast they make changes.
It's a lot faster and a lot more consistent than the Linux effort, in fact,
there is no comparison.
I'm not claiming that the coding style is the source of their speed, but
it is part of the culture which is the source of their speed.
As far as I can tell, you are just asserting that leading by example is
more effective. Am I incorrect? Do you have data? I have piles which
shows the opposite.
> Maybe humiliation works at
> Sun, when you're getting a paycheck, but in the world of volunteer
> development it just makes people walk.
Huh. Not sure I agree with that either. It's definitely a dicey area
but go through the archives (or your memory if it is better than mine)
and look at how the various leaders here respond to bad choices. It's
basically public humiliation. Linus is especially inclined to speak
his mind when he sees something bad. And people stick around.
I think the thing you are missing is that what I am describing is a lot
like boot camp. Someone with more knowledge and experience than you
yells at your every mistake, you hate it for a while, and you emerge
from boot camp a stronger person with more skills and good habits as
well as a sense of pride. If there was a way to "lead by example" and
accomplish the same goals in the same time, don't you think someone
would have figured that out by now?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
John Kodis
> Human beings know and understand context, and can use it
> effectively. 'idx' or 'i' or 'bh' may make perfect sense in
> context. There is absolutely no need for
> JournalBHThatIsStoredAndSyncedWithSuperblock.
Mathematics has a rich tradition of using short variable names such as
"pi" rather than something like "circle-circumference-to-diameter-ratio".
They keep formulas from becoming unreadably long, and have a meaning
which is well understood in context. While the long version may more
self-explainatory, it's the short form which is universally preferred.
-- John Kodis.
RaúlNúńezde Arenas Coronado
>"Paul G. Allen" wrote:
>> IMEO, there is but one source as reference for coding style: A book =
by
>> the name of "Code Complete". (Sorry, I can't remember the author and=
I
>> no longer have a copy. Maybe my Brother will chime in here and fill =
in
>> the blanks since he still has his copy.)
>Hungarian notation???
>That was developed by programmers with apparently no skill to
>see/remember how a variable is defined. IMHO in the Linux community
>it's widely considered one of the worst coding styles possible.
Not at all... Hungarian notation is not so bad, except it is only
understood by people from hungary. So the name }:))) I just use it
when I write code for Hungary or secret code that no one should
read...
>> - Short variable/function names that someone thinks is descriptive =
but
>> really isn't.
>not all variable names need their purpose obvious to complete newbies.=
>sometimes it takes time to understand the code's purpose, in which cas=
e
>the variable names become incredibly descriptive.
Here you are right. The code can be seen really as a book: you
can start reading at the middle and yet understand some of the story,
but it's far better when you start at the beginning ;))) Moreover,
most of the variable and function names in the kernel code are quite
descriptive, IMHO.
Of course, more comments and more descriptive names doesn't harm,
but some times they bloat the code...
Raúl
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
Galappatti, Kishantha
personal here. I personally think there should be an established coding
style that should be kept to as much as possible but the way to implement
that is by helping the contributors to do so with tools etc, not by
castigating them in a "hall of shame". Isn't open source about inclusion and
creativity?
Just my opinion.
--kish
-----Original Message-----
From: Dana Lacoste [mailto:dana.l...@peregrine.com]
Sent: Friday, November 30, 2001 1:19 PM
To: 'Larry McVoy'; Henning Schmiedehausen
Cc: Jeff Garzik; linux-...@vger.kernel.org
Subject: RE: Coding style - a non-issue
Any chance that you guys could calm down a bit?
I bet the guys in Redmond who were referred to
earlier are enjoying it, but it's just trash for
the rest of us....
> Henning, perhaps you can explain to me how the following isn't a
>
> "I don't do XYZ"
>
> "XYZ"
>
> statement?
This one I understood though :
Al made a personal attack. He defended against the attack,
and preluded his defence with a disclaimer.
This issue has gone beyond productivity to personal name calling
and spurious defence. Can we all just move on a bit maybe?
Thanks
--
Dana Lacoste - Linux Developer
Peregrine Systems - Ottawa, Canada
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Paul G. Allen
>
>
> We could definitely use a ton more comments... patches accepted.
>
I've actually thought of doing just that. :)
Alas, I'm too busy coding other things right now, so kernel stuff
(unless I need something to make the other project I'm working on
work/work better) will just have to wait. Hell, I'm even behind 2 or 3
kernel versions on the documentation I've been putting on my web site.
:(
> > - Opening curly braces at the end of a the first line of a large code
> > block making it extremely difficult to find where the code block begins
> > or ends.
>
> use a decent editor
A person shouldn't _need_ a decent editor to pick out the beginning/end
of a code block (or anything else for that matter). The problem is
exacerbated when such a block contains other blocks and quickly picking
out where each begins/ends becomes tiresome. I _do_ have excellent
editors, IDEs, and source code browsers and have used many different
kinds in many different jobs. They still can not replace what the human
eye and mind perceive.
>
> > - Short variable/function names that someone thinks is descriptive but
> > really isn't.
>
> not all variable names need their purpose obvious to complete newbies.
> sometimes it takes time to understand the code's purpose, in which case
> the variable names become incredibly descriptive.
It should not take "time" to discover the purpose of _any_ variable or
function, or file, whether newbie or not. The point of coding is to
solve a problem, not perform an excersise in deductive or logical
reasoning before the problem (which usually involves further logical
reasoning) can be solved.
PGA
--
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com
Jeff Garzik
> It should not take "time" to discover the purpose of _any_ variable or
> function, or file, whether newbie or not. The point of coding is to
> solve a problem, not perform an excersise in deductive or logical
> reasoning before the problem (which usually involves further logical
> reasoning) can be solved.
Part of the problem being solved by Linux kernel code is efficient long
term maintenance and efficient peer review. Overly verbose code does
not solve these problems.
Jeff
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
-
Paul G. Allen
>
> On Fri, Nov 30, 2001 at 10:20:43AM -0800, Paul G. Allen wrote:
> > antirez wrote:
> > A variable/function name should ALWAYS be descriptive of the
> > variable/function purpose. If it takes a long name, so be it. At least
> > the next guy looking at it will know what it is for.
>
> I agree, but descriptive != long
>
> for (mydearcountr = 0; mydearcounter < n; mydearcounter++)
>
> and it was just an example. Read it as "bad coding style".
>
Well if you're counting dear in the kernel, I'd say you have more
problems than your coding style. ;)
PGA
--
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com
Paul G. Allen
>
> On Fri, Nov 30, 2001 at 02:00:18PM -0500, Jeff Garzik wrote:
>
> > Human beings know and understand context, and can use it
> > effectively. 'idx' or 'i' or 'bh' may make perfect sense in
> > context. There is absolutely no need for
> > JournalBHThatIsStoredAndSyncedWithSuperblock.
JounalBH would be far better than i or idx.
>
> Mathematics has a rich tradition of using short variable names such as
> "pi" rather than something like "circle-circumference-to-diameter-ratio".
> They keep formulas from becoming unreadably long, and have a meaning
> which is well understood in context. While the long version may more
> self-explainatory, it's the short form which is universally preferred.
>
While 'pi', 'e', 'theta', 'phi', etc. are universally understood, things
like 'i', 'a', and 'idx' are not. I can use these for anything I want
and even for more than one thing, and they say nothing about what they
are for. 'i', 'j', etc. are fine as loop counters and array indexes
where their meaning is apparent by context, but are _not_ fine in other
situations. You (or the person that wrote the code) may think that the
name is perfectly fine, but someone else that thinks a bit different may
not.
PGA
--
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com
Andrew Morton
>
> We could definitely use a ton more comments... patches accepted.
>
Too late. Useful comments go in during, or even before the code.
While we're on the coding style topic: ext2_new_block.
-
Tim Hockin
> > but some times they bloat the code...
> >
>
> ;), but what's wrong with that? At least a person can understand what's
> going on and get to coding, instead of deciphering.
I'd happily download 50 MB kernel tarballs, if the extra 25 MB were
ACCURATE and UP TO DATE comments.
Larry McVoy
On Fri, Nov 30, 2001 at 10:54:39PM +0100, Daniel Phillips wrote:
> On November 30, 2001 08:05 pm, Larry McVoy wrote:
> > Huh. Not sure I agree with that either. It's definitely a dicey area
> > but go through the archives (or your memory if it is better than mine)
> > and look at how the various leaders here respond to bad choices. It's
> > basically public humiliation. Linus is especially inclined to speak
> > his mind when he sees something bad. And people stick around.
>
> There's an additional pattern, you'll notice that the guys who end up wearing
> the dung are the ones with full time Linux programming jobs, who basically
> have no option but to stick around. Do that to every newbie and after a
> while we'll have a smoking hole in the ground where Linux used to be.
>
> A simple rule to remember is: when code is bad, criticize the code, not the
> coder.
Your priorities are upside down. The code is more important than the
coder, it will outlive the coder's interest in that code. Besides,
this isn't some touchy feely love fest, it's code. It's suppose to
work and work well and be maintainable. You don't get that by being
"nice", you get that by insisting on quality. If being nice worked,
we wouldn't be having this conversation.
> > I think the thing you are missing is that what I am describing is a lot
> > like boot camp. Someone with more knowledge and experience than you
> > yells at your every mistake, you hate it for a while, and you emerge
> > from boot camp a stronger person with more skills and good habits as
> > well as a sense of pride.
>
> Thanks, but I'll spend my summer in some other kind of camp ;-) I'm sure it
> works for some people, but mutual respect is more what I'm used to and prefer.
The problem here is that you are assuming that yelling at someone means
that you don't respect that someone. Nothing could be further from the
truth. If you didn't respect them enough to think you could get good
results from them, I doubt you'd be yelling at them in the first place.
Don't confuse intense demands for excellence with a lack of respect,
that's not the case.
> > If there was a way to "lead by example" and
> > accomplish the same goals in the same time, don't you think someone
> > would have figured that out by now?
>
> Somebody did, and as hard as it is for some to fit it into their own model of
> the universe, there is somebody leading by example, not running a command
> economy but a self-organizing meritocracy. Do we achieve the same goals in
> the same time? Sometimes it doesn't seem like it, but because this thing
> just keeps crawling relentlessly forward on a thousand fronts, in the end we
> accomplish even more than Sun does.
Bah. Daniel, you are forgetting that I know what Sun has done first hand
and I know what Linux has done first hand. If you think that Linux is
at the same level as Sun's OS or ever will be, you're kidding yourself.
Linux is really cool, I love it, and I use it every day. But it's not
comparable to Solaris, sorry, not even close. I'm not exactly known for
my love of Solaris, you know, in fact I really dislike it. But I respect
it, it can take a licking and keep on ticking. Linux isn't there yet
and unless the development model changes somewhat, I'll stand behind my
belief that it is unlikely to ever get there.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Andrew Morton
>
> Linux isn't there yet
> and unless the development model changes somewhat, I'll stand behind my
> belief that it is unlikely to ever get there.
I am (genuinely) interested in what changes you think are needed.
-
rddu...@osdl.org
| Larry McVoy wrote:
| >
| > Linux isn't there yet
| > and unless the development model changes somewhat, I'll stand behind my
| > belief that it is unlikely to ever get there.
|
| I am (genuinely) interested in what changes you think are needed.
Same here, regarding both development model and OS functionality,
reliability, etc.
--
~Randy
Paul Jackson
|> Part of the problem being solved by Linux kernel code is
|> efficient long term maintenance and efficient peer review.
|> Overly verbose code does not solve these problems.
Code serves two masters - it instructs computers, and it
instructs humans (code readers, maintainers, forgetful authors
a month later, ...).
Often the first master, the computer, is the less demanding.
One can usually beat the code into submission with enough
effort, even if uninspired. There are exceptions to this,
such as perhaps virtual memory and C++ compilers, which
get just plain hard for most humans.
The second master is usually the more demanding. Great code
not only works, but is also a delight to read and maintain.
Like literature, there is perhaps a typical taxonomy of
code, by how readable it is:
- there's quick draft hurried code with terse names and
confused structure, free of comment
- there's more methodical, verbose code - overburdened
with uninspired, but exhaustive comments and baroque
code embellishments
- there's the eloquent gem, the polished pearl, the O'Henry
short story, the Dijkstra algorithm - which looks sometimes
like the hurried quick draft until you realize how hard it
is to improve or simplify it, and until you observe either
the many discarded drafts on the cutting room floor, or
that the author was inspired with genius.
So, yes, overly verbose code doesn't solve problems, but it
might show more effort to communicate with humans than confused
early drafts.
Unfortunately, that extra effort can sometimes be more of an
impediment than a help. It can be easier to nurse terse early
confused drafts into decent code than overweight bloat ... less
shit to shovel.
--
I won't rest till it's the best ...
Manager, Linux Scalability
Paul Jackson <p...@sgi.com> 1.650.933.1373
Alexander Viro
On Fri, 30 Nov 2001, Andrew Morton wrote:
> Jeff Garzik wrote:
> >
> > We could definitely use a ton more comments... patches accepted.
> >
>
> Too late. Useful comments go in during, or even before the code.
>
> While we're on the coding style topic: ext2_new_block.
Yes. I hope that new variant (see balloc.c,v) gets the thing into
better form, but then I'm obviously biased...
Larry McVoy
> Larry McVoy wrote:
> >
> > Linux isn't there yet
> > and unless the development model changes somewhat, I'll stand behind my
> > belief that it is unlikely to ever get there.
>
> I am (genuinely) interested in what changes you think are needed.
Well I have an opinion, not sure if it will be well received or not,
but here goes.
There is a choice which needs to be made up front, and that is this:
do you want to try and turn the Linux kernel hackers into Sun style
hackers or do you want to try something else?
This assumes we have agreement that there is a difference between the
two camps. I'd rather not get into a "this way is better than that way"
discussion, let's just postulate that the Sun way has some pros/cons
and so do the Linux way.
If you want to try and make Linux people work like Sun people, I think
that's going to be tough. First of all, Sun has a pretty small kernel
group, they work closely with each other, and they are full time,
highly paid, professionals working with a culture that is intolerant of
anything but the best. It's a cool place to be, to learn, but I think
it is virtually impossible to replicate in a distributed team, with way
more people, who are not paid the same or working in the same way.
Again, let's not argue the point, let's postulate for the time being
that the Linux guys aren't going to work like the Sun guys any time soon.
So what's the problem? The Sun guys fix more bugs, handle more corner
cases, and scale up better (Linux is still better on the uniprocessors
but the gap has narrowed considerably; Sun is getting better faster than
Linux is getting better, performance wise. That's a bit unfair because
Linux had, and has, better absolute numbers so there was less room to
improve, but the point is that Sun is catching up fast.)
As the source base increases in size, handles more devices, runs on more
platforms, etc., it gets harder and harder to make the OS be reliable.
Anyone can make a small amount of code work well, it's exponentially
more difficult to make a large amount of code work well. There are lots
of studies which show this to be true, the mythical man month is a good
starting place.
OK, so it sounds like I'm saying that the Linux guys are lame, Sun is
great, and there isn't any chance that Linux is going to be as good
as Solaris. That's not quite what I'm saying. *If* you want to play
by the same rules as Sun, i.e., develop and build things the same way,
then that is what I'm saying. The Linux team will never be as good
as the Sun team unless the Sun team gets a lot worse. I think that's
a fact of life, Sun has 100s of millions of dollars a year going into
software development. ESR can spout off all he likes, but there is no
way a team of people working for fun is going to compete with that.
On the other hand, there is perhaps a way Linux could be better. But it
requires changing the rules quite a bit.
Instead of trying to make the Linux hackers compete with the Sun hackers,
what would happen if you architected your way around the problem?
For example, suppose I said we need to have a smaller, faster, more
reliable uniprocessor kernel. Suppose I could wave a magic wand and
make SMP go away (I can't, but bear with me for a second). The problem
space just got at least an order of magnitude less complex than what Sun
deals with. I think they are up to 32-64 way SMP and you can imagine,
I hope, the additional complexity that added. OK, so *if* uniprocessor
was the only thing we had to worry about, or say 2-4 way SMP with just
a handful of locks, then can we agree that it is a lot more likely that
we could produce a kernel which was in every way as good or better than
Sun's kernel, on the same platform? If the answer is yes, keep reading,
if the answer is no, then we're done because I don't know what to do if
we can't get that far.
For the sake of discussion, let's assume that you buy what I am saying
so far. And let's say that we agree that if you were to toss the SMP
stuff then we have a good chance at making a reliable kernel, albeit
an uninteresting one when compared to big boxes. If you want me to go
into what I think it would take to do that, I will.
The problem is that we can't ignore the SMP issues, it drives hardware
sales, gets press, it's cool, etc. We have to have both but the problem
is that if we have both we really need Sun's level of professionalism
to make it work, and it isn't realistic to expect that from a bunch of
underpaid (or not at all paid) Linux hackers.
Here's how you get both. Fork the development efforts into the SMP part
and the uniprocessor part. The uniprocessor focus is on reliability,
stability, performance. The SMP part is a whole new development effort,
which is architected in such a way as to avoid the complexity of a
traditional SMP implementation.
The uniprocessor team owns the core architecture of the system. The
abstractions provided, the baseline code, etc., that's all uni. The
focus there is a small, fast, stable kernel.
The SMP team doesn't get to touch the core code, or at least there is
a very strong feedback loop against. In private converstations, we've
started talking about the "punch in the nose" feedback loop, which means
while it may be necessary to touch generic code for the benefit of SMP,
someone has to feel strongly enough about it that they well sacrifice
their nose.
It would seem like I haven't solved anything here, just painted a nice
but impossible picture. Maybe. I've actually thought long and hard
about the approach needed to scale up without touching all the code
and it is radically different from the traditional way (i.e., how
Sun, SGI, Sequent, etc., did it). If you are interested in that, I'll
talk about it but I'll wait to see if anyone cares.
The summary over all of this is:
If you want to solve all the problems that Sun does, run on the same
range of UP to big SMP, Linux is never going to be as reliable as
Solaris. My opinion, of course, but one that is starting to gain
some traction as the OS becomes more complex.
That leaves you with a choice: either give up on some things,
magically turn the Linux hackers into Sun hackers, or
architect your way around the problem.
My vote is the last one, it fits better with the Linux effort, the answer
is way more cool than anything Sun or anyone else has done, and it lets
you have a simple mainline kernel source base.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Rik van Riel
> Fact of life: we all suck at reviewing our own code. You, me, Ken
> Thompson, anybody - we tend to overlook bugs in the code we'd written.
> Depending on the skill we can compensate - there are technics for
> that, but it doesn't change the fact that review by clued people who
> didn't write the thing tends to show bugs we'd missed for years.
Absolutely agreed. Note that this goes hand in hand with
another issue, no matter how scary it may sound to other
people ... <drum roll>
DOCUMENTATION
Because, without documentation we can only see what code
does and not what it's supposed to do.
This in turn means other people cannot identify bugs in
the code, simply because they're not sure what the code
is supposed to do.
regards,
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
Rik van Riel
> "Paul G. Allen" wrote:
> > IMEO, there is but one source as reference for coding style: A book by
> > the name of "Code Complete". (Sorry, I can't remember the author and I
> > no longer have a copy. Maybe my Brother will chime in here and fill in
> > the blanks since he still has his copy.)
>
> Hungarian notation???
>
> That was developed by programmers with apparently no skill to
> see/remember how a variable is defined. IMHO in the Linux community
> it's widely considered one of the worst coding styles possible.
If your functions are so large that you need hungarian
notation to figure out the type of each variable, chances
are forgetting the variable type isn't the biggest of your
problems ;)
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
-
Rik van Riel
> Jeff Garzik wrote:
> >
> > We could definitely use a ton more comments... patches accepted.
>
> Too late. Useful comments go in during, or even before the code.
Indeed, patches with comment updates tend to get
discarded by Linus. ;(
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
-
Rik van Riel
> > Linux isn't there yet
> > and unless the development model changes somewhat, I'll stand behind my
> > belief that it is unlikely to ever get there.
>
> I am (genuinely) interested in what changes you think are needed.
I'm very interested too, though I'll have to agree with Larry
that Linux really isn't going anywhere in particular and seems
to be making progress through sheer luck.
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
-
Linus Torvalds
On Fri, 30 Nov 2001, Rik van Riel wrote:
>
> I'm very interested too, though I'll have to agree with Larry
> that Linux really isn't going anywhere in particular and seems
> to be making progress through sheer luck.
Hey, that's not a bug, that's a FEATURE!
You know what the most complex piece of engineering known to man in the
whole solar system is?
Guess what - it's not Linux, it's not Solaris, and it's not your car.
It's you. And me.
And think about how you and me actually came about - not through any
complex design.
Right. "sheer luck".
Well, sheer luck, AND:
- free availability and _crosspollination_ through sharing of "source
code", although biologists call it DNA.
- a rather unforgiving user environment, that happily replaces bad
versions of us with better working versions and thus culls the herd
(biologists often call this "survival of the fittest")
- massive undirected parallel development ("trial and error")
I'm deadly serious: we humans have _never_ been able to replicate
something more complicated than what we ourselves are, yet natural
selection did it without even thinking.
Don't underestimate the power of survival of the fittest.
And don't EVER make the mistake that you can design something better than
what you get from ruthless massively parallel trial-and-error with a
feedback cycle. That's giving your intelligence _much_ too much credit.
Quite frankly, Sun is doomed. And it has nothing to do with their
engineering practices or their coding style.
Linus
Davide Libenzi
[ A lot of stuff Pro-Sun ]
Wait a minute.
Wasn't it you that were screaming against Sun, leaving their team because
their SMP decisions about scaling sucked, because their OS was bloated
like hell with sync spinlocks, saying that they tried to make it scale but
they failed miserably ?
What is changed now to make Solaris, a fairly vanishing OS, to be the
reference OS/devmodel for every kernel developer ?
Wasn't it you that were saying that Linux will never scale with more than
2 CPUs ?
Isn't Linux SMP improved from the very first implementation ?
Isn't Linux SMP improved from the very first implementation w/out losing
reliability ?
Why you don't try to compare 2.0.36 with 2.4.x let's say on a 8 way SMP ?
Why should it stop improving ?
Because you know that adding fine grained spinlocks will make the OS
complex to maintain and bloated ... like it was Solaris before you
suddendly changed your mind.
<YOUR QUOTE>
> Then people want more performance. So they thread some more and now
> the locks aren't 1:1 to the objects. What a lock covers starts to
> become fuzzy. Thinks break down quickly after this because what
> happens is that it becomes unclear if you are covered or not and
> it's too much work to figure it out, so each time a thing is added
> to the kernel, it comes with a lock. Before long, your 10 or 20
> locks are 3000 or more like what Solaris has. This is really bad,
> it hurts performance in far reaching ways and it is impossible to
> undo.
</YOUR QUOTE>
I kindly agree with this, just curious to understand which kind of amazing
architectural solution Solaris took to be a reference for SMP
development/scaling.
- Davide
Mike Castle
> Well, sheer luck, AND:
> - free availability and _crosspollination_ through sharing of "source
> code", although biologists call it DNA.
> - a rather unforgiving user environment, that happily replaces bad
> versions of us with better working versions and thus culls the herd
> (biologists often call this "survival of the fittest")
> - massive undirected parallel development ("trial and error")
Linux is one big genetic algorithms project?
mrc
--
Mike Castle dal...@ix.netcom.com www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
Larry McVoy
> On Fri, 30 Nov 2001, Larry McVoy wrote:
> Wait a minute.
> Wasn't it you that were screaming against Sun, leaving their team because
> their SMP decisions about scaling sucked, because their OS was bloated
> like hell with sync spinlocks, saying that they tried to make it scale but
> they failed miserably ?
Yup, that's me, guilty on all charges.
> What is changed now to make Solaris, a fairly vanishing OS, to be the
> reference OS/devmodel for every kernel developer ?
It's not. I never said that we should solve the same problems the same
way that Sun did, go back and read the posting.
> Wasn't it you that were saying that Linux will never scale with more than
> 2 CPUs ?
No, that wasn't me. I said it shouldn't scale beyond 4 cpus. I'd be pretty
lame if I said it couldn't scale with more than 2. Should != could.
> Because you know that adding fine grained spinlocks will make the OS
> complex to maintain and bloated ... like it was Solaris before you
> suddendly changed your mind.
Sorry it came out like that, I haven't changed my mind one bit.
> <YOUR QUOTE>
> > Then people want more performance. So they thread some more and now
> > the locks aren't 1:1 to the objects. What a lock covers starts to
> > become fuzzy. Thinks break down quickly after this because what
> > happens is that it becomes unclear if you are covered or not and
> > it's too much work to figure it out, so each time a thing is added
> > to the kernel, it comes with a lock. Before long, your 10 or 20
> > locks are 3000 or more like what Solaris has. This is really bad,
> > it hurts performance in far reaching ways and it is impossible to
> > undo.
> </YOUR QUOTE>
>
> I kindly agree with this, just curious to understand which kind of amazing
> architectural solution Solaris took to be a reference for SMP
> development/scaling.
OK, so you got the wrong message. I do _not_ like the approach Sun took,
it's a minor miracle that they are able to make Solaris work as well as
it works given the design decisions they made.
What I do like is Sun's engineering culture. They work hard, they don't
back away from the corner cases, they have high standards. All of which
and more are, in my opinion, a requirement to try and solve the problems
the way they solved them.
So the problem I've been stewing on is how you go about scaling the OS
in a way that doesn't require all those hot shot sun engineers to make
it work and maintain it.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Petko Manolov
100% agree (better not play gods) and i think this is the end of
the discussion.
Petko
Keith Owens
Henning Schmiedehausen <h...@intermeta.de> wrote:
>Are you willing to judge "ugliness" of kernel drivers? What is ugly?
>... Is the aic7xxx driver ugly because it needs libdb ? ...
Yes, and no, mainly yes. Requiring libdb, lex and yacc to to generate
the firmware is not ugly, user space programs can use any tools that
the developer needs. I have no opinion either way about the driver
code, from what I can tell aic7xxx is a decent SCSI driver, once it is
built.
What is ugly in aic7xxx is :-
* Kludging BSD makefile style into aix7ccc/aicasm/Makefile. It is not
compatible with the linux kernel makefile style.
* Using a manual flag (CONFIG_AIC7XXX_BUILD_FIRMWARE) instead of
automatically detecting when the firmware needs to be rebuilt. Users
who set that flag by mistake but do not have libdb, lex and yacc
cannot compile a kernel.
* Not checking that the db.h file it picked will actually compile and
link.
* Butchering the modules_install rule to add a special case for aic7xxx
instead of using the same method that every other module uses.
* Including endian.h in the aic7xxx driver, but endian.h is a user
space include. Code that is linked into the kernel or a module
MUST NOT include user space headers.
* Not correctly defining the dependencies between generated headers and
the code that includes those headers. Generated headers require
explicit dependencies, the only reason it works is because aic7xxx ...
* Ships generated files and overwrites them under the same name.
Shipping generated files is bad enough but is sometime necessary when
the end user might not have the tools to build the files (libdb, lex,
yacc). Overwriting the shipped files under the same name is asking
for problem with source repositories and generating spurious diffs.
All of the above problems are caused by a developer who insists on
doing his own makefile style instead of following the kernel standards
for makefiles. Developers with their own standards are BAD!
BTW, I have made repeated offers to rewrite the aic7xx makefiles for
2.4 but the aic7xxx maintainer refuses to do so. I _will_ rewrite them
in 2.5, as part of the kernel build 2.5 redesign.
Keith Owens, kernel build maintainer.
Andrew Morton
>
> On Fri, 30 Nov 2001, Larry McVoy wrote:
>
> [ A lot of stuff Pro-Sun ]
>
> Wait a minute.
umm.. Let's try to keep moving forward here.
Larry appears to be referring to the proposal sometimes
known as ccClusters. I'd ask him a couple of followup questions:
Is there any precedent for the ccCluster idea, which would
increase confidence that it'll actually work?
Will it run well on existing hardware, or are changes needed?
You're assuming that our current development processes are
sufficient for development of a great 1-to-4-way kernel, and
that the biggest force against that is the introduction of
fine-grained locking. Are you sure about this? Do you see
ways in which the uniprocessor team can improve?
My take is that there's a sort of centralism in the kernel where
key people get atracted into mm/*.c, fs/*.c, net/most_everything
and kernel/*.c while other great wilderness of the tree (with
honourable exceptions) get moldier. How to address that?
Stephan von Krawczynski
Larry McVoy <l...@bitmover.com> wrote:
> [...]
> Here's how you get both. Fork the development efforts into the SMP part
> and the uniprocessor part. The uniprocessor focus is on reliability,
> stability, performance. The SMP part is a whole new development effort,
> which is architected in such a way as to avoid the complexity of a
> traditional SMP implementation.
>
> The uniprocessor team owns the core architecture of the system. The
> abstractions provided, the baseline code, etc., that's all uni. The
> focus there is a small, fast, stable kernel.
>
> The SMP team doesn't get to touch the core code, or at least there is
> a very strong feedback loop against. In private converstations, we've
> started talking about the "punch in the nose" feedback loop, which means
> while it may be necessary to touch generic code for the benefit of SMP,
> someone has to feel strongly enough about it that they well sacrifice
> their nose.
Hi Larry,
let me first tell you this: I am only stating my very personal opinion here and
am probably no guy of your experience or insight in high-tech delevopment
groups. But I saw the whole business for quite some years now, so my thinking:
Your proposal is the wrong way, because:
1) You split up "the crew". Whatever you may call "the crew" here, they all
have one thing in common: they are working on the _same_ project _and_ (very
important either) _one_ man has the final decision. If you look at _any_ other
OS developed by quite a number of completely different people you have to admit
one thing: everything was busted when they began to split up in different
"branches". That simply does not work out. I am only referring to simple human
interaction and communication here, nothing to do with the technical issues.
One of the basic reasons for the success of Linux so far is the collaborated
work of a damn lot of people on the _same_ project.
2) I cannot see the _need_ for such a "team-splitup". If you say one team (core
team) has the "last word" about the baseline code, what do you think will
happen if "necessary" code changes for the second team will be refused? Simple:
they will fork a completely new linux-tree. And this is _the_ end. If you were
to write a driver, what tree will you choose after that? I mean you are dealing
with the main reason why people like linux, here. And not: SCO Unix 3.x,
Unixware, Solaris, Minix, AT&T Unix, Xenix, HPUX, AIX, BSD, NetBSD, BSDi,
Solaris-for-Intel, make-my-day ... (all registered trademark of their
respective owners, which have all low interaction capabilities)
I don't want that, do we want that?
3) Your SMP team (you are talking of true high scaled SMP here) has a very big
problem: it has _very_ few users (compared to UP) and even less developers with
the _hardware_ you need for something like that. I mean you are not talking
about buying an Asus Board and 2 PIII here, you talk about serious, expensive
hardware here. How many people have this at home, or at work for free playing?
Well, see what I mean?
4) Warning, this is the hard stuff!
Ok, so you are fond of SUN. Well, me too. But I am not completely blind, not
yet :-) So I must tell you, if Solaris were the real big hit, then why its
Intel-Version is virtualy been eaten up on the market (the _buying_ market out
there) by linux? The last time I met a guy seriously talking about Solaris
(x86) being "better" than Linux was about three years ago. And btw, this was
_the_ last guy talking about it at all. So lets simply assume this: the Solaris
UP market is already gone, if you are talking about the _mass_ market. This
parrot is _deceased_! It is plain dead.
Now you are dealing with another problem: SUN (being kind of the last resort of
a widespread and really working commercial unix) will have a lot of work to do
in the future to keep up with the simple mass of software and application
coming in for linux, only because it is even _more_ widespread today than
Solaris has ever been. And it is _real_ cheap, and you get it _everywhere_. And
everybody owns a box on which you can use it.
This is going to get very hard for SUN, if they do not enter a stage of
complete rethinking what is going on out there.
To make that clear: _nobody_ here _fights_ against SUN or Solaris. Quite a few
of us like it very much. But this is a commercial product. It needs to be sold
to survive - and that is going to be a future problem. SUN will not survive
only building the high-power low-mass computer. CRAY did not either. So maybe
the real good choice would be this: let the good parts of Solaris (and maybe
its SMP features) migrate into linux. This does not mean they should lay off
the staff, just on contrary: these are brilliant people, let them do what they
can do best, but keep an eye on the market. We are in the state of: the market
_demands_ linux. It has already become a well-known trademark, I tend to
believe better-known than Solaris. Somehow one has the feeling they indeed know
whats coming (fs), but have not come to the final (and hard to take)
conclusion.
And to clarify: I am not taking any drugs. This is serious. I have the strong
feeling, that there is already a big player out there, that has learnt a hard
lesson: IBM - and the lesson named OS/2.
When OS/2 came out, I told the people: if they are not going to give it away
for free, they will not make it. And they didn't. Indeed I did not expect them
to learn at all (simply because big companies are mostly not quick-movers), but
they do really astonishing things nowadays. I have the strong feeling the
management is at least as brilliant as the Solaris developpers and worth every
buck, too.
But this is only my small voice, and quite possibly only few are listening, if
any ...
Regards,
Stephan
PS: Is this really a topic for a kernel-mailing-list?
Davide Libenzi
> On Fri, Nov 30, 2001 at 04:50:34PM -0800, Linus Torvalds wrote:
> > Well, sheer luck, AND:
> > - free availability and _crosspollination_ through sharing of "source
> > code", although biologists call it DNA.
> > - a rather unforgiving user environment, that happily replaces bad
> > versions of us with better working versions and thus culls the herd
> > (biologists often call this "survival of the fittest")
> > - massive undirected parallel development ("trial and error")
>
> Linux is one big genetic algorithms project?
It is more subtle, look better inside :)
- Davide
Davide Libenzi
> On Fri, Nov 30, 2001 at 05:13:38PM -0800, Davide Libenzi wrote:
> > On Fri, 30 Nov 2001, Larry McVoy wrote:
> > Wait a minute.
> > Wasn't it you that were screaming against Sun, leaving their team because
> > their SMP decisions about scaling sucked, because their OS was bloated
> > like hell with sync spinlocks, saying that they tried to make it scale but
> > they failed miserably ?
>
> Yup, that's me, guilty on all charges.
>
> > What is changed now to make Solaris, a fairly vanishing OS, to be the
> > reference OS/devmodel for every kernel developer ?
>
> It's not. I never said that we should solve the same problems the same
> way that Sun did, go back and read the posting.
This is your quote Larry :
<>
If you want to try and make Linux people work like Sun people, I think
that's going to be tough. First of all, Sun has a pretty small kernel
group, they work closely with each other, and they are full time,
highly paid, professionals working with a culture that is intolerant of
anything but the best. It's a cool place to be, to learn, but I think
it is virtually impossible to replicate in a distributed team, with way
more people, who are not paid the same or working in the same way.
<>
So, if these guys are smart, work hard and are professionals, why did they
take bad design decisions ?
Why didn't they implemented different solutions like, let's say "multiple
independent OSs running on clusters of 4 CPUs" ?
What we really have to like about Sun ?
Me personally, if I've to choose, I'll take the logo.
- Davide
Larry McVoy
> > It's not. I never said that we should solve the same problems the same
> > way that Sun did, go back and read the posting.
>
> This is your quote Larry :
>
> <>
> If you want to try and make Linux people work like Sun people, I think
> that's going to be tough. First of all, Sun has a pretty small kernel
> group, they work closely with each other, and they are full time,
> highly paid, professionals working with a culture that is intolerant of
> anything but the best. It's a cool place to be, to learn, but I think
> it is virtually impossible to replicate in a distributed team, with way
> more people, who are not paid the same or working in the same way.
> <>
I'm sorry, I'm lost. You are quoting what I said, that's what I said
said, so what's the point? yes, for the third time, that's what I said
and that's what I meant.
> So, if these guys are smart, work hard and are professionals, why did they
> take bad design decisions ?
> Why didn't they implemented different solutions like, let's say "multiple
> independent OSs running on clusters of 4 CPUs" ?
Because, just like the prevailing wisdom in the Linux hackers, they thought
it would be relatively straightforward to get SMP to work. They started at
2, went to 4, etc., etc. Noone ever asked them to go from 1 to 100 in one
shot. It was always incremental.
I recently talked over the approach I have in mind with the architect of
Sun's multithreaded kernel, the guy who started and guided that effort at
Sun. He agreed that if he had thought of my approach he would have done
it that way. We both agreed it was unlikely that anyone would think of
that approach without first having done it the hard way.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Tim Hockin
> something more complicated than what we ourselves are, yet natural
> selection did it without even thinking.
a very interesting argument, but not very pertinent - we don't have 10's of
thousands of year or even really 10's of years. We have to use intellect
to root out the obviously bad ideas, and even more importantly the
bad-but-not-obviously-bad ideas.
> Quite frankly, Sun is doomed. And it has nothing to do with their
> engineering practices or their coding style.
I'd love to hear your thoughts on why.
Linus Torvalds
On Fri, 30 Nov 2001, Tim Hockin wrote:
>
> > I'm deadly serious: we humans have _never_ been able to replicate
> > something more complicated than what we ourselves are, yet natural
> > selection did it without even thinking.
>
> a very interesting argument, but not very pertinent - we don't have 10's of
> thousands of year or even really 10's of years. We have to use intellect
> to root out the obviously bad ideas, and even more importantly the
> bad-but-not-obviously-bad ideas.
Directed evolution - ie evolution that has more specific goals, and faster
penalties for perceived failure, works on the scale of tens or hundreds of
years, not tens of thousands. Look at dog breeding, but look even more at
livestock breeding, where just a few decades have made a big difference.
The belief that evolution is necessarily slow is totally unfounded.
HOWEVER, the belief that _too_ much direction is bad is certainly not
unfounded: it tends to show up major design problems that do not show up
with less control. Again, see overly aggressive breeding of some dogs
causing bad characteristics, and especially the poultry industry.
And you have to realize that the above is with entities that are much more
complex than your random software project, and where historically you have
not been able to actually influence anything but selection itself.
Being able to influence not just selection, but actually influencing the
_mutations_ that happen directly obviously cuts down the time by another
large piece.
In short, your comment about "not pertinent" only shows that you are
either not very well informed about biological changes, or, more likely,
it's just a gut reaction without actually _thinking_ about it.
Biological evolution is alive and well, and does not take millions of
years to make changes. In fact, most paleolontologists consider some of
the changes due to natural disasters to have happened susprisingly fast,
even in the _absense_ of "intelligent direction".
Of course, at the same time evolution _does_ heavily tend to favour
"stable" life-forms (sharks and many amphibians have been around for
millions of years). That's not because evolution is slow, but simply
because good lifeforms work well in their environments, and if the
environment doesn't change radically they have very few pressures to
change.
There is no inherent "goodness" in change. In fact, there are a lot of
reasons _against_ change, something we often forget in technology. The
fact that evolution is slow when there is no big reason to evolve is a
_goodness_, not a strike against it.
> > Quite frankly, Sun is doomed. And it has nothing to do with their
> > engineering practices or their coding style.
>
> I'd love to hear your thoughts on why.
You heard them above. Sun is basically inbreeding. That tends to be good
to bring out specific characteristics of a breed, and tends to be good for
_specialization_. But it's horrible for actual survival, and generates a
very one-sided system that does not adapt well to change.
Microsoft, for all the arguments against them, is better off simply
because of the size of its population - they have a much wider consumer
base, which in turn has caused them largely to avoid specialization. As a
result, Microsoft has a much wider appeal - and suddenly most of the
niches that Sun used to have are all gone, and its fighting for its life
in many of its remaining ones.
Why do you think Linux ends up being the most widely deployed Unix? It's
avoided niches, it's avoided inbreeding, and not being too directed means
that it doesn't get the problems you see with unbalanced systems.
Face it, being one-sided is a BAD THING. Unix was dying because it was
becoming much too one-sided.
Try to prove me wrong.
Linus
Victor Yodaiken
>
> whole solar system is?
>
> Guess what - it's not Linux, it's not Solaris, and it's not your car.
>
> It's you. And me.
>
> And think about how you and me actually came about - not through any
> complex design.
>
> Right. "sheer luck".
Somehow this does not give me a warm and fuzzy feeling about
the length of the next Linux kernel development cycle.
> And don't EVER make the mistake that you can design something better than
> what you get from ruthless massively parallel trial-and-error with a
> feedback cycle. That's giving your intelligence _much_ too much credit.
Linux is what it is because of design, not accident. And you know
that better than anyone.
If mindless rooting about could make a good OS, then we'd all be using
[ in a rare moment of good sense I don't finish this sentence ]
The question is whether Linux can still be designed at
current scale.
> Quite frankly, Sun is doomed. And it has nothing to do with their
> engineering practices or their coding style.
The San Andreas fault?
Linus Torvalds
On Fri, 30 Nov 2001, Victor Yodaiken wrote:
>
> > And don't EVER make the mistake that you can design something better than
> > what you get from ruthless massively parallel trial-and-error with a
> > feedback cycle. That's giving your intelligence _much_ too much credit.
>
> Linux is what it is because of design, not accident. And you know
> that better than anyone.
Let's just be honest, and admit that it wasn't designed.
Sure, there's design too - the design of UNIX made a scaffolding for the
system, and more importantly it made it easier for people to communicate
because people had a mental _model_ for what the system was like, which
means that it's much easier to discuss changes.
But that's like saying that you know that you're going to build a car with
four wheels and headlights - it's true, but the real bitch is in the
details.
And I know better than most that what I envisioned 10 years ago has
_nothing_ in common with what Linux is today. There was certainly no
premeditated design there.
And I will claim that nobody else "designed" Linux any more than I did,
and I doubt I'll have many people disagreeing. It grew. It grew with a lot
of mutations - and because the mutations were less than random, they were
faster and more directed than alpha-particles in DNA.
> The question is whether Linux can still be designed at
> current scale.
Trust me, it never was.
And I will go further and claim that _no_ major software project that has
been successful in a general marketplace (as opposed to niches) has ever
gone through those nice lifecycles they tell you about in CompSci classes.
Have you _ever_ heard of a project that actually started off with trying
to figure out what it should do, a rigorous design phase, and a
implementation phase?
Dream on.
Software evolves. It isn't designed. The only question is how strictly you
_control_ the evolution, and how open you are to external sources of
mutations.
And too much control of the evolution will kill you. Inevitably, and
without fail. Always. In biology, and in software.
Amen.
Linus
Larry McVoy
> > The question is whether Linux can still be designed at
> > current scale.
>
> Trust me, it never was.
Yeah, right, Linus. We should all go home and turn loose the monkeys and
let them pound on the keyboard. They'll just as good a job, in fact, by
your reasoning they'll get there faster, they aren't so likely to waste
time trying to design it.
I can't believe the crap you are spewing on this one and I don't think you
do either. If you do, you need a break. I'm all for letting people explore,
let software evolve, that's all good. But somebody needs to keep an eye on
it.
If that's not true, Linus, then bow out. You aren't needed and *you*
just proved it. You can't have it both ways. Either you are here
for a reason or you aren't. So which is it? You're arguing that you
don't matter. I personally don't agree, I think Linux would be a pile
of dog doo without you. If you don't agree, back off and see what happens.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Linus Torvalds
On Fri, 30 Nov 2001, Larry McVoy wrote:
>
> I can't believe the crap you are spewing on this one and I don't think you
> do either. If you do, you need a break. I'm all for letting people explore,
> let software evolve, that's all good. But somebody needs to keep an eye on
> it.
Like somebody had to keep an eye on our evolution so that you had a chance
to be around?
Who's naive?
> If that's not true, Linus, then bow out. You aren't needed and *you*
> just proved it.
Oh, absolutely.
I wish more people realized it. Some people realize it only when they get
really pissed off at me and say "Go screw yourself, I can do this on my
own". And you know what? They are right too, even if they come to that
conclusion for what I consider the wrong reasons.
The reason I'm doing Linux is not because I think I'm "needed". It's
because I enjoy it, and because I happen to believe that I'm better than
most at it. Not necessarily better than everybody else around there, but
good enough, and with the social ties to make me unbeatable right now.
But "indispensable"? Grow up, Larry. You give me too much credit.
And why should I bow out just because I'm not indispenable? Are you
indispensable for the continued well-being of humanity? I believe not,
although you are of course free to disagree. Should you thus "bow out" of
your life just because you're strictly speaking not really needed?
Do I direct some stuff? Yes. But, quite frankly, so do many others. Alan
Cox, Al Viro, David Miller, even you. And a lot of companies, which are
part of the evolution whether they realize it or not. And all the users,
who end up being part of the "fitness testing".
And yes, I actually do believe in what I'm saying.
Linus
Andreas Dilger
> On Fri, Nov 30, 2001 at 04:50:34PM -0800, Linus Torvalds wrote:
> > Quite frankly, Sun is doomed. And it has nothing to do with their
> > engineering practices or their coding style.
>
> The San Andreas fault?
I wish people would stop saying that, I have never been to California. ;-)
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Mike Fedyk
> Henning, perhaps you can explain to me how the following isn't a
>
> "I don't do XYZ"
>
> "XYZ"
>
> statement?
>
> On Fri, Nov 30, 2001 at 06:53:05PM +0100, Henning Schmiedehausen wrote:
> > You may want to know that I work in this
> > industry for about 15 years and write commercial code (that is "code
> > that ships") since about that time (and I don't run around telling
> > everybody each and every time about it and what I've already done).
>
> That would be the "I don't do XYZ..."
>
> > I've
> > written code in a good two dozen languages (including things that really
> > deserve to die like Comal) and I've worked in projects from "one man
> > show" to "lots of people in Elbonia also work on this".
>
> And this would be the "XYZ".
>
> If you are going to yell at people for a particular behaviour, it's really
> more effective if you don't show that behaviour in the midst of your yelling,
> wouldn't you agree? Just a friendly thought.
>
He's basically complaining that you like to point out what you have done in
the past a lot. Then goes to say that he has qualifications to prove that
his opinion should be listened to.
Not that I've been reading lkml long enough to notice...
> > So, please, please, Larry, _STOP THE FUCK PATRONIZING OTHERS_.
>
> It would appear that you find everything I say patronizing, regardless of
> what it is or how it is said. I'm sorry about that, but I'm not going
> to change how I speak to suit you. Yell all you want. I'd suggest
> that if you find my emails offensive, you add me to your kill file.
>
I don't know about you, but I wouldn't want to be in anyone's killfile.
> > The question now is, what is "amateur behaviour": Forcing this driver
> > writer to change or to tolerate his style in his driver? We're still
> > talking about a driver, not about the VM subsystem or the networking
> > core.
>
> Your approach to this whole topic is a good example of why I run my own
> company and I have absolute authority to fire people at will. If you
> worked here and you persisted with this approach, you would be fired,
> without question. I don't know how to say it more clearly, I don't
> say it lightly, hiring someone, training them, all of that is a huge
> investment. One which I would discard if you couldn't fit in. Coding
> style is part of fitting in, it isn't optional in any code I pay for.
>
Key words: "pay for".
This is Linux-Kernel. Each developer is on their own on how they pay the
their bills. The question is... Why not accept a *driver* that *works* but
the source doesn't look so good? Maintainability? Yes. Take the code, and
encourage better code. Or even convert said initial submission to the
kernel style.
What really needs to happen...
Accept the driver, but also accept future submissions that *only* clean up
the comments. It has been said that patches with comments and without code
have been notoriously droped.
mf
Victor Yodaiken
> and I doubt I'll have many people disagreeing. It grew. It grew with a lot
> of mutations - and because the mutations were less than random, they were
> faster and more directed than alpha-particles in DNA.
Ok. There was no design, just "less than random mutations".
Deep.
There was a overall architecture, from Dennis and Ken. There
where a couple of good sound design principles, and there were a
couple of people with some sense of how it should work together.
None of that is incompatible with lots of trial and error and learn
by doing.
Here's a characteristic good Linux design method ,( or call it "less than random
mutation method" if that makes you feel happy): read the literature,
think hard, try something, implement
it, find it doesn't do what was hoped and tear the whole thing down.
That's design. Undesigned systems use the method of: implement some crap and then try to
engineer the consequences away.
>
> > The question is whether Linux can still be designed at
> > current scale.
>
> Trust me, it never was.
Trust you? Ha.
> And I will go further and claim that _no_ major software project that has
> been successful in a general marketplace (as opposed to niches) has ever
> gone through those nice lifecycles they tell you about in CompSci classes.
That's classic:
A) "trust me"
B) now here's a monster bit of misdirection for you to choke on.
Does anyone believe in those stupid software lifcycles?
No.
So does it follow that this has anything to do with design?
No.
> Have you _ever_ heard of a project that actually started off with trying
> to figure out what it should do, a rigorous design phase, and a
> implementation phase?
>
> Dream on.
I've seen better arguments in slashdot.
There was no puppet master - ok.
There was no step by step recipe that showed how it should all work - ok
There was no design involved - nope.
Mike Fedyk
> _the_ last guy talking about it at all. So lets simply assume this: the Solaris
> UP market is already gone, if you are talking about the _mass_ market. This
> parrot is _deceased_! It is plain dead.
Not completely. Many people who *need* to develop for solaris on sun
hardware will run solaris x86 at home (or maybe on a corporate laptop) to be
able to work at home and test the software there too. I know one such
developer myself, there have to be more.
> So maybe
> the real good choice would be this: let the good parts of Solaris (and maybe
> its SMP features) migrate into linux.
Before 2.3 and 2.4 there probably would've been much more contention against
something like this. Even now with large SMP scalability goals, I think it
would be hard to get something like this to be accepted into Linux.
mf
Alexander Viro
On Fri, 30 Nov 2001, Mike Fedyk wrote:
> This is Linux-Kernel. Each developer is on their own on how they pay the
> their bills. The question is... Why not accept a *driver* that *works* but
> the source doesn't look so good?
Because this "works" may very well include exploitable buffer overruns in
kernel mode. I had seen that - ioctl() assuming that nobody would pass
it deliberately incorrect arguments and doing something like
copy_from_user(&foo, arg, sizeof(foo));
copy_from_user(bar, foo.addr, foo.len);
The problem being, seeing what really happens required half an hour of
wading through the shitload of #defines. _After_ seeing copy_from_user()
in a macro during greap over the tree - that's what had triggered the
further search.
> What really needs to happen...
>
> Accept the driver, but also accept future submissions that *only* clean up
> the comments. It has been said that patches with comments and without code
> have been notoriously droped.
Commented pile of shit is still nothing but a pile of shit. If you comment
Netscape to hell and back it will still remain a festering dungpile. Same
for NT, GNOME, yodda, yodda...
Linus Torvalds
On Fri, 30 Nov 2001, Victor Yodaiken wrote:
>
> Ok. There was no design, just "less than random mutations".
> Deep.
I'm not claiming to be deep, I'm claiming to do it for fun.
I _am_ claiming that the people who think you "design" software are
seriously simplifying the issue, and don't actually realize how they
themselves work.
> There was a overall architecture, from Dennis and Ken.
Ask them. I'll bet you five bucks they'll agree with me, not with you.
I've talked to both, but not really about this particular issue, so I
might lose, but I think I've got the much better odds.
If you want to see a system that was more thoroughly _designed_, you
should probably point not to Dennis and Ken, but to systems like L4 and
Plan-9, and people like Jochen Liedtk and Rob Pike.
And notice how they aren't all that popular or well known? "Design" is
like a religion - too much of it makes you inflexibly and unpopular.
The very architecture of UNIX has very much been an evolution. Sure, there
are some basic ideas, but basic ideas do not make a system.
When they say that the devil is in the details, they are trying to tell
you that the details MATTER. In fact, the details matter quite a lot more
than the design ever does.
> Here's a characteristic good Linux design method ,( or call it "less than random
> mutation method" if that makes you feel happy): read the literature,
> think hard, try something, implement
Hah.
I don't think I've seen very many examples of that particular design
methodology.
It's impressive that you think this is how stuff gets done, but from
personal experience I would say that it's certainly not true to any
noticeable degree. The impressive part is that Linux development could
_look_ to anybody like it is that organized.
Yes, people read literature too, but that tends to be quite spotty. t's
done mainly for details like TCP congestion control timeouts etc - they
are _important_ details, but at the same time we're talking about a few
hundred lines out of 20 _million_.
And no, I'm no tclaiming that the rest is "random". But I _am_ claiming
that there is no common goal, and that most development ends up being done
for fairly random reasons - one persons particular interest or similar.
It's "directed mutation" on a microscopic level, but there is very little
macroscopic direction. There are lots of individuals with some generic
feeling about where they want to take the system (and I'm obviously one of
them), but in the end we're all a bunch of people with not very good
vision.
And that is GOOD.
A strong vision and a sure hand sound like good things on paper. It's just
that I have never _ever_ met a technical person (including me) whom I
would trust to know what is really the right thing to do in the long run.
Too strong a strong vision can kill you - you'll walk right over the edge,
firm in the knowledge of the path in front of you.
I'd much rather have "brownian motion", where a lot of microscopic
directed improvements end up pushing the system slowly in a direction that
none of the individual developers really had the vision to see on their
own.
And I'm a firm believer that in order for this to work _well_, you have to
have a development group that is fairly strange and random.
To get back to the original claim - where Larry idolizes the Sun
engineering team for their singlemindedness and strict control - and the
claim that Linux seems ot get better "by luck": I really believe this is
important.
The problem with "singlemindedness and strict control" (or "design") is
that it sure gets you from point A to point B in a much straighter line,
and with less expenditure of energy, but how the HELL are you going to
consistently know where you actually want to end up? It's not like we know
that B is our final destination.
In fact, most developers don't know even what the right _intermediate_
destinations are, much less the final one. And having somebody who shows
you the "one true path" may be very nice for getting a project done, but I
have this strong belief that while the "one true path" sometimes ends up
being the right one (and with an intelligent leader it may _mostly_ be the
right one), every once in a while it's definitely the wrong thing to do.
And if you only walk in single file, and in the same direction, you only
need to make one mistake to die.
In contrast, if you walk in all directions at once, and kind of feel your
way around, you may not get to the point you _thought_ you wanted, but you
never make really bad mistakes, because you always ended up having to
satisfy a lot of _different_ opinions. You get a more balanced system.
This is what I meant by inbreeding, and the problem that UNIX
traditionally had with companies going for one niche.
(Linux companies also tend to aim for a niche, but they tend to aim for
_different_ niches, so the end result is the very "many different
directions" that I think is what you _want_ to have to survive).
> > And I will go further and claim that _no_ major software project that has
> > been successful in a general marketplace (as opposed to niches) has ever
> > gone through those nice lifecycles they tell you about in CompSci classes.
>
> That's classic:
> A) "trust me"
> B) now here's a monster bit of misdirection for you to choke on.
>
> Does anyone believe in those stupid software lifcycles?
> No.
> So does it follow that this has anything to do with design?
> No.
Hey, the whole _notion_ of "design" is that you know what you're going to
write, and you design for it.
Or do you have some other meaning of the word "design" that I haven't
heard about.
Linus
Mike Fedyk
> Here's how you get both. Fork the development efforts into the SMP part
> and the uniprocessor part.
Basically with linux, and enough #ifdef's you end up with both in one. IIUC
What would be nice is UP only drivers for initial release. Write a driver
module that says "I'm made for UP and haven't been tested with SMP/HighMEM"
so if you try to compile it with those features it would break with a
helpful error message.
What would be interesting would be SMP with support for UP. The UP only
module would be inserted into a SMP kernel, but would only work inside one
processor, and would have source compatibility with both UP ans SMP kernels.
No non-UP locking required.
Is something like this possible?
Stephen Satchell
At 06:02 PM 11/30/01 -0800, Tim Hockin wrote:
> > Linux sez:
> > I'm deadly serious: we humans have _never_ been able to replicate
> > something more complicated than what we ourselves are, yet natural
> > selection did it without even thinking.
>
>a very interesting argument, but not very pertinent - we don't have 10's of
>thousands of year or even really 10's of years. We have to use intellect
>to root out the obviously bad ideas, and even more importantly the
>bad-but-not-obviously-bad ideas.
Disagree with your position strongly. It's very pertinent.
Most of the bad-but-not-obviously-bad ideas get rooted out by people trying
them and finding them to be wanting. Take, for example, the VM flap in the
2.4.* tree: an astonishing side effect of the operation of the VM system
caused people to come up with one that wasn't so astonishing. We're not
sure why the original VM caused such problems. We fixed it anyway. (No, I
played no part in that particular adventure, I was just viewing from the
sidelines.)
The "Linux Way" as I understand it is to release early and release
often. That means that we go through a "generation" of released code every
few weeks, and a "generation" of beta candidates just about daily...and if
you include the patches that appear here during every 24 hours, the
generation cycle is even faster than that. That means that any mutations
that are detrimental to the organism are exposed within days -- sometimes
even hours -- of their introduction into the code base.
When we have a development tree open (as 2.5 is now freshly open) there are
even more generations of code, which further makes natural selection viable
as a weeding process for good and bad code. The difference is that the
number of people affected by the weeding process is smaller, and the
probability of killing production systems with mutations becomes
smaller. The population of the organism is thus healthier because
mutations affect a smaller fraction of the population, and the chances of
expensive illness is reduced.
Beneficial mutations are "back-ported" into the 2.4 and even the 2.2 code
trees, mutations that have proven their worth by extensive experimentation
and experience. Unlike the biological equivalent, this selective spreading
of mutations further improves the health of the population of organisms.
Now that I've stretched the analogy as far as I care to, I will stop
now. Please consider the life-cycle of the kernel when thinking about what
Linus said.
Just my pair-o-pennies(tm).
Stephen Satchell
Stephen Satchell
At 07:30 PM 11/30/01 -0800, Larry McVoy wrote:
>Yeah, right, Linus. We should all go home and turn loose the monkeys and
>let them pound on the keyboard. They'll just as good a job, in fact, by
>your reasoning they'll get there faster, they aren't so likely to waste
>time trying to design it.
You are confusing the production of Shakespeare with the production of good
OS code.
The high-level design aspect is that there is a problem to be solved or a
feature to be provided. That represents a goal. Some goals are good and
some goals are bad. In many cases, you learn which when you actually do
the code to implement the goal, and determine whether it helps, hinders, or
just bloats the OS.
The lower-level design aspect is planning how to achieve the
goal. Implementation of the lower-level design in code to achieve the goal
can contain flaws, flaws that don't appear on paper but raise ugly warts
when you actually try the implementation out. In this sense, this is like
a mutation to achieve a specific effect -- blue eyes, say -- that has a
disastrous side effect -- it causes the heart to have a single chamber
instead of four.
This assumes that your, um, mutation even lets the organism live. Many
don't. We call it debugging.
>I can't believe the crap you are spewing on this one and I don't think you
>do either. If you do, you need a break. I'm all for letting people explore,
>let software evolve, that's all good. But somebody needs to keep an eye on
>it.
I don't know you, so I don't know how long you have been in the
industry. I've watched Unix evolve from the beginning. AT&T streams
versus Berkeley sockets was a wonderful war, and we are all for the better
for the experimentation because we got the best of both -- especially as I
was involved in ARPAnet in the beginning and saw the influence of what
turned into TCP/IP in both environments. We have different styles of
system initialization, with some being better for manual management and
some being better for package management -- and we have both living in the
world today. The development of X-terminals was fun, too, to try to
divorce the requirements for a screen from the system that feeds it, and
yet today the two different processes run together in a single box without
too much problem.
These were the products of evolution, of system designers trying to meet a
need, and the process of getting there was painful and left a lot of
corpses behind it -- piles of dead code, for sure, but also dead companies
and burned-out development people. That's part of the business,
particularly in the commercial world.
"But someone has to keep an eye on it." Very true. After all, in this
process of natural selection, how do we weed out the mutations that don't
work? In the Linux development environment, we have several levels of
weeding going on. First, there is peer testing -- people downloading
patches and trying out new things, which weeds out the worst of the
mutations. Then, there are the maintainers who sit in judgement as the
patches roll by, picking out the deformed ones bodily and making sure that
two patches that change the same code play nicely with each other. We then
have the pre-releases, which for the 2.4 tree were patch-inspected and
maintained by Linux and by Alan Cox, which people can download and try on
playpen systems with applications to see if anything subtly nasty crept in
-- this weeds out a few of the mutations that harm the organism but doesn't
kill it outright. Finally, we have a production release into which people
throw all the varied and wacky applications -- and sometimes an ugly (like
the VM problem) finally is exposed to the light.
Interestingly, you see a similar development process at commercial software
vendors and with the successful Open Source projects. Some of the details
differ (especially the details on the review process) but the overall
process is similar. Why? It works.
I suggest you check out this site http://www.swebok.org/ and specifically
download this document
http://www.swebok.org/documents/stoneman095/Trial_Version_0_95.pdf AND READ
IT before responding further. While the Software Engineering Body Of
Knowledge does not use the exact concepts that Linus used in describing how
things are done, you will find interesting correlations between what is
described by this document and the idea that you have called "crap."
Pay particular attention to the section on Validation and Verification.
Stephen Satchell
Zilvinas Valinskas
> [cc list trimmed]
>
> You are confusing the production of Shakespeare with the production of good
> OS code.
>
> The high-level design aspect is that there is a problem to be solved or a
> feature to be provided. That represents a goal. Some goals are good and
> some goals are bad. In many cases, you learn which when you actually do
> the code to implement the goal, and determine whether it helps, hinders, or
> just bloats the OS.
>
Sometimes design only _works_ it's way around problems ...
--
Zilvinas Valinskas
Tim Hockin
> Most of the bad-but-not-obviously-bad ideas get rooted out by people trying
> them and finding them to be wanting. Take, for example, the VM flap in the
>
Ahh right, like the OOM killer. There's a brilliant idea that got rooted
out to where it belongs...
> The "Linux Way" as I understand it is to release early and release
> often. That means that we go through a "generation" of released code every
And disregard the "mutations" that have already been "selected for" (to
carry the analogy) in other systems. And disregard any edge-case that is
"too hard" or "too rare" or "involves serious testing".
> Now that I've stretched the analogy as far as I care to, I will stop
> now. Please consider the life-cycle of the kernel when thinking about what
> Linus said.
I can't consider joe.random developer adding a feature as a "mutation".
It's just not analogous in my mind.
Alan Cox
> mutation method" if that makes you feel happy): read the literature,
> think hard, try something, implement it
That assumes computer science is a functional engineering discipline. Its
not, at best we are at the alchemy stage of progression. You put two things
together it goes bang and you try to work out why.
In many of these fields there is no formal literature. The scientific paper
system in computer science is based on publishing things people already
believe. Much of the rest of the knowledge is unwritten or locked away in
labs as a trade secret, and wil probably never be reused.
Take TCP for example. The TCP protocol is specified in a series of
documents. If you make a formally correct implementation of the base TCP RFC
you won't even make connections. Much of the flow control behaviour, the
queueing and the detail is learned only by being directly part of the
TCP implementing community. You can read all the scientific papers you
like, it will not make you a good TCP implementor.
Alan
Alan Cox
> that the biggest force against that is the introduction of
> fine-grained locking. Are you sure about this? Do you see
> ways in which the uniprocessor team can improve?
ccCluster seems a sane idea to me. I don't by Larry's software engineering
thesis but ccCluster makes sense simply because when you want an efficient
system in computing you get it by not pretending one thing is another.
SMP works best when the processors are not doing anything that interacts
with another CPU.
> key people get atracted into mm/*.c, fs/*.c, net/most_everything
> and kernel/*.c while other great wilderness of the tree (with
> honourable exceptions) get moldier. How to address that?
Actually there are lots of people who work on the driver code nowdays
notably the janitors. The biggest problem there IMHO is that when it comes
to driver code Linus has no taste, so he keeps accepting driver patches
which IMHO are firmly at the hamburger end of "taste"
Another thing for 2.5 is going to be to weed out the unused and unmaintained
drivers, and either someone fixes them or they go down the comsic toilet and
we pull the flush handle before 2.6 comes out.
Thankfully the scsi layer breakage is going to help no end in the area of
clockwork 8 bit scsi controllers, which is major culprit number 1. number 2
is probably the audio which is hopefully going to go away with ALSA based
code.
Alan
Alan Cox
> > 2 CPUs ?
>
> No, that wasn't me. I said it shouldn't scale beyond 4 cpus. I'd be pretty
> lame if I said it couldn't scale with more than 2. Should != could.
Question: What happens when people stick 8 threads of execution on a die with
a single L2 cache ?
Rik van Riel
> And don't EVER make the mistake that you can design something better than
> what you get from ruthless massively parallel trial-and-error with a
> feedback cycle. That's giving your intelligence _much_ too much credit.
So, are we going to take out the appendix in 2.5 or will
we continue hoping our kernel doesn't catch an illness
without actually doing anything preventive ?
Biological selection does nothing except removing the weak
ones, it cannot automatically create systems which work well.
In short, I believe the biological selection is just that,
selection. The creation of stuff will need some direction.
regards,
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
Rik van Riel
> On Fri, Nov 30, 2001 at 06:17:43PM -0800, Davide Libenzi wrote:
> > So, if these guys are smart, work hard and are professionals, why did they
> > take bad design decisions ?
> > Why didn't they implemented different solutions like, let's say "multiple
> > independent OSs running on clusters of 4 CPUs" ?
>
> Because, just like the prevailing wisdom in the Linux hackers, they
> thought it would be relatively straightforward to get SMP to work.
> They started at 2, went to 4, etc., etc. Noone ever asked them to go
> from 1 to 100 in one shot. It was always incremental.
Incremental stuff always breaks and misses out on the corner
cases. The same seems to be true for stuff coming out of
random mutation and biological selection ... natural selection
really doesn't care about corner cases.
This, for example, has always resulted in a VM subsystem which
works nicely under low load but falls apart under high load.
Any efforts to fix that corner case have been met with nothing
but resistance.
Lets face it, if you want to deal with corner cases you don't
want to deal with Linus.
regards,
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
-