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 ;)).
Then we can all get on with doing useful things.
Cheers
Peter
> 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
The problem was solved years ago.
scripts/Lindent
On Thu, Nov 29, 2001 at 09:29:26AM +1000, Peter Waltenberg wrote:
> 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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Wed, 2001-11-28 at 18:29, Peter Waltenberg wrote:
> 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
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...
> 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 :-)
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Wed, 28 Nov 2001, Larry McVoy wrote:
> > 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
From: Alexander Viro <[email protected]>
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.
:-)
Alexander Viro wrote:
>
>>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
On Wed, 28 Nov 2001, Alexander Viro wrote:
> 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 <[email protected]> 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...
>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 :-)
Cool. I can really see it. "foo inc." releases a GPL driver for Linux
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).
Press release:
"If you support Linux, you may get flamed and humiliated in public for
doing so. Don't do it."
Grow up. There is more to life than coding style that is not "Al Viro
compatible (TM)".
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". If they only would use sane init scripts. ;-)
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
On Fri, Nov 30, 2001 at 10:00:00AM +0000, Henning P. Schmiedehausen wrote:
> Larry McVoy <[email protected]> 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...
>
> >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 :-)
>
> Cool. I can really see it. "foo inc." releases a GPL driver for Linux
> 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
On Fri, 2001-11-30 at 16:26, Larry McVoy wrote:
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 [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
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.
Jeff
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
On Fri, 2001-11-30 at 17:47, Jeff Garzik wrote:
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 [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
> 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.
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
On Fri, Nov 30, 2001 at 06:15:28PM +0100, Henning Schmiedehausen wrote:
> 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.
>
> And you really want to judge code just because someone likes to wrap
> 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
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.
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...
Henning Schmiedehausen wrote:
> 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...
Hi Larry,
On November 30, 2001 06:27 pm, Larry McVoy wrote:
> 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.
Err, because you're still working at Sun? I'll just ignore that last little
non sequitur, your comment about professionals adapting to the prevailing
standards is right on.
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.
--
Daniel
> 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
> 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.
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.
Thanks.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Fri, 2001-11-30 at 18:27, Larry McVoy wrote:
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 [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
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.
Alan Cox wrote:
>
> > 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.
Russell King wrote:
>
> 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).
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.
Thanks.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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:[email protected]:/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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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.
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 <[email protected]>
http://www.kyuzz.org/antirez
finger [email protected] for PGP key
28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF
Russell King wrote:
>
> 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?
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.
> 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
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?
On Fri, 2001-11-30 at 18:55, Alexander Viro wrote:
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 [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
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 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
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 ;)).
>
> 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.
http://www.akamai.com
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
antirez wrote:
>
> 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.
http://www.akamai.com
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.
Steve McConnell
source: http://www.construx.com/stevemcc/cc.htm
-john
On Friday, November 30, 2001, at 01:19 , Dana Lacoste wrote:
> 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/
[email protected]
"Alcohol and calculus don't mix. Developer/Project Lead
Don't drink and derive." --Unknown http://www.themes.org/
[email protected]
=====================================================================
Diverse coding styles in the Linux kernel create long term maintenance
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
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.
Yes, lead by example, it's at least as effective. Maybe humiliation works at
Sun, when you're getting a paycheck, but in the world of volunteer
development it just makes people walk.
--
Daniel
"John H. Robinson, IV" wrote:
>
> 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.
http://www.akamai.com
Book : Code Complete
Author : Steve McConnell
Publisher: Microsoft Press
Nestor :-)
----- Original Message -----
From: "Paul G. Allen" <[email protected]>
To: "Linux kernel developer's mailing list" <[email protected]>;
<[email protected]>; <[email protected]>
Sent: Friday, November 30, 2001 10:15 AM
Subject: Re: Coding style - a non-issue
> 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 ;)).
> >
> > 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.
> http://www.akamai.com
On Fri, 30 Nov 2001, Martin Dalecki wrote:
> > 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: [email protected], PGP key available +
On Fri, 2001-11-30 at 19:13, Larry McVoy wrote:
> 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 [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
Russell King wrote:
>
> 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:[email protected]:/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.
On Fri, Nov 30, 2001 at 07:40:29PM +0100, Maciej W. Rozycki wrote:
> 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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
"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.
> 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
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".
--
Salvatore Sanfilippo <[email protected]>
http://www.kyuzz.org/antirez
finger [email protected] for PGP key
28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF
"Paul G. Allen" 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.
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
On Fri, Nov 30, 2001 at 07:43:01PM +0100, Daniel Phillips wrote:
> 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.
>
> Yes, lead by example, it's at least as effective.
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
Hi Jeff and Paul :)
>"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 case
>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
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.
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.
i agree with that dana. Sure coding style is important but lets not get
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:[email protected]]
Sent: Friday, November 30, 2001 1:19 PM
To: 'Larry McVoy'; Henning Schmiedehausen
Cc: Jeff Garzik; [email protected]
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
Jeff Garzik wrote:
>
>
> 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.
http://www.akamai.com
"Paul G. Allen" wrote:
> 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
"Ra?l N??ez de Arenas Coronado" wrote:
>
> >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...
I prefer Pig Latin myself. ;)
>
> >> - 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.
>
> 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.
>
There's no way on earth I would ever start reading at the beginning of 3
million lines of code just so I can understand bobsdriver.o, which is
only 10,000 lines. I should not have to start at the beginning of
bobsdrvier.o either if I only needed to solve one problem in one
function somewhere near the end of it.
I have worked on several large projects and have rarely known how every
piece of any of them worked. I didn't have to. I only needed to know
about the portion(s) I was responsible for. I was able to do that with
the better projects because they were commented correctly and were
rather self documenting.
> Of course, more comments and more descriptive names doesn't harm,
> but some times they bloat the code...
>
Actually it bloats the source (we all know C++ bloats the resulting code
;), but what's wrong with that? At least a person can understand what's
going on and get to coding, instead of deciphering.
PGA
--
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
http://www.akamai.com
antirez wrote:
>
> 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.
http://www.akamai.com
John Kodis wrote:
>
> 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.
http://www.akamai.com
Followup to: <[email protected]>
By author: Jeff Garzik <[email protected]>
In newsgroup: linux.dev.kernel
>
> "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.
>
Indeed. What can you say for a technique which basically promotes
*reducing* abstraction and information hiding?
There is a reason why the Win64 ABI uses the same "int" and "long" as
Win32... (both are 32 bits.) They added meaningless abstractions, and
didn't add abstractions where they needed to...
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
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.
-
> > Of course, more comments and more descriptive names doesn't harm,
> > but some times they bloat the code...
> >
>
> Actually it bloats the source (we all know C++ bloats the resulting 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.
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.
> 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.
> 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.
--
Daniel
This is my last post on this topic, I don't think I can say more than I have.
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
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.
-
Followup to: <[email protected]>
By author: Larry McVoy <[email protected]>
In newsgroup: linux.dev.kernel
> >
> > 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.
>
So the sensible thing to do is, again, to criticize the code, not the
coder.
There are multiple reasons for that:
a) The code is what counts.
b) People take personal attacks, well, personally. It causes
unnecessary bad blood.
c) There are people who will produce beautiful code one minute, and
complete shitpiles the next one.
If a certain piece of code is a shitpile, go ahead and say so. Please
do, however, explain why that is, and please give the maintainer a
chance to listen before being flamed publically.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On Fri, 30 Nov 2001, Andrew Morton wrote:
| 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
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...
On Fri, Nov 30, 2001 at 02:17:33PM -0800, Andrew Morton wrote:
> 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
On Fri, 30 Nov 2001, Alexander Viro wrote:
> 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/
On Fri, 30 Nov 2001, Jeff Garzik wrote:
> "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/
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.
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/
On Fri, 30 Nov 2001, Andrew Morton wrote:
> 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.
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/
Hi Rik,
On December 1, 2001 01:35 am, Rik van Riel wrote:
> On Fri, 30 Nov 2001, Andrew Morton wrote:
> > 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.
>
> 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.
You just reminded me of Minnesota Fats most famous quote:
"The more I practice, the luckier I get"
--
Daniel
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
On Fri, 30 Nov 2001, Larry McVoy wrote:
[ 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
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?
mrc
--
Mike Castle [email protected] http://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
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.
> 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
On 30 Nov 2001 18:15:28 +0100,
Henning Schmiedehausen <[email protected]> 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.
:-)) This made my day.. May be my week. :-))
100% agree (better not play gods) and i think this is the end of
the discussion.
Petko
Linus Torvalds wrote:
> 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 wrote:
>
> 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?
On Fri, 30 Nov 2001 15:57:40 -0800
Larry McVoy <[email protected]> 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?
On Fri, 30 Nov 2001, Mike Castle wrote:
> 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
On Fri, 30 Nov 2001, Larry McVoy wrote:
> 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
On Fri, Nov 30, 2001 at 06:17:43PM -0800, Davide Libenzi wrote:
> > 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
> 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.
> 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.
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
On Fri, Nov 30, 2001 at 04:50:34PM -0800, Linus Torvalds wrote:
>
> 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".
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?
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
On Fri, Nov 30, 2001 at 07:15:55PM -0800, Linus Torvalds wrote:
> > 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
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
On Nov 30, 2001 20:02 -0700, Victor Yodaiken wrote:
> 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/
On Fri, Nov 30, 2001 at 10:07:29AM -0800, Larry McVoy wrote:
> 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
On Fri, Nov 30, 2001 at 07:15:55PM -0800, Linus Torvalds wrote:
> 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.
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.
On December 1, 2001 04:30 am, 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.
>
> 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.
If you've been involved in any design sessions with Linus - if you could even
grace them with that name - you know he relies way more on intuition than
process. Actually, far from taking the role of the omniscient creator, he
tends to act more like the survival test. Not that he's short of the
necessary skills to do it your way. I think he does it the way he does it
because it's fun and interesting and, oh yes, effective.
--
Daniel
On Sat, Dec 01, 2001 at 02:21:57AM +0100, Stephan von Krawczynski wrote:
> _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
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...
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
On Fri, Nov 30, 2001 at 03:57:40PM -0800, Larry McVoy wrote:
> 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?
[cc list trimmed]
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
On December 1, 2001 06:15 am, Linus Torvalds wrote:
> On Fri, 30 Nov 2001, Victor Yodaiken wrote:
> > 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.
I do it a little differently: think hard, try something, implement, read the
literature, repeat as necessary.
--
Daniel
[cc list trimmed]
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
On Fri, Nov 30, 2001 at 10:31:24PM -0800, Stephen Satchell wrote:
> [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
At 09:43 PM 11/30/01 -0800, Stephen Satchell wrote:
> 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.
> 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
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
> 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?
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
> > 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.
Question: What happens when people stick 8 threads of execution on a die with
a single L2 cache ?
On Fri, 30 Nov 2001, Linus Torvalds 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.
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/
On Fri, 30 Nov 2001, Larry McVoy wrote:
> 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/
Hi Keith,
When I have had to prepare a Makefile for sym-2 as a sub-directory of
drivers/scsi (sym53c8xx_2), it didn't seem to me that a non-ugly way to do
so was possible. I mean that using sub-directory for scsi drivers wasn't
expected by the normal kernel build procedure. Looking into some network
parts that wanted to do so, I only discovered hacky stuff. This left me in
the situation I had to do this in an ugly way.
As you cannot ignore the scsi driver directory is a mess since years due
to too many sources files in an single directory. Will such ugly-ness be
cleaned up in linux-2.5?
By the way, in my opinion, a software that is as ugly as you describe but
not more looks excellentware to me. :-)
G?rard.
On Sat, 1 Dec 2001, Keith Owens wrote:
> On 30 Nov 2001 18:15:28 +0100,
> Henning Schmiedehausen <[email protected]> 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.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Subject changed and cc trimmed.
On Sat, 1 Dec 2001 09:54:48 +0100 (CET),
=?ISO-8859-1?Q?G=E9rard_Roudier?= <[email protected]> wrote:
>When I have had to prepare a Makefile for sym-2 as a sub-directory of
>drivers/scsi (sym53c8xx_2), it didn't seem to me that a non-ugly way to do
>so was possible. I mean that using sub-directory for scsi drivers wasn't
>expected by the normal kernel build procedure. Looking into some network
>parts that wanted to do so, I only discovered hacky stuff. This left me in
>the situation I had to do this in an ugly way.
kbuild 2.5 is designed to cope with components that are spread over
several directories, as well as drivers in their own sub directory.
Supporting sym53c8xx_2 was just one line in drivers/scsi/Makefile.in.
select(CONFIG_SCSI_NCR53C7xx 53c7,8xx.o)
link_subdirs(sym53c8xx_2) # HBA in its own directory
select(CONFIG_SCSI_SYM53C8XX sym53c8xx.o)
plus drivers/scsi/sym53c8xx_2/Makefile.in.
objlink(sym53c8xx.o sym_fw.o sym_glue.o sym_hipd.o sym_malloc.o sym_misc.o
sym_nvram.o)
select(CONFIG_SCSI_SYM53C8XX_2 sym53c8xx.o)
>As you cannot ignore the scsi driver directory is a mess since years due
>to too many sources files in an single directory. Will such ugly-ness be
>cleaned up in linux-2.5?
At some time in the 2.5 series I hope to split drivers/scsi into core,
arch independent drivers, arch specific drivers and peripheral drivers
(tape, cdrom etc.), with a top level scsi/Makefile.in that contains:
link_subdirs(core)
link_subdirs(hba)
link_subdirs(acorn)
# link_subdirs(any other arch specific scsi directories here)
link_subdirs(peripheral)
At the moment, adding a new driver means changing the middle of the
Makefile which is nasty. It also prevents kbuild 2.5 from supporting
add on SCSI drivers in an easy manner. With a clean split like the
above, testing a new driver outside the kernel source tree only
requires drivers/scsi/hba/Makefile.in.append containing just one line
for the new object.
Whether the drivers are all in one directory or are futher sub divided
is up to the SCSI or individual driver maintainers. Obviously drivers
built from multiple files should be in their own sub directory. That
still leaves a large number of drivers built from single source files,
how should they be split, if at all? One directory per driver is
overkill, grouping by supplier breaks when the supplier is taken over,
grouping by chipset might be useful.
I must emphasise that this is just my wishlist. It needs broad
agreement from the SCSI maintainers before we start moving the files
around. Until there is agreement, linux-2.5 will have the same
cluttered scsi makefile, converted to kbuild 2.5 style.
On Sat, 1 Dec 2001, Alan Cox wrote:
> > > 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.
>
> Question: What happens when people stick 8 threads of execution on a die with
> a single L2 cache ?
As long as we will not have clean asynchronous mechanisms available from
user land, some applications will have to use more threads of execution
than needed, even with programmers that aren't thread-maniac.
Response to your question: If the problem is to optimize IOs against 8
slow devices using synchronous IO APIs , you will get far better
performances. :-)
G?rard.
On Fri, Nov 30, 2001 at 09:15:50PM -0800, Linus Torvalds wrote:
>
> 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.
Just to make sure we are speaking the same language, here is what the
Oxford English Dictionary sez
Design: (1) a plan or scheme conceived in the mind; a project.
...
(2) a purpose, an intention, an aim
...
(3) an end in view, a goal
...
(4) A preliminary sketch, a plan or pattern
For the verb we get things like: "draw, sketch, outline, delineate"
>
> > 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.
You're on. Send me the $5.
Here's what Dennis Ritchie wrote in his preface to the re-issued Lions
book:
"you will see in the code an underlying structure that has
lasted a long time and has managed to accomodate vast changes
in the computing environment"
> 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.
You appear to be using "design" to mean "complete specification".
See above.
>
> 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.
Memory fades with age, as I know from sad experience, but try to
remember who wrote things like:
|
|However, I still would not call "pthreads" designed.
|
|Engineered. Even well done for what it tried to do. But not "Designed".
|
|This is like VMS. It was good, solid, engineering. Design? Who needs
|design? It _worked_.
|
|But that's not how UNIX is or should be. There was more than just
|engineering in UNIX. There was Design with a capital "D". Notions of
|"process" vs "file", and things that transcend pure engineering.
|Minimalism.
|
|In the end, it comes down to aesthetics. pthreads is "let's solve a
|problem". But it's not answering the big questions in the universe.
|It's not asking itself "what is the underlying _meaning_ of threads?".
|"What is the big picture?".
Some academic twit, no doubt, with no understanding or experience in
actually making a blue collar OS really work.
The same fool once wrote:
> Think about WHY our system call latency beats everybody else on the
> planet. Think about WHY Linux is fast. It's because it's designed
> right.
Please send the $5 soon.
On Sat, Dec 01, 2001 at 08:57:17AM +0000, Alan Cox wrote:
> > 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
>
> 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.
Recently, our correspondent from Wales wrote:
... the changes have been done and
tested one at a time as they are merged. Real engineering process is the
only way to get this sort of thing working well.
I really dislike this "alchemy" stuff. It's demeaning and misleading.
All the alchemists ever managed to create were cases of mercury
poisoning.
> 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.
And you can hack away all you want, you'll never get TCP to work either.
This stuff is a mixture of theory and practice and
whether your theory is picked up from years of experience, boozy
arguments, and thinking, or from a strictly supervised
tour of the library it's theory all the same.
CS is like any other skilled field. There's a difference between a guy
who knows how to hammer and a master carpenter.
> Recently, our correspondent from Wales wrote:
> ... the changes have been done and
> tested one at a time as they are merged. Real engineering process is the
> only way to get this sort of thing working well.
Which doesn't conflict. Engineering does not require science. Science helps
a lot but people built perfectly good brick walls long before they knew why
cement works.
> All the alchemists ever managed to create were cases of mercury
> poisoning.
and chemistry, eventually. You take it as far more demeaning than its meant.
But right now given two chunks of code, I find out what happens by putting
them together not by formal methods. In the case of alchemy v chemistry the
chemists know whether it will probably go bang before they try it (and the
chemical engineers still duck anyway)
Alan
On Sat, Dec 01, 2001 at 01:38:11PM +0000, Alan Cox wrote:
> Which doesn't conflict. Engineering does not require science. Science helps
> a lot but people built perfectly good brick walls long before they knew why
> cement works.
>
> > All the alchemists ever managed to create were cases of mercury
> > poisoning.
>
> and chemistry, eventually. You take it as far more demeaning than its meant.
>
> But right now given two chunks of code, I find out what happens by putting
> them together not by formal methods. In the case of alchemy v chemistry the
> chemists know whether it will probably go bang before they try it (and the
> chemical engineers still duck anyway)
Oh come on Alan. You look at a patch and can discard 99% of the really
bad ones _before_ you try them out. How do you do it? Divination?
Nobody uses formal methods for anything other than generating papers
with more authors than readers. It's true that the academicians
have made a fetish out of the elaborate typesetting that they call
"theory", but in the real world, the distinction between science and
engineering is nothing more than some class snobbery and a rough
categorization of who pays for the work.
If there is a point here, which now seems unlikely, it's that there are
design and engineering skills needed to make real software work.
Neither slashdot nor the formal methods research fellows at Oxford
are capable of generating Linux.
Stephan von Krawczynski <[email protected]> [01/11/30 20:27]:
> 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?
I can't say for the O/S buying market. But I do embedded (pretty large
embedded systems but embedded nonetheless) development and we walked away
from Solaris after comparing the complexity of our first network drivers.
STREAMS: just say no.
Mike Castle wrote:
> Linux is one big genetic algorithms project?
No but I'm sure the VM layer is :-)
-- Jamie
On Sat, Dec 01, 2001 at 11:04:30AM -0500, Mark Frazer wrote:
> Stephan von Krawczynski <[email protected]> [01/11/30 20:27]:
> > 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?
>
> I can't say for the O/S buying market. But I do embedded (pretty large
> embedded systems but embedded nonetheless) development and we walked away
> from Solaris after comparing the complexity of our first network drivers.
>
> STREAMS: just say no.
Amen to that. STREAMS would be one of the strongest arguments in favor
of Linus' theory that evolution takes care of it. STREAMS were done at
Sun by some "architects" who thought they would be better than sockets.
Linus is dead right, on this sort of issue, Linux responds quickly and
weeds out the crap. We still have some room for discussion on the
design issues, but yeah, Sun blew it on this one and refused to admit it.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, 1 Dec 2001, Jamie Lokier wrote:
> Mike Castle wrote:
> > Linux is one big genetic algorithms project?
>
> No but I'm sure the VM layer is :-)
I guess we now know the reason Linus purposefully
makes sure no comment ever matches the code ;/
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
On Sat, Dec 01, 2001 at 10:05:55AM +0000, Alan Cox wrote:
> > 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?
>
> 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.
Careful Alan. That sounds suspiciously like a "design principle", and
true macho Linux developers don't need no theoretical stuff like that.
They just slop that code together and see what explodes - pulling their
alchemists hats over their eyes for protection.
>
> > 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"
"Taste" ? Now you want aesthetics as well as theory. I'm horrified.
Technical content: does anyone know the max spinlock depth in Linux 2.5
?
On Fri, Nov 30, 2001 at 12:06:43PM -0800, Paul G. Allen wrote:
[snip]
> 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.
Uhhhm, knowing when a code block begins? Usually you'll notice this from
the indentation. It's quite hard not to notice a tabsized shift
to the right...
[snip]
/David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
On Sat, Dec 01, 2001 at 09:18:54AM -0200, Rik van Riel wrote:
> 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.
Creation is as simple as:
1. If you encounter a problem, try to solve it.
2. If you cannot solve it, mark/document/publish it and try to
work around it for now.
3. If you cannot work around it, leave it to other people and
offer help.
Which is pretty much what this list here is for ;-)
Regards
Ingo Oeser
--
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
On Sat, 1 Dec 2001, Ingo Oeser wrote:
> On Sat, Dec 01, 2001 at 09:18:54AM -0200, Rik van Riel wrote:
> > 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.
>
> Creation is as simple as:
>
> 1. If you encounter a problem, try to solve it.
> 2. If you cannot solve it, mark/document/publish it and try to
> work around it for now.
> 3. If you cannot work around it, leave it to other people and
> offer help.
>
> Which is pretty much what this list here is for ;-)
4. If the problem cannot be solved with a quick hack by
one person, give up and switch to another OS.
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
> Amen to that. STREAMS would be one of the strongest arguments in favor
> of Linus' theory that evolution takes care of it. STREAMS were done at
> Sun by some "architects" who thought they would be better than sockets.
Wasn't Dennis Ritchie one of the "architects" of STREAMS at Bell Labs?
A Stream Input-Output System : AT&T Bell Laboratories Technical Journal
63, No. 8 Part 2 (October, 1984)
(http://cm.bell-labs.com/cm/cs/who/dmr/st.pdf)
--ricardo
On Sat, Dec 01, 2001 at 07:38:42PM +0100, Ricardo Galli wrote:
> > Amen to that. STREAMS would be one of the strongest arguments in favor
> > of Linus' theory that evolution takes care of it. STREAMS were done at
> > Sun by some "architects" who thought they would be better than sockets.
>
> Wasn't Dennis Ritchie one of the "architects" of STREAMS at Bell Labs?
>
> A Stream Input-Output System : AT&T Bell Laboratories Technical Journal
> 63, No. 8 Part 2 (October, 1984)
Dennis wrote something called "streams" not be confused with "STREAMS".
He was trying to provide a more flexible mechanism for tty line
disciplines. The Sys III guys grabbed it and decided to promote it as
a networking infrastructure, because System III et al did not have
networking. Dennis doesn't like the result any better than any of us.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On December 1, 2001 05:27 pm, Rik van Riel wrote:
> On Sat, 1 Dec 2001, Jamie Lokier wrote:
> > Mike Castle wrote:
> > > Linux is one big genetic algorithms project?
> >
> > No but I'm sure the VM layer is :-)
>
> I guess we now know the reason Linus purposefully
> makes sure no comment ever matches the code ;/
2.5 is now open, I'm sure Linus will take patches to fix comment bugs now.
--
Daniel
On Sat, Dec 01, 2001 at 07:38:42PM +0100, Ricardo Galli wrote:
> > Amen to that. STREAMS would be one of the strongest arguments in favor
> > of Linus' theory that evolution takes care of it. STREAMS were done at
> > Sun by some "architects" who thought they would be better than sockets.
>
> Wasn't Dennis Ritchie one of the "architects" of STREAMS at Bell Labs?
Different thing. Same name.
>
> A Stream Input-Output System : AT&T Bell Laboratories Technical Journal
> 63, No. 8 Part 2 (October, 1984)
>
> (http://cm.bell-labs.com/cm/cs/who/dmr/st.pdf)
>
> --ricardo
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Sat, Dec 01, 2001 at 07:13:55AM +0100, Daniel Phillips wrote:
> On December 1, 2001 06:15 am, Linus Torvalds wrote:
> > On Fri, 30 Nov 2001, Victor Yodaiken wrote:
> > > 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.
>
> I do it a little differently: think hard, try something, implement, read the
> literature, repeat as necessary.
Ordering is not key in this recipe.
On December 1, 2001 09:17 pm, Victor Yodaiken wrote:
> On Sat, Dec 01, 2001 at 07:13:55AM +0100, Daniel Phillips wrote:
> > On December 1, 2001 06:15 am, Linus Torvalds wrote:
> > > On Fri, 30 Nov 2001, Victor Yodaiken wrote:
> > > > 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.
> >
> > I do it a little differently: think hard, try something, implement, read the
> > literature, repeat as necessary.
>
> Ordering is not key in this recipe.
Right, I'm just saying that's how I typically do it. A decade ago I'd
probably have put the 'try something' first, and a decade before that,
'read the litature'.
--
Daniel
Hello,
wow, what a nice discussion. I am reading the l-k through an
archive, so please forgive me if I am going to say something
that was already said, but I did not yet read it.
Linus wrote:
> Don't underestimate the power of survival of the fittest.
Well, your theory is really an interesting view on the
software development. However, I think that there are
some points that need some more discussion.
First, you are probably right in the long-term. The nature
did have enough time for excursions in one or another
direction - the "project" of life is several orders of magnitude
older than a single generation. You say that it is possible
to help the evolution. But you still need many generations
to be sure that a good result at some stage is not only some
statistical variance.
The technology does not IMHO work that way - Linux (Unix
in all its flavours, Windows, ...) is very young.
We are not in the stage where life exists for millions
of years. We are in the stage where the first cells
have formed and are still quite vulnerable. There is only
a thin line between survival as a kind and extinction (sp?).
I think that in this stage not ignoring the role of
the design is a good thing (and no, I don't believe in God :-)).
Besides that, are you talking about evolution in general,
or about evolution of a particular kind? The competition
is not the same in these cases.
> - massive undirected parallel development ("trial and error")
This is not what is happening here. The parallelism does
exist but is not massive in any way. There are not thousands
of people writing the same stuff. There are not even thousands
of people able to write a good bug report on a particular bug.
There are maybe three (as in the VM recently) authors of some
subsystem and in the end effect there is a God (or two after
a brief disagreement :-)) that decides. No way is this analogous
to the natural selection where the decision happens statistically
on a whole population. This works between Linux and Windows,
but not between implementation ideas.
Al Viro wrote:
> 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
Absolutely. But what I really miss is an early-warning system.
No matter how good Linus might be in reviewing the submissions,
he cannot catch it all - nobody is _that_ good.
What I feel hurts the Linux is that the testing standards
are very, very low. Heck, Linus does not probably even compile
the code he releases with the widely used configuration options
(otherwise a non-compiling loop.o would not be possible).
Throwing releases onto the public is not testing. Saying
"it works/does not work for me" is not testing. Testing
is _actively_ trying to break things, _very_ preferably
by another person that wrote the code and to do it
in documentable and reproducible way. I don't see many
people doing it.
Linus wrote:
> 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.
Well, I don't know what they tell in the classes now - I am 33
and in this area the theories change much faster than practice :-)
> 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?
I have heard of projects that did succeeded doing well defined
revision cycles with each cycle figuring out what more or better
it should do, the design of it (more or less rigorous),
implementation, then something what you forgot :-) - testing
and deployment.
The project I am working on now (a process control system)
exists for 15 years and is quite successful. It is vertical
market, not horizontal, but hardly a niche. More control
_did_ help it at one stage, where we had a little quality
crisis.
Maybe it is just because people tend to forget the wrong
things, but I have a strong feeling that Linux starts
to have problems with quality that we did not see before,
at least not in this amount. We are nearly a year in
the stable series and we need to change fundamental things
that broadly affect other parts - VM, devfs, ... This is
not evolution, this is surgery. USB support was one big
argument for 2.4, yet it is far from stable.
My opinion is, that you are _very_ good at maintaining general
overview of a big chunk of code together with being able
to maintain a general direction that makes sense. I don't
think I know someone other that is able to do this. But
I also think that the kernel is in the stage where this
won't be much longer possible even for you. I have seen
software projects going through some kind of crisis
and the symptoms tended be very similar. In the early
stages there are tools (version management, bug reporting
system) and policies (testing standards) that can help.
In the later stages the crisis is in the management.
I cannot say from the outside (I am not doing active kernel
development), in what stage (if in any) the kernel is.
But I have the gut feeling that something should be done.
Evolution does not have the option to vote with its feet.
The people do. While Linux is not much more stable than it
was and goes through a painful stabilization cycle on every
major release, Windows does go up with the general stability with
every release. W2k were better than NT, XP are better than W2k.
Windows (I mean the NT-branch) did never eat my filesystems.
Bad combination of USB and devfs was able to do this in half
an hour, and this was vendor kernel that did hopefully get
more testing than that what is released to the general public.
I surely cannot recommend using 2.4 to our customers.
And frankly, I see the Microsoft borrowing ideas from the open
community. They make things more open - slow, but they are.
They are going to give out compilers for free and charge
for the (quite good and IMHO worth the money) IDE. They are
building communities. Guess why?...
You might of course say that you don't care - the nature
also basically does not care where the evolution is going.
I would like to see more control in the kernel development,
especially regarding quality standards.
Regards
--
Stano
> "it works/does not work for me" is not testing. Testing
> is _actively_ trying to break things, _very_ preferably
> by another person that wrote the code and to do it
> in documentable and reproducible way. I don't see many
> people doing it.
If you want a high quality, tested supported kernel which has been through
extensive QA then use kernel for a reputable vendor, or do the QA work
yourself or with other people. We have kernel janitors, so why not kernel QA
projects ?
However you'll need a lot of time, a lot of hardware and a lot of attention
to procedure
Alan
David Weinehall wrote:
>
> On Fri, Nov 30, 2001 at 12:06:43PM -0800, Paul G. Allen wrote:
>
> [snip]
> > 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.
>
> Uhhhm, knowing when a code block begins? Usually you'll notice this from
> the indentation. It's quite hard not to notice a tabsized shift
> to the right...
>
Whitespace can be placed almost anywhere and the program will still
compile. It can even be removed altogether. The only thing that keeps a
program legible is proper formatting. It's real damn easy to miss a
brace when the formatting is poor. And real easy to spend an hour trying
to figure out where that missing brace goes, that is after the hour you
spent figuring out that it was missing in the first place.
I guess some people Just Don't Get It. Some people just do not know how
to write maintainable code.
PGA
--
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
http://www.akamai.com
On Saturday, December 1, 2001, at 03:39 , Stanislav Meduna wrote:
> Throwing releases onto the public is not testing. Saying
> "it works/does not work for me" is not testing. Testing
> is _actively_ trying to break things, _very_ preferably
> by another person that wrote the code and to do it
> in documentable and reproducible way. I don't see many
> people doing it.
If someone sent me a whole slew of hardware and provided a me with a
steady income so I didn't have to work, I could do this. But fact of the
matter is, most of the people working on the kernel are doing it not for
a living, but for fun or they enjoy it. They probably don't have the
endless fields of hardware that vendors do. If the above is what you
want, stick with vendor releases and not Linus (or maintainer) releases.
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Developer/Project Lead
Don't drink and derive." --Unknown http://www.themes.org/
[email protected]
=====================================================================
Linus Torvalds <[email protected]> said:
> 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.
In any case, Larry's suggestion would fracture Linux. Also, Solaris might
be a fine piece of work, but what is commonly called Linux (i.e.,
distributions) is more flexible, easier to use, and friendly
overall. Besides, the kernel handles an insane selection of hardware, and
is able to interoperate with allmost everything else there is. No mean
feat, that one.
> Hey, that's not a bug, that's a FEATURE!
Bingo!
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
On Sat, 1 Dec 2001, Alan Cox wrote:
> > "it works/does not work for me" is not testing. Testing
> > is _actively_ trying to break things, _very_ preferably
> > by another person that wrote the code and to do it
> > in documentable and reproducible way. I don't see many
> > people doing it.
>
> If you want a high quality, tested supported kernel which has been through
> extensive QA then use kernel for a reputable vendor, or do the QA work
> yourself or with other people. We have kernel janitors, so why not kernel QA
> projects ?
I know a Co. that has its headquarters about 200 miles north of where I
live that has the more organized development/qa cycle and still I won't change
Linux for their kernel even under weapon menace.
- Davide
On Fri, Nov 30, 2001 at 12:27:37PM -0800, Paul G. Allen wrote:
> 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
the meaning of 'i', 'j', 'k', is universal. show me a real world
program (or programming book!) not from redmond that doesn't use these
names for loop counters.
j.
--
R N G G "Well, there it goes again... And we just sit
I G G G here without opposable thumbs." -- gary larson
On Sat, 1 Dec 2001, Alan Cox wrote:
> > > 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.
>
> Question: What happens when people stick 8 threads of execution on a die with
> a single L2 cache ?
Or for example the new HP PARISC design ( Mako ) with two on-die cores,
3-4 Mb L1 I-Cache per core, 3-4 Mb L1 D-Cache per core and up to 32 Mb
external L2 ( with on-die tagging ).
Anyway it's still better 8 on-die threads of execution sharing an L2
instead of 8 CPU with 1 thread of execution shring through the external
bus.
- Davide
john slee wrote:
>
> On Fri, Nov 30, 2001 at 12:27:37PM -0800, Paul G. Allen wrote:
> > 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
>
> the meaning of 'i', 'j', 'k', is universal. show me a real world
> program (or programming book!) not from redmond that doesn't use these
> names for loop counters.
>
If you'd been paying attention, I discounted simple loop counters in an
early post.
PGA
--
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
http://www.akamai.com
On Fri, 30 Nov 2001, Linus Torvalds wrote:
>
> 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 most successful software have born from fixing/patching an
initial/simple implementation while the greatest software failures
have born from deep planning and design.
And for successful I mean widely used/apreciated/longlived.
You start with a very limited ( in features ) initial version, people
happen to like it, you sell/distribute it and they're going to ask for new
features.
Some of these new features will fit the initial design some other will
make you patching it in an undesigned way, but you think that you'll fix
it later.
But people are going to like it even more and become more hungry of new
features, some of them will fit in the initial implementation design some
other will introduce crappy patching, but later time is fix time.
And so on.
What is the deep thought in this, it's that if you've time for deep
planning/design it means that nobody is actually using your software and
when your cutting edge, well designed implementation will see the light,
noone is gonna use it because they've already embraced something else.
Not cutting edge, not really deeply designed but a fu*king working real
software that is solving real problems for the 99% of its users.
- Davide
On Sat, Dec 01, 2001 at 01:29:14PM -0800, Paul G. Allen wrote:
> compile. It can even be removed altogether. The only thing that keeps a
> program legible is proper formatting. It's real damn easy to miss a
> brace when the formatting is poor. And real easy to spend an hour trying
And this is why Python has chosen the format that it has.
--
Tracy Reed http://www.ultraviolet.org
"Every artist is a cannibal, every poet is a thief.
They all kill their inspiration, and sing about the grief." - U2
In response to:
> "it works/does not work for me" is not testing. Testing
> is _actively_ trying to break things, _very_ preferably
> by another person that wrote the code and to do it
> in documentable and reproducible way. I don't see many
> people doing it.
from "Stanislav Meduna <[email protected]>", Alan Cox said:
"If you want a high quality, tested supported kernel which
has been through extensive QA then use kernel for a
reputable vendor, or do the QA work yourself or with other
people. We have kernel janitors, so why not kernel QA
projects ?
"However you'll need a lot of time, a lot of hardware and
a lot of attention to procedure"
But in his earlier e-mail, Stanislav Meduna said:
"Evolution does not have the option to vote with its feet.
The people do. While Linux is not much more stable than it
was and goes through a painful stabilization cycle on every
major release, Windows does go up with the general stability with
every release. W2k were better than NT, XP are better than W2k.
Windows (I mean the NT-branch) did never eat my filesystems.
Bad combination of USB and devfs was able to do this in half
an hour, and this was *VENDOR KERNEL* that did hopefully get
more testing than that what is released to the general public.
I surely cannot recommend using 2.4 to our customers."
which seems to negate the point Alan was attempting to make.
Just thought I'd set the record straight.
NOTE: Emphasis mine.
"Everyone's got a story to tell, and everyone's got some pain.
And so do you. Do you think you are invisble?
And everyone's got a story to sell, and everyone is strange.
And so are you. Did you think you were invincible?"
- "Invisible", Majik Alex
> > "it works/does not work for me" is not testing. Testing
> > is _actively_ trying to break things, _very_ preferably
> > by another person that wrote the code and to do it
> > in documentable and reproducible way. I don't see many
> > people doing it.
>
> If you want a high quality, tested supported kernel which has been through
> extensive QA then use kernel for a reputable vendor, or do the QA work
> yourself or with other people.
Correct. But this has one problem - it is splitting resources.
Pushing much of the QA work later in the process means
that the bugs are found later, that there is more people
doing this as absolutely necessary and that much more
communication (and this can be the most important bottleneck)
is needed as necessary.
The need of the VM change is probably a classical example -
why was it not clear at the 2.4.0-pre1, that the current
implementation is broken to the point of no repair? I am
not seeking who is guilty, it is irrelevant, but I think
there is a lesson to be learned and I would like to see
the cause to be identified and steps to be taken that move
such experiments into the development series. The 2.2 also
had issues, but 2.4 has IMHO more issues that are not
localized and fixable without affecting other parts.
Evolution does not need to be efficient. I still think that
software development should be - if we loose half a year,
the more organized competitor will be more than happy.
As a user of the vendor's kernel I have no idea what to do
with a bug. The vendor kernel has hundreds of patches that
are or are not, fully or partially merged into the mainstream
for various reasons - you know this surely much better
than I do :-) Now where do I send a bug report and -
more important - where do I look when I want to have
all available information to an issue, so I can be
more specific (or cancel the report completely because
it is clearly duplicate)? Should I consult my vendor's
bugzilla, systems of all other vendors, l-k and specialized
mailing lists of the given subsystem? I doubt that
many of us will...
There is no single place where the bug reports are sent and -
much more important - where their history can be viewed.
The kernel itself has nothing but linux-kernel (overloaded
with tons of non-relevant stuff such as this thread :-))
and probably various TODO lists of the developers.
I really feel that at least the information should be
centralized so that the info can be hyperlinked. You work
with the kernel so closely that you are probably able
to keep the track of the important issues. 99% of users
wanting to at least report bugs are not. Finding something
in the l-k is hard, but even the managers can normally
operate an issue tracking system - I see them doing it
every day :-)
The classical tools such as version control or issue tracking
system were discussed many times and were rejected - not
by evolution, but by one-man decision. linux-kernel does
not show me when and _why_ something was changed. Changelogs
are big step in the right direction, but I think that more
is needed. Frankly, I think that managing the submissions
in a mail folder of Linus is not the right way of doing this
for a project of this size.
I understand that it is impossible for Linus to write a meaningful
comment and to check in a changeset each time he decides to
accept stuff. I think that at some time he will be forced
to give some write-access to a mainstream branch to a few
other people (btw, this final review is imho in strong conflict
with his evolution theory).
> We have kernel janitors, so why not kernel QA projects ?
Yes, this should be probably discussed. If a development
can be distributed and quite organized at the same time,
so can probably the testing. I have already seen such project
somewhere on the web - no idea where they are now.
But an effective QA project is not possible without support
from the developers themselves. Black-box testing is only
one kind of tests. If a design is not documented, it is
much more harder to try to break it.
> However you'll need a lot of time, a lot of hardware and
> a lot of attention to procedure
I know - our QA department sits next door and this is userspace
application, so hardware does not matter :-)
Regards
--
Stano
[email protected] (H. Peter Anvin) wrote on 30.11.01 in <[email protected]>:
> By author: Jeff Garzik <[email protected]>
> > "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.
> >
>
> Indeed. What can you say for a technique which basically promotes
> *reducing* abstraction and information hiding?
>
> There is a reason why the Win64 ABI uses the same "int" and "long" as
> Win32... (both are 32 bits.) They added meaningless abstractions, and
> didn't add abstractions where they needed to...
Well, that doesn't necessarily make the idea itself completely crap just
because the standard implementation is.
Sure, calling a variable "I point to a char! And by the way, I'm named
Fritz" may be a bad idea, but in some situations it may well make sense to
say that a certain variable is a container and another is a lock.
And it seems that sometimes, the kernel does just that. (pagecache_lock,
page_list, just picking two fast examples from 2.4.0 mm)
But lpfilename is, indeed, fucking insane.
MfG Kai
[email protected] (Mike Fedyk) wrote on 30.11.01 in <[email protected]>:
> On Sat, Dec 01, 2001 at 02:21:57AM +0100, Stephan von Krawczynski wrote:
> > 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.
It works for SGI/Irix/XFS, why would it not work for SUN/Solaris/whatever?
MfG Kai
[email protected] (Paul G. Allen) wrote on 30.11.01 in <[email protected]>:
> John Kodis wrote:
> > 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'd certainly call 'i' well understood in both math and computing. In
math, 'i' is what engineers call 'j' (i*i == -1), and in computing, 'i'
('j', 'k', ...) is a counter for loops (some variant of int) that don't
exceed about a screenful.
> I can use these for anything I want
> and even for more than one thing,
Of course, if you use them differently from what the convention is, *then*
you are in trouble.
> 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.
Yup.
MfG Kai
[email protected] (Linus Torvalds) wrote on 30.11.01 in <[email protected]>:
> 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?
Yes.
That one gave rise to _The_Mythical_Man_Month_.
Or in other words, it demonstrated how this was broken enough to create
one of the more important classics in the field.
MfG Kai
[email protected] (Linus Torvalds) wrote on 30.11.01 in <[email protected]>:
> On Fri, 30 Nov 2001, Victor Yodaiken wrote:
> > 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.
Recently, that seems to get popular in gcc. Sometimes, on [email protected],
you'll see a whole thread where people throw one literature reference
after another at each other.
Maybe a whole 3% of the traffic.
MfG Kai
On Sat, 1 Dec 2001 21:39:16 +0100 (CET), Stanislav Meduna
<[email protected]> wrote:
>Hello,
>
>wow, what a nice discussion. I am reading the l-k through an
>archive, so please forgive me if I am going to say something
>that was already said, but I did not yet read it.
>
>
>Linus wrote:
>> Don't underestimate the power of survival of the fittest.
>
>Well, your theory is really an interesting view on the
>software development. However, I think that there are
>some points that need some more discussion.
>
>First, you are probably right in the long-term. The nature
>did have enough time for excursions in one or another
>direction - the "project" of life is several orders of magnitude
>older than a single generation. You say that it is possible
>to help the evolution. But you still need many generations
>to be sure that a good result at some stage is not only some
>statistical variance.
To make the process interesting long term, you need the periodic mass
extinction to open up ecologic windows for new development. Absent
that you would wind up stuck in some local optimum.
>
>The technology does not IMHO work that way - Linux (Unix
>in all its flavours, Windows, ...) is very young.
>We are not in the stage where life exists for millions
>of years. We are in the stage where the first cells
>have formed and are still quite vulnerable. There is only
>a thin line between survival as a kind and extinction (sp?).
>I think that in this stage not ignoring the role of
>the design is a good thing (and no, I don't believe in God :-)).
>
>Besides that, are you talking about evolution in general,
>or about evolution of a particular kind? The competition
>is not the same in these cases.
>
>> - massive undirected parallel development ("trial and error")
>
>This is not what is happening here.
The current Linux environment is much like the accelerated change
observed in directed breeding... say with breeding dogs or horses...
with an "intelligence" pushing toward desired characteristics (instead
of blind nature) progress is very rapid.
john alvord
Davide Libenzi <[email protected]> writes:
> What is the deep thought in this, it's that if you've time for deep
> planning/design it means that nobody is actually using your software
> and when your cutting edge, well designed implementation will see
> the light, noone is gonna use it because they've already embraced
> something else.
Also known as "Worse is Better":
http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html
--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10
Brinkhoff Consulting http://www.brinkhoff.se/ programming
On Sun, 2 Dec 2001, Stanislav Meduna wrote:
> The need of the VM change is probably a classical example -
> why was it not clear at the 2.4.0-pre1, that the current
> implementation is broken to the point of no repair?
It wasn't broken to the point of no repair until Linus
started integrating use-once and dropping bugfixes.
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
> The need of the VM change is probably a classical example -
> why was it not clear at the 2.4.0-pre1, that the current
> implementation is broken to the point of no repair? I am
Because nobody had run good test sets by then - anyway it was repairable.
Linus kept ignoring, refusing and merging conflicting patches. The -ac tree
since 2.4.9-ac or so with Rik's actual fixes he wanted Linus to takes passes
the Red Hat test suite. 2.4.16 kind of passes it now.
It had nothing to do with the VM being broken and everything to do with
what Linus applied. As it happens it looks like the new VM is better
performing for low loads which is good, but the whole VM mess wasn't bad QA
and wasn't bad design.
Linus was even ignoring patches that fixed comments in the VM code that
referenced old behaviour. And due to the complete lack of VM documentation
at the moment I can only assume he's been dropping Andrea's VM comments/docs
too.
Alan
> Bad combination of USB and devfs was able to do this in half
> an hour, and this was *VENDOR KERNEL* that did hopefully get
> more testing than that what is released to the general public.
> I surely cannot recommend using 2.4 to our customers."
So change vendor. There are reasons Red Hat for example does not ship devfs.
It's never been good enough to pass inspection let alone coverage or stress
testing it.
Alan Cox wrote:
> 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.
Please consider the following wipe out candidates as well:
1. ftape <- it should really really go away
2. proprietary CD-ROM
3. xd.c (ridiculous isn't it?)
4. old ide driver...
5. old directory reading syscalls.
Alan Cox wrote:
>
> > > 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.
>
> Question: What happens when people stick 8 threads of execution on a die with
> a single L2 cache ?
That had been already researched. Gogin bejoind 2 threads on a single
CPU
engine doesn't give you very much... The first step is giving about 25%
the second only about 5%. There are papers in the IBM research magazine
on
this topic in context of the PowerPC.
> > Question: What happens when people stick 8 threads of execution on a die with
> > a single L2 cache ?
>
> That had been already researched. Gogin bejoind 2 threads on a single
> CPU
> engine doesn't give you very much... The first step is giving about 25%
> the second only about 5%. There are papers in the IBM research magazine
> on
The IBM papers make certain architectural assumptions. With some of the
tiny modern CPU cores its going to perfectly viable to put 4 or 8 of them
on one die. At that point cccluster still has to have cluster nodes scaling
to 8 way
Rik van Riel wrote:
>
> On Fri, 30 Nov 2001, Linus Torvalds 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.
>
> 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,
One thing Linus doesn't realize is that the most successfull
results of the biological selection are not the high mamals but
simle archaic bacterias. This is the point where his
analogy breaks badly.
One one thing he simple appears to have forgotten: Operating
systems have a *purpose*. Therefore the stuff one wan't to do with
a system is what is driving it's true developement - this is most
pertinent in the developement of a driver - one does it to
use some kind of hardware it's that simple.
However I agree with him fully that most of the so called
software engineering methods do not have much in common with
the reality out there and are basically a self exercise.
> Please consider the following wipe out candidates as well:
>
> 2. proprietary CD-ROM
> 3. xd.c (ridiculous isn't it?)
> 4. old ide driver...
I know people using all 3 of those, while bugs in some of the old scsi 8bit
drivers went unnoticed for a year.
Alan
> The -ac tree since 2.4.9-ac or so with Rik's actual fixes
> he wanted Linus to takes passes the Red Hat test suite.
> 2.4.16 kind of passes it now.
Is the test suite (or at least part of it) public, or is it
considered to be a trade-secret of Red Hat? I see there
is a "Red Hat Ready Test Suite" - is this a part of it?
Regards
--
Stano
> Is the test suite (or at least part of it) public, or is it
> considered to be a trade-secret of Red Hat? I see there
> is a "Red Hat Ready Test Suite" - is this a part of it?
The main Red Hat test suite is a version of Cerberus (originally from VA
and much extended), its all free software and its available somewhere
although I don't have the URL to hand, Arjan ?
On Fri, 30 Nov 2001, Linus Torvalds wrote:
> 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.
the fundamental reasons why this happens are the following, special
conditions of our planet:
- the human brain has a limited capacity, both in terms of 'storage'
and 'computational power'.
- the world itself, at least how we understand it currently, is
inherently random. (Such randomness is the main driving force of
'structure' as well, it seems.)
- this planet has limited resources, so 'survival of the fittest' is
still the main driving force of 'life'.
- we do not know and understand the rules of our world yet, and chip
technology (which drives and enables operating systems) is right at the
edge (and often beyond the edge) of what physics is capable of
explaining today. We simply do not know what breakthrough (or brick
wall of performance) might happen in 1, 2 or 5 years. We did not know
50 years ago that something like 'SMP' would happen and be commonplace
these days. I mean, often we dont even know what might happen in the
next minute.
due to these fundamental issues the development of 'technology' becomes
very, very unpredictable. We only have 5 billion brain cells, and there's
no upgrade path for the time being. Software projects such as Linux are
already complex enough to push this limit. And the capacity limits of the
human brain, plus the striving towards something better (driven by human
needs) cause thousands of ambitios people working on parts of Linux in
parallel.
a few things are clear:
- if we knew the rules of this world and knew how to apply them to every
detail then we'd be building the 'perfect chip' by this christmas, and
there would probably be no need for anything else, ever.
- if the human brain (and human fingers) had no limits then we'd be
designing the 'perfect OS' from grounds up and write it in 2 minutes.
- and if the world wasnt random then there would probably be nothing
on this planet, ever.
but the reality is that we humans have severe limits, and we do not
understand this random world yet, so we'll unevitably have lots of fun
writing random pieces of Linux (or other) code in many many years to come.
in fact, most computer science books are a glaring example of how limited
the human brain is, and how small and useless part of the world we are
able to explain exactly ;-)
and frankly, i'd *very* disappointed if it was possible to predict the
future beyond our lifetime, and if it was possible to design a perfect
enough OS that does not need any changing in the foreseable future. I'd be
a pretty disappointed and bored person, because someone would predict what
happens and we'd only be dumbly following that grand plan. But the reality
is that such grand plan does not exist. One of the exciting things about
developing an OS is that we almost never know what's around the next
corner.
This whole effort called Linux might look structured on the micro-level
(this world *does* appear to have some rules apart of chaos), but it
simply *cannot* be anything better than random on the macro (longterm)
level. So we better admit this to ourselves and adapt to it.
And anyone who knows better knows something that is worth a dozen Nobel
prizes.
Ingo
On Sun, 02 Dec 2001 17:25:54 +0100
Martin Dalecki <[email protected]> wrote:
> One one thing he [Linus] simple appears to have forgotten: Operating
> systems have a *purpose*.
He didn't. The simple purpose of all being is equal: survival
As it is equal to all, talking about it is pretty redundant.
Regards,
Stephan
On Sun, 2 Dec 2001, Alan Cox wrote:
> > Please consider the following wipe out candidates as well:
> >
> > 2. proprietary CD-ROM
> > 3. xd.c (ridiculous isn't it?)
> > 4. old ide driver...
>
> I know people using all 3 of those, while bugs in some of the old scsi 8bit
> drivers went unnoticed for a year.
We need a 'prompt for unmaintained drivers' trailing-edge option in the
build process so people will know when something's been orphaned and pick
it up.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
On Sun, 2 Dec 2001, Martin Dalecki wrote:
> One thing Linus doesn't realize is that the most successfull results
> of the biological selection are not the high mamals but simle archaic
> bacterias. This is the point where his analogy breaks badly.
the fact that simple forms of life still exist shows only one thing: often
the environment is so harsh (ie. so *random*) that only the simplest can
survive. This is not 'success', it's a bow towards chaos.
the other reason is that simple forms of life are often just a tool for
higher forms of lifes to exist, or do not matter to the existence of
higher forms of life. Lets note that the human race *did* eradicate
certain strains of bacteria from this planet completely (except some more
or less safe places of storage), such as smallpocks, which pretty much
shows who has 'succeeded'.
Ingo
On Fri, 30 Nov 2001, Linus Torvalds wrote:
> 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!
Don't forget the fact that 2.4 is the first kernel you
managed to get stable under high load since 1.2.
Both 2.0 and 2.2 didn't get stable until Alan took over
and Alan's 2.4 fork got stable some 4 months before your
2.4 tree got stable.
I think you've pretty much proven how well random
development works.
regards,
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
Oliver Xymoron wrote:
>
> On Sun, 2 Dec 2001, Alan Cox wrote:
>
> > > Please consider the following wipe out candidates as well:
> > >
> > > 2. proprietary CD-ROM
> > > 3. xd.c (ridiculous isn't it?)
> > > 4. old ide driver...
> >
> > I know people using all 3 of those, while bugs in some of the old scsi 8bit
> > drivers went unnoticed for a year.
>
> We need a 'prompt for unmaintained drivers' trailing-edge option in the
> build process so people will know when something's been orphaned and pick
> it up.
There's already CONFIG_OBSOLETE...
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
On Sun, 2 Dec 2001, Ingo Molnar wrote:
> This whole effort called Linux might look structured on the micro-level
> (this world *does* appear to have some rules apart of chaos), but it
> simply *cannot* be anything better than random on the macro (longterm)
> level. So we better admit this to ourselves and adapt to it.
Note that this screams for some minimal kind of modularity
on the source level, trying to limit the "magic" to as small
a portion of the code base as possible.
Also, natural selection tends to favour the best return/effort
ratio, not the best end result. Letting a kernel take shape
due to natural selection pressure could well result in a system
which is relatively simple, works well for 95% of the population,
has the old cruft level at the upper limit of what's deemed
acceptable and completely breaks for the last 5% of the population.
That is, unless we give those last 5% of the population baseball
bats and Linus his house address, in which case there is some
biological pressure to merge the fixes needed for those folks ;)
regards,
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
On Sun, 2 Dec 2001, Rik van Riel wrote:
> Note that this screams for some minimal kind of modularity on the
> source level, trying to limit the "magic" to as small a portion of the
> code base as possible.
Linux is pretty modular. It's not dogmatically so, nor does it attempt to
guarantee absolute or externally visible modularity, but most parts of it
are pretty modular.
> Also, natural selection tends to favour the best return/effort ratio,
> not the best end result. [...]
there is no 'effort' involved in evolution. Nature does not select along
the path we went. It's exactly this property why it took 5 billion years
to get here, while Linux took just 10 years to be built from grounds up.
The fact is that bacteria took pretty random paths for 2 billion years to
get to the next level. That's alot of 'effort'. So *once* we have
something that is better, it does not matter how long it took to get
there.
( This kind of 'development effort' is not the same as 'robustness', ie.
the amount of effort needed to keep it at the complexity level it is,
against small perturbations in the environment - but that is a different
kind of effort. )
> [...] Letting a kernel take shape due to natural selection pressure
> could well result in a system which is relatively simple, works well
> for 95% of the population, has the old cruft level at the upper limit
> of what's deemed acceptable and completely breaks for the last 5% of
> the population.
no. An insect that is 95.1% effective digesting banana leafs in the jungle
will completely eradicate a competing insect that is 95.0% effective
digesting banana leaves, within a few hundred generations. (provided both
insects have exactly the same parameters otherwise.) And it does not
matter whether it took 100 million years to get to 95.1%, or just one
lucky set of alpha particles hitting a specific DNA part of the original
insect.
Ingo
On Sun, 2 Dec 2001, Jeff Garzik wrote:
> Oliver Xymoron wrote:
> >
> > On Sun, 2 Dec 2001, Alan Cox wrote:
> >
> > > > Please consider the following wipe out candidates as well:
> > > >
> > > > 2. proprietary CD-ROM
> > > > 3. xd.c (ridiculous isn't it?)
> > > > 4. old ide driver...
> > >
> > > I know people using all 3 of those, while bugs in some of the old scsi 8bit
> > > drivers went unnoticed for a year.
> >
> > We need a 'prompt for unmaintained drivers' trailing-edge option in the
> > build process so people will know when something's been orphaned and pick
> > it up.
>
> There's already CONFIG_OBSOLETE...
And it's practically obsolete itself, outside of the ARM directory. What
I'm proposing is something in the Code Maturity menu that's analogous to
EXPERIMENTAL along with a big (UNMAINTAINED) marker next to unmaintained
drivers. Obsolete and unmaintained and deprecated all mean slightly
different things, by the way. So the config option would probably say
'Show obsolete, unmaintained, or deprecated items?' and mark each item
appropriately. Anything that no one made a fuss about by 2.7 would be
candidates for removal.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Oliver Xymoron wrote:
>
> On Sun, 2 Dec 2001, Jeff Garzik wrote:
>
> > Oliver Xymoron wrote:
> > >
> > > On Sun, 2 Dec 2001, Alan Cox wrote:
> > >
> > > > > Please consider the following wipe out candidates as well:
> > > > >
> > > > > 2. proprietary CD-ROM
> > > > > 3. xd.c (ridiculous isn't it?)
> > > > > 4. old ide driver...
> > > >
> > > > I know people using all 3 of those, while bugs in some of the old scsi 8bit
> > > > drivers went unnoticed for a year.
> > >
> > > We need a 'prompt for unmaintained drivers' trailing-edge option in the
> > > build process so people will know when something's been orphaned and pick
> > > it up.
> >
> > There's already CONFIG_OBSOLETE...
>
> And it's practically obsolete itself, outside of the ARM directory. What
> I'm proposing is something in the Code Maturity menu that's analogous to
> EXPERIMENTAL along with a big (UNMAINTAINED) marker next to unmaintained
> drivers. Obsolete and unmaintained and deprecated all mean slightly
> different things, by the way. So the config option would probably say
> 'Show obsolete, unmaintained, or deprecated items?' and mark each item
> appropriately. Anything that no one made a fuss about by 2.7 would be
> candidates for removal.
The idea behind CONFIG_OBSOLETE is supposed to be that it does not
actually appear as a Y/N option. You enclose a Config.in option with
that, and it disappears
But I'm all for removing old stuff. There is no reason to keep
something that flat out doesn't work and hasn't for a long long time...
if somebody wants to pick it up they can grab linux-2.2 or linux-2.0
from any FTP mirror.
Jeff
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
On Sun, 2 Dec 2001, Jeff Garzik wrote:
> Oliver Xymoron wrote:
> >
> > And it's practically obsolete itself, outside of the ARM directory. What
> > I'm proposing is something in the Code Maturity menu that's analogous to
> > EXPERIMENTAL along with a big (UNMAINTAINED) marker next to unmaintained
> > drivers. Obsolete and unmaintained and deprecated all mean slightly
> > different things, by the way. So the config option would probably say
> > 'Show obsolete, unmaintained, or deprecated items?' and mark each item
> > appropriately. Anything that no one made a fuss about by 2.7 would be
> > candidates for removal.
>
> The idea behind CONFIG_OBSOLETE is supposed to be that it does not
> actually appear as a Y/N option. You enclose a Config.in option with
> that, and it disappears
Which works for stuff that is really known broken. It doesn't work for
stuff that you'd like to get rid of but you suspect people may still be
using (sbpcd) or stuff that you want to phase out (initrd).
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
----- Original Message -----
From: "Alan Cox" <[email protected]>
To: <[email protected]>
Cc: "Alan Cox" <[email protected]>; "Larry McVoy" <[email protected]>;
"Davide Libenzi" <[email protected]>; "Andrew Morton"
<[email protected]>; "Daniel Phillips" <[email protected]>; "Henning
Schmiedehausen" <[email protected]>; "Jeff Garzik"
<[email protected]>; <[email protected]>
Sent: Sunday, December 02, 2001 11:42 AM
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
> > > Question: What happens when people stick 8 threads of execution on a
die with
> > > a single L2 cache ?
> >
> > That had been already researched. Gogin bejoind 2 threads on a single
> > CPU
> > engine doesn't give you very much... The first step is giving about 25%
> > the second only about 5%. There are papers in the IBM research magazine
> > on
>
> The IBM papers make certain architectural assumptions. With some of the
> tiny modern CPU cores its going to perfectly viable to put 4 or 8 of them
> on one die. At that point cccluster still has to have cluster nodes
scaling
> to 8 way
Semiconductor technology will push this way because it's no longer possible
to propagate a signal across the die in one clock cycle. This means
pipeline
interlocking becomes vastly more complicated. The simple solution puts
several CPU cores on the die, each able to interlock in one clock but
sharing
memory over several clocks.
On December 2, 2001 09:12 pm, Ingo Molnar wrote:
> On Sun, 2 Dec 2001, Rik van Riel wrote:
> > Also, natural selection tends to favour the best return/effort ratio,
> > not the best end result. [...]
>
> there is no 'effort' involved in evolution. Nature does not select along
> the path we went. It's exactly this property why it took 5 billion years
> to get here, while Linux took just 10 years to be built from grounds up.
> The fact is that bacteria took pretty random paths for 2 billion years to
> get to the next level. That's alot of 'effort'.
One fact that is often missed by armchair evolutionists is that evolution is
not random. It's controlled by a mechanism (most obviously: gene shuffling)
and the mechanism *itself* evolves. That is why evolution speeds up over
time. There's a random element, yes, but it's not the principle element.
The fact that Linux has evolved from nothing to what it is in a mere 10 years
- 30 if you count the 20 years of Unix that came before it - is due entirely
to the fact that Nature has evolved a very efficient mechanism (us) to guide
Linux's evolution.
> So *once* we have something that is better, it does not matter how long it
> took to get there.
Sure, once you are better than the other guy you're going to eat his lunch.
But time does matter: a critter that fails to get its evolutionary tail in
gear before somebody eats its lunch isn't going to get a second chance.
--
Daniel
> And it's practically obsolete itself, outside of the ARM directory. What
Thats just history. Doesn't mean it won't do the job. Probably when we get
to say 2.5.4 or so someone should do a build all as modules and anything
that doesn't build gets an obsolete tag until someone fixes it.
Anything not fixed for 2.6 will then be nicely labelled
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Alan Cox
> Sent: Saturday, December 01, 2001 2:06 AM
> To: Andrew Morton
> Cc: Davide Libenzi; Larry McVoy; Daniel Phillips; Henning
> Schmiedehausen; Jeff Garzik; [email protected]
> Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
> 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.
I am *completely* underwhelmed by ALSA, *especially* in the areas of
usability and documentation! I have an M-Audio Delta 66 sound card and I was
unable to get ALSA to work with it. At the time I attempted this, I did not
have the free time to do c-code-level integration work; I needed something
that was plug-and-play with usable documentation. I ended up buying the
closed-source OSS/Linux driver, which at least installs and boots. Their
documentation isn't much better, and I finally was forced to dual-boot
Windows 2000 to get a usable audio tool set for this device.
My point here is that just because a composer is *capable* of doing
integration work and building or repairing tools (and I am) does *not* mean
he (or she :-) has either the time or the willingness to do so (and I
don't).
--
Take Your Trading to the Next Level!
M. Edward Borasky, Meta-Trading Coach
[email protected]
http://www.meta-trading-coach.com
http://groups.yahoo.com/group/meta-trading-coach
On Sun, 2 Dec 2001 19:41:26 +0100
Daniel Phillips <[email protected]> wrote:
> One fact that is often missed by armchair evolutionists is that evolution is
> not random. It's controlled by a mechanism (most obviously: gene shuffling)
> and the mechanism *itself* evolves. That is why evolution speeds up over
> time. There's a random element, yes, but it's not the principle element.
You mean "controlled" up to the point where your small environment got randomly
hit by a smaller sized stone coming right from the nowhere corner of the
universe, or not?
Regards,
Stephan
On December 2, 2001 08:04 pm, Stephan von Krawczynski wrote:
> On Sun, 2 Dec 2001 19:41:26 +0100
> Daniel Phillips <[email protected]> wrote:
>
> > One fact that is often missed by armchair evolutionists is that evolution is
> > not random. It's controlled by a mechanism (most obviously: gene shuffling)
> > and the mechanism *itself* evolves. That is why evolution speeds up over
> > time. There's a random element, yes, but it's not the principal element.
>
> You mean "controlled" up to the point where your small environment got randomly
> hit by a smaller sized stone coming right from the nowhere corner of the
> universe, or not?
See "principal" above. There's a random element in the game of bridge, too,
but it's not the principal element.
--
Daniel
Victor Yodaiken <[email protected]> said:
[...]
> Linux is what it is because of design, not accident. And you know
> that better than anyone.
I'd say it is better because the mutations themselves (individual patches)
go through a _very_ harsh evaluation before being applied in the "official"
sources. There is a population of kernels out there (each developer has a
few, distributions check out others, ...), only what survives there has got
a chance to be considered for inclusion.
Sure, this is not the only way Linux moves forward. But it is a large
factor in the success of "Release early. Release often. Take patches from
everywhere."
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
Tim Hockin <[email protected]> said:
> "Linus Torvalds" at Nov 30, 2001 04:50:34 PM said:
> > 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.
If you look at what people in the evolutionistic algorithms camp are doing,
you'll see them consider "mutations" that force movement in the "best"
direction (steepest ascent), not just at random, and similarly other
"intelligent" genetic operators.
In any case, what Linus is saying isn't just "go and change stuff at
random" either..., this is clearly a metaphor. An apt one.
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
Larry McVoy <[email protected]> said:
[...]
> 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.
Maybe that is because 128 CPU machines aren't exactly common... just as
SPARC, m68k, S/390 development lags behind ia32 just because there are
many, many more of the later around.
Just as Linus said, the development is shaped by its environment.
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
> But I'm all for removing old stuff. There is no reason to keep
> something that flat out doesn't work and hasn't for a long long
time...
> if somebody wants to pick it up they can grab linux-2.2 or linux-2.0
> from any FTP mirror.
By the way, what happened to xiafs?
Back to 2.0.33 it even didn't work (complaints after newfs).
Just an interest...
Thorsten
On Sun, 2 Dec 2001 20:17:33 +0100
Daniel Phillips <[email protected]> wrote:
> > You mean "controlled" up to the point where your small environment got
randomly
> > hit by a smaller sized stone coming right from the nowhere corner of the
> > universe, or not?
>
> See "principal" above. There's a random element in the game of bridge, too,
> but it's not the principal element.
Please name another planet where your controlling principle is proven to even
exist.
For a being that is located on a "very small stage in a vast cosmic arena"
(Carl Sagan) you have a very strong opinion about the big picture. How come you
think you are able to _see_ it at all?
Wouldn't it be more accurate to simply admit, we _can't_ see it (at least
currently) and therefore it must be referred to as _random_? Obviously nobody
is hindered to try to find more pixels of the big picture. But shouldn't one
keep in mind that the picture is possibly _very_ big, compared to oneself and
the levels of complexity we are adjusted to.
A dropped stone is possibly only falling _down_ relative to _your_ personal
point of view.
Regards,
Stephan
On Sat, Dec 01, 2001 at 08:18:06PM -0300, Horst von Brand wrote:
> Victor Yodaiken <[email protected]> said:
> > Linux is what it is because of design, not accident. And you know
> > that better than anyone.
>
> I'd say it is better because the mutations themselves (individual patches)
> go through a _very_ harsh evaluation before being applied in the "official"
> sources.
Which is exactly Victor's point. That evaluation is the design. If the
mutation argument held water then Linus would apply *ALL* patches and then
remove the bad ones. But he doesn't. Which just goes to show that on this
mutation nonsense, he's just spouting off.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, Dec 01, 2001 at 08:05:59PM -0300, Horst von Brand wrote:
> Larry McVoy <[email protected]> said:
>
> [...]
>
> > 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.
>
> Maybe that is because 128 CPU machines aren't exactly common... just as
> SPARC, m68k, S/390 development lags behind ia32 just because there are
> many, many more of the later around.
>
> Just as Linus said, the development is shaped by its environment.
Really? So then people should be designing for 128 CPU machines, right?
So why is it that 100% of the SMP patches are incremental? Linux is
following exactly the same path taken by every other OS, 1->2, then 2->4,
then 4->8, etc. By your logic, someone should be sitting down and saying
here is how you get to 128. Other than myself, noone is doing that and
I'm not really a Linux kernel hack, so I don't count.
So why is it that the development is just doing what has been done before?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Hi!
> >> 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 :-)
>
> Cool. I can really see it. "foo inc." releases a GPL driver for Linux
> 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).
>
> Press release:
>
> "If you support Linux, you may get flamed and humiliated in public for
> doing so. Don't do it."
And what? Bad driver is better than proprietary hardware, still good
driver is better than good driver.
And yes, I'd like to see that hall of shame.
Pavel
--
"I do not steal MS software. It is not worth it."
-- Pavel Kankovsky
Hi!
> > 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.
Question is... what hurts us more. Bad press or bad code? I guess bad
code is worse...
Pavel
--
"I do not steal MS software. It is not worth it."
-- Pavel Kankovsky
On Sun, 2 Dec 2001, Larry McVoy wrote:
> So why is it that the development is just doing what has been done before?
No matter how often you try to reinvent the wheel, you'll
end up converging to a round shape.
The sad thing is that many of the people here have to try
the octagonal wheel first (because it's "simpler to build
and more maintainable" ?) and then get confused when they
run into problems.
cheers,
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
I have been following this thread with a mixture of amusement and exasperation - amusement that intelligent people like Linus, who ought to know better, are spouting this evolution stuff, and exasperation that some people think that because someone's an expert in one thing, they are an expert in all things.
The idea of genetic evolution itself is complete nonsense - biological systems don't evolve genetically, they evolve environmentally. Biological systems change as a result of random mutation, and what doesn't work doesn't survive. What people try to pass off as evolution is simply the less fit not surviving to pass on their bad genes. Sort of like the hundred monkeys idea.
But that is all completely irrelevent to coding, since it is extremely inefficient for systems to "evolve" based on trial and error. The way modern systems evolve is based on (hopefully) *intelligent* selection - I write a patch, submit it to Linus. He doesn't accept it, throw it in the kernel, and that's it - he looks at it, what it does, and decides if it fits in the Grand Scheme of things - kernel efficiency, speed, flexibility, extensability, and maintainability - and *then* decides if it makes it in. They key difference is that in nature, mutation is random because it can afford to be - in coding, it isn't because we don't have thousands or millions of years to find out whether or not something works or not.
That being said, I am well aware that "genetic programming" has made some progress in that direction, mainly because it doesn't take millenia to figure out what works and what doesn't. But that's a long way from "evolving" an entire operating system. I don't believe for a moment that homo sapiens "evolved" from pond scum although I might believe that some fellow homo sapiens *are* pond scum!) - it only makes sense that we are a created species, and that Homo Erectus ans all the rest were early genetic experiments. Who created homo sapiens is beyond the scope of this discussion ;)
Original Message:
-----------------
From: Larry McVoy [email protected]
Date: Sun, 02 Dec 2001 12:25:26 -0800
To: [email protected], [email protected], [email protected]
Subject: Re: Coding style - a non-issue
On Sat, Dec 01, 2001 at 08:18:06PM -0300, Horst von Brand wrote:
> Victor Yodaiken <[email protected]> said:
> > Linux is what it is because of design, not accident. And you know
> > that better than anyone.
>
> I'd say it is better because the mutations themselves (individual patches)
> go through a _very_ harsh evaluation before being applied in the "official"
> sources.
Which is exactly Victor's point. That evaluation is the design. If the
mutation argument held water then Linus would apply *ALL* patches and then
remove the bad ones. But he doesn't. Which just goes to show that on this
mutation nonsense, he's just spouting off.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Larry McVoy <[email protected]> writes:
> On Sat, Dec 01, 2001 at 08:05:59PM -0300, Horst von Brand wrote:
> > Larry McVoy <[email protected]> said:
> >
> > [...]
> >
> > > 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.
> >
> > Maybe that is because 128 CPU machines aren't exactly common... just as
> > SPARC, m68k, S/390 development lags behind ia32 just because there are
> > many, many more of the later around.
> >
> > Just as Linus said, the development is shaped by its environment.
>
> Really? So then people should be designing for 128 CPU machines, right?
> So why is it that 100% of the SMP patches are incremental? Linux is
> following exactly the same path taken by every other OS, 1->2, then 2->4,
> then 4->8, etc. By your logic, someone should be sitting down and saying
> here is how you get to 128. Other than myself, noone is doing that and
> I'm not really a Linux kernel hack, so I don't count.
>
> So why is it that the development is just doing what has been done before?
Hmm. Meanwhile linux appears to be the platform of choice for new
clusters. And if you are working on a cluster you can by incremental
improvements reach your design Larry. In truth a 128 CPU machine is a
modest cluster. The typical goal for a large system I have seen is a
1000 Node cluster. Which could mean anywhere from 1000 to 4000
processors. And I have seen a few serious proposals for even larger
systems.
So with a cluster you start by looking for something that scales, on a
relatively slow interconnect. Which is simply lots, and lots of
kernels, that don't know each other at all. And then you figure out
how to get them all talking to each other.
As has been pointed out exporting an interface that looks to the
programmer like a giant SMP. Tends to make programs share too much
data, and thus get high degrees of lock contention.
The next incremental step is to get some good distributed and parallel
file systems. So you can share one filesystem across the cluster.
And there is some work going on in those areas. luster, gfs,
intermezzo.
Eric
On Sun, 2 Dec 2001, Larry McVoy wrote:
> On Sat, Dec 01, 2001 at 08:05:59PM -0300, Horst von Brand wrote:
> > Larry McVoy <[email protected]> said:
> >
> > [...]
> >
> > > 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.
> >
> > Maybe that is because 128 CPU machines aren't exactly common... just as
> > SPARC, m68k, S/390 development lags behind ia32 just because there are
> > many, many more of the later around.
> >
> > Just as Linus said, the development is shaped by its environment.
>
> Really? So then people should be designing for 128 CPU machines, right?
> So why is it that 100% of the SMP patches are incremental? Linux is
> following exactly the same path taken by every other OS, 1->2, then 2->4,
> then 4->8, etc. By your logic, someone should be sitting down and saying
> here is how you get to 128. Other than myself, noone is doing that and
> I'm not really a Linux kernel hack, so I don't count.
>
> So why is it that the development is just doing what has been done before?
That's exactly the Linus point: no long term preventive design.
That means short term design on what we actually have or on what we can
think available in a very near future.
Because, again, if you start designing now an SMP solution for 128 CPUs,
you're going to model it on the current technology that won't probably fit
in future SMP architectures and you'll be screwed up.
There should be a reason why software evolves in this way, think about it.
Either everyone else is fool or you're the prophet.
And if you're the prophet and you think that the future of multiprocessing
is UP on clusters, why instead of spreading your word between us poor
kernel fans don't you pull out money from your pocket ( or investors ) and
start a new Co. that will have that solution has primary and unique goal ?
You could be the J.C. Maxwell of the next century.
- Davide
> > Just as Linus said, the development is shaped by its environment.
>
> Really? So then people should be designing for 128 CPU machines, right?
Linux environment is a single athlon/pii type processor with 128-256Mb of
RAM, because quite simply thats what most developers have.
> So why is it that 100% of the SMP patches are incremental? Linux is
> following exactly the same path taken by every other OS, 1->2, then 2->4,
> then 4->8, etc. By your logic, someone should be sitting down and saying
> here is how you get to 128. Other than myself, noone is doing that and
> I'm not really a Linux kernel hack, so I don't count.
The problem being that unless you happen to have a load of people with 128
processor boxes you can't verify your work is even useful or correct.
You can look at Linux development and the areas which have been heavily
funded rather than written for fun/need by people and you'll see a heavy
slant to the enterprise end. J Random Hacker doesn't have an IA64, an 8 way
SMP box or 2Tb of disk so J Random Hacker is much more interested in making
sure his/her webcam works (which is why we pee all over Solaris X86 on device
support).
Alan
> > a) media echo that "linux core developers start insulting code
> > committers"
> >
> > b) vendors start cleaning up their code.
>
> Question is... what hurts us more. Bad press or bad code? I guess bad
> code is worse...
What would be much much more constructive isnt quite a hall of shame - its
to build a set of pages that take problem drivers and quote chunks of them
with an explanation of _why_ it is wrong, what should be used instead and
possible the "after" code if it also gets cleaned up.
That way people coming along actually learn something from it. Anyone can
be a critic, its rather harder and much more valuable to be a critic that
actually has positive impacts on what you criticize
Alan
Larry McVoy wrote:
>
> Really? So then people should be designing for 128 CPU machines, right?
Linux only supports 99 CPUs. At 100, "ksoftirqd_CPU100" overflows
task_struct.comm[].
Just thought I'd sneak in that helpful observation.
-
> The next incremental step is to get some good distributed and parallel
> file systems. So you can share one filesystem across the cluster.
> And there is some work going on in those areas. luster, gfs,
> intermezzo.
gfs went proprietary - you want opengfs
A lot of good work on the rest of that multi-node clustering is going on
already - take a look at the compaq open source site.
cccluster is more for numa boxes, but it needs the management and SSI views
that the compaq stuff offers simply because most programmers won't program
for a cccluster or manage one.
Alan
On Sun, 2 Dec 2001, Alan Cox wrote:
> What would be much much more constructive isnt quite a hall of shame - its
> to build a set of pages that take problem drivers and quote chunks of them
> with an explanation of _why_ it is wrong, what should be used instead and
> possible the "after" code if it also gets cleaned up.
I planned to do something like this for the kernel-janitor project.
The janitor todo-list is aparently too terse for some people, and
having a perl script to point out problems wasn't enough. Maybe having the
script point to a webpage explaining /why/ xxxx needs changing would be
more useful.
The current TODO list there goes halfway toward this, but needs
expanding, more explanations etc.. Any contributions more than
welcomed.
regards,
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Sun, 2 Dec 2001 15:53:46 -0500
"[email protected]" <[email protected]> wrote:
> I have been following this thread with a mixture of amusement and exasperation - amusement that intelligent people like Linus, who ought to know better, are spouting this evolution stuff, and exasperation that some people think that because someone's an expert in one thing, they are an expert in all things.
No offense toward anyone but I find that many non-religious people can be found in the CompSci area of expertise. I'm not sure why this is but besides myself and another friend all the other people I know in that general field are atheists. It would only make sense that we would hear atheist type remarks within these discussions just as we would hear Christian remarks in another field of expertise that seems to attract Christians.
>
> The idea of genetic evolution itself is complete nonsense - biological systems don't evolve genetically, they evolve environmentally. Biological systems change as a result of random mutation, and what doesn't work doesn't survive. What people try to pass off as evolution is simply the less fit not surviving to pass on their bad genes. Sort of like the hundred monkeys idea.
True. Many mutations in human DNA cause the resulting human to be unable to reproduce once they reach the age where a normal human could do so.
>
> But that is all completely irrelevent to coding, since it is extremely inefficient for systems to "evolve" based on trial and error. The way modern systems evolve is based on (hopefully) *intelligent* selection - I write a patch, submit it to Linus. He doesn't accept it, throw it in the kernel, and that's it - he looks at it, what it does, and decides if it fits in the Grand Scheme of things - kernel efficiency, speed, flexibility, extensability, and maintainability - and *then* decides if it makes it in. They key difference is that in nature, mutation is random because it can afford to be - in coding, it isn't because we don't have thousands or millions of years to find out whether or not something works or not.
We have a way of being able to direct the evolution of our code as we can control the bad parts and teh good parts and what gets added and what doesn't. We have no control over our DNA (human genetics may have proven me wrong already but if not, it shouldn't take more than a few months more) so mutations in the human race are more random.
>
> That being said, I am well aware that "genetic programming" has made some progress in that direction, mainly because it doesn't take millenia to figure out what works and what doesn't. But that's a long way from "evolving" an entire operating system. I don't believe for a moment that homo sapiens "evolved" from pond scum although I might believe that some fellow homo sapiens *are* pond scum!) -
*finally* someone who doesn't believe in evolution of the human race. As a side note, i've heard some people say that a bolt of lightning triggered some proteins to start growing into single celled organisms and then into what we now call today human beings. I take offense that I came from a single celled organism. I believe the more complex an object or system is the less randomness can be added in order to arrive at the current/final version. I think we all agree the human body is the most complex object in the universe so how can we say that our existence was an accident?
An operating system is a complex system as well. We all know code doesn't evolve on its own to generate an operating system right? :) It has to be created and as time goes on code forks are sometimes introduced. In humans that could be somewhat akin to whites, blacks, asians, etc. But they were all created from the code that God started with. He just released his source code(dna) a little later in the development tree than some people may have wanted so there was no point in letting us evolve into something more as we were already different enough. :)
>it only makes sense that we are a created species, and that Homo Erectus ans all the rest were early genetic > experiments. Who created homo sapiens is beyond the scope of this discussion ;)
It is beyond the scope. If we attempted that topic we would be branded as close-minded even though the others (read: non-religious) can do it and they defend themselves by saying its free speech.
my time is out for this post.
brandon
On Sun, 2 Dec 2001, Andrew Morton wrote:
> > Really? So then people should be designing for 128 CPU machines, right?
> Linux only supports 99 CPUs. At 100, "ksoftirqd_CPU100" overflows
> task_struct.comm[].
> Just thought I'd sneak in that helpful observation.
Wasn't someone looking at fixing that problem so it didn't need a per-cpu
thread ? 128 kernel threads sitting around waiting for a problem that
rarely happens seems a little.. strange. (for want of a better word).
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
> Please Larry, have a look at the environment: nobody here owns a box
> with 128 CPUs. Most of the people here take care of things they either
> - own themselves
> - have their hands own at work
> - get paid for
>
> You will not find _any_ match with 128 CPUs here.
Nor will you find any match with 4 or 8 CPU systems, except in very rare
cases. Yet changes go into the system for 8 way and 16 way performance.
That's a mistake.
I'd be ecstatic if the hackers limited themselves to what was commonly
available, that is essentially what I'm arguing for.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Alan Cox <[email protected]>
Date: Sun, 2 Dec 2001 16:57:46 +0000 (GMT)
The main Red Hat test suite is a version of Cerberus (originally from VA
and much extended), its all free software and its available somewhere
although I don't have the URL to hand, Arjan ?
http://people.redhat.com/bmatthews/cerberus/
brandon wrote:
|
| *finally* someone who doesn't believe in evolution of the human race.
| As a side note, i've heard some people say that a bolt of lightning
| triggered some proteins to start growing into single celled organisms
| and then into what we now call today human beings. I take offense
| that I came from a single celled organism. I believe the more complex
| an object or system is the less randomness can be added in order to
| arrive at the current/final version. I think we all agree the human
| body is the most complex object in the universe so how can we say that
| our existence was an accident?
Again, a complete misunderstanding of evolution. Evolution is itself
a design process.. it is simply a design process that admits to an
literally unthinkable amount of complexity. No individual or team of
individuals, no matter how intelligent, could sit down and create from
scratch the Linux kernel as it exists today. There are tons and tons
of design elements in the code that emerged from trial and error, and
from interactions between the hardware to be supported, the user level
code to run on it, and the temporal exigencies of the kernel code
itself. The fact that humans applied thought to all (well, at least
to some) of the changes made doesn't mean that the overarching dynamic
isn't an evolutionary one.
Taking offense at evolution having produced us from simpler organisms
is like taking offense at the rain, or the sun setting at night. We
can now look at life and actually read the code, and see how much is
held in common and how much varies between different organisms, just
as surely as we can with all of the linux kernels over the last ten
years. Both systems have lots of characteristics in common, and for
perfect reasons.
Linus is right.
-------------------------------------------------------------------------------
Jonathan Abbey [email protected]
Applied Research Laboratories The University of Texas at Austin
Ganymede, a GPL'ed metadirectory for UNIX http://www.arlut.utexas.edu/gash2
Followup to: <000b01c17b68$2ff846e0$30d8fea9@ecce>
By author: "[MOc]cda*mirabilos" <[email protected]>
In newsgroup: linux.dev.kernel
>
> By the way, what happened to xiafs?
> Back to 2.0.33 it even didn't work (complaints after newfs).
>
It got ripped out because the vfs changed and noone ported it.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
"M. Edward Borasky" <[email protected]> said:
[...]
> My point here is that just because a composer is *capable* of doing
> integration work and building or repairing tools (and I am) does *not* mean
> he (or she :-) has either the time or the willingness to do so (and I
> don't).
So band together with some others with your same problem, and pay somebody
to fix it. What you saved on propietary OS lease should make up for it.
Amply.
Oh wait, you are just a troll, right?
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
Horst von Brand wrote:
> Have you got any idea how QA is done in closed environments?
Yes I do. I write commercial sofware for 10 years and have
experience with QA systems in two companies, one of them
major. I think I have seen the full range of QA in various projects -
from a complete negation to a silly buerocratic inefficient one.
> Complex software *has* bugs, bugs which aren't apparent
> except under unsusual circumstances are rarely found in the
> first round of bug chasing.
Sure. But we now have 2.4.16, not 2.4.0 and guess what? -
there is a big thread about fs corruption going right now
in the l-k :-( This should _not_ happen in the stab{le,ilizing}
series and if it happened, the cause should be identified
and measures taken.
I for one think that the kernel has overgrown its current
development model and that some _incremental_ steps
in the direction of both more formal control and delegation
of responsibilities are needed. I think that the most active
kernel developers should discuss the future of the development
model, as they are the only ones that can really come up
with a solution.
It is of course only my opinion - if I am alone having it, forget it.
> > As a user of the vendor's kernel I have no idea what to do
> > with a bug.
>
> Report it to the vendor, through the documented channels?
Did this. It is two months, I did some cornering of the problem
and augmented the report several times. The issue is still NEW,
without any response asking to try a patch, supply more details
or such. Yes, this speaks more of the vendor than of the Linux.
But what impression do you think the average user gets from
such experience?
Regards
--
Stano
On Sun, 2 Dec 2001, Davide Libenzi wrote:
> That's exactly the Linus point: no long term preventive design.
And now for the ones that don't speak Italish :
s/preventive/prior/
- Davide
On December 2, 2001 09:25 pm, Larry McVoy wrote:
> On Sat, Dec 01, 2001 at 08:18:06PM -0300, Horst von Brand wrote:
> > Victor Yodaiken <[email protected]> said:
> > > Linux is what it is because of design, not accident. And you know
> > > that better than anyone.
> >
> > I'd say it is better because the mutations themselves (individual patches)
> > go through a _very_ harsh evaluation before being applied in the
"official"
> > sources.
>
> Which is exactly Victor's point. That evaluation is the design.
Nope, that isn't design, that's reacting.
> If the mutation argument held water then Linus would apply *ALL* patches
> and then remove the bad ones. But he doesn't. Which just goes to show
> that on this mutation nonsense, he's just spouting off.
Hogwash ;) Please see my post above where I point out 'evolution isn't
random'. Your genes have a plan, if only a vague one. It goes something
like this: "we'll allow random variations, but only along certain lines,
within limits, and in certain combinations, and we'll try to stick to
variations that haven't killed us in the past."
Sounds a lot like how Linus does things, huh?
I'm sure Linus does have quite considerable talent for design, but I haven't
seen him execise it much. Mostly he acts as a kind of goodness daemon,
sitting in his little pinhole and letting what he considers 'good' stuff pass
into the box. There's no doubt about it, it's different from the way you
like to develop, you and me both. Equally clearly, it works pretty well.
--
Daniel
On December 2, 2001 09:53 pm, [email protected] wrote:
> I have been following this thread with a mixture of amusement and
> exasperation - amusement that intelligent people like Linus, who ought to
> know better, are spouting this evolution stuff, and exasperation that some
> people think that because someone's an expert in one thing, they are an
> expert in all things.
That's because you're not quite clear on the concept.
> ...in nature, mutation is random
It isn't random, if it were most mutated individuals would be stillborn.
> because it can afford to be...
No it can't.
--
Daniel
> *finally* someone who doesn't believe in evolution of the human race. As a side note, i've heard some people say that a bolt of lightning triggered some proteins to start growing into single celled organisms and then into what we now call today human beings. I take offense that I came from a single celled organism. I believe the more complex an object or system is the less randomness can be added in order to arrive at the current/final version. I think we all agree the human body is the most complex object in the universe so how can we say that our existence was an accident?
>
I personally will stay out of the religious side of this argument,
having been flamed for standing up for any religious stand point on this
list.
However, I just finished my two bio classes for my CS degree. It is
interesting that you mention this lightening theory. My bio book (sorry
no references and no quotes, maybe later) stated that many people
(60's-80's) have tried very hard to duplicate and find conditions
whereby simple molecules could even form basic RNA or other such
biological/organic compounds. They had some very minimal success. In
the end it was concluded that the methods they were trying probably
would never have created RNA and other such things that may have
assembled a cell. Some of these tests were based on this lightening
theory.
Maybe such spontaneous life could have happened another way... I don't
really know.
As for software evolution. I would have to weigh in with my opinion
being somewhere between Linus and many others. Software does evolve.
Just about any human project does. This is one reason why there are
"versions", "editions", etc. You can only design so much. Then you go
back and evolve it. Is Linus right that there was nearly no design?? I
think he would know best about the earliest roots of Linux. However, I
think he is wrong that now there is no design (though there may be no
master plan, which would mean it is controlled evolution more than
engineered/designed).
Anyway, I will sink back into silence for now.
Trever Adams
Alan Cox <[email protected]> writes:
> > The next incremental step is to get some good distributed and parallel
> > file systems. So you can share one filesystem across the cluster.
> > And there is some work going on in those areas. luster, gfs,
> > intermezzo.
>
> gfs went proprietary - you want opengfs
Right.
> A lot of good work on the rest of that multi-node clustering is going on
> already - take a look at the compaq open source site.
Basically my point.
> cccluster is more for numa boxes, but it needs the management and SSI views
> that the compaq stuff offers simply because most programmers won't program
> for a cccluster or manage one.
I've seen a fair number of mpi programs, and if you have a program
that takes weeks to run on a single system. There is a lot of
incentive to work it out. Plus I have read about a lot of web sites
that are running on a farm of servers. Admittedly the normal
architecture has one fat database server behind the web servers, but
that brings me back to needing a good distributed storage techniques.
And I really don't care if most programmers won't program for a
cccluster. Most programmers don't have one or a problem that needs
one to solve. So you really only need those people interested in the
problem to work on it.
But single system image type projects are useful, but need to be
watched. You really need to standardize on how a cluster is put
together (software wise), and making things easier always helps. But
you also need to be very careful because you can easily write code
that does not scale. And people doing cluster have wild notions of
scaling o.k. 64 Nodes worked let's try a thousand...
As far as I can tell the only real difference between a numa box, and
a normal cluster of machines running connected with fast ethernet is
that a numa interconnect is a blazingly fast interconnect. So if you
can come up with a single system image solution over fast ethernet a
ccNuma machine just magically works.
Eric
Stanislav Meduna <[email protected]> said:
> "Alan Cox" at dec 01, 2001 09:18:15 said:
[...]
> > If you want a high quality, tested supported kernel which has been through
> > extensive QA then use kernel for a reputable vendor, or do the QA work
> > yourself or with other people.
> Correct. But this has one problem - it is splitting resources.
> Pushing much of the QA work later in the process means
> that the bugs are found later, that there is more people
> doing this as absolutely necessary and that much more
> communication (and this can be the most important bottleneck)
> is needed as necessary.
Have you got any idea how QA is done in closed environments?
> The need of the VM change is probably a classical example -
> why was it not clear at the 2.4.0-pre1, that the current
> implementation is broken to the point of no repair?
Perhaps because of the same phenomenon that made MS state "WinNT 4.0 has no
flaws" when asked about a nasty problem shortly after release, and it is
now at sp6a + numerous "hotfixes". Like Win2k which now has sp2. Like
Solaris, which still is being fixed. Etc, ad nauseam. Complex software
*has* bugs, bugs which aren't apparent except under unsusual circumstances
are rarely found in the first round of bug chasing.
[...]
> As a user of the vendor's kernel I have no idea what to do
> with a bug.
Report it to the vendor, through the documented channels?
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
On Sun, 02 Dec 2001 15:21:57 -0800 (PST),
"David S. Miller" <[email protected]> wrote:
> From: Keith Owens <[email protected]>
> Date: Sat, 01 Dec 2001 12:17:03 +1100
>
> What is ugly in aic7xxx is :-
>
>You missed:
>
>* #undef's "current"
Where? fgrep -ir current 2.4.17-pre2/drivers/scsi/aic7xxx did not find it.
> On Sat, Dec 01, 2001 at 08:05:59PM -0300, Horst von Brand wrote:
> > Just as Linus said, the development is shaped by its environment.
>
> Really? So then people should be designing for 128 CPU machines,
right?
> So why is it that 100% of the SMP patches are incremental? Linux is
> following exactly the same path taken by every other OS, 1->2, then
2->4,
> then 4->8, etc. By your logic, someone should be sitting down and
saying
> here is how you get to 128. Other than myself, noone is doing that
and
> I'm not really a Linux kernel hack, so I don't count.
>
> So why is it that the development is just doing what has been done
before?
Please Larry, have a look at the environment: nobody here owns a box
with 128 CPUs. Most of the people here take care of things they either
- own themselves
- have their hands own at work
- get paid for
You will not find _any_ match with 128 CPUs here.
_Obviously_ you are completely right if this were a company _building_
these boxes. Then your question is the right one, as they would get
paid for the job.
But this is a different environment. As long as you cannot buy these
boxes at some local store for a buck and a bit, you will have no
chance to find willing people for your approach. Therefore it is
absolutely clear, that it will (again) walk the line from 1,2,4,8 ...
CPUs, because the boxes will be available along this line.
I give you this advice: if you _really_ want to move something in this
area, find someone who should care about this specific topic, and has
the money _and_ the will to pay for development of critical GPL code
like this.
Take the _first_ step: create the environment. _Then_ people will come
and follow your direction.
Regards,
Stephan
Larry McVoy wrote:
> Which is exactly Victor's point. That evaluation is the design. If the
> mutation argument held water then Linus would apply *ALL* patches and then
> remove the bad ones. But he doesn't. Which just goes to show that on this
> mutation nonsense, he's just spouting off.
Eh, come on Larry. You're too smart for this crap (as are others, your
straw just broke the camel's back). Linus was just using an analogy to
illustrate some very valid points. All analogies break down when
applied to the nth degree. Insulting Linus because you've found a spot
where the analogy breaks is just ludicrous.
regards,
David
From: Keith Owens <[email protected]>
Date: Sat, 01 Dec 2001 12:17:03 +1100
What is ugly in aic7xxx is :-
You missed:
* #undef's "current"
On Sun, Dec 02, 2001 at 08:34:09PM -0500, David L. Parsley wrote:
> Larry McVoy wrote:
> > Which is exactly Victor's point. That evaluation is the design. If the
> > mutation argument held water then Linus would apply *ALL* patches and then
> > remove the bad ones. But he doesn't. Which just goes to show that on this
> > mutation nonsense, he's just spouting off.
>
> Eh, come on Larry. You're too smart for this crap (as are others, your
> straw just broke the camel's back). Linus was just using an analogy to
> illustrate some very valid points. All analogies break down when
> applied to the nth degree. Insulting Linus because you've found a spot
> where the analogy breaks is just ludicrous.
This whole mutation crap is ludicrous and if you read through the archives
you can find numerous examples where Linus himself says so. I have no idea
why he is saying what he is, but that's neither here nor there. Nonsense
is nonsense, regardless of who says it or why they say it.
Doesn't it strike you the least bit strange that when I challenge Linus to
bow out because he asserts that he isn't needed, this is just some grand
experiment in genetics which is working fine, he says everything would be
fine if he left but he isn't going to because he's having fun? Isn't that
just a tad convenient? It's a crock of crap too. Linus has excellent taste,
better than any OS guy I've run into in 20 years, and if he bowed out a ton
of crap would make it into the kernel that doesn't now. Genetic mutation
my ass. If you want an experiment in evolution, then let *everything* into
the kernel. That's how evolution works, it tries everything, it doesn't
prescreen. Go read Darwin, go think, there isn't any screening going on,
evolution *is* the screening.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sun, 2 Dec 2001, Alan Cox wrote:
> > Is the test suite (or at least part of it) public, or is it
> > considered to be a trade-secret of Red Hat? I see there
> > is a "Red Hat Ready Test Suite" - is this a part of it?
>
> The main Red Hat test suite is a version of Cerberus (originally from VA
> and much extended), its all free software and its available somewhere
> although I don't have the URL to hand, Arjan ?
I think it's at <http://people.redhat.com/bmatthews/cerberus/>
later,
chris
--
Chris Ricker [email protected]
For if we may compare infinities, it would
seem to require a greater infinity of power
to cause the causes of effects, than to
cause the effects themselves.
-- Erasmus Darwin
Dave Jones wrote:
>
> On Sun, 2 Dec 2001, Andrew Morton wrote:
>
> > > Really? So then people should be designing for 128 CPU machines, right?
> > Linux only supports 99 CPUs. At 100, "ksoftirqd_CPU100" overflows
> > task_struct.comm[].
> > Just thought I'd sneak in that helpful observation.
>
> Wasn't someone looking at fixing that problem so it didn't need a per-cpu
> thread ?
Not to my knowledge.
> 128 kernel threads sitting around waiting for a problem that
> rarely happens seems a little.. strange. (for want of a better word).
I've kinda lost the plot on ksoftirqd. Never really understood
why a thread was needed for this, nor why it runs at nice +20.
But things seem to be working now.
-
Larry McVoy <[email protected]> said:
> [email protected] on Sat, Dec 01, 2001 at 08:18:06PM -0300
[...]
> > I'd say it is better because the mutations themselves (individual patches)
> > go through a _very_ harsh evaluation before being applied in the "official"
> > sources.
> Which is exactly Victor's point. That evaluation is the design. If the
> mutation argument held water then Linus would apply *ALL* patches and then
> remove the bad ones. But he doesn't. Which just goes to show that on this
> mutation nonsense, he's just spouting off.
Who is to say that bad mutations can't be weeded out _before_ a full
organism is built? It seems not to happen openly in nature's evolution
(then again, there are non-viable embryos, various DNA repair mechanisms
that seem to go wrong all the time in certain parts of the genome, parts
that mutate very fast while others don't change, ...), but this is just a
metaphor, not a slavish following. We certainly (at least think we) can do
better than just random typing.
In your reading, the environment (which evaluates individuals) is the
design. Right (in the sense that you end up with individuals fit to that
environment), but also very wrong (as many quite different layouts will
work).
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
On Sun, 2 Dec 2001, Brandon McCombs wrote:
[snip badly-formatted creationism advocacy]
Please, learn to
* use line breaks
* be intellectually honest
* be at least remotely on-topic
*plonk*
On Mon, Dec 03, 2001 at 01:55:08AM +0100, Daniel Phillips wrote:
> I'm sure Linus does have quite considerable talent for design, but I haven't
> seen him execise it much. Mostly he acts as a kind of goodness daemon,
> sitting in his little pinhole and letting what he considers 'good' stuff pass
> into the box. There's no doubt about it, it's different from the way you
> like to develop, you and me both. Equally clearly, it works pretty well.
This is a good explanation of why Linux may fail as a project, but it is
pure fantasy as to how it has so far succeded as a project.
The tiny part of system I wrote directly and the larger part that
I got to see up close involved a great deal of design, old fashioned
careful engineering, and even aesthetic principles of what wasgood
design.
Don't drink the cool aid. Go back and look in the kernel archives and
you will see extensive design discussions among all the core developers.
Linus has a point about the development of Linux not being in
accord with some master plan (at least not one anyone admits to) , but
that's about as far as it goes.
On Sun, 2 Dec 2001, Rik van Riel wrote:
> I think you've pretty much proven how well random
> development works.
i think it's fair to say that we should not increase entropy artificially,
eg. we should not apply randomly generated patches to the kernel tree.
the point is, we should accept the fact that while this world appears to
be governed by rules to a certain degree, the world is also chaotic to a
large degree, and that a Grand Plan That Explains Everything does not
exist. And even if it existed, we are very far away from achieving it, and
even if some friendly alien dropped it on our head, we'd very likely be
unable to get our 5 billion brain cells into a state that is commonly
referred to as 'fully grokking it'.
and having accepted these limitations, we should observe the unevitable
effects of them: that any human prediction of future technology
development beyond 5 years is very, very hypothetical, and thus we must
have some fundamental way of dealing with this unpredictability. (such as
trying to follow Nature's Smart Way Of Not Understanding Much But Still
Getting Some Work Done - called evolution.)
Ingo
Larry McVoy <[email protected]> said:
> [email protected] on Sun, Dec 02, 2001 at 11:52:32PM +0100 said:
[...]
> > You will not find _any_ match with 128 CPUs here.
>
> Nor will you find any match with 4 or 8 CPU systems, except in very rare
> cases. Yet changes go into the system for 8 way and 16 way performance.
> That's a mistake.
And you are proposing a fork for handling exactly this? I don't get it...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On December 3, 2001 01:04 pm, Victor Yodaiken wrote:
> On Mon, Dec 03, 2001 at 01:55:08AM +0100, Daniel Phillips wrote:
> > I'm sure Linus does have quite considerable talent for design, but I haven't
> > seen him exercise it much. Mostly he acts as a kind of goodness daemon,
> > sitting in his little pinhole and letting what he considers 'good' stuff pass
> > into the box. There's no doubt about it, it's different from the way you
> > like to develop, you and me both. Equally clearly, it works pretty well.
>
> This is a good explanation of why Linux may fail as a project, but it is
> pure fantasy as to how it has so far succeeded as a project.
>
> The tiny part of system I wrote directly and the larger part that
^^^^^^^^^
> I got to see up close involved a great deal of design, old fashioned
> careful engineering, and even aesthetic principles of what wasgood
> design.
You're just supporting the point of view that Linus has been espousing, and
I personally support: Linux is engineered at a micro level[1] but evolves
on its own at a macro level.
Sure, Linux evolves with help from Linus, but he acts as a filter, not a
designer. When Linus does on rare occasions forget himself and actually
design something, its micro-engineering like you or I would do. So if Linux
is designed, who does do the designing, can you name him? I can tell you for
sure it's not Linus.
> Don't drink the cool aid. Go back and look in the kernel archives and
> you will see extensive design discussions among all the core developers.
> Linus has a point about the development of Linux not being in
> accord with some master plan (at least not one anyone admits to) , but
> that's about as far as it goes.
Don't worry about me drinking the cool aid, first I already drank it and
second I'm personally already fully devoted to the notion of design process,
including all the usual steps: blue sky, discussion, requirements, data
design, detail design, prototype, etc. etc. You'll find the 'paper trails'
in the archives if you've got the patience to go spelunking, and you'll have
a hard time finding one of those designs that became a dead end. This design
thing does work for me. It doesn't change the fact that what I'm doing is
micro-engineering.
I'll get really worried if Linus wakes up one day and decides that from now
on he's going to properly engineer every aspect of the Linux kernel. The
same way I'd feel if Linux got taken over by a committee.
--
Daniel
[1] In places. All those little warts and occasional pools of sewage are
clearly not 'engineered'.
>> Really? So then people should be designing for 128 CPU machines, right?
>
> Linux only supports 99 CPUs. At 100, "ksoftirqd_CPU100" overflows
> task_struct.comm[].
>
> Just thought I'd sneak in that helpful observation.
For machines that are 99bit architectures or more, maybe. For 32 bit machines,
your limit is 32, for 64 bit, 64.
M.
> As far as I can tell the only real difference between a numa box, and
> a normal cluster of machines running connected with fast ethernet is
> that a numa interconnect is a blazingly fast interconnect.
Plus some fairly hairy cache coherency hardware.
> So if you
> can come up with a single system image solution over fast ethernet a
> ccNuma machine just magically works.
it's not cc if you just use fast ethernet.
Martin.
>> Please Larry, have a look at the environment: nobody here owns a box
>> with 128 CPUs. Most of the people here take care of things they either
>> - own themselves
>> - have their hands own at work
>> - get paid for
>>
>> You will not find _any_ match with 128 CPUs here.
>
> Nor will you find any match with 4 or 8 CPU systems, except in very rare
> cases. Yet changes go into the system for 8 way and 16 way performance.
> That's a mistake.
>
> I'd be ecstatic if the hackers limited themselves to what was commonly
> available, that is essentially what I'm arguing for.
We need a *little* bit of foresight. If 4 ways are common now, and 8 ways
and 16 ways are available, then in a year or two 8 ways (at least) will be
commonplace. On the other hand 128 cpu machines are a way off, and
I'd agree we shouldn't spend too much time on them right now.
Martin.
> -----Original Message-----
> From: Horst von Brand [mailto:[email protected]]
> Sent: Sunday, December 02, 2001 7:23 PM
> To: M. Edward Borasky
> Cc: [email protected]
> Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
>
>
> "M. Edward Borasky" <[email protected]> said:
>
> [...]
>
> > My point here is that just because a composer is *capable* of doing
> > integration work and building or repairing tools (and I am)
> does *not* mean
> > he (or she :-) has either the time or the willingness to do so (and I
> > don't).
>
> So band together with some others with your same problem, and pay somebody
> to fix it. What you saved on propietary OS lease should make up for it.
> Amply.
What I spent on Windows 2000 is $300 US. This converted my $400
top-of-the-line sound card from a useless space-taker on my desk to a
functioning musical device. As for banding together with some others, well,
they are even *more* frustrated than I am, because most of them are *purely*
musicians and *can't* program. Nor do they have the money to spend on
programmers. I'm on a number of musical mailing lists, and their
overwhelming complaint is that they spend most of their time being system
administrators rather than musicians/composers. And these are people using
*commercial* tools -- some *quite* expensive -- on Windows and Macs.
> Oh wait, you are just a troll, right?
Not really ... if you'd like I can be, though. Eventually, when I run out of
other projects, I'll sit down and force ALSA to work with my sound card if
someone hasn't done it already. Of course, now that I have the sound card
running and Windows 2000, why would I need to? So much of Linux is
plug-and-play right now, at least the Red Hat Linux that I'm using. I bought
a sound card unsupported by Red Hat because I knew of two drivers for it --
OSS/Linux and ALSA. I tried ALSA first and gave up on it after a week of
agony on the ALSA mailing list. Then I bought OSS/Linux, which installed
fine but didn't generate any sound. When I sent e-mail to the support desk,
I got a very fast response -- RTFM. The FM in this case consists of a single
page ASCII document which is less than helpful.
What I'm trying to establish here is that if ALSA is to become the
main-stream Linux sound driver set, it's going to need to support -- *fully*
support -- the top-of-the-line sound cards like my M-Audio Delta 66. It
isn't enough to just support the Envy chip inside -- it has to support the
whole card with interfaces to all the sound tools that come with KDE and
Gnome! It has to install flawlessly, boot flawlessly and understand
everything that is in the card. I haven't checked recently to see if the
ALSA situation has changed any -- too busy making music on my Windows
machine :-).
--
Take Your Trading to the Next Level!
M. Edward Borasky, Meta-Trading Coach
[email protected]
http://www.meta-trading-coach.com
http://groups.yahoo.com/group/meta-trading-coach
On Fri, Nov 30, 2001 at 12:17:43PM -0800, Paul G. Allen wrote:
> Actually it bloats the source (we all know C++ bloats the resulting code
> ;), but what's wrong with that? At least a person can understand what's
> going on and get to coding, instead of deciphering.
Yes, I do see the smiley, but since its not clear to me on whether its meant
as a "j/k" or not, and being tried of listening the same shit for years,
I'll have to add that C++ does not bloat code.
--
____/| Ragnar H?jland Freedom - Linux - OpenGL | Brainbench MVP
\ o.O| PGP94C4B2F0D27DE025BE2302C104B78C56 B72F0822 | for Unix Programming
=(_)= "Thou shalt not follow the NULL pointer for | (http://www.brainbench.com)
U chaos and madness await thee at its end."
In view of the 100's of messages spawned by this topic, I can only be thankful
that this is a "non-issue" ;-) Just imagine a substantive topic like, maybe,
Linux!
---------------------------------------------+-----------------------------
Tommy Reynolds | mailto: <[email protected]>
Red Hat, Inc., Embedded Development Services | Phone: +1.256.704.9286
307 Wynn Drive NW, Huntsville, AL 35805 USA | FAX: +1.256.837.3839
Senior Software Developer | Mobile: +1.919.641.2923
> One one thing he simple appears to have forgotten: Operating
> systems have a *purpose*.
You're forgetting that Linus makes a kernel, not an OS.
This isn't the Linux OS Mailing List, it's the Linux Kernel Mailing List.
How can Linus be expected to make a formal design for a kernel
when he has no control over how the kernel is used?
(This being the strength of Linux : it can be used almost everywhere)
If you want an _OS_ try one of the BSD's : they have a declared purpose,
after all :)
Dana Lacoste
Peregrine Systems
Ottawa, Canada
Larry McVoy <[email protected]> writes:
>then 4->8, etc. By your logic, someone should be sitting down and saying
>here is how you get to 128. Other than myself, noone is doing that and
>I'm not really a Linux kernel hack, so I don't count.
"No one that you know". I'm always surprised that you're able to speak
with such confidence. There may be lots of things going on that don't
daily report to you.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
On Mon, Dec 03, 2001 at 11:01:24PM +0000, Henning P. Schmiedehausen wrote:
> Larry McVoy <[email protected]> writes:
>
> >then 4->8, etc. By your logic, someone should be sitting down and saying
> >here is how you get to 128. Other than myself, noone is doing that and
> >I'm not really a Linux kernel hack, so I don't count.
>
> "No one that you know". I'm always surprised that you're able to speak
> with such confidence. There may be lots of things going on that don't
> daily report to you.
Right you are, but... There is also piles of information that I absorb
on a daily basis, and I'm always willing to be educated. For example,
you could educate me about all those 128 processor Linux boxes in the
world and fill in a hole in my knowledge. I'm listening...
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
>> Larry McVoy <[email protected]> writes:
>>
>> > then 4->8, etc. By your logic, someone should be sitting down and saying
>> > here is how you get to 128. Other than myself, noone is doing that and
>> > I'm not really a Linux kernel hack, so I don't count.
>>
>> "No one that you know". I'm always surprised that you're able to speak
>> with such confidence. There may be lots of things going on that don't
>> daily report to you.
>
> Right you are, but... There is also piles of information that I absorb
> on a daily basis, and I'm always willing to be educated. For example,
> you could educate me about all those 128 processor Linux boxes in the
> world and fill in a hole in my knowledge. I'm listening...
SGI has machines bigger than 128 (if memory serves, 1024??) that I thought
had booted Linux. The Sequent/IBM NUMA-Q archictecture now supports Linux
and would go to 64 procs if we removed a few bitmap limitations from the kernel
that have been patched out before (well, actually 60 is easy, 64 would require
some more apic modifications).
Anyway, bigger than 8 way is no pipedream. I'll admit few people could afford
such machines, but they do exist.
Martin.
On Sun, 2 Dec 2001, Daniel Phillips wrote:
> One fact that is often missed by armchair evolutionists is that
> evolution is not random. It's controlled by a mechanism (most
> obviously: gene shuffling) and the mechanism *itself* evolves. That is
> why evolution speeds up over time. There's a random element, yes, but
> it's not the principle element.
claiming that the randomness is not the principle element of evolution is
grossly incorrect.
there are two components to the evolution of species: random mutations and
a search of the *existing* gene space called gene shuffling. (to be more
exact gene shuffling is only possible for species that actually do it -
bacteria dont.)
In fact gene shuffling in modern species is designed to 'search for useful
features rewarded by the environment to combine them in one specimen'. Ie.
the combination of useful features such as 'feathers' or 'wings',
introduced as random mutations of dinosaurs. Gene shuffling does not
result in radically new features.
gene shuffling is just the following rule: 'combine two successful DNA
chains more or less randomly to find out whether we can get the better
genes of the two.'. Since most species reproduce more than once, random
gene shuffling has a chance of combining the best possible genes. Risking
oversimplification, i'd say that genes are in essence invariant 'modules'
of a species' genetic plan, which can be intermixed between entities
without harming basic functionality. A requirement of the gene shuffling
process is that the resulting entity has to remain compatible enough with
the source entities to be able to reproduce itself and intermix its genes
with the original gene pool.
in terms of Linux, various new genes are similar to various patches that
improve the kernel. Some of them produce a kernel that crashes trivially,
those are obviously incorrect. Some of them might or might not be useful
in the future. We dont know how the environment will evolve in the future,
so we better keep all our options open and have a big enough 'gene pool'.
The development of individual patches is 'directed' and 'engineered' in
the sense that they produce a working kernel and they are derived from
some past experience and expectations of future. They might be correct or
incorrect, but judging them is always a function of the 'environment'.
Some patches become 'correct' over time. Eg. the preemptable kernel
patches are gaining significance these days - it was clearly a no-no 3
years ago. This is because the environment has changed, and certain
patches predicted or guessed the direction of technology environment
correctly.
if you look at patches on the micro-level, it has lots of structure, and
most of it is 'engineered'. If you look at it on the macro-level, the
Linux kernel as a whole has
(and gene shuffling itself has another random component as well, it's the
imperfectness of it that is one of the sources of random mutations.)
saying that the randomness of evolution is not the principle element is
like claiming that the current Linux code is sufficient and we only have
to shuffle around existing functions to make it better.
> > So *once* we have something that is better, it does not matter how long it
> > took to get there.
>
> Sure, once you are better than the other guy you're going to eat his
> lunch. But time does matter: a critter that fails to get its
> evolutionary tail in gear before somebody eats its lunch isn't going
> to get a second chance.
this is another interesting detail: the speed of being able to adopt to a
changing environment does matter.
But the original claim which i replied to was that the cost of developing
a new 'feature' matters. Which i said is not true - evolution does not
care about time of development if the environment is relatively stable, or
is changing slowly. The speed of evolution/development only matters once
the environment changes fast.
So to draw the analogy with Linux - as long as the environment (chip
technology, etc.) changes rapidly, what matters most is the ability to
evolve. But once the environment 'cools down' a bit, we can freely search
for the most perfect features in a stable environment, and we'll end up
being 99.9% perfect (or better). [ The original claim which i replied to
said that we'll end up being 95% perfect and stop there, because further
development is too expensive - this claim i took issue with. ]
In fact this happened a number of times during Linux's lifetime. Eg. the
prospect of SMP unsettled the codebase alot and the (relative) quality of
uniprocessor Linux perhaps even decreased. Once the external environment
has settled down, other aspects of Linux caught up as well.
believe me, there was no 'grand plan'. Initially (5 years ago) Linus said
that SMP does not matter much at the moment, and that nothing should be
done in SMP space that hurts uniprocessors. Today it's exactly the other
way around. And i think it's perfectly possible that there will be a new
paradigm in 5 years.
Ingo
> you could educate me about all those 128 processor Linux boxes in the
> world and fill in a hole in my knowledge. I'm listening...
There are at least two sets of people working on NUMA machines of that
order, as well as the IBM work on smaller NUMA systems.
Alan
> > can come up with a single system image solution over fast ethernet a
> > ccNuma machine just magically works.
>
> it's not cc if you just use fast ethernet.
Thats a matter for handwaving and distributed shared memory algorithms. The
general point is still true - if you assume your NUMA interconnects are
utter crap when performance and latency issues come up - you'll get the
right results.
> What I'm trying to establish here is that if ALSA is to become the
> main-stream Linux sound driver set, it's going to need to support -- *fully*
> support -- the top-of-the-line sound cards like my M-Audio Delta 66. It
Not really. The number of people who actually care about such cards is close
to nil. What matters is that the API can cleanly express what the Delta66
can do, and that you can write a driver for it under ALSA without hacking up
the ALSA core.
I'm happy both of those are true.
On Mon, 3 Dec 2001, Daniel Phillips wrote:
> [...] Please see my post above where I point out 'evolution isn't
> random'. Your genes have a plan, if only a vague one. It goes
> something like this: "we'll allow random variations, but only along
> certain lines, within limits, and in certain combinations, and we'll
> try to stick to variations that haven't killed us in the past."
so what you say in essence is that "evolution isnt random, it's random"
;-) The fact that the brownean motion is 'vaguely directed' (ie. evolution
has a limited amount of 'memory' of past experience coded into the DNA)
does not make it less random. Randomness does not have to be completely
undirected - perhaps you know a different definition for 'random'. Just
the fact that we got from bacteria to humans and from bacteria to trees
shows that it's not only random, it's also unstable and chaotic. (the same
initial conditions resulted in multiple, wildly different and almost
completely unrelated set of end results.)
and nobody claimed Linux development was totally (chryptographically)
random. We just claim that Linux development has a fair dose of randomness
and unpredictability besides having a fair dose of structure, and that its
development model is much closer to evolution than to the formal methods
of software development.
at which point i think we finally agree?
Ingo
Larry McVoy wrote:
>>Please Larry, have a look at the environment: nobody here owns a box
>>with 128 CPUs. Most of the people here take care of things they either
>>- own themselves
>>- have their hands own at work
>>- get paid for
>>
>>You will not find _any_ match with 128 CPUs here.
>>
>
> Nor will you find any match with 4 or 8 CPU systems, except in very rare
> cases. Yet changes go into the system for 8 way and 16 way performance.
> That's a mistake.
>
> I'd be ecstatic if the hackers limited themselves to what was commonly
> available, that is essentially what I'm arguing for.
"There are only black cars, we don't make any other color. Noone has
ordered a car with a different color cause we don't accept those orders.
And since noone orders why add colors? Unnecessary cruft."
In essence, People don't run big boxes due to scalability issues, fixing
those might get someone to install a 16-Way.
They sure as hell aren't gonna buy one and then wait around 3 years for
Linux to support it.
// Stefan
Alan Cox <[email protected]> writes:
> > you could educate me about all those 128 processor Linux boxes in the
> > world and fill in a hole in my knowledge. I'm listening...
> There are at least two sets of people working on NUMA machines of that
> order, as well as the IBM work on smaller NUMA systems.
Are you NUMA people listening? What do you think of Larry's ideas?
--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10
Brinkhoff Consulting http://www.brinkhoff.se/ programming
> In essence, People don't run big boxes due to scalability issues, fixing
> those might get someone to install a 16-Way.
Hackers don't run Linux on 16 way boxes because they cost $100,000 each
Alan
Horst von Brand <[email protected]> writes:
Hi,
>> Nor will you find any match with 4 or 8 CPU systems, except in very rare
>> cases. Yet changes go into the system for 8 way and 16 way performance.
>> That's a mistake.
>And you are proposing a fork for handling exactly this? I don't get it...
[Ah, and I've sworn that I won't participate in this thread again...]
99.99% of your userbase have one or two processors. 99.999% of your
userbase have less than 8 processors.
It simply doesn't make sense to design something for 128+ Processors
if noone uses it. Especially if it puts a penalty on the user base
with one or two processors. Then such a design is actively hurting
your user base. And this is nonsense. That's why the design goes
1->2->4->8. We got SMP once a core developer got a sponsored SMP
board. Not because Linus designed his OS with "I want to scale to lots
of processors I can only dream of". Along that road lies madness (and
maybe GNU Hurd ;-) ).
I actually have five (at a customers site) eight-way machines.
Unfortunately now they all run Windows 2000 (Datacenter Edition
(TM)). But if the "eight-way" support would hurt the "two way"
machines, I'd advocate to put that code at least under a compile
switch.
Actually I do like the idea in Larrys' paper. It doesn't hurt beyond
eight way, because the next eight processors are their own
"system". Just because it doesn't hurt the smaller boxes (much).
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
"Stanislav Meduna" <[email protected]> said:
> Horst von Brand wrote:
[...]
> > Complex software *has* bugs, bugs which aren't apparent
> > except under unsusual circumstances are rarely found in the
> > first round of bug chasing.
> Sure. But we now have 2.4.16, not 2.4.0 and guess what? -
> there is a big thread about fs corruption going right now
> in the l-k :-( This should _not_ happen in the stab{le,ilizing}
> series and if it happened, the cause should be identified
> and measures taken.
Glitches _do_ happen. IIRC, there have been _less_ in 2.4.x than before
(might just be skewed perspective...).
> I for one think that the kernel has overgrown its current
> development model and that some _incremental_ steps
> in the direction of both more formal control and delegation
> of responsibilities are needed. I think that the most active
> kernel developers should discuss the future of the development
> model, as they are the only ones that can really come up
> with a solution.
Right. Or somebody has to fork off a "QA-linux". Or people should help with
QA (kernel-janitors, delelop tests, run tests and report back, ...)
[...]
> > > As a user of the vendor's kernel I have no idea what to do
> > > with a bug.
> >
> > Report it to the vendor, through the documented channels?
>
> Did this. It is two months, I did some cornering of the problem
> and augmented the report several times. The issue is still NEW,
> without any response asking to try a patch, supply more details
> or such. Yes, this speaks more of the vendor than of the Linux.
Change vendor. That is one of the beauties of Linux: If your vendor doesn't
get their act together, you can switch.
> But what impression do you think the average user gets from
> such experience?
Bad, no doubt. But fear not, with the "marvelous engineering" of some
vendors of closed products you wait for _years_ for fixes to severe bugs.
So in perspective Linux only looks bad. They look horrible ;-/
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
Larry McVoy <[email protected]> said:
[...]
> Doesn't it strike you the least bit strange that when I challenge Linus to
> bow out because he asserts that he isn't needed, this is just some grand
> experiment in genetics which is working fine, he says everything would be
> fine if he left but he isn't going to because he's having fun?
Hummm... Linux works because there is a harsh evaluation of patches that
try to make it into the stock kernel. There Linus _is_ needed, if nothing
else as a final authority almost everybody respects.
If he enjoys what he is doing, why shouldn't he go on doing it? If he seems
to be doing it right, irrespective of whatever reason (right or terribly
wrong) he gives for it?
> Isn't that
> just a tad convenient? It's a crock of crap too. Linus has excellent taste,
> better than any OS guy I've run into in 20 years, and if he bowed out a ton
> of crap would make it into the kernel that doesn't now. Genetic mutation
> my ass.
Accept patches and ideas from all over the place, coupled with evaluation
of said patches and suggestions which weeds out the bad ones before
integration, others when they show wanting after integration is a form of
evolution. No overall direction, no grand design a la OS/360, just design
(sort of) in rather limited areas at a time. Not 100% Darwinian evolution,
with some taints of "acquired traits are inherited", and some (limited)
sense of direction, and also cross movement of traits form others (be it
BSD, or different kernel lines).
> If you want an experiment in evolution, then let *everything* into
> the kernel. That's how evolution works, it tries everything, it doesn't
> prescreen. Go read Darwin, go think, there isn't any screening going on,
> evolution *is* the screening.
Why does the screening have to be at the level of full organisms? It
_looks_ that way because you don't see the busted sperm or broken eggs, or
the stillborn embryos which make up the "preliminary checks show it won't
work" in nature. The process is (hopefully) much more efficient here than
in nature, and visible, that is all.
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
Alan Cox wrote:
>>In essence, People don't run big boxes due to scalability issues, fixing
>>those might get someone to install a 16-Way.
>>
>
> Hackers don't run Linux on 16 way boxes because they cost $100,000 each
>
> Alan
>
And here I thought all linux hackers were millionaires :)
// Stefan
On Tue, Dec 04, 2001 at 09:28:49AM +0000, Alan Cox wrote:
> On Mon, Dec 03, 2001 at 06:31:38AM -0800, M. Edward Borasky wrote:
> > What I'm trying to establish here is that if ALSA is to become the
> > main-stream Linux sound driver set, it's going to need to support --
> > *fully* support -- the top-of-the-line sound cards like my M-Audio
> > Delta 66.
>
> Not really. The number of people who actually care about such cards is
> close to nil. What matters is that the API can cleanly express what
> the Delta66 can do, and that you can write a driver for it under ALSA
> without hacking up the ALSA core.
Indeed. And I'm sure the ALSA-team would be delighted and fully willing
to write a working driver, if mr Borasky donated an M-Audio Delta 66
together with full documentation to them...
/David
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
I'm going to weigh in here in favor of limiting effort on SMP development by
the core Linux team to systems with 4 processors and under. And not just
because I'd like to see those developers freed up to work on my M-Audio
Delta 66 :-). The economics of massively parallel MIMD machines just aren't
there. Sure, the military guys would *love* to have a petaflop engine, but
they're gonna build 'em anyway and quite probably not bother to contribute
their kernel source on this mailing list. *Commercial* applications for
supercomputers of this level are few and far between. I'm happy with my
GFlop-level UP Athlon Thunderbird. And if Moore's Law (or the AMD equivalent
:-) still holds, in 12 months I'll have something twice as fast (I've had it
for six months already :-).
--
Take Your Trading to the Next Level!
M. Edward Borasky, Meta-Trading Coach
[email protected]
http://www.meta-trading-coach.com
http://groups.yahoo.com/group/meta-trading-coach
Andrew Morton wrote:
> > 128 kernel threads sitting around waiting for a problem that
> > rarely happens seems a little.. strange. (for want of a better word).
>
> I've kinda lost the plot on ksoftirqd. Never really understood
> why a thread was needed for this, nor why it runs at nice +20.
> But things seem to be working now.
Me no idea either. It wasn't to work around the problem of losing
softirqs on syscall return was it? Because there was a patch for that
in the low-latency set that fixed that without a thread, and without a
delay...
-- Jamie
> I'm going to weigh in here in favor of limiting effort on SMP development by
> the core Linux team to systems with 4 processors and under. And not just
> because I'd like to see those developers freed up to work on my M-Audio
> Delta 66 :-). The economics of massively parallel MIMD machines just aren't
> there. Sure, the military guys would *love* to have a petaflop engine, but
> they're gonna build 'em anyway and quite probably not bother to contribute
> their kernel source on this mailing list. *Commercial* applications for
> supercomputers of this level are few and far between. I'm happy with my
> GFlop-level UP Athlon Thunderbird. And if Moore's Law (or the AMD equivalent
> :-) still holds, in 12 months I'll have something twice as fast (I've had it
> for six months already :-).
Two things.
1) If a company (say, IBM) pays people to work on 8 / 16 way scalability
because that's what they want out of Linux, then stopping development
on that isn't going to get effort redirected to fixing your soundcard (yes,
I realise you were being flippant, but the point's the same), the headcount
is just going to disappear. AKA your choice isn't "patches for 8 way
scalablilty, or patches for subsystem X that you're more interested in",
your choice is "patches for 8-way scalabity, or no patches". Provided that
those patches don't break anything else, you still win overall by getting them.
2) Working on scalability for 8 / 16 way machines will show up races,
performance problems et al that exist on 2 / 4 way machines but don't
show up as often, or as obviously. I have a 16 way box that shows up
races in the Linux kernel that might take you years to find on a 2 way.
What I'm trying to say is that you still win. Not as much as maybe you'd
like, but, hey, it's work you're getting for free, so don't complain too
much about it. The maintainers are very good at beating the message
into us that we can't make small systems any worse performing whilst
making the big systems better.
Martin.
On Sun, 2 Dec 2001, Larry McVoy wrote:
> If you want an experiment in evolution, then let *everything* into
> the kernel. That's how evolution works, it tries everything, it doesn't
> prescreen. Go read Darwin, go think, there isn't any screening going on,
> evolution *is* the screening.
So-called 'natural selection' is only a subset of things that can quite
legitimately be called evolution. And there certainly is screening in
nature, it's called sexual selection.
Linus's point is mainly about parallelism. Many more changes get tried in
the Linux space than could ever happen in a traditional software
development environment.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
On Tue, 4 Dec 2001, Alan Cox wrote:
> > What I'm trying to establish here is that if ALSA is to become the
> > main-stream Linux sound driver set, it's going to need to support -- *fully*
> > support -- the top-of-the-line sound cards like my M-Audio Delta 66. It
> Not really. The number of people who actually care about such cards is close
> to nil. What matters is that the API can cleanly express what the Delta66
> can do, and that you can write a driver for it under ALSA without hacking up
> the ALSA core.
> I'm happy both of those are true.
ALSA has supported ice1712 chipset for some time now.
BTW Delta 66 isnt top of the line -- Delta 1010 is. And ALSA supports it
too.
-Dan
--
[-] Omae no subete no kichi wa ore no mono da. [-]
On Tue, 4 Dec 2001, David Weinehall wrote:
> Indeed. And I'm sure the ALSA-team would be delighted and fully willing
> to write a working driver, if mr Borasky donated an M-Audio Delta 66
> together with full documentation to them...
ALSA already has a working driver...!
-Dan
--
[-] Omae no subete no kichi wa ore no mono da. [-]
On Tue, Dec 04, 2001 at 11:35:11AM -0800, Dan Hollis wrote:
> On Tue, 4 Dec 2001, David Weinehall wrote:
> > Indeed. And I'm sure the ALSA-team would be delighted and fully willing
> > to write a working driver, if mr Borasky donated an M-Audio Delta 66
> > together with full documentation to them...
>
> ALSA already has a working driver...!
The point I was trying to make was just "stop complaining about lack
of drivers, contribute one or help someone else create one. I wasn't
criticizing ALSA, rather the opposite. Now, if I could just find
someone willing to program a driver for that old 8-bit, totally sucky,
IBM ACPA/A I have (the only MCA sound adapter I have managed to get
hold of...)
/David
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
On Mon, 3 Dec 2001, Keith Owens wrote:
> On Sun, 02 Dec 2001 15:21:57 -0800 (PST),
> "David S. Miller" <[email protected]> wrote:
> > From: Keith Owens <[email protected]>
> > Date: Sat, 01 Dec 2001 12:17:03 +1100
> >
> > What is ugly in aic7xxx is :-
> >
> >You missed:
> >
> >* #undef's "current"
>
> Where? fgrep -ir current 2.4.17-pre2/drivers/scsi/aic7xxx did not find it.
What is ugly is "David S. Miller" ?
The 'Z' in the first name and the 'K' in the family name. :-)
G?rard.
On Tue, 4 Dec 2001, G?rard Roudier wrote:
>
> On Mon, 3 Dec 2001, Keith Owens wrote:
>
> > On Sun, 02 Dec 2001 15:21:57 -0800 (PST),
> > "David S. Miller" <[email protected]> wrote:
> > > From: Keith Owens <[email protected]>
> > > Date: Sat, 01 Dec 2001 12:17:03 +1100
> > >
> > > What is ugly in aic7xxx is :-
> > >
> > >You missed:
> > >
> > >* #undef's "current"
> >
> > Where? fgrep -ir current 2.4.17-pre2/drivers/scsi/aic7xxx did not find it.
>
> What is ugly is "David S. Miller" ?
^^
Amusing mistake, I wanted to write 'in' instead of 'is'. :-)
>
> The 'Z' in the first name and the 'K' in the family name. :-)
>
> G?rard.
>
>
folx,
although i agree with the sentiment expressed below, i beg to differ...
On Tue, 4 Dec 2001, M. Edward Borasky wrote:
> Sure, the military guys would *love* to have a petaflop engine, but
> they're gonna build 'em anyway and quite probably not bother to contribute
> their kernel source on this mailing list. *Commercial* applications for
> supercomputers of this level are few and far between.
the CPlant (http://www.cs.sandia.gov/cplant/) system software (currently
built on top of Linux 2.2 but it's working now on 2.4 as well) is Open
Source (GPL). CPlant is built by Sandia National Labs (which could be
interpreted as "the military guys" is is currently one of the largest
Linux-based supercomputers in the world. The source for it is publicly
available and gives some interesting insight to what happens when you try
to scale beyond the "traditional" 32 or 64 processor cluster.
Additionally, the same systems software is being used in at least one big
commercial application (for processing genetic information).
my point here is not that building huge SMP machine makes sense
(obviously, for reasons that have been repeatedly reexplained by others
including Larry McVoy, it doesn't). my point is just that many parts of
the national security aparatus are playing well in the Linux kernel
development space these days and it's foolish to write them off.
todd underwood, vp & cto
oso grande technologies, inc.
[email protected]
"Those who give up essential liberties for temporary safety deserve
neither liberty nor safety." - Benjamin Franklin
On Mon, 3 Dec 2001, Keith Owens wrote:
> On Sun, 02 Dec 2001 15:21:57 -0800 (PST),
> "David S. Miller" <[email protected]> wrote:
> > From: Keith Owens <[email protected]>
> > Date: Sat, 01 Dec 2001 12:17:03 +1100
> >
> > What is ugly in aic7xxx is :-
> >
> >You missed:
> >
> >* #undef's "current"
>
> Where? fgrep -ir current 2.4.17-pre2/drivers/scsi/aic7xxx did not find it.
OMFG, it's been fixed... this is amazing. I am honestly shocked.
>> > you could educate me about all those 128 processor Linux boxes in the
>> > world and fill in a hole in my knowledge. I'm listening...
>> There are at least two sets of people working on NUMA machines of that
>> order, as well as the IBM work on smaller NUMA systems.
>
> Are you NUMA people listening? What do you think of Larry's ideas?
I presume we're talking about what he calls ccClusters or SMP clusters.
I did a little background reading and found a couple of his old posts.
I'm not an expert on this, though I've done some work in the NUMA area.
So I'll stick my neck out for people to chop off - I'm not sure I'd agree with
some of his premises:
> Premise 1: SMP scaling is a bad idea beyond a very small number processors.
> The reasoning for this is that when you start out threading a kernel,
> it's just a few locks. That quickly evolves into more locks, and
> for a short time, there is a 1:1 mapping between each sort of object
> in the system (file, file system, device, process, etc) and a lock.
> So there can be a lot of locks, but there is only one reader/writer
> lock per object instance. This is a pretty nice place to be - it's
> understandable, explainable, and maintainable.
>
> 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.
OK, apart from the fact that there's some leaps of faith here (mostly
due to a lack of detail, I need to go and read some more of his papers),
the obvious objection to this is that just because he's seen it done badly
before, even that it's easy to do badly, it doesn't mean it's impossible to
do it well (it being scalability to many processors).
We will try to make it scale without breaking the low end systems. If we
can, all well and good. If we can't then our patches will get rejected
and we'll all be publicly flogged. Fair enough. And, yes, it's hard. And,
yes, it'll take a while.
But whilst we gradually make scalability better, NUMA boxes will still
work in the meantime - just not quite as fast. I currently have a NUMA
box that thinks it an SMP box ... it still works, just not particularly efficiently.
It will get better.
> Premise 3: it is far easier to take a bunch of operating system images
> and make them share the parts they need to share (i.e., the page
> cache), than to take a single image and pry it apart so that it
> runs well on N processors.
Of course it's easier. But it seems like you're left with much more work to
reiterate in each application you write to run on this thing. Do you want to
do the work once in the kernel, or repeatedly in each application? I'd say
it's a damned sight easier to make an application work well on one big
machine than on a cluster.
I like Linus' opinion on the subject, which I'd boil down to "implement
both, see what works". We must have the most massivly parallel
software engineering team for any OS ever - let's use it ;-)
Martin.
On Tue, 4 Dec 2001, Martin J. Bligh wrote:
> > Premise 3: it is far easier to take a bunch of operating system images
> > and make them share the parts they need to share (i.e., the page
> > cache), than to take a single image and pry it apart so that it
> > runs well on N processors.
>
> Of course it's easier. But it seems like you're left with much more
> work to reiterate in each application you write to run on this thing.
> Do you want to do the work once in the kernel, or repeatedly in each
> application?
There seems to be a little misunderstanding here; from what
I gathered when talking to Larry, the idea behind ccClusters
is that they provide a single system image in a NUMA box, but
with separated operating system kernels.
Of course, this is close to what a "single" NUMA kernel often
ends up doing with much ugliness, so I think Larry's idea to
construct NUMA OSes by putting individual kernels of nodes to
work together makes a lot of sense.
regards,
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
>> > Premise 3: it is far easier to take a bunch of operating system images
>> > and make them share the parts they need to share (i.e., the page
>> > cache), than to take a single image and pry it apart so that it
>> > runs well on N processors.
>>
>> Of course it's easier. But it seems like you're left with much more
>> work to reiterate in each application you write to run on this thing.
>> Do you want to do the work once in the kernel, or repeatedly in each
>> application?
>
> There seems to be a little misunderstanding here; from what
> I gathered when talking to Larry, the idea behind ccClusters
> is that they provide a single system image in a NUMA box, but
> with separated operating system kernels.
OK, then I've partially misunderstood this ... can people provide some
more reference material? Please email to me, and I'll collate the results
back to the list (should save some traffic).
I have already the following:
http://www.bitmover.com/talks/cliq/slide01.html
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0001.2/1172.html
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0001.3/0236.html
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0007.3/1222.html
Thanks,
Martin.
On Tue, Dec 04, 2001 at 03:37:37PM -0800, Martin J. Bligh wrote:
> >> > Premise 3: it is far easier to take a bunch of operating system images
> >> > and make them share the parts they need to share (i.e., the page
> >> > cache), than to take a single image and pry it apart so that it
> >> > runs well on N processors.
> >>
> >> Of course it's easier. But it seems like you're left with much more
> >> work to reiterate in each application you write to run on this thing.
> >> Do you want to do the work once in the kernel, or repeatedly in each
> >> application?
> >
> > There seems to be a little misunderstanding here; from what
> > I gathered when talking to Larry, the idea behind ccClusters
> > is that they provide a single system image in a NUMA box, but
> > with separated operating system kernels.
Right except NUMA is orthogonal, ccClusters work fine on a regular SMP
box.
> OK, then I've partially misunderstood this ... can people provide some
> more reference material? Please email to me, and I'll collate the results
> back to the list (should save some traffic).
I'll try and type in a small explanation, I apologize in advance for the
bervity, I'm under a lot of pressure on the BK front these days...
The most recent set of slides are here:
http://www.bitmover.com/ml/slide01.html
A couple of useful papers are at
http://www.bitmover.com/llnl/smp.pdf
http://www.bitmover.com/llnl/labs.pdf
The first explains why I think fine grained multi threading is a mistake
and the second is a paper I wrote to try and get LLNL to push for what
I called SMP clusters (which are not a cluster of SMPs, they are a
cluster of operating system instances on a single SMP).
The basic idea is this: if you consider the usefulness of an SMP versus a
cluster, the main thing in favor of the SMP is
all processes/processors can share the same memory at memory speeds.
I typically describe this as "all processes can mmap the same data".
A cluster loses here, even if it provides DSM over a high speed
link, it isn't going to have 200 ns caches misses, it's orders of
magnitude slower. For a lot of MPI apps that doesn't matter, but
there are apps for which high performance shared memory is required.
There are other issues like having a big fast bus, load balancing, etc.,
but the main thing is that you can share data quickly and coherently.
If you don't need that performance/coherency and you can afford to
replicate the data, a traditional cluster is a *much* cheaper and
easier answer. Many problems, such as web server farms, are better
done on Beowulf style clusters than an SMP, they will actually scale
better.
OK, so suppose we focus on the SMP problem space. It's a requirement
that all the processes on all the processors need to be able to access
memory coherently. DSM and/or MPI isn't an answer for this problem
space.
The traditional way to use an SMP is to take a single OS image and
"thread" it such that all the CPUs can be in the OS at the same time.
Pretty much all the data structures need to get a lock and each CPU
takes the lock before it uses the data structure. The limit of the
ratio of locks to cache lines is 1:1, i.e., each cache line will need
a lock in order to get 100% of the scaling on the system (yes, I know
this isn't quite true but it is close and you get the idea).
Go read the "smp.pdf" paper for my reasons on why this is a bad approach,
I'll assume for now you are willing to agree that it is for the purposes
of discussion.
If we want to get the most use out of big SMP boxes but we also want to
do the least amount of "damage" in the form of threading complexity in
the source base. This is a "have your cake and eat it too" goal, one
that I think is eminently reachable.
So how I propose we do this is by booting multiple Linux images on
a single box. Each OS image owns part of the machine, 1-4 CPUs, 0 or
more devices such as disk, ethernet, etc., part of memory. In addition,
all OS images share, as a page cache, part of main memory, typically
the bulk of main memory.
The first thing to understand that the *only* way to share data is in
memory, in the globally shared page cache. You do not share devices,
devices are proxied. So if I want data from your disk or file system,
I ask you to put it in memory and then I mmap it. In fact, you really
only share files and you only share them via mmap (yeah, read and write
as well but that's the uninteresting case).
This sharing gets complex because now we have more than one OS image
which is managing the same set of pages. One could argue that the
code complexity is just as bad as a fine grained multi threaded OS
image but that's simply incorrect. I would hide almost 100% of this
code in a file system, with some generic changes (as few as possible)
in the VM system. There are some changes in the process layer as well,
but we'll talk about them later.
If you're sitting here thinking about all the complexity involved in
sharing pages, it is really helpful to think about this in the following
way (note you would not actually implement it like this in the long
run but you could start this way):
Imagine that for any given file system there is one server OS image and N
client os images. Imagine that for each client, there is a proxy process
running on behalf of the client on the server. Sort of like NFS biods.
Each time the client OS wants to do an mmap() it asks the proxy to do
the mmap(). There are some corner cases but if you think about it, by
having the proxies do the mmaps, we *know* that all the server OS data
structures are correct. As far as the server is concerned, the remote
OS clients are no different than the local proxy process. This is from
the correctness point of view, not the performance point of view.
OK, so we've handled setting up the page tables, but we haven't handled
page faults or pageouts. Let's punt on pageouts for the time being,
we can come back to that. Let's figure out a pagefault path that will
give correct, albeit slow, behaviour. Suppose that when the client faults
on a page, the client side file system sends a pagefault message to the
proxy, the proxy faults in the page, calls a new vtop() system call to
get the physical page, and passes that page descriptor back to the client
side. The client side loads up the TLB & page tables and away we go.
Whoops, no we don't, because the remote OS could page out the page and
the client OS will get the wrong data (think about a TLB shootdown that
_didn't_ happen when it should have; bad bad bad). Again, thinking
just from the correctness point of view, suppose the proxy mlock()ed
the page into memory. Now we know it is OK to load it up and use it.
This is why I said skip pageout for now, we're not going to do them
to start with anyway.
OK, so start throwing stones at this. Once we have a memory model that
works, I'll go through the process model.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Larry McVoy <[email protected]> wrote:
> > > There seems to be a little misunderstanding here; from what
> > > I gathered when talking to Larry, the idea behind ccClusters
> > > is that they provide a single system image in a NUMA box, but
> > > with separated operating system kernels.
>
> Right except NUMA is orthogonal, ccClusters work fine on a regular SMP
> box.
...[details omitted for the moment]...
The basic idea seems a sound one, though maybe consider going from
a simple/robust cluster solution back to NUMA boxen. A transparent
virtual computer image is kind of the goal long-term, right?
That is the plan I have for a different OS/kernel I'm working on,
and it seems valid so far.
Uni-proc design plus simple SMP only in the core kernel code fixes
SO many little SMP brain-deadnesses.
For example, there should be no reason that most drivers or any other
random kernel module should know anything about SMP. Under Linux, it
annoys me to no end that I have to ever know (and yes, I count compiling
against "SMP" configuration having to know)... more and more sources of
error.
Then, as long as you make the simple cluster solution handle "hot-swap/
bring-up/tear-down" of nodes from the beginning, you can easily do
things like bring new processor modules, machines, etc. online or out
of your system.
This even argues that you should try working from something like a
Mosix cluster as a starting point, to test it out.
--
Erich Stefan Boleyn <[email protected]> http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"
From: Larry McVoy <[email protected]>
Date: Tue, 4 Dec 2001 16:36:46 -0800
OK, so start throwing stones at this. Once we have a memory model that
works, I'll go through the process model.
What is the difference between your messages and spin locks?
Both seem to shuffle between cpus anytime anything interesting
happens.
In the spinlock case, I can thread out the locks in the page cache
hash table so that the shuffling is reduced. In the message case, I
always have to talk to someone.
On Tue, 4 Dec 2001, David S. Miller wrote:
> From: Larry McVoy <[email protected]>
> Date: Tue, 4 Dec 2001 16:36:46 -0800
>
> OK, so start throwing stones at this. Once we have a memory model that
> works, I'll go through the process model.
>
> What is the difference between your messages and spin locks?
> Both seem to shuffle between cpus anytime anything interesting
> happens.
>
> In the spinlock case, I can thread out the locks in the page cache
> hash table so that the shuffling is reduced. In the message case, I
> always have to talk to someone.
Time ago I read an interesting article that implemented shared memory over
network ( ATM in that case ) reproducing in large scale the
cache/memory/bus computer architecture.
Shared memory on each node was the equivalent of the CPU cache, a "generic
shared memory repository" was the equivalent of the main memory and the
snooping traffic was running on the network.
I think I picked it up from ACM but I can't find it right now.
- Davide
At 06:36 PM 12/4/01 -0800, David S. Miller wrote:
>What is the difference between your messages and spin locks?
>Both seem to shuffle between cpus anytime anything interesting
>happens.
>
>In the spinlock case, I can thread out the locks in the page cache
>hash table so that the shuffling is reduced. In the message case, I
>always have to talk to someone.
While what I'm about to say has little bearing on the SMP/cc case: one
significant advantage of messages over spinlocks is being able to assign
priority with low overhead in the quick-response real-time multi-CPU
arena. I worked with a cluster of up to 14 CPUs using something very much
like NUMA in which task scheduling used a set of prioritized message
queues. The system I worked on was designed to break transaction-oriented
tasks into a string of "work units" each of which could be processed very
quickly -- on the order of three milliseconds or less. (The limit of 14
CPUs was set by the hardware used to implement the main system bus.)
I bring this up only because I have never seen a spinlock system that dealt
with priority issues very well when under heavy load.
OK, I've said my piece, now I'll sit back and continue to watch your
discussion.
Satch
On Tue, Dec 04, 2001 at 06:36:01PM -0800, David S. Miller wrote:
> From: Larry McVoy <[email protected]>
> Date: Tue, 4 Dec 2001 16:36:46 -0800
>
> OK, so start throwing stones at this. Once we have a memory model that
> works, I'll go through the process model.
>
> What is the difference between your messages and spin locks?
> Both seem to shuffle between cpus anytime anything interesting
> happens.
>
> In the spinlock case, I can thread out the locks in the page cache
> hash table so that the shuffling is reduced. In the message case, I
> always have to talk to someone.
Two points:
a) if you haven't already, go read the Solaris doors paper. Now think about
a cross OS instead of a cross address space doors call. They are very
similar. Think about a TLB shootdown, it's sort of a doors style cross
call already, not exactly the same, but do you see what I mean?
b) I am not claiming that you will have less threading in the page cache.
I suspect it will be virtually identical except that in my case 90%+
of the threading is in the ccCluster file system, not the generic code.
I do not want to get into a "my threading is better than your threading"
discussion. I'll even go so far as to say that this approach will have
more threading if that makes you happy, as long as we agree it is outside
of the generic part of the kernel. So unless I have CONFIG_CC_CLUSTER,
you pay nothing or very, very little.
Where this approach wins big is everywhere except the page cache. Every
single data structure in the system becomes N-way more parallel -- with
no additional locks -- when you boot up N instances of the OS. That's
a powerful statement. Sure, I freely admit that you'll add a few locks
to deal with cross OS synchronization but all of those are configed out
unless you are running a ccCluster. There is absolutely zero chance that
you can get the same level of scaling with the same number of locks using
the traditional approach. I'll go out on a limb and predict it is at
least 100x as many locks. Think about it, there are a lot of things that
are threaded simply because of some corner case that happens to show up
in some benchmark or workload. In the ccCluster case, those by and large
go away. Less locks, less deadlocks, less memory barriers, more reliable,
less filling, tastes great and Mikey likes it :-)
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, Dec 01, 2001 at 01:29:14PM -0800, Paul G. Allen wrote:
> David Weinehall wrote:
> >
> > On Fri, Nov 30, 2001 at 12:06:43PM -0800, Paul G. Allen wrote:
> >
> > [snip]
> > > 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.
> >
> > Uhhhm, knowing when a code block begins? Usually you'll notice this from
> > the indentation. It's quite hard not to notice a tabsized shift
> > to the right...
> >
>
> Whitespace can be placed almost anywhere and the program will still
> compile. It can even be removed altogether. The only thing that keeps a
> program legible is proper formatting. It's real damn easy to miss a
> brace when the formatting is poor. And real easy to spend an hour trying
> to figure out where that missing brace goes, that is after the hour you
> spent figuring out that it was missing in the first place.
>
Then when you get your hands on code like this you have two bugs to fix:
1) The origional problem you wanted to code up
2) Fix the formatting.
I suggest (yes, more work) that you run the code through the code normalizer
for that project and then look at the code produced from that.
That way, you will be able to see the code blocks in a standard way. As you
look at the formatted code, you can program in the old indentation format.
When you're done, you have two patches. One with the origional fix, and
another with the formatting improvements.
You'll probably want to get a concensus of what the other developers in the
project have agreed upon before you submit the formatting patch. Much the
way this thread may turn out...
mf
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Todd Underwood
> Sent: Tuesday, December 04, 2001 12:49 PM
> To: M. Edward Borasky
> Cc: [email protected]
> Subject: Re: Over 4-way systems considered harmful :-)
>
> folx,
>
> although i agree with the sentiment expressed below, i beg to differ...
>
> the CPlant (http://www.cs.sandia.gov/cplant/) system software (currently
> built on top of Linux 2.2 but it's working now on 2.4 as well) is Open
> Source (GPL). CPlant is built by Sandia National Labs (which could be
> interpreted as "the military guys" is is currently one of the largest
> Linux-based supercomputers in the world. The source for it is publicly
> available and gives some interesting insight to what happens when you try
> to scale beyond the "traditional" 32 or 64 processor cluster.
>
> Additionally, the same systems software is being used in at least one big
> commercial application (for processing genetic information).
>
> my point here is not that building huge SMP machine makes sense
> (obviously, for reasons that have been repeatedly reexplained by others
> including Larry McVoy, it doesn't). my point is just that many parts of
> the national security aparatus are playing well in the Linux kernel
> development space these days and it's foolish to write them off.
>
> todd underwood, vp & cto
> oso grande technologies, inc.
> [email protected]
>
> "Those who give up essential liberties for temporary safety deserve
> neither liberty nor safety." - Benjamin Franklin
Yes ... but ... it is interesting how quickly the priorities and policies of
the National Laboratories can be "re-focused" with the change of the person
residing at 1600 Pennsylvania Avenue and "other factors" :-). Been there ...
done that ... got the scars :-). In short: "Moore's Law: good. Amdahl's Law:
bad" :-)
--
Take Your Trading to the Next Level!
M. Edward Borasky, Meta-Trading Coach
[email protected]
http://www.meta-trading-coach.com
http://groups.yahoo.com/group/meta-trading-coach
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Martin J. Bligh
> Sent: Tuesday, December 04, 2001 9:41 AM
> To: M. Edward Borasky; [email protected]
> Subject: Re: Over 4-way systems considered harmful :-)
>
> Two things.
>
> 1) If a company (say, IBM) pays people to work on 8 / 16 way scalability
> because that's what they want out of Linux, then stopping development
> on that isn't going to get effort redirected to fixing your
> soundcard (yes,
> I realise you were being flippant, but the point's the same), the
> headcount
> is just going to disappear. AKA your choice isn't "patches for 8 way
> scalablilty, or patches for subsystem X that you're more interested in",
> your choice is "patches for 8-way scalabity, or no patches". Provided that
> those patches don't break anything else, you still win overall by
> getting them.
I don't see how this is a win for me. And it is a win for IBM only if it
gives them some advantage in serving their customers. I can certainly
*conceive* of workloads bursty enough to justify an 8-processor server, but
do they exist in the real world? And if they do, is a single 8-processor
server better than a pair of 4-processor servers when you take graceful
handling of faults into account? IBM has been building high-availability
systems for *decades*, preferring to field *slightly* slower but
*significantly* more reliable gear, which, legend has it, no one has ever
been fired for purchasing. :-)
> 2) Working on scalability for 8 / 16 way machines will show up races,
> performance problems et al that exist on 2 / 4 way machines but don't
> show up as often, or as obviously. I have a 16 way box that shows up
> races in the Linux kernel that might take you years to find on a 2 way.
Perhaps effort should be placed into software development processes and
tools that deny race conditions the right to be born, rather than depending
on testing on a 16-processor system to find them expeditiously :-). And
there is a whole discipline of software performance engineering to build
performance in from the start. Advances like that would be a *huge* win for
the Linux community, given our (relative) freedom from corporate-world
limitations like deadlines, sales quotas, programmer salaries, and
full-color brochures.
> What I'm trying to say is that you still win. Not as much as maybe you'd
> like, but, hey, it's work you're getting for free, so don't complain too
> much about it. The maintainers are very good at beating the message
> into us that we can't make small systems any worse performing whilst
> making the big systems better.
No, but we can release partly-baked VM schemes that have a shelf life on the
order of days :-). Seriously, though, I don't like stepping on someone
else's dream, especially since *my* dream -- a GFLOP dedicated to computer
music -- has been fulfilled for about $1500 US. When I bought that machine,
I thought I was going to need two processors -- one to run the OS and
service the keyboard, mouse and monitor and a second dedicated to generating
audio samples in real time. I had no idea how powerful these chips were
until I started shopping around. And when I loaded the Atlas linear algebra
library up on my Athlon and saw the speeds it was getting, I was in shock
for almost a week!
However, as I said in another post: "Moore's Law: good. Amdahl's Law: bad."
I guess the new generation has to discover Amdahl's Law for itself, and
*this* distinguished but elderly scientist is eager to be proven wrong :-).
--
Take Your Trading to the Next Level!
M. Edward Borasky, Meta-Trading Coach
[email protected]
http://www.meta-trading-coach.com
http://groups.yahoo.com/group/meta-trading-coach
From: Larry McVoy <[email protected]>
Date: Tue, 4 Dec 2001 19:23:17 -0800
There is absolutely zero chance that you can get the same level
of scaling with the same number of locks using the traditional
approach. I'll go out on a limb and predict it is at least 100x as many locks.
Coming from the background of having threaded from scratch a complete
networking stack (ie. my shit doesn't stink and I'm here to tell you
about it :-))) I think your claims are pretty much out of whack.
Starting from initial implementation to having all the locking
disappear from the kernel profiles during any given load was composed
of three tasks:
1) Is this object almost entirely reader based (or the corrolary)?
Use special locking that exploits this. See linux/brlock.h
for one such "special locking" we invented to handle these
cases optimally.
This transformation results in ZERO shared dirty cache
lines if the initial analysis is correct.
2) Can we "fan out" the locking so that people touching
seperate objects %99 of the time touch different cache
lines?
This doesn't mean "more per-object locking", it means more
like "more per-zone locking". Per-hashchain locking falls
into this category and is very effective for any load I
have ever seen.
3) Is this really a per-cpu "thing"? The per-cpu SKB header
caches are an example of this. The per-cpu SLAB magazines
are yet another.
Another source of scalability problems has nothing to do with whether
you do some kind of clustering or not. You are still going to get
into situations where multiple cpus want (for example) page 3 of
libc.so :-) (what I'm trying to say is that it is a hardware issue
in some classes of situations)
Frankly, after applying #1 and/or #2 and/or #3 above to what shows up
to have contention (I claim the ipv4 stack to have had this done for
it) there isn't much you are going to get back. I see zero reasons to
add any more locks to ipv4, and I don't think we've overdone it in the
networking either.
Even more boldly, I claim that Linux's current ipv4 scales further
than anything coming out of Sun engineering. From my perspective
Sun's scalability efforts are more in line with "rubber-stamp"
per-object locking when things show up in the profiles than anything
else. Their networking is really big and fat. For example the
Solaris per-socket TCP information is nearly 4 times the size of that
in Linux (last time I checked their headers). And as we all know
their stuff sits on top of some thick infrastructure (ie. STREAMS)
(OK, here is where someone pops up a realistic networking benchmark
where we scale worse than Solaris. I would welcome such a retort
because it'd probably end up being a really simple thing to fix.)
My main point: I think we currently scale as far as we could in the
places we've done the work (which would include networking) and it
isn't "too much locking".
The problem areas of scalability, for which no real solution is
evident yet, involve the file name lookup tree data structures,
ie. the dcache under Linux. All accesses here are tree based, and
everyone starts from similar roots. So you can't per-node or
per-branch lock as everyone traverses the same paths. Furthermore you
can't use "special locks" as in #1 since this data structure is
neither heavy reader nor heavy writer.
But the real point here is that SMP/cc clusters are not going to solve
this name lookup scaling problem.
The dcache_lock shows up heavily on real workloads under current
Linux. And it will show up just as badly on a SMP/cc cluster. SMP/cc
clusters talk a lot about "put it into a special filesystem and scale
that all you want" but I'm trying to show that frankly thats where the
"no solution evident" scaling problems actually are today.
If LLNL was not too jazzed up about your proposal, I right now don't
blame them. Because with the information I have right now, I think
your claims about it's potential are bogus.
I really want to be shown wrong, simply because the name path locking
issue is one that has been giving me mental gas for quite some time.
Another thing I've found is that SMP scalability changes that help
the "8, 16, 32, 64" cpu case almost never harm the "4, 2" cpu
cases. Rather, they tend to improve the smaller cpu number cases.
Finally, as I think Ingo pointed out recently, some of the results of
our SMP work has even improved the uniprocessor cases.
Franks a lot,
David S. Miller
[email protected]
----- Original Message -----
From: "David S. Miller" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>; <[email protected]>;
<[email protected]>
Sent: Tuesday, December 04, 2001 11:05 PM
Subject: Re: SMP/cc Cluster description
> From: Larry McVoy <[email protected]>
> Date: Tue, 4 Dec 2001 19:23:17 -0800
>
> Even more boldly, I claim that Linux's current ipv4 scales further
> than anything coming out of Sun engineering. From my perspective
> Sun's scalability efforts are more in line with "rubber-stamp"
> per-object locking when things show up in the profiles than anything
> else. Their networking is really big and fat. For example the
> Solaris per-socket TCP information is nearly 4 times the size of that
> in Linux (last time I checked their headers). And as we all know
> their stuff sits on top of some thick infrastructure (ie. STREAMS)
> (OK, here is where someone pops up a realistic networking benchmark
> where we scale worse than Solaris. I would welcome such a retort
> because it'd probably end up being a really simple thing to fix.)
David,
The job you did on ipv4 is quite excellent. I multi-threaded the ODI layer
in NetWare,
and I have reviewed your work and it's as good as anything out there. The
fewer locks,
the better. Also, I agree that Sun's "hot air" regarding their SMP is just
that. Sure, they
have a greart priority inheritenace model, but big f_cking deal. sleep
locks and their behaviors
have little to do with I./O scaling on interrupt paths, other than to
increase the background
transaction activity on the memory bus.
Your ipv4 work is not perfect, but it's certainly good enough. We found
with NetWare that SMP
scaling was tough to achieve since the processor was never the bottleneck --
the I/O bus was.
Uniprocessor NetWare 3.12 still runs circles around Linux or anything else,
and it's not
multithreaded, just well optimaized (and hand coded in assembler).
There are a few optimizations you could still to do to make it even faster,
but these are off line
discussions. :-)
Jeff
.
>
> Franks a lot,
> David S. Miller
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Sun, Dec 02, 2001 at 12:05:00AM +0200, Kai Henningsen wrote:
> [email protected] (Mike Fedyk) wrote on 30.11.01 in <[email protected]>:
>
> > On Sat, Dec 01, 2001 at 02:21:57AM +0100, Stephan von Krawczynski wrote:
>
> > > 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.
>
> It works for SGI/Irix/XFS, why would it not work for SUN/Solaris/whatever?
>
I meant actually transplanting Solaris's SMP into Linux. You don't see SGI
doing anything like this...
> For example, there should be no reason that most drivers or any other
> random kernel module should know anything about SMP. Under Linux, it
> annoys me to no end that I have to ever know (and yes, I count compiling
> against "SMP" configuration having to know)... more and more sources of
> error.
Unfortunately the progression with processors seems to be going the
wrong way. Spin locks are getting more not less expensive. That makes
CONFIG_SMP=n a meaningful optimisation for the 99%+ of people not running
SMP
Alan
>>>>> "Larry" == Larry McVoy <[email protected]> writes:
Larry> Where this approach wins big is everywhere except the page cache. Every
Larry> single data structure in the system becomes N-way more parallel -- with
Larry> no additional locks -- when you boot up N instances of the OS. That's
I was wondering about multiple OS instances in their own address
space. What's the need for separate address spaces for the kernels ?
It looks more natural to me to _actually_ have N instances of kernel
data structures in the _same address space_, i.e. turning
each global variable into an array_ indexed by an "instance id",
much in the same way as we have now per-CPU structures. Well,
I don't actually think it would be as simple as stated above, I'm just
proposing it as a general approach towards ccclustering.
(btw, there was some discussion on #kernelnewbies, on Nov 12th and
21st, you can find the logs here
http://vengeance.et.tudelft.nl/~smoke/log/kernelnewbies/2001-11/)
Regards,
-velco
Hi
My box is: Cyrix 486, 12Meg RAM, CS4239 ISA sound
card,
no pci controler
I tested your patch both with kernel 2.4.14 +
preemptible patches + ide patches , and with
kernel 2.4.16 clean.
The patch applied cleanly on both kernels.
The play command is working like it was working
without this patch.
But when I was running mtv (http://www.mpegtv.com)
the only thing I can hear is noise.
Whithout your patch mtv is playing the sound with
interrupts.
I didn't done extended testing because i don't have
sound files on my computer (just movies) but if you
want something specific tested please let me know
and i'll try to help
Bye
=====
,-----.
," ^ ^ ",
| @ @ |
----OOOO---------------OOOO----
___________________________________________________________
Nokia 5510 Dr?le de look... et quel son !
Cliquez sur http://fr.promotions.yahoo.com/nokia/
D?couvrez-le et tentez votre chance pour en gagner un !
Fin du concours le 16 d?cembre.
> I don't see how this is a win for me. And it is a win for IBM only if it
> gives them some advantage in serving their customers. I can certainly
> *conceive* of workloads bursty enough to justify an 8-processor server, but
> do they exist in the real world? And if they do, is a single 8-processor
> server better than a pair of 4-processor servers when you take graceful
> handling of faults into account? IBM has been building high-availability
> systems for *decades*, preferring to field *slightly* slower but
> *significantly* more reliable gear, which, legend has it, no one has ever
> been fired for purchasing. :-)
We (Sequent, now bought by IBM) sold 64 processor servers to people
who needed them (the main market was large databases) so, yes, there
is definitely a market for larger systems. It's cheaper to build a big processor
farm out of a Beowulf style cluster, but it's not always easy / possible to
split up your application over something like that. If you're generating
fractals, it's easy, for other applications, it's not.
> Perhaps effort should be placed into software development processes and
> tools that deny race conditions the right to be born, rather than depending
> on testing on a 16-processor system to find them expeditiously :-). And
I wish you good fortune, sir. When you've acheived that, come back and
tell me, and we'll stop testing stuff ;-) It's always better to not code bugs in
the first place, but that's not the world we live in ...
> there is a whole discipline of software performance engineering to build
> performance in from the start. Advances like that would be a *huge* win for
> the Linux community, given our (relative) freedom from corporate-world
> limitations like deadlines, sales quotas, programmer salaries, and
> full-color brochures.
I'm all for encouraging good programming practices. In a way that's actually
harder in the diverse Linux community with hundreds, nay, thousands of
engineers putting code in. But we should still try - keeping the infrastructure
simple helps, for example. Trying to bug fix badly designed / written code is
pissing into the wind.
M.
----- Original Message -----
From: "Alan Cox" <[email protected]>
To: <[email protected]>
Cc: "Larry McVoy" <[email protected]>; <[email protected]>
Sent: Wednesday, December 05, 2001 2:09 AM
Subject: Re: SMP/cc Cluster description [was Linux/Pro]
> > For example, there should be no reason that most drivers or any other
> > random kernel module should know anything about SMP. Under Linux, it
> > annoys me to no end that I have to ever know (and yes, I count compiling
> > against "SMP" configuration having to know)... more and more sources of
> > error.
>
> Unfortunately the progression with processors seems to be going the
> wrong way. Spin locks are getting more not less expensive. That makes
> CONFIG_SMP=n a meaningful optimisation for the 99%+ of people not running
> SMP
Amen.
Jeff
>
>
> Alan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>> > There seems to be a little misunderstanding here; from what
>> > I gathered when talking to Larry, the idea behind ccClusters
>> > is that they provide a single system image in a NUMA box, but
>> > with separated operating system kernels.
>
> Right except NUMA is orthogonal, ccClusters work fine on a regular SMP
> box.
Can you clarify exactly what hardware you need for ccClusters? I've heard
from some people that you need some hardware support to do remote
memory accesses, but you seem to be saying you don't ?
If I give you 16 SMP systems, each with 4 processors and a gigabit
ethernet card, and connect those ethers through a switch, would that
be sufficient hardware?
>> OK, then I've partially misunderstood this ... can people provide some
>> more reference material? Please email to me, and I'll collate the results
>> back to the list (should save some traffic).
>
> I'll try and type in a small explanation, I apologize in advance for the
> bervity, I'm under a lot of pressure on the BK front these days...
>
> The most recent set of slides are here:
>
> http://www.bitmover.com/ml/slide01.html
>
> A couple of useful papers are at
>
> http://www.bitmover.com/llnl/smp.pdf
> http://www.bitmover.com/llnl/labs.pdf
>
> The first explains why I think fine grained multi threading is a mistake
> and the second is a paper I wrote to try and get LLNL to push for what
> I called SMP clusters (which are not a cluster of SMPs, they are a
> cluster of operating system instances on a single SMP).
OK, I went and read those, and I think I now understand the general
concept of what you're advocating. Before we get into too many low-level
technical discussions, if we can step back for a second and take the
50,000 ft view ....
(I've said "we" quite a bit below, where maybe I should sometimes say "I".
I think my views are very roughly representative of *some* other NUMA people,
but I have no right whatsoever to claim that, and I'm not really that sure of it
either. Lots of things below shamelessly stolen from people who've been kind
enough to explain such concepts to me in the past).
I think what you're trying to get to is actually quite similar to where we're
trying to get to, you're just going up the mountain from the other side than
the point we chose to start at. I'll leave aside the discussion for the moment
of which face is easier to scale, I just want to point out that we're actually
going to more or less the same place.
We're both trying to present a single system image to the application
by coupling a bunch of SMP systems together. To take an example of
a NUMA architecture (the one I know reasonably well) the Sequent / IBM
NUMA-Q hardware architecture is basically a bunch of 4 way PCs with a big
fat interconnect slung down the back of them (I'm sure I'll get hung, drawn
and quartered by marketing for that. They're *really* nice PCs. The interconnect
is *very* quick. And there's some really nice cache coherency hardware, etc.
But basically they're just 4 way SMPs + interconnect).
(I'm going to call each of the SMP units a node) You might choose to to do some
of the memory transfers between nodes in software - we chose to do it in
hardware. You might choose to have distinct physical memory maps, we chose
to have a unified one. That's more of a detail - the concept's still the same.
We started out with the concept of a single OS image from a single instance of
the kernel (like a really big SMP box), and we break things down as need be.
As I understand what you're advocating, you want to start out with multiple
instances of the kernel and build them back into one single OS image.
If you'll forgive me being rather woolly and simplistic for the minute (and don't
try to analyse this analogy to death), imagine the OS as two layers:
1) an upper layer doing things like system calls, etc. that provide a user level API
2) a lower layer doing things like page cache, disk IO, etc.
As I understand this, both of us will have the upper layer as a single instance
across the whole system. We'll start with a single instance of the lower layer,
you'll start with multiple instances. You'll presumably have to glue some bits
of that lower layer together, we'll presumably break some apart.
>From what I've read of your documents, you seem to think the only way we
can make a single OS instance scale is by introducing billions of fine-grained
locks. I'm sure that's not *exactly* what you meant, but that's kind of how it
comes across. Yes, there will defintely need to be some splitting up of locks.
But there are lots of other tools in the toolbox. Some things we might well do
are introduce a per-node page cache, maybe a per node dcache / inode
cache. One example we've already is have a scheduler that can be set up
with a seperate runqueue per node. And we'll replicate a copy of kernel
text to every node - processes on that node will use a local copy of the
kernel text.
By the time we've split up a bunch of subsystems to work on a per-node
basis (with some global interactions between them) like this, it starts to look
a lot more like what you're doing with ccClusters.
Let's take an example of a bunch of statistics counters (say 200) that
start off with a single lock covering all of them. We could break up the
lock into 200 locks, one for each stats counter, or we could break up
the counters into one counter per CPU with atomic update with no locking.
If you want to know the result of the counters, you read all of them and
add them together. No locking at all. In the case of many writes and few
reads, this would work much better. There are many ways to crack a nut
(or a lock).
I don't think fine-grained locking necessarily makes things slower. Done
badly, it certainly could. It could easily make things more complex, especially
if done badly. It will probably make things a little more complex, even if done
well. Personally, I believe that we can keep that managable, especially if
we're careful to actually document stuff. This means, for instance, things
like Rick Lindsley's locking document, and actually putting some comments
against data structures saying what they're locked by! (Each is one index
into the x-map). We should avoid getting too carried away, and creating
*too* many locks - that is a danger, I agree with you there.
> The basic idea is this: if you consider the usefulness of an SMP versus a
> cluster, the main thing in favor of the SMP is
>
> all processes/processors can share the same memory at memory speeds.
> I typically describe this as "all processes can mmap the same data".
> A cluster loses here, even if it provides DSM over a high speed
> link, it isn't going to have 200 ns caches misses, it's orders of
> magnitude slower. For a lot of MPI apps that doesn't matter, but
> there are apps for which high performance shared memory is required.
I think a far more valid / interesting comparison would be NUMA vs
ccClusters rather than SMP - they're much more comparible. I don't
think anyone's advocating a 128 way SMP system (or at least I'm not).
> There are other issues like having a big fast bus, load balancing, etc.,
> but the main thing is that you can share data quickly and coherently.
> If you don't need that performance/coherency and you can afford to
> replicate the data, a traditional cluster is a *much* cheaper and
> easier answer. Many problems, such as web server farms, are better
> done on Beowulf style clusters than an SMP, they will actually scale
> better.
Absolutely. For for some problems, the Beowulf style approach is much
cheaper and easier.
> OK, so suppose we focus on the SMP problem space. It's a requirement
> that all the processes on all the processors need to be able to access
> memory coherently. DSM and/or MPI isn't an answer for this problem
> space.
>
> The traditional way to use an SMP is to take a single OS image and
> "thread" it such that all the CPUs can be in the OS at the same time.
> Pretty much all the data structures need to get a lock and each CPU
> takes the lock before it uses the data structure. The limit of the
> ratio of locks to cache lines is 1:1, i.e., each cache line will need
> a lock in order to get 100% of the scaling on the system (yes, I know
> this isn't quite true but it is close and you get the idea).
>
> Go read the "smp.pdf" paper for my reasons on why this is a bad approach,
> I'll assume for now you are willing to agree that it is for the purposes
> of discussion.
>
> If we want to get the most use out of big SMP boxes but we also want to
> do the least amount of "damage" in the form of threading complexity in
> the source base. This is a "have your cake and eat it too" goal, one
> that I think is eminently reachable.
>
> So how I propose we do this is by booting multiple Linux images on
> a single box. Each OS image owns part of the machine, 1-4 CPUs, 0 or
> more devices such as disk, ethernet, etc., part of memory. In addition,
> all OS images share, as a page cache, part of main memory, typically
> the bulk of main memory.
>
> The first thing to understand that the *only* way to share data is in
> memory, in the globally shared page cache. You do not share devices,
> devices are proxied. So if I want data from your disk or file system,
> I ask you to put it in memory and then I mmap it. In fact, you really
> only share files and you only share them via mmap (yeah, read and write
> as well but that's the uninteresting case).
>
> This sharing gets complex because now we have more than one OS image
> which is managing the same set of pages. One could argue that the
> code complexity is just as bad as a fine grained multi threaded OS
> image but that's simply incorrect. I would hide almost 100% of this
> code in a file system, with some generic changes (as few as possible)
> in the VM system. There are some changes in the process layer as well,
> but we'll talk about them later.
>
> If you're sitting here thinking about all the complexity involved in
> sharing pages, it is really helpful to think about this in the following
> way (note you would not actually implement it like this in the long
> run but you could start this way):
>
> Imagine that for any given file system there is one server OS image and N
> client os images. Imagine that for each client, there is a proxy process
> running on behalf of the client on the server. Sort of like NFS biods.
> Each time the client OS wants to do an mmap() it asks the proxy to do
> the mmap(). There are some corner cases but if you think about it, by
> having the proxies do the mmaps, we *know* that all the server OS data
> structures are correct. As far as the server is concerned, the remote
> OS clients are no different than the local proxy process. This is from
> the correctness point of view, not the performance point of view.
>
> OK, so we've handled setting up the page tables, but we haven't handled
> page faults or pageouts. Let's punt on pageouts for the time being,
> we can come back to that. Let's figure out a pagefault path that will
> give correct, albeit slow, behaviour. Suppose that when the client faults
> on a page, the client side file system sends a pagefault message to the
> proxy, the proxy faults in the page, calls a new vtop() system call to
> get the physical page, and passes that page descriptor back to the client
> side. The client side loads up the TLB & page tables and away we go.
> Whoops, no we don't, because the remote OS could page out the page and
> the client OS will get the wrong data (think about a TLB shootdown that
> _didn't_ happen when it should have; bad bad bad). Again, thinking
> just from the correctness point of view, suppose the proxy mlock()ed
> the page into memory. Now we know it is OK to load it up and use it.
> This is why I said skip pageout for now, we're not going to do them
> to start with anyway.
That doesn't seem a million miles away from creating yourself a local memory
buffer, and then setting up the DMA engine of an interface card on a remote
node to transfer you the data into that local buffer. Not exactly the same,
but the concept's not all that dissimilar.
Martin.
> If I give you 16 SMP systems, each with 4 processors and a gigabit
> ethernet card, and connect those ethers through a switch, would that
> be sufficient hardware?
You've completely misunderstood the message, sorry, I must not have been clear.
What I am proposing is to cluster *OS* images on a *single* SMP as a way of
avoiding most of the locks necessary to scale up a single OS image on the
same number of CPUs.
It has nothing to do with clustering more than one system, it's not that kind
of clustering. It's clustering OS images.
To make it easy, let's imagine you have a 16 way SMP box and an OS image that
runs well on one CPU. Then a ccCluster would be 16 OS images, each running
on a different CPU, all on the same hardware.
DEC has done this, Sun has done this, IBM has really done this, but what none
of them have done is make mmap() work across OS boundaries. If all OS images
could share the same page cache, that's a first order approximation of an
16-way SMP OS with out all the locking.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Alan Cox <[email protected]> wrote:
> > For example, there should be no reason that most drivers or any other
> > random kernel module should know anything about SMP. Under Linux, it
> > annoys me to no end that I have to ever know (and yes, I count compiling
> > against "SMP" configuration having to know)... more and more sources of
> > error.
>
> Unfortunately the progression with processors seems to be going the
> wrong way. Spin locks are getting more not less expensive. That makes
> CONFIG_SMP=n a meaningful optimisation for the 99%+ of people not running
> SMP
I appreciate the costs (having worked in the Intel x86 arch team) and don't
like that part either, but the question at hand is whether you need the SMP
locks in most of the compiled drivers/modules themselves. That is in part
an artifact of the old architecture before they were loadable.
This really goes into a side-topic, but plainly:
The general driver/random module framework in Linux really needs to get
separated from the core kernel, and made so that it doesn't need to be
recompiled between minor kernel versions. Perhaps even pulling the
drivers in general apart from each other, just aggregating releases for
convenience.
MS with Windows (and even DOS) went the right direction here. In fact,
they have been hurting themselves by what lack of driver interoperability
there is even between Windows NT/2K/XP. Admittedly they didn't have much
of a choice with their closed-source scheme, but it still is a better
solution from a usability and stability point of view in general.
Don't get me wrong, I only run MS Software on 2 of my 8 machines (and
have been trying to remove one of those with Wine/WineX), but I appreciate
a better overall solution when I see one.
I will go so far as to say, for the long term this is necessary for the
survival of Linux, and would help it's health even in the server arena.
For example, we need the ability to easily:
-- Install random drivers on top of your kernel version and not
have them disappear when changing kernels unless that is desired.
This is just a royal pain for most people I've ever dealt with
who are not kernel hackers, and rightly so.
-- Install random kernels while retaining the same drivers for
testing/stability purposes.
I know that on my Linux servers, it bugs me that it's hard/nigh
impossible sometimes to change the core kernel and still trust
the drivers haven't drifted.
Those can usually be done by someone who is willing to/capable of
performing sleazy tricks or detailed hacking, but it's a burden. It
gets prohibitive often enough to be very frustrating, and I'm more patient
than most I know with random kernel hacking.
Stability/control/compatibility is in general of far more concern to most
than tweaked performance of the core kernel against the drivers. That
wouldn't be given up either, it just becomes an option.
A lesser solution, but moderately workable in the short-term:
Build a framework for an external "drivers" source/binary tree that can be
(via a single command) rebuilt for a different Linux kernel version. This
is arguably a Linux distribution thing.
--
Erich Stefan Boleyn <[email protected]> http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"
I wrote:
> This really goes into a side-topic, but plainly:
>
> The general driver/random module framework in Linux really needs to get
> separated from the core kernel, and made so that it doesn't need to be
> recompiled between minor kernel versions. Perhaps even pulling the
> drivers in general apart from each other, just aggregating releases for
> convenience.
...and licensing issues aside (probably only GPL for the moment), this
kind of thing could form the basis for an open-source kernel/OS-independent
set of drivers.
I know that I have been intending on doing a Linux driver compatibility
layer of sorts for my OS project (going to be GPL'd) I'm working on.
Maybe there are some others interested in this kind of project?
--
Erich Stefan Boleyn <[email protected]> http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"
On Wed, 05 Dec 2001 11:40:07 -0800
[email protected] wrote:
> This really goes into a side-topic, but plainly:
>
> The general driver/random module framework in Linux really needs to get
> separated from the core kernel, and made so that it doesn't need to be
> recompiled between minor kernel versions. Perhaps even pulling the
> drivers in general apart from each other, just aggregating releases for
> convenience.
You have just expressed my wildest nightmares. Just go ahead ...
> MS with Windows (and even DOS) went the right direction here. In fact,
> they have been hurting themselves by what lack of driver interoperability
> there is even between Windows NT/2K/XP. Admittedly they didn't have much
> of a choice with their closed-source scheme, but it still is a better
> solution from a usability and stability point of view in general.
You can only be plain kidding with this statement. If you split the drivers
from the rest of the kernel, you managed to get rid of this nice (yes, I really
meant nice) monolithic design, where I only need a simple config file to
_update_ to a new kernel revision (_up_, not _down_) and be happy (including
all the drivers). Obviously you just prove yourself wrong - mentioning not
working driver interoperability between NT/2K/XP whatever - with the idea that
it is indeed possible to make major new kernel versions (which should be
getting better btw) without _any_ changes in the driver framework that will
break your nice and stable but _old_ drivers. What's the use of this? You are
not talking about releasing driver-plugin-/framework-patches or the like just
to load _old_ drivers into _new_ kernel-environment?
Is this what they do at MS? Well if, they have not come that far.
> Don't get me wrong, I only run MS Software on 2 of my 8 machines (and
> have been trying to remove one of those with Wine/WineX), but I appreciate
> a better overall solution when I see one.
This brings up memories about reading Peter Nortons' latest hardcore books some
years ago, brrrr.
Reading between your lines, I can well see that you are most probably talking
about closed-source linux-drivers breaking with permanently released new kernel
revisions. But, in fact, this is the closed-source phenomenon, and _not_ linux.
> I will go so far as to say, for the long term this is necessary for the
> survival of Linux, and would help it's health even in the server arena.
You just invented the circle with edges: you are talking about "long-term" and
"MS drivers solution" at the same time. Remember, this company is currently
saying the product cycle is 3 years. I know pretty big companies that haven't
even managed to get the NT drivers really working under W2K, and were just shot
down by XP release.
I tend to believe we could just wait another two MS cycles to have even the
biggest MS-fans converted to kernel-hackers, only because of being real fed up
with the brilliant, long term driver design.
Regards,
Stephan
[email protected] writes:
>
> MS with Windows (and even DOS) went the right direction here. In fact,
> they have been hurting themselves by what lack of driver interoperability
> there is even between Windows NT/2K/XP. Admittedly they didn't have much
> of a choice with their closed-source scheme, but it still is a better
> solution from a usability and stability point of view in general.
I remember some quote from a Microsoft manager when they released Win2k.
(paraphrased) "A significant percentage of the blue screens in NT4 were
caused by buggy third party drivers." (and then how they will try to avoid
it in the future by having more stringent windows logo tests etc.
The experience in recemt Linux is basically similar. Single Linux has
gained vendor support in drivers it has gotten a lot more unstable
than it used to be (sad but true). There are first a lot more and more
complex drivers than there used to be. A lot of drivers both writen
by individuals and also companies for their are simply crappy buggy
code. I could give you numerous examples here; names withheld to
protect the guilty. For hardware companies it might be because driver
writing is not a profit center, but a cost. There might be other
reasons. There are just a lot of bad drivers around.
[This is not a general insult on driver writers; there are some very well
written drivers, but also unfortunately a lot of bad ones.]
Now when a driver crashes guess who is blamed? Not the driver author
but the Linux kernel is seen as unstable and it effectively is as
a end result - it doesn't work for the user. All just because of bad drivers.
The solution that is tried in Linux land to avoid the "buggy drivers" ->
"linux going to windows levels of stability" trap is to keep drivers in tree
and aggressively auditing them; trying to fix their bugs.
A lot of driver code is actually cut'n'pasted or based
on other driver code (or you can say they often use common design patterns)
Now when a bug/race/.. is found and fixed in one driver having the majority
of drivers in tree makes it actually possible to fix the bug who is likely
in other drivers who use similar code there too. With having drivers in external
trees that crashing/angry user/debugging/etc. would likely need to be done once
per driver; overall causing much more pain for everybody.
Your scheme would make this strategy of tight quality control of
drivers much harder, and I think it wouldn't do good to the long term
stability of linux.
There are other reasons why linux has really no stable driver interface.
Sometimes it is just needed to break drivers to fix some bugs cleanly.
Getting rid of this possibility (fixing bugs cleanly even if it requires
changes in other kernel code) would also cause more bugs in the long term.
-Andi
>> If I give you 16 SMP systems, each with 4 processors and a gigabit
>> ethernet card, and connect those ethers through a switch, would that
>> be sufficient hardware?
>
> You've completely misunderstood the message, sorry, I must not have been clear.
Oops ... that's twice now ;-) Maybe I'm reading it with too many preconceived
notions of what you're doing from conversations I've had with other people
about ccClusters. I'll try to do a mental reset, and start from a clean slate.
> What I am proposing is to cluster *OS* images on a *single* SMP as a way of
> avoiding most of the locks necessary to scale up a single OS image on the
> same number of CPUs.
Which, to me, makes the whole thing much less interesting, since there aren't
SMP systems about that are really large that I know of anyway. Scaling to
the size of current SMP systems is a much less difficult problem than scaling
to the size of NUMA systems.
BUT ... much of the rest of the message I sent you still applies anyway.
You can create virtual "pools" or "resource domains" within an SMP system
in the same way nodes exist on NUMA and work from the starting point of
a single OS image, instead of multiple.
The main advantage of starting with a single OS image, as I see it, is
that you have a system that works fine, but performs badly, from the
outset. Makes it easier to do development on - that's where I have the
NUMA-Q platform at the moment - it thinks it's an SMP box.
Martin.
> > What I am proposing is to cluster *OS* images on a *single* SMP as a way of
> > avoiding most of the locks necessary to scale up a single OS image on the
> > same number of CPUs.
>
> Which, to me, makes the whole thing much less interesting, since there aren't
> SMP systems about that are really large that I know of anyway. Scaling to
> the size of current SMP systems is a much less difficult problem than scaling
> to the size of NUMA systems.
We don't agree on any of these points. Scaling to a 16 way SMP pretty much
ruins the source base, even when it is done by very careful people.
> The main advantage of starting with a single OS image, as I see it, is
> that you have a system that works fine, but performs badly, from the
> outset.
Hey, I can make one of those :-)
Seriously, I went through this at SGI, that's exactly what they did, and it
was a huge mistake and it never worked.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> We don't agree on any of these points. Scaling to a 16 way SMP pretty much
> ruins the source base, even when it is done by very careful people.
I'd say that the normal current limit on SMP machines is 8 way.
But you're right, we don't agree. Time will tell who was right.
When I say I'm interested in 16 way scalability, I'm not talking about
SMP, so perhaps we're talking at slightly cross purposes.
> Seriously, I went through this at SGI, that's exactly what they did, and it
> was a huge mistake and it never worked.
You seem to make this odd logical deduction quite a bit - you (or company X)
has tried concept X before. Their implementation didn't work. Therefore the
concept is bad. It's not particularly convincing as an argument style to others.
But I understand that it makes *you* want to try something else.
Martin.
Stephan von Krawczynski <[email protected]> wrote:
...
> You can only be plain kidding with this statement. If you split the
> drivers from the rest of the kernel, you managed to get rid of this
> nice (yes, I really meant nice) monolithic design, where I only need
> a simple config file to _update_ to a new kernel revision (_up_, not
> _down_) and be happy (including all the drivers).
Hmm. There is little fundamentally incompatible with having splits in
the core kernel and sets of drivers, and getting most of what you want
here.
However, the comment about being "happy (including all the drivers)"
seems a bit naive in my experience. That makes the assumption that the
drivers in the new/old/whatever kernel you change to are necessarily of
the same caliber as the ones you came from, and that is not always true
by any means.
Also, in a world where one values stability, being able to rev
backward is quite important also. The lack of software package tools
like rpm being able to "downgrade" software easily is a serious one in
my mind. What do you do when you install something major and it
breaks, but it has interdependencies on multiple other things?
I don't object to producing well-tested full sets of driver source that
go with kernel versions, I just don't want them to be tied if I have
a need to pull something apart (a driver from one version and from
another are the only ones that run stably), which frankly happens too
often for my taste. Even if it didn't I'd still want it as much as
possibly for the fall-back options it provides.
...
> working driver interoperability between NT/2K/XP whatever - with the
> idea that it is indeed possible to make major new kernel versions (which
> should be getting better btw) without _any_ changes in the driver
> framework that will break your nice and stable but _old_ drivers. What's
> the use of this? You are not talking about releasing driver-plugin-/
> framework-patches or the like just to load _old_ drivers into _new_
> kernel-environment?
> Is this what they do at MS? Well if, they have not come that far.
I didn't go far enough with my comment. I should have said that the
lack of a common driver framework base that works between *all* (or nearly
all, some obsolescence is ok) their Windows versions is a problem.
In the consumer line (win3.1/95/98/me) where they were keeping very good
compatibility across some kinds of drivers (it had it's problems, to be
sure), they were trying the hardest because they recognized that the
most important thing was to just have things work in the first place.
NOTE: I'm not endorsing their overall API convenience (driver or
Win16/Win32), stability, suitability, merchantability, whatever, I'm
just talking about drivers and their distribution model at the moment.
...
> Reading between your lines, I can well see that you are most probably
> talking about closed-source linux-drivers breaking with permanently
> released new kernel revisions. But, in fact, this is the closed-source
> phenomenon, and _not_ linux.
No, though I don't object to closed-source in general per se. I hate it
for myself and businesses I've worked for because I like to be able to
fix/improve/whatever code, but I recognize that the majority of users
out there would never touch code.
My general feeling is that binary drivers are ok/should be supported well
across versions since that is the thing you load in at boot/bring-system-
up time. Having separate (and usually many) step(s) to getting a driver
and having it load on your system is a major and I'm thinking artificial
pain.
In general my argument stems from the same basis that the kernel/user-level
interface does: keeping interfaces stable and removing packaging/bundling
requirements across major boundaries almost always yield a win somewhere.
In the case of MS and drivers, the win they have in convenience to end-users
of all types, and the ability to mix and match drivers forward or backward
up to some limitations in API revisions.
...
> I tend to believe we could just wait another two MS cycles to have even
> the biggest MS-fans converted to kernel-hackers, only because of being
> real fed up with the brilliant, long term driver design.
Most people will never touch code or a compiler, and just want a simple
obvious formula or even to have the system automagically do the Right
Things for you. Even many programmers have limitations of curiousity or
energy, and it isn't a bad thing to organize even core system things to
be easy.
MS may be stupid/annoying in other ways, but they know this and have
moved toward it, albeit sluggishly at times.
--
Erich Stefan Boleyn <[email protected]> http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"
On Wed, Dec 05, 2001 at 01:14:45PM -0800, Martin J. Bligh wrote:
> > Seriously, I went through this at SGI, that's exactly what they did, and it
> > was a huge mistake and it never worked.
>
> You seem to make this odd logical deduction quite a bit - you (or company X)
> has tried concept X before. Their implementation didn't work. Therefore the
> concept is bad. It's not particularly convincing as an argument style to others.
I think you'll find that a common theme amongst people with experience.
I also will point out that what you are saying is exactly what I and
every other young hotshot said in our twenties. It's funny how when
you let 15 years go by the people that you argued with in the past
suddenly become right. It's certainly been a pattern in my life that
when I argue with people who are older and more experienced, 9 times out
of 10, I let some years pass and I find myself arguing their position.
It's also interesting to note that these days virtually 100% of that
sort of discussion is with someone younger. Hardly conclusive, but
you can see a pattern emerging.
You are right in suggesting that there are other answers, but what you
miss is that they are not very likely to work. The field of operating
systems is well explored, in fact, I challenge you to name 5 things that
Linux has done which have not been done before. The point being that
the graph of choices is well pruned. Feel free to ignore the pruning,
there is always a chance that the old farts have pruned off a fruitful
branch, or times have changed soas to invalidate the reasoning; just be
warned that the chances are low.
What I'm trying to do is avoid having Linux go down some paths that I
have seen other people go down because those paths have *all* resulted
in a kernel that none of us would want. You can assert all you like
that you'll not make those mistakes, but having seen those same assertions
a half a dozen times before from a half a dozen different OS efforts, all
of which were staffed with talented and careful people, you'll forgive
my skepticism.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> What I'm trying to do is avoid having Linux go down some paths that I
> have seen other people go down because those paths have *all* resulted
> in a kernel that none of us would want. You can assert all you like
> that you'll not make those mistakes, but having seen those same assertions
> a half a dozen times before from a half a dozen different OS efforts, all
> of which were staffed with talented and careful people, you'll forgive
> my skepticism.
You're right to point out the pitfalls that others have found in such paths
before - it's informative, and it's interesting. Personally I think I'd rather
walk down that path, trying to avoid known pitfalls, than try your new
path, but I'll be delighted to see how your concept works out in practice.
Good luck to you.
I still think (see my previous email) that we're actually heading to more or
less the same place from different directions, which was actually my main
point.
Time will tell ;-)
Martin.
> I still think (see my previous email) that we're actually heading to more or
> less the same place from different directions, which was actually my main
> point.
Oh, I agree with that. There is no doubt of that, I thought that was fairly
apparent. We aren't arguing about "what" we are arguing about "how". You
are saying "I can take the path explored before and do it better" and I'm
saying "Maybe, but extremely unlikely given history. It's far more likely
that you'll repeat history by ignoring it, a time honored tradition, albeit
ill-advised."
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Andi Kleen <[email protected]> wrote:
> [email protected] writes:
>
> > MS with Windows (and even DOS) went the right direction here. In fact,
> > they have been hurting themselves by what lack of driver interoperability
> > there is even between Windows NT/2K/XP. Admittedly they didn't have much
> > of a choice with their closed-source scheme, but it still is a better
> > solution from a usability and stability point of view in general.
>
> I remember some quote from a Microsoft manager when they released Win2k.
> (paraphrased) "A significant percentage of the blue screens in NT4 were
> caused by buggy third party drivers." (and then how they will try to avoid
> it in the future by having more stringent windows logo tests etc.
Sure. Though if they really cared enough, they could have a
"safe-driver" mode that would run the drivers in protected address
spaces or something. There is a performance loss associated with this
obviously, but it would be a great way to run drivers while testing them
out, or if you had a critical need and a driver would eat itself
occasionally.
> The experience in recemt Linux is basically similar. Single Linux has
> gained vendor support in drivers it has gotten a lot more unstable
> than it used to be (sad but true). There are first a lot more and more
> complex drivers than there used to be. A lot of drivers both writen
> by individuals and also companies for their are simply crappy buggy
> code. I could give you numerous examples here; names withheld to
> protect the guilty. For hardware companies it might be because driver
> writing is not a profit center, but a cost. There might be other
> reasons. There are just a lot of bad drivers around.
[see above comment about a "safe-driver" mode... I'm already working
on this for my own OS project, and have been moderately tempted to do
it for Linux (as well as an automatic buffer-overflow protector) ]
I'm not disagreeing with you, in fact this is the major reason I'd want
such a framework.
You can pick the drivers that way relatively easily, and stick to the ones
you know work!! Right now, that is very difficult (and effectively
impossible for most) if you rev anything kernel/driver-related.
There could even be a website that maintained info about drivers and
known-working versions. Having such info for the kernel tree wouldn't
be a bad idea as is.
The distribution folks could work with the general community on this
pretty easily I'd guess.
> Now when a driver crashes guess who is blamed? Not the driver author
> but the Linux kernel is seen as unstable and it effectively is as
> a end result - it doesn't work for the user. All just because of bad
> drivers.
>
> The solution that is tried in Linux land to avoid the "buggy drivers" ->
> "linux going to windows levels of stability" trap is to keep drivers in
> tree and aggressively auditing them; trying to fix their bugs.
This works kind of fine when you're talking about developers (though the
problems I mention below aren't completely aleviated either, just not as
bad). For random people or even IT folks trying to maintain some systems
I would say this is not a feature.
Their only alternative right now is to try out things that work for them
in a very coarse-grained manner ("try out this kernel" : "hmm, didn't work").
A good example is if you need a driver for some new bit of hardware...
you often have to rev your entire kernel/driver tree to get it. Most would
have no choice but to do so unless hand-held by a kernel hacker.
If it breaks something else (which happens often enough) then you're just
SOL.
I.e. I think too many things are tied together for non-hackers.
> A lot of driver code is actually cut'n'pasted or based
> on other driver code (or you can say they often use common design patterns)
> Now when a bug/race/.. is found and fixed in one driver having the majority
> of drivers in tree makes it actually possible to fix the bug who is likely
> in other drivers who use similar code there too. With having drivers in
> external trees that crashing/angry user/debugging/etc. would likely need
> to be done once per driver; overall causing much more pain for everybody.
>
> Your scheme would make this strategy of tight quality control of
> drivers much harder, and I think it wouldn't do good to the long term
> stability of linux.
Not necessarily at all.
You're talking about 2 things:
Driver maintenance: This mostly need not change, so your example of fixing
problems is the same.
Driver/kernel error reporting: I say the same thing as I said about MS:
that if we cared enough, we'd have a "safe-driver" framework and driver/
module versioning so that we can tell pretty much exactly where the
problem occured. You don't use it all the time by any means, but if you
want to get a report answered, there would be some trivial way to turn it
on.
[The "safe-driver" thing obviously may not be the identical footprint so
a crash may not happen the same way or at all, but if it doesn't happen,
then hey, you have a way to run stably, which for most people that is
enough]
Note that MS has been getting a lot of pushback from people about the
inclusion of third-party drivers (to the point where they've partially
disabled the "signed drivers" thing by default, falling back from an
earlier position in the Win XP beta of not accepting them without some
major gyrations on the part of the poor person trying to just run their
hardware). Just saying "no" isn't that supportable a position.
For example, I think the "module tainted" thing is not terribly useful
along the lines of really fixing bugs. It may be an indicator and tell
the core kernel folks when not to "waste their time on some binary-only
bug", but I'm not sure what else it does.
> There are other reasons why linux has really no stable driver interface.
> Sometimes it is just needed to break drivers to fix some bugs cleanly.
> Getting rid of this possibility (fixing bugs cleanly even if it requires
> changes in other kernel code) would also cause more bugs in the long term.
This is of course a different problem, but it's unclear if it's one that
would cause more bugs.
Unstable interfaces between major subsystems are often a sign of lack of
design. [ok, I'm flamebait, but at least I'll be warm-n-toasty now that
it's colder outside]
--
Erich Stefan Boleyn <[email protected]> http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"
Hi!
> 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.
Hey, I still have 8-bit isa scsi card somewhere.... Last time I fixed
that was just before 2.4 because that was when I got it... Don't flush
drivers too fast, please... If you kill drivers during 2.5, people
will not notice, and even interesting drivers will get killed. Killing
them during 2.6.2 might be better.
Pavel
--
"I do not steal MS software. It is not worth it."
-- Pavel Kankovsky
On Wed, 5 Dec 2001, Larry McVoy wrote:
> > I still think (see my previous email) that we're actually heading to more or
> > less the same place from different directions, which was actually my main
> > point.
>
> Oh, I agree with that. There is no doubt of that, I thought that was fairly
> apparent. We aren't arguing about "what" we are arguing about "how". You
> are saying "I can take the path explored before and do it better" and I'm
> saying "Maybe, but extremely unlikely given history. It's far more likely
> that you'll repeat history by ignoring it, a time honored tradition, albeit
> ill-advised."
Larry, I'd like to remember You that science progress has been made by
people that forced common knowledge, starting from Platone spherical earth
up to Einstain theory of relativity.
A lot of failures sure, but a single success is enough to pay out.
The _main_ difference with the two examples is that earth has always been
spherical and sub-atomic mechanics is always been in that way, while
technology progress could make someone else to succeed where you failed
time ago.
- Davide
On Wed, Dec 05, 2001 at 02:13:04PM -0800, Davide Libenzi wrote:
> On Wed, 5 Dec 2001, Larry McVoy wrote:
> > Oh, I agree with that. There is no doubt of that, I thought that was fairly
> > apparent. We aren't arguing about "what" we are arguing about "how". You
> > are saying "I can take the path explored before and do it better" and I'm
> > saying "Maybe, but extremely unlikely given history. It's far more likely
> > that you'll repeat history by ignoring it, a time honored tradition, albeit
> > ill-advised."
>
> Larry, I'd like to remember You that science progress has been made by
> people that forced common knowledge, starting from Platone spherical earth
> up to Einstain theory of relativity.
> A lot of failures sure, but a single success is enough to pay out.
How about you go read Einstein's history and show me where he made
discoveries by retracing paths which had been shown time and again to
be fruitless? You'll look for quite a while.
Great leaps forward typically come from a fresh approach, not from
retrying the same tired out ideas which have failed in the past.
On the other hand, as an old boss pointed out to me once, "don't worry
about the people wasting their time doing it wrong, it keeps them out of
your way". So maybe I should just bow out of this part of the discussion.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Mon, Dec 03, 2001 at 10:39:08PM -0300, Horst von Brand wrote:
> > If you want an experiment in evolution, then let *everything* into
> > the kernel. That's how evolution works, it tries everything, it doesn't
> > prescreen. Go read Darwin, go think, there isn't any screening going on,
> > evolution *is* the screening.
>
> Why does the screening have to be at the level of full organisms? It
> _looks_ that way because you don't see the busted sperm or broken eggs, or
> the stillborn embryos which make up the "preliminary checks show it won't
> work" in nature. The process is (hopefully) much more efficient here than
> in nature, and visible, that is all.
And I'd add something more along those lines..
Evolution and selection is about species, not individuals as its commonly
considered, so what might be bad for an individual (getting "screened" at
early ages) might be good for (reproduction of) the species (since it
ensures a better reproduction material quality) Darwinian evolution doesnt
fit too well in the kernel.
On the other hand we can think of developers' minds as a copy-on-write DNA.
DNA knows when something wont work, so it doesn't try it. Screening :)
--
____/| Ragnar H?jland Freedom - Linux - OpenGL | Brainbench MVP
\ o.O| PGP94C4B2F0D27DE025BE2302C104B78C56 B72F0822 | for Unix Programming
=(_)= "Thou shalt not follow the NULL pointer for | (http://www.brainbench.com)
U chaos and madness await thee at its end."
On Wed, 5 Dec 2001, Larry McVoy wrote:
> Seriously, I went through this at SGI, that's exactly what they did, and it
> was a huge mistake and it never worked.
In what sense do you think it "never worked"? It worked for a huge
range of systems and applications.
But then, you left SGI before the process was really finished didn't
you? (IRIX 6.5 was the first release that had all the pieces fully in
place.)
Nigel Gamble [email protected]
Mountain View, CA, USA. http://www.nrg.org/
On Wed, 5 Dec 2001, Larry McVoy wrote:
> On Wed, Dec 05, 2001 at 02:13:04PM -0800, Davide Libenzi wrote:
> > On Wed, 5 Dec 2001, Larry McVoy wrote:
> > > Oh, I agree with that. There is no doubt of that, I thought that was fairly
> > > apparent. We aren't arguing about "what" we are arguing about "how". You
> > > are saying "I can take the path explored before and do it better" and I'm
> > > saying "Maybe, but extremely unlikely given history. It's far more likely
> > > that you'll repeat history by ignoring it, a time honored tradition, albeit
> > > ill-advised."
> >
> > Larry, I'd like to remember You that science progress has been made by
> > people that forced common knowledge, starting from Platone spherical earth
> > up to Einstain theory of relativity.
> > A lot of failures sure, but a single success is enough to pay out.
>
> How about you go read Einstein's history and show me where he made
> discoveries by retracing paths which had been shown time and again to
> be fruitless? You'll look for quite a while.
You're a funny guy Larry, suggesting other people to go for reading
something that, until now, I gave for sure that You've read before
suggesting someone else to read.
At that time there was a bunch of Phisics gurus saying that conventional
law of mechanins would apply even for sub-atomical particles.
Thanks god Albert decided to prove that maybe these guys where wrong.
- Davide
> The solution that is tried in Linux land to avoid the "buggy drivers" ->
> "linux going to windows levels of stability" trap is to keep drivers in tree
> and aggressively auditing them; trying to fix their bugs.
We need to teach Linus about "taste" in drivers. His core code taste is
impeccable, but I'm not fond of his driver taste ;)
Alan (currently cleaning up NCR5380)
> If I give you 16 SMP systems, each with 4 processors and a gigabit
> ethernet card, and connect those ethers through a switch, would that
> be sufficient hardware?
Take a 16 CPU numa box thats really 4x4 + numa glue and run it as if it
was the 4 processors, 4 nodes with gige, only allowing for extra operations
"take access to remote page" "release access to remote page"
On Sat, 1 Dec 2001 00:14:54 -0500 (EST)
Alexander Viro <[email protected]> wrote:
>
>
> 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
And: bad code spreads. Anyone who has done infrastructure change in the
kernel sees this: people copy (presumed) working code.
Hence I now lean towards "change EVERYTHING" rather than "wrap old source, add
new", and "fix even if not broken", eg. my "set_bit needs a long" patch which
also changed x86-specific code (where it doesn't matter).
Cheers,
Rusty.
--
Anyone who quotes me is an idiot. -- Rusty Russell.
> that was just before 2.4 because that was when I got it... Don't flush
> drivers too fast, please... If you kill drivers during 2.5, people
> will not notice, and even interesting drivers will get killed. Killing
> them during 2.6.2 might be better.
They need to die before 2.6. I'm all for leaving the code present and the
ability to select
Expert
Drivers that need fixing
Clockwork scsi controller, windup mark 2
in 2.6 so that people do fix them
Alan
On Wednesday 05 December 2001 02:11 pm, Larry McVoy wrote:
> > If I give you 16 SMP systems, each with 4 processors and a gigabit
> > ethernet card, and connect those ethers through a switch, would that
> > be sufficient hardware?
>
> You've completely misunderstood the message, sorry, I must not have been
> clear. What I am proposing is to cluster *OS* images on a *single* SMP as a
> way of avoiding most of the locks necessary to scale up a single OS image
> on the same number of CPUs.
>
> It has nothing to do with clustering more than one system, it's not that
> kind of clustering. It's clustering OS images.
So basically, you're just turning the per-processor data into a tree?
> To make it easy, let's imagine you have a 16 way SMP box and an OS image
> that runs well on one CPU. Then a ccCluster would be 16 OS images, each
> running on a different CPU, all on the same hardware.
>
> DEC has done this, Sun has done this, IBM has really done this, but what
> none of them have done is make mmap() work across OS boundaries.
The shared memory clustering people are basically trying to make
mmap+semaphores work across a high speed LAN. Why? Because it's cheap, and
the programming model's familiar.
Approaching it all from a different direction, though. Probably not of help
to you...
Rob
On Tuesday 04 December 2001 07:36 pm, Larry McVoy wrote:
> The most recent set of slides are here:
>
> http://www.bitmover.com/ml/slide01.html
>
> A couple of useful papers are at
>
> http://www.bitmover.com/llnl/smp.pdf
> http://www.bitmover.com/llnl/labs.pdf
>
> The first explains why I think fine grained multi threading is a mistake
> and the second is a paper I wrote to try and get LLNL to push for what
> I called SMP clusters (which are not a cluster of SMPs, they are a
> cluster of operating system instances on a single SMP).
This sounds a bit like the shared memory cluster work. (See last month's big
thread I had with Martin. There's URLs on the web but my laptop's offline
right now. Google would know.)
If you take a beowulf style cluster, add in shared memory that can page fault
across the network (just for explicitly shared mappings, like a networked
shm), and a networkable sempahore implementation, you can program it a lot
like NUMA without needing special hardware. (Gigabit ethernet covers a lot
of sins, and Myrinet's still relatively cheap compared to most
supercomputers.) You can even do a cheesy implementation of everything in
userspace if you're not trying to scale it very far (although that largely
wastes the point of myrinet, at least).
Some people have even been working on migrating processes from one node to
another to automatically load balance, although that's a bit fancier than
I've ever bothered with. The hard part of it all is management of the
cluster, and that's something people have been putting a LOT of effort into
from all directions...
> The basic idea is this: if you consider the usefulness of an SMP versus a
> cluster, the main thing in favor of the SMP is
>
> all processes/processors can share the same memory at memory speeds.
> I typically describe this as "all processes can mmap the same data".
> A cluster loses here, even if it provides DSM over a high speed
> link, it isn't going to have 200 ns caches misses, it's orders of
> magnitude slower. For a lot of MPI apps that doesn't matter, but
> there are apps for which high performance shared memory is required.
>
> There are other issues like having a big fast bus, load balancing, etc.,
> but the main thing is that you can share data quickly and coherently.
10gig ethernet is supposed to be coming out in 2003, and some people have
prototypes already. I'm fairly certain this is faster than the current
generations of PCI bus. Of course throughput != latency, but Grace Hopper
was font of carrying around 11 centimeters of wire in her knitting bag and
calling it a nanosecond, which is where the big bucks NUMA systems have their
problems too. :)
> If you don't need that performance/coherency and you can afford to
> replicate the data, a traditional cluster is a *much* cheaper and
> easier answer.
The amount of ram a copy of the OS takes up these days is CHEAP. A well
tuned system needs what, an extra 16 megs per node? (And that includes a lot
of squishiness for buffers you probably need per-node anyway.) If you're
worried about that expense, you're obviously not paying for high-end hardware
anyway...
I've seen people trying to do spinlocks across a numa system. Why? Don't Do
That Then. Purely OS internal abstractions don't need to be shared across
the cluster. I can share a printer through the network right now by just
having my app talk to the server handling it, yet people seem to be trying to
make part of the driver for a device live on the other side of the NUMA
machine. Why? (Because we can! Doesn't make it a good idea...)
> If we want to get the most use out of big SMP boxes but we also want to
> do the least amount of "damage" in the form of threading complexity in
> the source base. This is a "have your cake and eat it too" goal, one
> that I think is eminently reachable.
>
> So how I propose we do this is by booting multiple Linux images on
> a single box. Each OS image owns part of the machine, 1-4 CPUs, 0 or
> more devices such as disk, ethernet, etc., part of memory. In addition,
> all OS images share, as a page cache, part of main memory, typically
> the bulk of main memory.
SMP is symmetrical. On a truly SMP machine, there's no point in having
multiple OS images because they're all equal cost to talk to main memory, so
they might as well share a kernel image. (It's read-only, there's no
contention, they just cache it. There may be per-CPU data structures, but
we've got those already.)
SMP is likely to increase as die sizes shrink, because you can put 4
processors on a chip today on PowerPC. (This is just an alternative to
insanely long pipelines that just start increasing latency of a pipeline
flush. Pentium 4 already has stages that do nothing more than transport data
from one side of the chip to the other, that's just nuts.) Plus more
execution cores: An athlon currently has 3 cores, as do iTanic and Crusoe.
Either you decouple them so they execute different stuff, or they run NOPs.
So either way, you wind up with SMP on one die. (You can't make chips TOO
much smaller because it becomes less economical to cut the wafer up that
small. Harvesting and connecting the chips at finer granularity increases
their cost...)
If die sizes shrink another 4 or 5 times before we hit atomic limits, we can
fit at least 32 processors on a chip. And then we just start increasing the
number of layers and make 3D circuitry assuming we can deal with the heat
problem (which people are working on: heat sinks in the middle of the chip,
just wire around it).
THIS is why many-way SMP is interesting. Crusoe and strongarm have the
northbridge on die which makes this kind of thing easier (getting into shared
L1 cache is bound to be fun), and then there's having the motherboard do SMP
as well. Assuming the motherboards can handle 8-way, dedicated memory
bandwidth interconnects (like ev6), if each chip has just 8 processors, we're
talking 64-way SMP for under $10k in a few years, meaning it'll be $2k a
couple years after that.
There are three main reasons we haven't seen SMP take off in the past 15
years, despite the fact there were SMP 486 motherboards back in the 80's.
The first is that nothing microsoft has ever put out could gracefully handle
it (they didn't even pretend to multitask one CPU until the 90's). The
second is that most programmers (outside of Unix and OS/2) didn't know what a
semaphore was before about 1998, and are just now thinking about breaking
stuff up so portions of the program can advance asynchronously. Third was
that low volume is high cost, so there was a chicken and egg problem on the
hardware side.
Now the programming's gradually starting to get there, and we've got our
first SMP athlon boards priced so a hobbyist can save up for one. I don't
think it's going to decrease in the future...
> OK, so we've handled setting up the page tables, but we haven't handled
> page faults or pageouts. Let's punt on pageouts for the time being,
> we can come back to that. Let's figure out a pagefault path that will
> give correct, albeit slow, behaviour. Suppose that when the client faults
> on a page, the client side file system sends a pagefault message to the
> proxy, the proxy faults in the page, calls a new vtop() system call to
> get the physical page, and passes that page descriptor back to the client
> side. The client side loads up the TLB & page tables and away we go.
> Whoops, no we don't, because the remote OS could page out the page and
> the client OS will get the wrong data (think about a TLB shootdown that
> _didn't_ happen when it should have; bad bad bad). Again, thinking
> just from the correctness point of view, suppose the proxy mlock()ed
> the page into memory. Now we know it is OK to load it up and use it.
> This is why I said skip pageout for now, we're not going to do them
> to start with anyway.
>
> OK, so start throwing stones at this. Once we have a memory model that
> works, I'll go through the process model.
If you only worry about explicitly shared memory (a multi-process model vs a
multi-thread model), you can cheese your way out of this by mounting a
modified network filesystem in /dev/shm if you don't mind hideously high
latency and a central point of failure. (The filesystem has to be able to
initiate page invalidations on mmaped areas, but I suspect this is a problem
somebody's already dealt with. Haven't played with it in a while...)
Rob
> I've seen people trying to do spinlocks across a numa system. Why? Don't Do
Because they work well enough for low-contention locks. We have numa
aware locks too. Or just make the resource node-local.
M.
> So either way, you wind up with SMP on one die. (You can't make chips TOO
> much smaller because it becomes less economical to cut the wafer up that
> small. Harvesting and connecting the chips at finer granularity increases
Except for VIA (where they cant really make them much smaller) the
mainstream x86 dies are _gigantic_
On Wednesday 05 December 2001 07:34 pm, Alan Cox wrote:
> > So either way, you wind up with SMP on one die. (You can't make chips
> > TOO much smaller because it becomes less economical to cut the wafer up
> > that small. Harvesting and connecting the chips at finer granularity
> > increases
>
> Except for VIA (where they cant really make them much smaller) the
> mainstream x86 dies are _gigantic_
Yeah. Exactly. Especially Intel's own. Itanium's enormous, and I mentioned
how Pentium 4 had pushed pipelining slightly beyond where you really get all
that much benefit from it.
They've grown to take advantage of larger transistor budgets, but that's
starting to hit limits on how big you can usefully make them before you get
serious diminishing returns and problems with clock skew and signal
propogation delays and other such fun. (Hence the experiments with clockless
processors, etc.) The longer the wire, the longer it takes a signal to go
down it. You want contained modules so you can clock them fast (hence
pipeline stages).
Athlon hasn't gone pipeline happy the way P4 has, so they don't suffer as
badly from pipeline stalls, but it already has three execution cores (and
requesite monstrous front-end decoding and scheduling stuff to those cores),
with no plans to add a fourth core because the third isn't busy enough that
they think it would help.
Yet manufacturing is going to continue to shrink the density, giving you more
area to work with and a higher transistor budget, which is about 80% of
Moore's Law. Despite gloom and doom predictions since at least the early
1980's has got four or five more doublings to go before we even have to worry
about increasing the number of layers to get extra space. So where's that
extra transistor budget going to go? Bigger L1 cache? Fun, but the main
benefit of a really huge cache isn't on a UP system, but on SMP. The benefit
of an L1 cache is one of them "integral of somevalue/x" functions, the
increase in which falls off pretty rapidly the bigger it gets: the more bytes
of cache the greater percentage chance your next piece of data will be in
cache, but also the more transistors are guaranteed to be sitting idle
because they do NOT contain data you need this cycle. A point of diminishing
returns definitely exists here.
You also can't make the chips infinitely small because it's not worth the
money (manufacturing expense). Beyond a certain point, more chips per wafer
aren't that much cheaper because the taxidermy to test, cut, connect, mount,
package, and ship them becomes a bigger percentage of the cost. And you
still want to amortize your factory, so reducing per-chip manufacturing
expense won't reduce cost noticeably anyway as long as new manufacturing
processes require billions to get the new line up and running.
Intel is trying to transition to VLIW as a way to use more linked execution
cores to do SOMETHING useful with the extra transistor budget, and
Transmeta's even trying to get VLIW to do something USEFUL, but it's a
different programming model that'll take a while to transition to, and it
requires intelligent compilers finding paralellism in the chip, which isn't
easy.
Or, you could use the execution units to run independent threads, which Intel
is ALREADY experimenting with (SMT instead of SMP), but that's really just a
way of backfitting SMP-on-a-die onto the existing linked-core design without
having to redo your process counter and cache circuitry. And again this
requires compilers to catch up, which won't happen for a while, and even then
a programmer could really do a better job of telling the computer what to do.
So the logical thing to do is SMP on a single die (which IBM at least has
been attempting). Not only does it convert transistors into execution speed
efficiently, it allows you to have a flaming big L1 and L2 cache in a way
that it's more likely to accomplish something useful.
And THAT'S what makes SMP interesting in the future. To me anyway. I could
be wrong...
Rob
Hi!
> believe me, there was no 'grand plan'. Initially (5 years ago) Linus said
> that SMP does not matter much at the moment, and that nothing should be
> done in SMP space that hurts uniprocessors. Today it's exactly the other
> way around.
I hope uniprocessors still matter... SMP is nice, but 90% machines are
still uniprocessors... [Or someone get me SMP ;)]
Pavel
--
"I do not steal MS software. It is not worth it."
-- Pavel Kankovsky
Hi!
> > I'm going to weigh in here in favor of limiting effort on SMP development by
> > the core Linux team to systems with 4 processors and under. And not just
> > because I'd like to see those developers freed up to work on my M-Audio
> > Delta 66 :-). The economics of massively parallel MIMD machines just aren't
> > there. Sure, the military guys would *love* to have a petaflop engine, but
> > they're gonna build 'em anyway and quite probably not bother to contribute
> > their kernel source on this mailing list. *Commercial* applications for
> > supercomputers of this level are few and far between. I'm happy with my
> > GFlop-level UP Athlon Thunderbird. And if Moore's Law (or the AMD equivalent
> > :-) still holds, in 12 months I'll have something twice as fast (I've had it
> > for six months already :-).
>
> Two things.
>
> 1) If a company (say, IBM) pays people to work on 8 / 16 way scalability
> because that's what they want out of Linux, then stopping development
> on that isn't going to get effort redirected to fixing your soundcard (yes,
> I realise you were being flippant, but the point's the same), the headcount
> is just going to disappear. AKA your choice isn't "patches for 8 way
> scalablilty, or patches for subsystem X that you're more interested in",
> your choice is "patches for 8-way scalabity, or no patches". Provided that
> those patches don't break anything else, you still win overall by getting them.
>
> 2) Working on scalability for 8 / 16 way machines will show up races,
> performance problems et al that exist on 2 / 4 way machines but don't
> show up as often, or as obviously. I have a 16 way box that shows up
> races in the Linux kernel that might take you years to find on a 2 way.
>
> What I'm trying to say is that you still win. Not as much as maybe you'd
> like, but, hey, it's work you're getting for free, so don't complain too
> much about it. The maintainers are very good at beating the message
> into us that we can't make small systems any worse performing whilst
> making the big systems better.
Making it perform better, while not hurting up, and *not making code
messier* is good thing. Messiness of code might be as importnat as
performance, or even more important.
Pavel
--
"I do not steal MS software. It is not worth it."
-- Pavel Kankovsky
On Tue, 04 Dec 2001 22:05:11 -0800 (PST)
"David S. Miller" <[email protected]> wrote:
> The problem areas of scalability, for which no real solution is
> evident yet, involve the file name lookup tree data structures,
> ie. the dcache under Linux. All accesses here are tree based, and
> everyone starts from similar roots. So you can't per-node or
> per-branch lock as everyone traverses the same paths. Furthermore you
> can't use "special locks" as in #1 since this data structure is
> neither heavy reader nor heavy writer.
Yes. dbench on 4-way was showing d_lookup hurting us, but replacing
dcache_lock with a rw_lock (Anton Blanchard provided an atomic_dec_and_wlock)
and a separate lock for the unused list DIDN'T HELP ONE BIT.
Why? Because there's no contention on the lock! The problem is almost
entirely moving the cacheline around (which is the same for a rw lock).
I'd love to say that I can solve this with RCU, but it's vastly non-trivial
and I haven't got code, so I'm not going to say that. 8)
Rusty.
--
Anyone who quotes me is an idiot. -- Rusty Russell.
On Thu, 6 Dec 2001, Rusty Russell wrote:
> I'd love to say that I can solve this with RCU, but it's vastly non-trivial
> and I haven't got code, so I'm not going to say that. 8)
Lockless algos could help if we're able to have "good" quiescent point
inside the kernel. Or better have a good quiescent infrastructure to have
lockless code to plug in.
- Davide
On Wed, 05 Dec 2001 11:40:07 -0800,
[email protected] wrote:
>Build a framework for an external "drivers" source/binary tree that can be
>(via a single command) rebuilt for a different Linux kernel version. This
>is arguably a Linux distribution thing.
kbuild 2.5. Already done.
From: Davide Libenzi <[email protected]>
Date: Wed, 5 Dec 2001 19:19:19 -0800 (PST)
On Thu, 6 Dec 2001, Rusty Russell wrote:
> I'd love to say that I can solve this with RCU, but it's vastly non-trivial
> and I haven't got code, so I'm not going to say that. 8)
Lockless algos could help if we're able to have "good" quiescent point
inside the kernel. Or better have a good quiescent infrastructure to have
lockless code to plug in.
Lockless algorithms don't get rid of the shared cache lines.
I used to once think that lockless algorithms were the SMP holy-grail,
but this was undone when I realized they had the same fundamental
overhead spinlocks do.
These lockless algorithms, instructions like CAS, DCAS, "infinite
consensus number", it's all crap. You have to seperate out the access
areas amongst different cpus so they don't collide, and none of these
mechanisms do that.
That is, unless some lockless algorithm involving %100 local dirty
state has been invented while I wasn't looking :-)
On Wed, Dec 05, 2001 at 11:56:17PM -0800, David S. Miller wrote:
> These lockless algorithms, instructions like CAS, DCAS, "infinite
> consensus number", it's all crap. You have to seperate out the access
> areas amongst different cpus so they don't collide, and none of these
> mechanisms do that.
Err, Dave, that's *exactly* the point of the ccCluster stuff. You get
all that seperation for every data structure for free. Think about
it a bit. Aren't you going to feel a little bit stupid if you do all
this work, one object at a time, and someone can come along and do the
whole OS in one swoop? Yeah, I'm spouting crap, it isn't that easy,
but it is much easier than the route you are taking.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Larry McVoy <[email protected]>
Date: Thu, 6 Dec 2001 00:02:16 -0800
Err, Dave, that's *exactly* the point of the ccCluster stuff. You get
all that seperation for every data structure for free. Think about
it a bit. Aren't you going to feel a little bit stupid if you do all
this work, one object at a time, and someone can come along and do the
whole OS in one swoop? Yeah, I'm spouting crap, it isn't that easy,
but it is much easier than the route you are taking.
How does ccClusters avoid the file system namespace locking issues?
How do all the OS nodes see a consistent FS tree?
All the talk is about the "magic filesystem, thread it as much as you
want" and I'm telling you that is the fundamental problem, the
filesystem name space locking.
On Wed, 2001-12-05 at 22:14, Martin J. Bligh wrote:
> > We don't agree on any of these points. Scaling to a 16 way SMP pretty much
> > ruins the source base, even when it is done by very careful people.
>
> I'd say that the normal current limit on SMP machines is 8 way.
> But you're right, we don't agree. Time will tell who was right.
> When I say I'm interested in 16 way scalability, I'm not talking about
> SMP, so perhaps we're talking at slightly cross purposes.
Well I do remember those Sequent Symmetry machines from university which
scaled to 24 processors and more. If I remember correctly they ran 16x
386 and 8x 486 in a single box (under Dynix?)
Wasn't too much interested in that then. I was to busy toying with my
Amiga. ;-)
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
one other thing to keep in mind on this entire discussion is that there
has not been a big incentive for the chip manufacturers to make a good
locking primitive (after all if 99% of the market is UP boxes why design
in extra stuff for the SMP modes)
This is changing as SMP boxes become mor popular.
has anyone pointed out this problem to the CPU vendors? it may be that
they would be interested in putting in some extra locking operations in a
future chip (for example I can easily see AMD implementing a 1
bit-per-lock set of locks that are arbatrated directly with the CPUs and
the chipset similar to the way cache coherancy works now rather then
the current model of useing a cacheline of memory that has to be moved
back and forth and then checked for status)
the big drawback would be that it would be non-standard commands which
each vendor would do differently, but the potential of implementing a
significant number of locks at the hardware level rather then just in
software is a very interesting thought.
David Lang
On 6 Dec
2001, Henning Schmiedehausen wrote:
> Date: 06 Dec 2001 10:50:43 +0100
> From: Henning Schmiedehausen <[email protected]>
> To: Martin J. Bligh <[email protected]>
> Cc: Larry McVoy <[email protected]>, Rik van Riel <[email protected]>,
> Lars Brinkhoff <[email protected]>,
> Alan Cox <[email protected]>, [email protected]
> Subject: Re: SMP/cc Cluster description [was Linux/Pro]
>
> On Wed, 2001-12-05 at 22:14, Martin J. Bligh wrote:
> > > We don't agree on any of these points. Scaling to a 16 way SMP pretty much
> > > ruins the source base, even when it is done by very careful people.
> >
> > I'd say that the normal current limit on SMP machines is 8 way.
> > But you're right, we don't agree. Time will tell who was right.
> > When I say I'm interested in 16 way scalability, I'm not talking about
> > SMP, so perhaps we're talking at slightly cross purposes.
>
> Well I do remember those Sequent Symmetry machines from university which
> scaled to 24 processors and more. If I remember correctly they ran 16x
> 386 and 8x 486 in a single box (under Dynix?)
>
> Wasn't too much interested in that then. I was to busy toying with my
> Amiga. ;-)
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
>
> Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
> D-91054 Buckenhof Fax.: 09131 / 50654-20
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Wed, 5 Dec 2001, Davide Libenzi wrote:
> On Thu, 6 Dec 2001, Rusty Russell wrote:
>
> > I'd love to say that I can solve this with RCU, but it's vastly non-trivial
> > and I haven't got code, so I'm not going to say that. 8)
>
> Lockless algos could help if we're able to have "good" quiescent point
> inside the kernel. Or better have a good quiescent infrastructure to
> have lockless code to plug in.
Machines get dragged down by _uncontended_ locks, simply
due to cache line ping-pong effects.
regards,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/
http://www.surriel.com/ http://distro.conectiva.com/
On Wed, 05 Dec 2001 13:17:47 -0800
[email protected] wrote:
> Stephan von Krawczynski <[email protected]> wrote:
> > You can only be plain kidding with this statement. If you split the
> > drivers from the rest of the kernel, you managed to get rid of this
> > nice (yes, I really meant nice) monolithic design, where I only need
> > a simple config file to _update_ to a new kernel revision (_up_, not
> > _down_) and be happy (including all the drivers).
>
> Hmm. There is little fundamentally incompatible with having splits in
> the core kernel and sets of drivers, and getting most of what you want
> here.
There is. You double the administrational work. Most updates are performed
because you want the latest bugfixes. If you get more bugfixes than you
intended - lucky.
Currently you draw the latest kernel-tree (or the latest _you_ like to use),
use your old .config and it works out - as long as you do not use closed-source
drivers.
If you split things up, you draw _two_ archives, compile and install both.
> However, the comment about being "happy (including all the drivers)"
> seems a bit naive in my experience. That makes the assumption that the
> drivers in the new/old/whatever kernel you change to are necessarily of
> the same caliber as the ones you came from, and that is not always true
> by any means.
Oops. Then you have a severe problem in understanding how linux _should_ be
worked with. Obviously you can go and buy some distribution and it may work out
pretty well. But being a serious administrator you _will_ do kernel updates
apart from the distro (sooner or later). If there are drivers in a newer kernel
release, that do not work any longer, compared to an older release, you should
say so. Best place would be the listed maintainer. Because if it doesn't do the
job for your configuration any longer, chances are high others were hit, too.
The maintainer cannot know, if you do not tell him.
I guess we have the mutual agreement here, that maintained drivers should get
better not worse through the revisions. This means configurations once
successful are not meant to break later on.
This basically is what I intended to say with "being happy" :-)
> Also, in a world where one values stability, being able to rev
> backward is quite important also. The lack of software package tools
> like rpm being able to "downgrade" software easily is a serious one in
> my mind. What do you do when you install something major and it
> breaks, but it has interdependencies on multiple other things?
This isn't kernel-related, is it? You can always boot the previous kernel (and
drivers), if you updated correctly. I am talking about revision-updates, not
major updates (like from 2.0 to 2.2). Major update will break mostly. But -
frankly spoken - it should. If you are using a bunch of very old binaries, you
should be driven to update these anyway.
> I don't object to producing well-tested full sets of driver source that
> go with kernel versions, I just don't want them to be tied if I have
> a need to pull something apart (a driver from one version and from
> another are the only ones that run stably), which frankly happens too
> often for my taste. Even if it didn't I'd still want it as much as
> possibly for the fall-back options it provides.
Can you give a striking example for this? (old driver ok, new driver broken,
both included in kernel releases)
> I didn't go far enough with my comment. I should have said that the
> lack of a common driver framework base that works between *all* (or nearly
> all, some obsolescence is ok) their Windows versions is a problem.
Which means: it does not work there.
> In the consumer line (win3.1/95/98/me) where they were keeping very good
> compatibility across some kinds of drivers (it had it's problems, to be
> sure), they were trying the hardest because they recognized that the
> most important thing was to just have things work in the first place.
I honour they were _trying_, only it was not successful. I wrote drivers for
all noted versions above and can tell you: it is a _mess_.
> NOTE: I'm not endorsing their overall API convenience (driver or
> Win16/Win32), stability, suitability, merchantability, whatever, I'm
> just talking about drivers and their distribution model at the moment.
Ok, lets put it this way: they use a completely split up model of driver
maintenance to get the most out of the market (anybody can release anything at
anytime and any quality and interoperability), and therefore everything tends
to be severly broken and complex in administration. You have to draw the latest
drivers for your graphics card, scsi card, scanner, printer, USB equipment,
even monitor from the respective source (manufacturer), install it seperately
and pray it does not shoot your last driver installation from different
hardware component - which it does in a significant percentage. And if you
upgrade from (e.g.) win95 to win98, you will draw all drivers again and
completely reinstall everything.
To tell the pure truth: nobody cares about anything on w*indoze.
> > Reading between your lines, I can well see that you are most probably
> > talking about closed-source linux-drivers breaking with permanently
> > released new kernel revisions. But, in fact, this is the closed-source
> > phenomenon, and _not_ linux.
>
> No, though I don't object to closed-source in general per se. I hate it
> for myself and businesses I've worked for because I like to be able to
> fix/improve/whatever code, but I recognize that the majority of users
> out there would never touch code.
They _should_ not do that. And they _need_ not do that today. The distros
really got very far on the path to the real lusers, that don't know much and
don't want to learn anything. This is ok.
I mean have you had a look at the latest distros, I found it amazing how far
things have already come. You can install client systems under linux in 20% of
the time you would need for _any_ windows.
> My general feeling is that binary drivers are ok/should be supported well
> across versions since that is the thing you load in at boot/bring-system-
> up time. Having separate (and usually many) step(s) to getting a driver
> and having it load on your system is a major and I'm thinking artificial
> pain.
I have learned something over the recent years: I guess RMS pointed in the
right direction. I _don't_ think binary drivers are ok. I want to control my
environment, and don't let _anybody_ control it _for_ me. And if something goes
wrong, I have a look. And if I am too dumb, I can ask somebody who isn't. And
there may be a lot of those.
> In general my argument stems from the same basis that the kernel/user-level
> interface does: keeping interfaces stable and removing packaging/bundling
> requirements across major boundaries almost always yield a win somewhere.
Carl Sagan "The Demon Haunted World":
"If there is a chain of argument every link in the chain must work."
> In the case of MS and drivers, the win they have in convenience to end-users
> of all types, and the ability to mix and match drivers forward or backward
> up to some limitations in API revisions.
Ah, yes. Indeed I am one of those thinking that a driver should _work_, I do
not measure its quality on the number of versions available - and loadable in
my environment. If I have to this, the driver is _broken_.
But yes, you are right: 99% of all w-users obviously think internet is designed
for downloading the latest w-drivers, and it is a definitive must to have all
revisions to find one working.
> > I tend to believe we could just wait another two MS cycles to have even
> > the biggest MS-fans converted to kernel-hackers, only because of being
> > real fed up with the brilliant, long term driver design.
>
> Most people will never touch code or a compiler, and just want a simple
> obvious formula or even to have the system automagically do the Right
> Things for you. Even many programmers have limitations of curiousity or
> energy, and it isn't a bad thing to organize even core system things to
> be easy.
I talked about the developers, but even talking about users, I do believe that
...
> MS may be stupid/annoying in other ways, but they know this and have
> moved toward it, albeit sluggishly at times.
... it is not their ultimate goal to let MS control their lives. You think this
is over-estimation? They are already handing out electronic _passports_, sorry,
but in my understanding of democracy this is not done by commercial companies.
This is what a state is all about - knowing and identifying its citizens - and
no one _else_.
MS is not stupid. I won't tell you what it is though, find out yourself.
Regards,
Stephan
>> > We don't agree on any of these points. Scaling to a 16 way SMP pretty much
>> > ruins the source base, even when it is done by very careful people.
>>
>> I'd say that the normal current limit on SMP machines is 8 way.
>> But you're right, we don't agree. Time will tell who was right.
>> When I say I'm interested in 16 way scalability, I'm not talking about
>> SMP, so perhaps we're talking at slightly cross purposes.
>
> Well I do remember those Sequent Symmetry machines from university which
> scaled to 24 processors and more. If I remember correctly they ran 16x
> 386 and 8x 486 in a single box (under Dynix?)
Actually they'd scale to about 30 Pentiums. But then again, note that I said
normal and current. Our Symmetry boxes fit neither of those criteria ;-)
M.
On Thu, 6 Dec 2001, Rik van Riel wrote:
> On Wed, 5 Dec 2001, Davide Libenzi wrote:
> > On Thu, 6 Dec 2001, Rusty Russell wrote:
> >
> > > I'd love to say that I can solve this with RCU, but it's vastly non-trivial
> > > and I haven't got code, so I'm not going to say that. 8)
> >
> > Lockless algos could help if we're able to have "good" quiescent point
> > inside the kernel. Or better have a good quiescent infrastructure to
> > have lockless code to plug in.
>
> Machines get dragged down by _uncontended_ locks, simply
> due to cache line ping-pong effects.
Rik, i think you're confused about lockless algos.
It's not an rwlock where the reader has to dirty a cacheline in any case,
the reader simply does _not_ write any cache line accessing the
list/hash/tree or whatever you use.
These algo uses barries and all changes are done when the system walk
through a quiescent state by flushing a list-of-changes.
Drawback, you've to be able to tollerate stale data.
- Davide
In message <1007632244.24677.1.camel@forge>, > : Henning Schmiedehausen writes:
> On Wed, 2001-12-05 at 22:14, Martin J. Bligh wrote:
> > > We don't agree on any of these points. Scaling to a 16 way SMP pretty
> much
> > > ruins the source base, even when it is done by very careful people.
> >
> > I'd say that the normal current limit on SMP machines is 8 way.
> > But you're right, we don't agree. Time will tell who was right.
> > When I say I'm interested in 16 way scalability, I'm not talking about
> > SMP, so perhaps we're talking at slightly cross purposes.
>
> Well I do remember those Sequent Symmetry machines from university which
> scaled to 24 processors and more. If I remember correctly they ran 16x
> 386 and 8x 486 in a single box (under Dynix?)
>
> Wasn't too much interested in that then. I was to busy toying with my
> Amiga. ;-)
>
> Regards
> Henning
Actually, up to 30 cpus, mixing and matching pairs of 12 or 16 MHz 80386,
25 or 50 MHz 80486, or 60 MHz Pentiums on the same SMP bus (known as
the Symmetry 2000 series).
NUMA-Q stuff went to 64 processors - with quad building blocks (4
identical processors) where you could mix and match Pentium Pro, Xeon,
Pentium III quads at various clock rates.
The internals of the OS looked a lot like any standard OS, with a few
pieces of secret sauce (e.g. the read-copy-update stuff - see
sf.net/projects/lse, multiprocessor counters, etc.) Code complexity
was not orders of magnitude higher to support these high end machines
with near linear scalability. It had some areas that were more complex,
but you train your staff on the complexitities, and it becomes standard
practice. Just like Linux is enormously more complex than the first DOS
OS's, DYNIX/ptx is somewhat more complex than Linux. But is Linux already
so complex that no one can contribute? I don't think so. Could DOS
engineers contribute to Linux? I think they have - with some updated
training and knowledge about the additional complexities.
I really don't think Larry's fears can only be solved by another new
OS rewrite. In some cases, just awareness of how to use the next
level of complex technology is enough to evolve the programmer to the
next stage. It is happening all the time. Doesn't mean that a fresh
approach is bad, either. But the premise that engineers will never be
smart enough to program for high count SMP is rediculous. The level
of complexity just isn't that much higher than where we are today.
gerrit
On Thu, 6 Dec 2001, Davide Libenzi wrote:
> > Machines get dragged down by _uncontended_ locks, simply
> > due to cache line ping-pong effects.
>
> Rik, i think you're confused about lockless algos.
> It's not an rwlock where the reader has to dirty a cacheline in any case,
> the reader simply does _not_ write any cache line accessing the
> list/hash/tree or whatever you use.
Hmmm indeed, so the cache lines can be shared as long
as the data is mostly read-only. I think I see it now.
However, this would only work for data which is mostly
read-only, not for anything else...
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/
http://www.surriel.com/ http://distro.conectiva.com/
On Thu, 6 Dec 2001, Rik van Riel wrote:
> On Thu, 6 Dec 2001, Davide Libenzi wrote:
>
> > > Machines get dragged down by _uncontended_ locks, simply
> > > due to cache line ping-pong effects.
> >
> > Rik, i think you're confused about lockless algos.
> > It's not an rwlock where the reader has to dirty a cacheline in any case,
> > the reader simply does _not_ write any cache line accessing the
> > list/hash/tree or whatever you use.
>
> Hmmm indeed, so the cache lines can be shared as long
> as the data is mostly read-only. I think I see it now.
>
> However, this would only work for data which is mostly
> read-only, not for anything else...
yes of course, but in such case these methods could help solving cache
issues over traditional rwlocks.
- Davide
Guys,
I am the maintaner of SCI, the ccNUMA technology standard. I know
alot about this stuff, and have been involved with SCI since
1994. I work with it every day and the Dolphin guys on some huge
supercomputer accounts, like Los Alamos and Sandia Labs in NM.
I will tell you this from what I know.
A shared everything approach is a programmers dream come true,
but you can forget getting reasonable fault tolerance with it. The
shared memory zealots want everyone to believe ccNUMA is better
than sex, but it does not scale when compared to Shared-Nothing
programming models. There's also a lot of tough issues for dealing
with failed nodes, and how you recover when peoples memory is
all over the place across a nuch of machines.
SCI scales better in ccNUMA and all NUMA technoogies scale very
well when they are used with "Explicit Coherence" instead of
"Implicit Coherence" which is what you get with SMP systems.
Years of research by Dr. Justin Rattner at Intel's High
performance labs demonstrated that shared nothing models scaled
into the thousands of nodes, while all these shared everything
"Super SMP" approaches hit the wall at 64 processors generally.
SCI is the fastest shared nothing interface out there, and it also
can do ccNUMA. Sequent, Sun, DG and a host of other NUMA providers
use Dolphin's SCI technology and have for years. ccNUMA is useful
for applications that still assume a shared nothing approach but that
use the ccNUMA and NUMA capabilities for better optimization.
Forget trying to recreate the COMA architecture of Kendall-Square.
The name was truly descriptive of what happened in this architecture
when a node fails -- goes into a "COMA". This whole discussion I have
lived through before and you will find that ccNUMA is virtually
unimplementable on most general purpose OSs. And yes, there are
a lot of products and software out there, but when you look under
the cover (like ServerNet) you discover their coherence models
for the most part relay on push/pull explicit coherence models.
My 2 cents.
Jeff
On Thu, Dec 06, 2001 at 12:09:32AM -0800, David S. Miller wrote:
> From: Larry McVoy <[email protected]>
> Date: Thu, 6 Dec 2001 00:02:16 -0800
>
> Err, Dave, that's *exactly* the point of the ccCluster stuff. You get
> all that seperation for every data structure for free. Think about
> it a bit. Aren't you going to feel a little bit stupid if you do all
> this work, one object at a time, and someone can come along and do the
> whole OS in one swoop? Yeah, I'm spouting crap, it isn't that easy,
> but it is much easier than the route you are taking.
>
> How does ccClusters avoid the file system namespace locking issues?
> How do all the OS nodes see a consistent FS tree?
>
> All the talk is about the "magic filesystem, thread it as much as you
> want" and I'm telling you that is the fundamental problem, the
> filesystem name space locking.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Thu, Dec 06, 2001 at 11:27:31AM -0700, Jeff V. Merkey wrote:
And also, if you download the SCI drivers in my area, and order
some SCI adapters from Dolphin in Albquerque, NM, you can set up
a ccNUMA system with standard PCs. Dolphin has 66Mhz versions (and
a 133Mhz coming in the future) that run at almost a gigabyte per
second node-2-node over a parallel fabric. The cross-sectional
SCI fabric bandwidth scales at (O)(2N) as you add nodes.
If you want to play around with ccNUMA with Standard PCs, these
cards are relatively inepxensive, and allow you to setup some
powerful cc/SMP systems with explicit coherence. The full
ccNUMA boxes from DG are expensive, however. That way, instead
of everyone talking about it, you guys could get some cool
hardware and experiment with some of your rather forward
looking and interesting ideas.
:-)
Jeff
>
>
> Guys,
>
> I am the maintaner of SCI, the ccNUMA technology standard. I know
> alot about this stuff, and have been involved with SCI since
> 1994. I work with it every day and the Dolphin guys on some huge
> supercomputer accounts, like Los Alamos and Sandia Labs in NM.
> I will tell you this from what I know.
>
> A shared everything approach is a programmers dream come true,
> but you can forget getting reasonable fault tolerance with it. The
> shared memory zealots want everyone to believe ccNUMA is better
> than sex, but it does not scale when compared to Shared-Nothing
> programming models. There's also a lot of tough issues for dealing
> with failed nodes, and how you recover when peoples memory is
> all over the place across a nuch of machines.
>
> SCI scales better in ccNUMA and all NUMA technoogies scale very
> well when they are used with "Explicit Coherence" instead of
> "Implicit Coherence" which is what you get with SMP systems.
> Years of research by Dr. Justin Rattner at Intel's High
> performance labs demonstrated that shared nothing models scaled
> into the thousands of nodes, while all these shared everything
> "Super SMP" approaches hit the wall at 64 processors generally.
>
> SCI is the fastest shared nothing interface out there, and it also
> can do ccNUMA. Sequent, Sun, DG and a host of other NUMA providers
> use Dolphin's SCI technology and have for years. ccNUMA is useful
> for applications that still assume a shared nothing approach but that
> use the ccNUMA and NUMA capabilities for better optimization.
>
> Forget trying to recreate the COMA architecture of Kendall-Square.
> The name was truly descriptive of what happened in this architecture
> when a node fails -- goes into a "COMA". This whole discussion I have
> lived through before and you will find that ccNUMA is virtually
> unimplementable on most general purpose OSs. And yes, there are
> a lot of products and software out there, but when you look under
> the cover (like ServerNet) you discover their coherence models
> for the most part relay on push/pull explicit coherence models.
>
> My 2 cents.
>
> Jeff
>
>
>
> On Thu, Dec 06, 2001 at 12:09:32AM -0800, David S. Miller wrote:
> > From: Larry McVoy <[email protected]>
> > Date: Thu, 6 Dec 2001 00:02:16 -0800
> >
> > Err, Dave, that's *exactly* the point of the ccCluster stuff. You get
> > all that seperation for every data structure for free. Think about
> > it a bit. Aren't you going to feel a little bit stupid if you do all
> > this work, one object at a time, and someone can come along and do the
> > whole OS in one swoop? Yeah, I'm spouting crap, it isn't that easy,
> > but it is much easier than the route you are taking.
> >
> > How does ccClusters avoid the file system namespace locking issues?
> > How do all the OS nodes see a consistent FS tree?
> >
> > All the talk is about the "magic filesystem, thread it as much as you
> > want" and I'm telling you that is the fundamental problem, the
> > filesystem name space locking.
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> If you want to play around with ccNUMA with Standard PCs, these
> cards are relatively inepxensive, and allow you to setup some
> powerful cc/SMP systems with explicit coherence. The full
> ccNUMA boxes from DG are expensive, however. That way, instead
> of everyone talking about it, you guys could get some cool
> hardware and experiment with some of your rather forward
> looking and interesting ideas.
Or you could just book some time on the 16x NUMA-Q that's publicly
available in the OSDL for free, and running Linux already.
Martin.
On Thu, Dec 06, 2001 at 10:36:57AM -0800, Martin J. Bligh wrote:
> > If you want to play around with ccNUMA with Standard PCs, these
> > cards are relatively inepxensive, and allow you to setup some
> > powerful cc/SMP systems with explicit coherence. The full
> > ccNUMA boxes from DG are expensive, however. That way, instead
> > of everyone talking about it, you guys could get some cool
> > hardware and experiment with some of your rather forward
> > looking and interesting ideas.
>
> Or you could just book some time on the 16x NUMA-Q that's publicly
> available in the OSDL for free, and running Linux already.
>
> Martin.
Could even have some shipped off to you guys if you to play
around with them. :-)
Jeff
On Thu, 6 Dec 2001, Jeff V. Merkey wrote:
> Guys,
>
> I am the maintaner of SCI, the ccNUMA technology standard. I know
> alot about this stuff, and have been involved with SCI since
> 1994. I work with it every day and the Dolphin guys on some huge
> supercomputer accounts, like Los Alamos and Sandia Labs in NM.
> I will tell you this from what I know.
>
> A shared everything approach is a programmers dream come true,
> but you can forget getting reasonable fault tolerance with it. The
> shared memory zealots want everyone to believe ccNUMA is better
> than sex, but it does not scale when compared to Shared-Nothing
> programming models. There's also a lot of tough issues for dealing
> with failed nodes, and how you recover when peoples memory is
> all over the place across a nuch of machines.
If you can afford rewriting/rearchitecting your application it's pretty
clear that the share-nothing model is the winner one.
But if you can rewrite your application using a share-nothing model you
don't need any fancy clustering architectures since beowulf like cluster
would work for you and they'll give you a great scalability over the
number of nodes.
The problem arises when you've to choose between a new architecture
( share nothing ) using conventional clusters and a
share-all/keep-all-your-application-as-is one.
The share nothing is cheap and gives you a very nice scalability, these
are the two mayor pros for this solution.
On the other side you've a vary bad scalability and a very expensive
solution.
But you've to consider :
1) rewriting is risky
2) good developers to rewrite your stuff are expensive ( $100K up to $150K
in my area )
These are the reason that let me think that conventional SMP machines will
have a future in addition to my believing that technology will help a lot
to improve scalability.
- Davide
On Thu, Dec 06, 2001 at 11:11:27AM -0800, Davide Libenzi wrote:
> On Thu, 6 Dec 2001, Jeff V. Merkey wrote:
>
> > Guys,
> >
> > I am the maintaner of SCI, the ccNUMA technology standard. I know
> > alot about this stuff, and have been involved with SCI since
> > 1994. I work with it every day and the Dolphin guys on some huge
> > supercomputer accounts, like Los Alamos and Sandia Labs in NM.
> > I will tell you this from what I know.
> >
> > A shared everything approach is a programmers dream come true,
> > but you can forget getting reasonable fault tolerance with it. The
> > shared memory zealots want everyone to believe ccNUMA is better
> > than sex, but it does not scale when compared to Shared-Nothing
> > programming models. There's also a lot of tough issues for dealing
> > with failed nodes, and how you recover when peoples memory is
> > all over the place across a nuch of machines.
>
> If you can afford rewriting/rearchitecting your application it's pretty
> clear that the share-nothing model is the winner one.
> But if you can rewrite your application using a share-nothing model you
> don't need any fancy clustering architectures since beowulf like cluster
> would work for you and they'll give you a great scalability over the
> number of nodes.
> The problem arises when you've to choose between a new architecture
> ( share nothing ) using conventional clusters and a
> share-all/keep-all-your-application-as-is one.
> The share nothing is cheap and gives you a very nice scalability, these
> are the two mayor pros for this solution.
> On the other side you've a vary bad scalability and a very expensive
> solution.
> But you've to consider :
>
> 1) rewriting is risky
>
> 2) good developers to rewrite your stuff are expensive ( $100K up to $150K
> in my area )
>
> These are the reason that let me think that conventional SMP machines will
> have a future in addition to my believing that technology will help a lot
> to improve scalability.
>
There's a way through the fog. Shared Nothing with explicit coherence.
You are correct, applications need to be rewritten to exploit it. It
is possible to run existing SMP apps process -> process across nodes
with ccNUMA, and this works, but you don't get the scaling as shared
nothing.
Jeff
Jeff
>
>
>
> - Davide
>
>
>
On December 6, 2001 09:02 am, Larry McVoy wrote:
> On Wed, Dec 05, 2001 at 11:56:17PM -0800, David S. Miller wrote:
> > These lockless algorithms, instructions like CAS, DCAS, "infinite
> > consensus number", it's all crap. You have to seperate out the access
> > areas amongst different cpus so they don't collide, and none of these
> > mechanisms do that.
>
> Err, Dave, that's *exactly* the point of the ccCluster stuff. You get
> all that seperation for every data structure for free. Think about
> it a bit. Aren't you going to feel a little bit stupid if you do all
> this work, one object at a time, and someone can come along and do the
> whole OS in one swoop? Yeah, I'm spouting crap, it isn't that easy,
> but it is much easier than the route you are taking.
What I don't get after looking at your material, is how you intend to do the
locking. Sharing a mmap across OS instances is fine, but how do processes on
the two different OS's avoid stepping on each other when they access the same
file?
--
Daniel
On Thu, Dec 06, 2001 at 08:42:05PM +0100, Daniel Phillips wrote:
> On December 6, 2001 09:02 am, Larry McVoy wrote:
> > On Wed, Dec 05, 2001 at 11:56:17PM -0800, David S. Miller wrote:
> > > These lockless algorithms, instructions like CAS, DCAS, "infinite
> > > consensus number", it's all crap. You have to seperate out the access
> > > areas amongst different cpus so they don't collide, and none of these
> > > mechanisms do that.
> >
> > Err, Dave, that's *exactly* the point of the ccCluster stuff. You get
> > all that seperation for every data structure for free. Think about
> > it a bit. Aren't you going to feel a little bit stupid if you do all
> > this work, one object at a time, and someone can come along and do the
> > whole OS in one swoop? Yeah, I'm spouting crap, it isn't that easy,
> > but it is much easier than the route you are taking.
>
> What I don't get after looking at your material, is how you intend to do the
> locking. Sharing a mmap across OS instances is fine, but how do processes on
> the two different OS's avoid stepping on each other when they access the same
> file?
Exactly the same way they would if they were two processes on a traditional
SMP OS.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Thu, Dec 06, 2001 at 09:10:51PM +0100, Daniel Phillips wrote:
> On December 6, 2001 08:53 pm, Larry McVoy wrote:
> > On Thu, Dec 06, 2001 at 08:42:05PM +0100, Daniel Phillips wrote:
> > > On December 6, 2001 09:02 am, Larry McVoy wrote:
> > > > On Wed, Dec 05, 2001 at 11:56:17PM -0800, David S. Miller wrote:
> > > > > These lockless algorithms, instructions like CAS, DCAS, "infinite
> > > > > consensus number", it's all crap. You have to seperate out the access
> > > > > areas amongst different cpus so they don't collide, and none of these
> > > > > mechanisms do that.
> > > >
> > > > Err, Dave, that's *exactly* the point of the ccCluster stuff. You get
> > > > all that seperation for every data structure for free. Think about
> > > > it a bit. Aren't you going to feel a little bit stupid if you do all
> > > > this work, one object at a time, and someone can come along and do the
> > > > whole OS in one swoop? Yeah, I'm spouting crap, it isn't that easy,
> > > > but it is much easier than the route you are taking.
> > >
> > > What I don't get after looking at your material, is how you intend to do the
> > > locking. Sharing a mmap across OS instances is fine, but how do processes on
> > > the two different OS's avoid stepping on each other when they access the same
> > > file?
> >
> > Exactly the same way they would if they were two processes on a traditional
> > SMP OS.
>
> They'd use locks internal to the VFS and fs, plus Posix-style locks and
> assorted other userland serializers, which don't come for free. As davem
> said, you'll have to present a coherent namespace, that's just one of the
> annoying details. So far you haven't said much about how such things are
> going to be handled.
Huh? Of course not, they'd use mutexes in a mmap-ed file, which uses
the hardware's coherency. No locks in the vfs or fs, that's all done
in the mmap/page fault path for sure, but once the data is mapped you
aren't dealing with the file system at all.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On December 6, 2001 08:53 pm, Larry McVoy wrote:
> On Thu, Dec 06, 2001 at 08:42:05PM +0100, Daniel Phillips wrote:
> > On December 6, 2001 09:02 am, Larry McVoy wrote:
> > > On Wed, Dec 05, 2001 at 11:56:17PM -0800, David S. Miller wrote:
> > > > These lockless algorithms, instructions like CAS, DCAS, "infinite
> > > > consensus number", it's all crap. You have to seperate out the access
> > > > areas amongst different cpus so they don't collide, and none of these
> > > > mechanisms do that.
> > >
> > > Err, Dave, that's *exactly* the point of the ccCluster stuff. You get
> > > all that seperation for every data structure for free. Think about
> > > it a bit. Aren't you going to feel a little bit stupid if you do all
> > > this work, one object at a time, and someone can come along and do the
> > > whole OS in one swoop? Yeah, I'm spouting crap, it isn't that easy,
> > > but it is much easier than the route you are taking.
> >
> > What I don't get after looking at your material, is how you intend to do the
> > locking. Sharing a mmap across OS instances is fine, but how do processes on
> > the two different OS's avoid stepping on each other when they access the same
> > file?
>
> Exactly the same way they would if they were two processes on a traditional
> SMP OS.
They'd use locks internal to the VFS and fs, plus Posix-style locks and
assorted other userland serializers, which don't come for free. As davem
said, you'll have to present a coherent namespace, that's just one of the
annoying details. So far you haven't said much about how such things are
going to be handled.
--
Daniel
From: Larry McVoy <[email protected]>
Date: Thu, 6 Dec 2001 12:10:04 -0800
Huh? Of course not, they'd use mutexes in a mmap-ed file, which uses
the hardware's coherency. No locks in the vfs or fs, that's all done
in the mmap/page fault path for sure, but once the data is mapped you
aren't dealing with the file system at all.
We're talking about two things.
Once the data is MMAP'd, sure things are coherent just like on any
other SMP, for the user.
But HOW DID YOU GET THERE? That is the question you are avoiding.
How do I look up "/etc/passwd" in the filesystem on a ccCluster?
How does OS image 1 see the same "/etc/passwd" as OS image 2?
If you aren't getting rid of this locking, what is the point?
That is what we are trying to talk about.
On Thu, Dec 06, 2001 at 12:15:54PM -0800, David S. Miller wrote:
> From: Larry McVoy <[email protected]>
> Date: Thu, 6 Dec 2001 12:10:04 -0800
>
> Huh? Of course not, they'd use mutexes in a mmap-ed file, which uses
> the hardware's coherency. No locks in the vfs or fs, that's all done
> in the mmap/page fault path for sure, but once the data is mapped you
> aren't dealing with the file system at all.
>
> We're talking about two things.
>
> Once the data is MMAP'd, sure things are coherent just like on any
> other SMP, for the user.
>
> But HOW DID YOU GET THERE? That is the question you are avoiding.
> How do I look up "/etc/passwd" in the filesystem on a ccCluster?
> How does OS image 1 see the same "/etc/passwd" as OS image 2?
>
> If you aren't getting rid of this locking, what is the point?
> That is what we are trying to talk about.
The points are:
a) you have to thread the entire kernel, every data structure which is a
problem. Scheduler, networking, device drivers, everything. That's
thousands of locks and uncountable bugs, not to mention the impact on
uniprocessor performance.
b) I have to thread a file system.
So I'm not saying that I'll thread less in the file system (actually I am,
but let's skip that for now and assume I have to do everything you have
to do). All I'm saying is that I don't have to worry about the rest of
the kernel which is a huge savings.
You tell me - which is easier, multithreading the networking stack to
64 way SMP or running 64 distinct networking stacks?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Hi!
> > cases. Yet changes go into the system for 8 way and 16 way performance.
> > That's a mistake.
> >
> > I'd be ecstatic if the hackers limited themselves to what was commonly
> > available, that is essentially what I'm arguing for.
>
> We need a *little* bit of foresight. If 4 ways are common now, and 8 ways
> and 16 ways are available, then in a year or two 8 ways (at least) will be
> commonplace. On the other hand 128 cpu machines are a way off, and
> I'd agree we shouldn't spend too much time on them right now.
90% developers have more than one machine to play with... So maybe there's
time for mosix to be merged...?
Then we can create memnet (netdevice over shared memory), and Larry's dream
can come true...
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Hi!
> > Premise 3: it is far easier to take a bunch of operating system images
> > and make them share the parts they need to share (i.e., the page
> > cache), than to take a single image and pry it apart so that it
> > runs well on N processors.
>
> Of course it's easier. But it seems like you're left with much more work to
> reiterate in each application you write to run on this thing. Do you want to
> do the work once in the kernel, or repeatedly in each application? I'd say
> it's a damned sight easier to make an application work well on one big
> machine than on a cluster.
With mosix, it is exactly as hard. You just run it. I can do that today.
Larry's ideas should look same w.r.t. user.. Or maybe you'll see 128x
boot messages, but that's it.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
[email protected] (Stephan von Krawczynski) wrote on 06.12.01 in <[email protected]>:
> I have learned something over the recent years: I guess RMS pointed in the
> right direction. I _don't_ think binary drivers are ok. I want to control my
> environment, and don't let _anybody_ control it _for_ me. And if something
> goes wrong, I have a look. And if I am too dumb, I can ask somebody who
> isn't. And there may be a lot of those.
And it is absolutely amazing what you *can* do, if you have the soure,
what you never expected to be able to do, but because you *do* have the
source, you just *have* to look at the problem area ... and poof! there's
something that certainly doesn't look right, maybe if you just try to
change this little bit ...
And thus you learn something new which you wouldn't even have tried with
closed source.
It's not only this. I remember when I first tried to get PPP to work - no,
wait, back then it was SLIP. (Slightly before Linux 1.0, I think.) It just
wouldn't work, and I had no idea why. Obviously I was doing something
wrong, but what?
So I looked at the relevant kernel part. Still rather unclear, but the
data has to go through *here* ... now suppose I insert a printk there, and
one there, and then reboot and retry and watch syslog ... aha! (Well,
actually, it took me several passes, and I don't remember what the problem
turned out to be except it wasn't a kernel bug.)
MfG Kai
> Then we can create memnet (netdevice over shared memory), and Larry's dream
> can come true...
I'm hoping, but my dreams do not include shared memory over a network.
That's just way too slow. It's been done a pile of times, every time
people say that the caching will make it fast enough and those people
are wrong every time.
People who think DSM is a good idea are the same people who think a
millisecond is OK for a cache miss (current cache miss times are well
under .0002 milliseconds).
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Larry McVoy <[email protected]>
Date: Thu, 6 Dec 2001 12:21:16 -0800
You tell me - which is easier, multithreading the networking stack to
64 way SMP or running 64 distinct networking stacks?
We've done %90 of the "other stuff" already, why waste the work?
We've done the networking, we've done the scheduler, and the
networking/block drivers are there too.
I was actually pretty happy with how easy (relatively) the networking
was to thread nicely.
The point is, you have to make a captivating argument for ccClusters,
what does it buy us now that we've done a lot of the work you are
telling us it will save?
----- Original Message -----
From: "Larry McVoy" <[email protected]>
To: "Pavel Machek" <[email protected]>
Cc: "Martin J. Bligh" <[email protected]>; "Larry McVoy"
<[email protected]>; "Stephan von Krawczynski" <[email protected]>; "Horst von
Brand" <[email protected]>; "lkml"
<[email protected]>
Sent: Thursday, December 06, 2001 3:50 PM
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
> > Then we can create memnet (netdevice over shared memory), and Larry's
dream
> > can come true...
>
> I'm hoping, but my dreams do not include shared memory over a network.
He's talking about net over shared memory, not shared memory over net.
On December 6, 2001 09:21 pm, Larry McVoy wrote:
> On Thu, Dec 06, 2001 at 12:15:54PM -0800, David S. Miller wrote:
> > If you aren't getting rid of this locking, what is the point?
> > That is what we are trying to talk about.
>
> The points are:
>
> a) you have to thread the entire kernel, every data structure which is a
> problem. Scheduler, networking, device drivers, everything. That's
> thousands of locks and uncountable bugs, not to mention the impact on
> uniprocessor performance.
>
> b) I have to thread a file system.
OK, this is your central point. It's a little more than just a mmap, no?
We're pressing you on your specific ideas on how to handle the 'peripheral'
details.
--
Daniel
On Thu, Dec 06, 2001 at 01:02:02PM -0800, David S. Miller wrote:
> We've done %90 of the "other stuff" already, why waste the work?
> We've done the networking, we've done the scheduler, and the
> networking/block drivers are there too.
The scheduler doesn't scale too well...
> I was actually pretty happy with how easy (relatively) the networking
> was to thread nicely.
>
> The point is, you have to make a captivating argument for ccClusters,
> what does it buy us now that we've done a lot of the work you are
> telling us it will save?
The most captivating arguments are along the following lines:
- scales perfectly across NUMA fabrics: there are a number of
upcoming architechures (hammer, power4, others) where the
latency costs on remote memory are significantly higher. By
making the entire kernel local, we'll see optimal performance
for local operations, with good performance for the remote
actions (the ccClusterFS should be very low overhead).
- opens up a number of possibilities in terms of serviceability:
if a chunk of the system is taken offline, only the one kernel
group has to go away. Useful in containing failures.
- lower overhead for SMP systems. We can use UP kernels local
to each CPU. Should make kernel compiles faster. ;-)
At the very least it is well worth investigating. Bootstrapping the
ccCluster work shouldn't take more than a week or so, which will let
us attach some hard numbers to the kind of impact it has on purely
cpu local tasks.
-ben
--
Fish.
> problem. Scheduler, networking, device drivers, everything. That's
> thousands of locks and uncountable bugs, not to mention the impact on
> uniprocessor performance.
Most of my block drivers in Linux have one lock. The block queuing layer
has one lock which is often the same lock.
> You tell me - which is easier, multithreading the networking stack to
> 64 way SMP or running 64 distinct networking stacks?
Which is easier. Managing 64 routers or managing 1 router ?
> the hardware's coherency. No locks in the vfs or fs, that's all done
> in the mmap/page fault path for sure, but once the data is mapped you
> aren't dealing with the file system at all.
ftruncate
On Thu, Dec 06, 2001 at 10:38:14PM +0000, Alan Cox wrote:
> > the hardware's coherency. No locks in the vfs or fs, that's all done
> > in the mmap/page fault path for sure, but once the data is mapped you
> > aren't dealing with the file system at all.
>
> ftruncate
I'm not sure what the point is. We've already agreed that the multiple OS
instances will have synchonization to do for file operations, ftruncate
being one of them.
I thought the question was how N user processes do locking and my answer
stands: exactly like they'd do it on an SMP, with mutex_enter()/exit() on
some portion of the mapped file. The mapped file is just a chunk of cache
coherent memory.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Thu, Dec 06, 2001 at 10:37:18PM +0000, Alan Cox wrote:
> > problem. Scheduler, networking, device drivers, everything. That's
> > thousands of locks and uncountable bugs, not to mention the impact on
> > uniprocessor performance.
>
> Most of my block drivers in Linux have one lock. The block queuing layer
> has one lock which is often the same lock.
Hooray! That's great and that's the way I'd like to keep it. Do you think
you can do that on a 64 way SMP? Not much chance, right?
> > You tell me - which is easier, multithreading the networking stack to
> > 64 way SMP or running 64 distinct networking stacks?
>
> Which is easier. Managing 64 routers or managing 1 router ?
That's a red herring, there are not 64 routers in either picture, there
are 64 ethernet interfaces in both pictures. So let me rephrase the
question: given 64 ethernets, 64 CPUs, on one machine, what's easier,
1 multithreaded networking stack or 64 independent networking stacks?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> > Most of my block drivers in Linux have one lock. The block queuing layer
> > has one lock which is often the same lock.
>
> Hooray! That's great and that's the way I'd like to keep it. Do you think
> you can do that on a 64 way SMP? Not much chance, right?
It wouldn't be a big problem to keep it that way on the well designed
hardware. The badly designed stuff (here Im thinking the NCR5380 I debugged
today since its fresh in my mind) I'd probably want 2 locks, one for queue
locking, one for request management.
> > Which is easier. Managing 64 routers or managing 1 router ?
> That's a red herring, there are not 64 routers in either picture, there
> are 64 ethernet interfaces in both pictures. So let me rephrase the
> question: given 64 ethernets, 64 CPUs, on one machine, what's easier,
> 1 multithreaded networking stack or 64 independent networking stacks?
I think you miss the point. If I have to program the system as 64
independant stacks from the app level I'm going to go slowly mad
> > ftruncate
>
> I'm not sure what the point is. We've already agreed that the multiple OS
> instances will have synchonization to do for file operations, ftruncate
> being one of them.
>
> I thought the question was how N user processes do locking and my answer
> stands: exactly like they'd do it on an SMP, with mutex_enter()/exit() on
> some portion of the mapped file. The mapped file is just a chunk of cache
ftrucate invalidates that memory under you, on all nodes. That means you do
end up needing cross node locking and your file operations simply won't lie
down and scale cleanly
On Thu, 6 Dec 2001, Larry McVoy wrote:
> I'm not sure what the point is. We've already agreed that the multiple OS
> instances will have synchonization to do for file operations, ftruncate
> being one of them.
That's nice. But said operation involves serious wanking with metadata
and _that_ would better have exclusion with write(2) and some warranties
about pageouts.
You can do lockless get_block() and truncate(). And it will be a hive
of races always ready to break out. We used to try that and it was
a fscking mess of unbelievable proportions - worse than that in full-blown
rename() support.
> On Thu, Dec 06, 2001 at 01:02:02PM -0800, David S. Miller wrote:
> > We've done %90 of the "other stuff" already, why waste the work?
> > We've done the networking, we've done the scheduler, and the
> > networking/block drivers are there too.
>
> The scheduler doesn't scale too well...
Understatement. However retrofitting a real scheduler doesn't break the
scalability of the system IMHO.
From: Benjamin LaHaise <[email protected]>
Date: Thu, 6 Dec 2001 17:27:08 -0500
- lower overhead for SMP systems. We can use UP kernels local
to each CPU. Should make kernel compiles faster. ;-)
Actually, this isn't what is being proposed. Something like
"4 cpu" SMP kernels.
At the very least it is well worth investigating. Bootstrapping the
ccCluster work shouldn't take more than a week or so, which will let
us attach some hard numbers to the kind of impact it has on purely
cpu local tasks.
I think it is worth considering too, but I don't know if a week
estimate is sane or not :-)
On Thu, Dec 06, 2001 at 10:55:37PM +0000, Alan Cox wrote:
> > > ftruncate
> >
> > I'm not sure what the point is. We've already agreed that the multiple OS
> > instances will have synchonization to do for file operations, ftruncate
> > being one of them.
> >
> > I thought the question was how N user processes do locking and my answer
> > stands: exactly like they'd do it on an SMP, with mutex_enter()/exit() on
> > some portion of the mapped file. The mapped file is just a chunk of cache
>
> ftrucate invalidates that memory under you, on all nodes. That means you do
> end up needing cross node locking and your file operations simply won't lie
> down and scale cleanly
Wait a second, you're missing something. If you are going to make a single
OS image work on a 64 way (or whatever) SMP, you have all of these issues,
right? I'm not introducing additional locking problems with the design.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Larry McVoy <[email protected]>
Date: Thu, 6 Dec 2001 15:15:04 -0800
Wait a second, you're missing something. If you are going to make a single
OS image work on a 64 way (or whatever) SMP, you have all of these issues,
right? I'm not introducing additional locking problems with the design.
And you're not taking any of them away from the VFS layer. That is
where all the real fundamental current scaling problems are in the
Linux kernel.
That is why I spent so much timing describing the filesystem name path
locking problem, those are the major hurdles we have to go over.
Networking is old hat, people have done work to improve the scheduler
scaling, it's just these hand full of VFS layer issues that are
dogging us.
So my point is, if you're going to promote some "locking complexity"
advantage, I don't think that's where a ccCluster even makes a dent in
the viability spectrum.
Where it does have advantages are for things like offlining node
clusters in a NUMA system. High availability et al.
On Thu, Dec 06, 2001 at 03:08:47PM -0800, David S. Miller wrote:
> From: Benjamin LaHaise <[email protected]>
> Date: Thu, 6 Dec 2001 17:27:08 -0500
>
> - lower overhead for SMP systems. We can use UP kernels local
> to each CPU. Should make kernel compiles faster. ;-)
>
> Actually, this isn't what is being proposed. Something like
> "4 cpu" SMP kernels.
I personally want to cluster small SMP OS images because I don't want to
do the process migration crap anywhere except at exec time, it simplifies
a lot. So I need a second order load balancing term that I can get
from 2 or 4 way smp nodes. If you are willing to process migration to
handle load imbalances, then you could do uniprocessor only. I think
the complexity tradeoff is in favor of the small SMP OS clusters, we
already have them. Process migration is a rats nest.
> At the very least it is well worth investigating. Bootstrapping the
> ccCluster work shouldn't take more than a week or so, which will let
> us attach some hard numbers to the kind of impact it has on purely
> cpu local tasks.
>
> I think it is worth considering too, but I don't know if a week
> estimate is sane or not :-)
Yeah, it's possible that you could get something booting in a week but I
think it's a bit harder than that too. One idea that was kicked around
was to use Jeff's UML work and "boot" multiple UML's on top of a virtual
SMP. You get things to work there and then do a "port" to real hardware.
Kind of a cool idea if you ask me.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Thu, Dec 06, 2001 at 03:19:45PM -0800, David S. Miller wrote:
> From: Larry McVoy <[email protected]>
> Date: Thu, 6 Dec 2001 15:15:04 -0800
>
> Wait a second, you're missing something. If you are going to make a single
> OS image work on a 64 way (or whatever) SMP, you have all of these issues,
> right? I'm not introducing additional locking problems with the design.
>
> And you're not taking any of them away from the VFS layer. That is
> where all the real fundamental current scaling problems are in the
> Linux kernel.
Sure I am, but I haven't told you how. Suppose that your current
VFS can handle N cpus byt you have N*M cpus. Take a look at
http://bitmover.com/lm/papers/bigfoot.ps and imagine applying that
technique here. To summarize what I'm proposing, the locking problems are
because too many cpus want at the same data structures at the same time.
One way to solve that is to fine grain thread the data structures, and
that is a pain in the ass. Another way to solve it may be to "stripe"
the file "servers". Imagine each CPU serving up a part of a bigfoot
file system. I've just reduced the scaling problems by a factor of M.
And, the ccCluster approach moves most of the nasty locking
problems into a ccCluster specific filesystem rather than buggering up
the generic paths.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
also some applications (i.e. databases) are such that nobody has really
been able to rewrite them into the shared nothing model (although oracle
has attempted it, from what I hear it has problems)
David Lang
On Thu, 6 Dec 2001,
Jeff V. Merkey wrote:
> Date: Thu, 6 Dec 2001 12:34:48 -0700
> From: Jeff V. Merkey <[email protected]>
> To: Davide Libenzi <[email protected]>
> Cc: David S. Miller <[email protected]>, [email protected],
> [email protected], Martin J. Bligh <[email protected]>,
> Rik vav Riel <[email protected]>, [email protected],
> Alan Cox <[email protected]>, [email protected],
> lkml <[email protected]>, [email protected]
> Subject: Re: SMP/cc Cluster description
>
> On Thu, Dec 06, 2001 at 11:11:27AM -0800, Davide Libenzi wrote:
> > On Thu, 6 Dec 2001, Jeff V. Merkey wrote:
> >
> > > Guys,
> > >
> > > I am the maintaner of SCI, the ccNUMA technology standard. I know
> > > alot about this stuff, and have been involved with SCI since
> > > 1994. I work with it every day and the Dolphin guys on some huge
> > > supercomputer accounts, like Los Alamos and Sandia Labs in NM.
> > > I will tell you this from what I know.
> > >
> > > A shared everything approach is a programmers dream come true,
> > > but you can forget getting reasonable fault tolerance with it. The
> > > shared memory zealots want everyone to believe ccNUMA is better
> > > than sex, but it does not scale when compared to Shared-Nothing
> > > programming models. There's also a lot of tough issues for dealing
> > > with failed nodes, and how you recover when peoples memory is
> > > all over the place across a nuch of machines.
> >
> > If you can afford rewriting/rearchitecting your application it's pretty
> > clear that the share-nothing model is the winner one.
> > But if you can rewrite your application using a share-nothing model you
> > don't need any fancy clustering architectures since beowulf like cluster
> > would work for you and they'll give you a great scalability over the
> > number of nodes.
> > The problem arises when you've to choose between a new architecture
> > ( share nothing ) using conventional clusters and a
> > share-all/keep-all-your-application-as-is one.
> > The share nothing is cheap and gives you a very nice scalability, these
> > are the two mayor pros for this solution.
> > On the other side you've a vary bad scalability and a very expensive
> > solution.
> > But you've to consider :
> >
> > 1) rewriting is risky
> >
> > 2) good developers to rewrite your stuff are expensive ( $100K up to $150K
> > in my area )
> >
> > These are the reason that let me think that conventional SMP machines will
> > have a future in addition to my believing that technology will help a lot
> > to improve scalability.
> >
>
> There's a way through the fog. Shared Nothing with explicit coherence.
> You are correct, applications need to be rewritten to exploit it. It
> is possible to run existing SMP apps process -> process across nodes
> with ccNUMA, and this works, but you don't get the scaling as shared
> nothing.
>
> Jeff
>
> Jeff
>
>
> >
> >
> >
> > - Davide
> >
> >
> >
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
From: Larry McVoy <[email protected]>
Date: Thu, 6 Dec 2001 15:32:57 -0800
And, the ccCluster approach moves most of the nasty locking
problems into a ccCluster specific filesystem rather than buggering
up the generic paths.
I still don't believe this, you are still going to need a lot of
generic VFS threading. This is why myself and others keep talking
about ftruncate(), namei() et al.
If I look up "/etc" on bigfoot, littletoe, or whatever fancy name you
want to call the filesystem setup, SOMETHING has to control access to
the path name components (ie. there has to be locking).
You are not "N*M scaling" lookups on filesystem path components.
In fact, bigfoot sounds like it would make path name traversal more
heavyweight than it is now because these stripes need to coordinate
with each other somehow.
You keep saying "it'll be in the filesystem" over and over. And the
point I'm trying to make is that this is not going to do away with the
fundamental problems. They are still there with a ccCluster, they are
still there with bigfoot, and you are not getting N*M scaling on
filesystem name component walks.
On Thu, Dec 06, 2001 at 03:47:35PM -0800, David S. Miller wrote:
> From: Larry McVoy <[email protected]>
> Date: Thu, 6 Dec 2001 15:32:57 -0800
>
> And, the ccCluster approach moves most of the nasty locking
> problems into a ccCluster specific filesystem rather than buggering
> up the generic paths.
>
> I still don't believe this, you are still going to need a lot of
> generic VFS threading. This is why myself and others keep talking
> about ftruncate(), namei() et al.
>
> If I look up "/etc" on bigfoot, littletoe, or whatever fancy name you
> want to call the filesystem setup, SOMETHING has to control access to
> the path name components (ie. there has to be locking).
Sure, but you are assuming one file system, which is global. That's
certainly one way to do it, but not the only way, and not the way that
I've suggested. I'm not sure if you remember this, but I always advocated
partially shared and partially private. /, for example, is private.
In fact, so is /proc, /tmp, and /dev. There are /gproc, /gtmp, and /gdev
which are in the global namespace and do for the cluster what /<xxx>
does for a regular machine.
We can go around and around on this and the end result will be that I will
have narrowed the locking problem down to the point that only the processes
which are actually using the resource have to participate in the locking.
In a traditional SMP OS, all processes have to participate.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Stephan von Krawczynski <[email protected]> wrote:
> [email protected] wrote:
>
> > Hmm. There is little fundamentally incompatible with having splits in
> > the core kernel and sets of drivers, and getting most of what you want
> > here.
>
> There is. You double the administrational work. Most updates are
> performed because you want the latest bugfixes. If you get more bugfixes
> than you intended - lucky.
> Currently you draw the latest kernel-tree (or the latest _you_ like to
> use), use your old .config and it works out - as long as you do not use
> closed-source drivers.
And if something breaks out of it - unlucky?
I again think your statement that "...and it works out" is naive.
See below for more.
> If you split things up, you draw _two_ archives, compile and install
> both.
Actually, that's something of my point.
I think the control to install one or the other, certainly for the
systems I want to be most reliable (firewalls/other servers), is of
high benefit, hence my proposing this in the first place.
All these things tied together means they all stand or fall together
for most people, it's only people like many on this list or other
kernel hackers that end up being able to do anything about it.
There are many important reasons why those in charge of so many
production computing environments around the world try to, when
faced with some broken component, want to *only* change that one
and not all or even a large subset of them. It is risky.
Even if you want to upgrade wholesale, then the ability to rev
backward something that doesn't work in the new set, but you know
works in the old form, is very valuable.
> Oops. Then you have a severe problem in understanding how linux _should_
> be worked with. Obviously you can go and buy some distribution and it
> may work out pretty well. But being a serious administrator you _will_
> do kernel updates apart from the distro (sooner or later). If there are
> drivers in a newer kernel release, that do not work any longer, compared
> to an older release, you should say so. Best place would be the listed
> maintainer. Because if it doesn't do the job for your configuration any
> longer, chances are high others were hit, too.
> The maintainer cannot know, if you do not tell him.
> I guess we have the mutual agreement here, that maintained drivers
> should get better not worse through the revisions. This means
> configurations once successful are not meant to break later on.
> This basically is what I intended to say with "being happy" :-)
OK, you're telling me that people "should fix it", but my point, and
one I haven't heard any contradiction to yet, is that often enough
people don't.
So, the response has been to hold the drivers close in so when
interfaces change/a bug is found, they can all be changed together.
I think there is some merit to that when you find a bug, but
otherwise this becomes a statistical shooting gallery.
My reasoning? Each time driver code is touched, in particular without
testing done afterward, there is some probability of another bug
being induced.
> > I don't object to producing well-tested full sets of driver source that
> > go with kernel versions, I just don't want them to be tied if I have
> > a need to pull something apart (a driver from one version and from
> > another are the only ones that run stably), which frankly happens too
> > often for my taste. Even if it didn't I'd still want it as much as
> > possibly for the fall-back options it provides.
>
> Can you give a striking example for this? (old driver ok, new driver
> broken, both included in kernel releases)
Not really striking per se, but 2 off of the top of my head I've had to
deal with:
-- integrated 10/100 MBit Enet network in a SiS735 motherboard,
effectively SiS900 chipset. Worked fine in later RH 7.1
kernel (2.4.3-rhat), but not with 7.2 kernel(s) (2.4.7-rhat &
2.4.9-rhat).
-- drivers for the Lucent pcmcia Orinoco series of cards work/
don't work across different revisions from 2.4.0-ish -> present.
Yes, I've reported various problems with other bits before, and
debugged some of my own, submitted patches, etc.
You can make the argument that some of them are young drivers/etc., but
that just proves my point that I want the control, not just for me, but
for others to easily load across drivers across different kernel
versions.
My issue with the current process is that it's developer-centric, and
though I've been able to work past these problems, none of the non-
kernel hackers I've known would generally care to.
In fact, several others who I know with similar hardware just gave up
when I told them they had to install a kernel/hacked driver patches.
> Ok, lets put it this way: they use a completely split up model of
> driver maintenance to get the most out of the market (anybody can
...
> hardware component - which it does in a significant percentage. And if
> you upgrade from (e.g.) win95 to win98, you will draw all drivers again
> and completely reinstall everything.
>
> To tell the pure truth: nobody cares about anything on w*indoze.
I can't believe you just said that. Maybe nobody *on this list*, but
in general, this makes it hard to take you at all seriously.
...
> > My general feeling is that binary drivers are ok/should be supported well
> > across versions since that is the thing you load in at boot/bring-system-
> > up time. Having separate (and usually many) step(s) to getting a driver
> > and having it load on your system is a major and I'm thinking artificial
> > pain.
>
> I have learned something over the recent years: I guess RMS pointed in the
> right direction. I _don't_ think binary drivers are ok. I want to control
> my environment, and don't let _anybody_ control it _for_ me. And if
> something goes wrong, I have a look. And if I am too dumb, I can ask
> somebody who isn't. And there may be a lot of those.
Huh? I didn't ask you to use them.
I'm just pointing out that binary drivers are the end-product (you don't
"insmod driver.c"), so it's kind of hard to just hand-wave them out of
existence. Not everyone has a fully self-hosted system with compilers
just sitting around to do your bidding.
Also, the model you present above is only suitable for a small fraction
of users. It is irrelevant to most users if the code is fixable. If
it doesn't work as is and there is no easy other thing they can try,
it is effectively broken.
--
Erich Stefan Boleyn <[email protected]> http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"
Keith Owens <[email protected]> wrote:
> On Wed, 05 Dec 2001 11:40:07 -0800,
> [email protected] wrote:
> >Build a framework for an external "drivers" source/binary tree that can be
> >(via a single command) rebuilt for a different Linux kernel version. This
> >is arguably a Linux distribution thing.
>
> kbuild 2.5. Already done.
Cool. Thanks for the good work guys!
[dang, now I have to go off and learn all about kbuild 2.5...]
--
Erich Stefan Boleyn <[email protected]> http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"
From: Larry McVoy <[email protected]>
Date: Thu, 6 Dec 2001 16:17:44 -0800
There are /gproc, /gtmp, and /gdev
which are in the global namespace and do for the cluster what /<xxx>
does for a regular machine.
And /getc, which is where my /getc/passwd is going to be.
We can go around and around on this and the end result will be that
I will have narrowed the locking problem down to the point that
only the processes which are actually using the resource have to
participate in the locking. In a traditional SMP OS, all processes
have to participate.
We can split up name spaces today with Al Viro's namespace
infrastructure.
But frankly for the cases where scalability matters, like a http
server, they are all going at the same files in a global file
space.
I still think ccClusters don't solve any new problems in the
locking space. "I get rid of it by putting people on different
filesystems" is not an answer which is unique to ccClusters, current
systems can do that.
On Thu, Dec 06, 2001 at 10:54:03PM +0000, Alan Cox wrote:
> > That's a red herring, there are not 64 routers in either picture, there
> > are 64 ethernet interfaces in both pictures. So let me rephrase the
> > question: given 64 ethernets, 64 CPUs, on one machine, what's easier,
> > 1 multithreaded networking stack or 64 independent networking stacks?
>
> I think you miss the point. If I have to program the system as 64
> independant stacks from the app level I'm going to go slowly mad
Well, that depends. Suppose the application is a webserver. Not your
simple static page web server, that one is on a shared nothing cluster
already. It's a webserver that has a big honkin' database, with lots
of data being updated all time, the classic sort of thing that a big
SMP can handle but a cluster could not. Fair enough?
Now imagine that the system is a collection of little OS images, each
with their own file system, etc. Except /home/httpd is mounted on
a globally shared file system. Each os image has its own set of
interfaces, one or more, and its own http server. Which updates
data in /home/httpd.
Can you see that this is a non-issue? For this application, the ccCluster
model works great. The data is all in a shared file system, nice and
coherent, the apps don't actually know there is another OS banging on the
data, it all just works.
Wait, I'll admit this means that the apps have to be thread safe, but that's
true for the traditional SMP as well.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> I still think ccClusters don't solve any new problems in the
> locking space. "I get rid of it by putting people on different
> filesystems" is not an answer which is unique to ccClusters, current
> systems can do that.
If your point is that it doesn't solve any locking problems in the filesystem,
I'll almost grant you that. Not quite because ccClusters open the door to
different ways of solving problems that a traditional SMP doesn't.
However, where it wins big is on everything else. Please explain to me how
you are going to make a scheduler that works for 64 CPUS that doesn't suck?
And explain to me how that will perform as well as N different scheduler
queues which I get for free. Just as an example. We can then go down the
path of every device driver, the networking stack, the process interfaces,
signals, etc.
There is a hell of a lot of threading that has to go on to get to
64 cpus and it screws the heck out of the uniprocessor performance.
I think you want to prove how studly you are at threading, David,
but what you are really doing is proving that you are buried in the
trees and can't see the forest. Pop up 50,000 feet and think about it.
Let's go have some beers and talk about it off line.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On December 06, 2001 05:26, Larry McVoy wrote: > Yeah, it's possible that you
could get something booting in a week but I > think it's a bit harder than
that too. One idea that was kicked around > was to use Jeff's UML work and
"boot" multiple UML's on top of a virtual > SMP. You get things to work there
and then do a "port" to real hardware. > Kind of a cool idea if you ask me.
Point me in the right direction. After reading over your slides and SMP paper
(still have the labs.pdf on my queue), it seemed to me that you could easily
simulate what you want with lots of UML's talking to each other. I think you
would need to create some kind of device that uses a file or a shared memory
segment as the cluster's memory. Actually, I think that (shared memory) is
how Jeff had intended on implementing SMP in UML anyway. At this point I
don't think UML supports SMP though I know of at least one person who was
attempting it.
Once said device would implemented, you could start working on the unique
challenges ccClusters present. I guess this would be what you consider
"bootstrapping", although I don't really know what that would entail at this
point. Then you just need some bored college student :) to hack it out.
I've been negligent in following this mammoth link...cluebat me if you
mentioned it somewhere upthread.
-- akk~
From: Larry McVoy <[email protected]>
Date: Thu, 6 Dec 2001 18:34:51 -0800
The data is all in a shared file system, nice and coherent, the
apps don't actually know there is another OS banging on the data,
it all just works.
Larry1: "One way to get the ccCluster scalability is by un-globalizing
the filesystem"
Larry2: "Let me tell you about this great application of ccClusters,
it involves using a shared file system. It all just works."
Either you're going to replicate everyone's content or you're going to
use a shared filesystem. In one case you'll go fast but have the same
locking problems as a traditional SMP, in the other case you'll go
slow because you'll be replicating all the time.
Which is it :-)
What I suppose is coming up is some example application that really
doesn't need a shared filesystem, which I bet will be a quite obscure
one or at least obscure enough that it can't justify ccCluster all on
it's own.
On Thu, Dec 06, 2001 at 03:16:13PM -0800, David Lang wrote:
> also some applications (i.e. databases) are such that nobody has really
> been able to rewrite them into the shared nothing model (although oracle
> has attempted it, from what I hear it has problems)
>
> David Lang
OPS (Oracle Parallel Server) is shared nothing.
Jeff
>
> On Thu, 6 Dec 2001,
> Jeff V. Merkey wrote:
>
> > Date: Thu, 6 Dec 2001 12:34:48 -0700
> > From: Jeff V. Merkey <[email protected]>
> > To: Davide Libenzi <[email protected]>
> > Cc: David S. Miller <[email protected]>, [email protected],
> > [email protected], Martin J. Bligh <[email protected]>,
> > Rik vav Riel <[email protected]>, [email protected],
> > Alan Cox <[email protected]>, [email protected],
> > lkml <[email protected]>, [email protected]
> > Subject: Re: SMP/cc Cluster description
> >
> > On Thu, Dec 06, 2001 at 11:11:27AM -0800, Davide Libenzi wrote:
> > > On Thu, 6 Dec 2001, Jeff V. Merkey wrote:
> > >
> > > > Guys,
> > > >
> > > > I am the maintaner of SCI, the ccNUMA technology standard. I know
> > > > alot about this stuff, and have been involved with SCI since
> > > > 1994. I work with it every day and the Dolphin guys on some huge
> > > > supercomputer accounts, like Los Alamos and Sandia Labs in NM.
> > > > I will tell you this from what I know.
> > > >
> > > > A shared everything approach is a programmers dream come true,
> > > > but you can forget getting reasonable fault tolerance with it. The
> > > > shared memory zealots want everyone to believe ccNUMA is better
> > > > than sex, but it does not scale when compared to Shared-Nothing
> > > > programming models. There's also a lot of tough issues for dealing
> > > > with failed nodes, and how you recover when peoples memory is
> > > > all over the place across a nuch of machines.
> > >
> > > If you can afford rewriting/rearchitecting your application it's pretty
> > > clear that the share-nothing model is the winner one.
> > > But if you can rewrite your application using a share-nothing model you
> > > don't need any fancy clustering architectures since beowulf like cluster
> > > would work for you and they'll give you a great scalability over the
> > > number of nodes.
> > > The problem arises when you've to choose between a new architecture
> > > ( share nothing ) using conventional clusters and a
> > > share-all/keep-all-your-application-as-is one.
> > > The share nothing is cheap and gives you a very nice scalability, these
> > > are the two mayor pros for this solution.
> > > On the other side you've a vary bad scalability and a very expensive
> > > solution.
> > > But you've to consider :
> > >
> > > 1) rewriting is risky
> > >
> > > 2) good developers to rewrite your stuff are expensive ( $100K up to $150K
> > > in my area )
> > >
> > > These are the reason that let me think that conventional SMP machines will
> > > have a future in addition to my believing that technology will help a lot
> > > to improve scalability.
> > >
> >
> > There's a way through the fog. Shared Nothing with explicit coherence.
> > You are correct, applications need to be rewritten to exploit it. It
> > is possible to run existing SMP apps process -> process across nodes
> > with ccNUMA, and this works, but you don't get the scaling as shared
> > nothing.
> >
> > Jeff
> >
> > Jeff
> >
> >
> > >
> > >
> > >
> > > - Davide
> > >
> > >
> > >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
From: Larry McVoy <[email protected]>
Date: Thu, 6 Dec 2001 18:43:27 -0800
However, where it wins big is on everything else. Please explain to me how
you are going to make a scheduler that works for 64 CPUS that doesn't suck?
What stops me from basically doing a scheduler which ends up doing
what ccCluster does, groups of 4 cpu nodes? Absolutely nothing of
course. How is ccCluster unique in this regard then?
The scheduler is a mess right now only because Linus hates making
major changes to it.
We can then go down the path of ... the networking stack ...
signals ...
Done and done. Device drivers are mostly done, and what was your
other category... oh process interfaces, those are done too.
In fact character devices are the only ugly area in 2.5.x, and
who really cares if TTYs scale to 64 cpus :-) But this will get
mostly done anyways to kill off the global kernel lock completely.
There is a hell of a lot of threading that has to go on to get to
64 cpus and it screws the heck out of the uniprocessor performance.
Not with CONFIG_SMP turned off. None of the interesting SMP overhead
hits the uniprocessor case.
Why do you keep talking about uniprocessor being screwed? This is why
we have CONFIG_SMP, to nop the bulk of it out.
I think you want to prove how studly you are at threading, David,
No, frankly I don't.
What I want is for you to show what is really unique and new about
ccClusters and what incredible doors are openned up by it. So far I
have been shown ONE, and that is the high availability aspect.
To me, it is far from the holy grail you portray it to be.
Let's go have some beers and talk about it off line.
How about posting some compelling arguments online first? :-)
It all boils down to the same shit currently. "ccClusters lets you do
this", and this is leading to "but we can do that already today".
Franks a lot,
David S. Miller
[email protected]
> However, where it wins big is on everything else. Please explain to me how
> you are going to make a scheduler that works for 64 CPUS that doesn't suck?
Modifying the current scheduler to use multiple scheduler queues is not
particularly hard. It's been done already. See http://lse.sourceforge.net or
Davide's work.
Please explain how you're going to load balance the scheduler queues across
your system in a way that doesn't suck.
> And explain to me how that will perform as well as N different scheduler
> queues which I get for free. Just as an example.
I dispute that the work that you have to do up front to get ccClusters to work
is "free". It's free after you've done the work already. You may think it's
*easier*, but that's different.
So we're going to do our work one step at a time in many small chunks, and
you're going to do it all at once in one big chunk (and not end up with as
cohesive a system out of the end of it) .... not necessarily a huge difference
in overall effort (though I know you think it is, the logic you're using to demonstrate
your point is fallacious).
Your objection to the "more traditional" way of scaling things (which seems
to be based around what you call the locking cliff) seems to be that it greatly
increases the complexity of the OS. I would say that splitting the system into
multiple kernels then trying to glue it all back together also greatly increases
the complexity of the OS. Oh, and the complexity of the applications that run
on it too if they have to worry about seperate bits of the FS for each instance
of the sub-OS.
Martin.
[email protected] said:
> it seemed to me that you could easily simulate what you want with
> lots of UML's talking to each other. I think you would need to create
> some kind of device that uses a file or a shared memory segment as
> the cluster's memory.
Yeah, there is already support for mapping in a random file and using that
as UML memory, so that would be used for the cluster interconnect for any
cluster emulations you wanted to run with UML.
> Actually, I think that (shared memory) is how
> Jeff had intended on implementing SMP in UML anyway.
No, at least not any shared memory that's not already there. UML uses a
host process for each UML process, and UML kernel data and text are
shared between all these host processes. SMP just means having more than
one host process runnable at a time. Each runnable process on the host
is a virtual processor.
> At this point I
> don't think UML supports SMP though I know of at least one person who
> was attempting it.
It doesn't yet. Someone is (or was), but I haven't heard a peep from him in
at least a month. So this is starting to look like another little project
which got quickly going but just as quickly abandoned.
Jeff
On Thu, 6 Dec 2001, Jeff V. Merkey wrote:
> On Thu, Dec 06, 2001 at 03:16:13PM -0800, David Lang wrote:
> > also some applications (i.e. databases) are such that nobody has really
> > been able to rewrite them into the shared nothing model (although oracle
> > has attempted it, from what I hear it has problems)
> >
> > David Lang
>
> OPS (Oracle Parallel Server) is shared nothing.
>
correct, and from what I have been hearing from my local database folks
it's significantly less efficiant then a large SMP machine (up intil you
hit the point where you just can't buy a machine big enough :-)
I'm interested in hearing more if you have had better experiances with it.
David Lang
On Thu, Dec 06, 2001 at 08:23:36PM -0800, David Lang wrote:
> On Thu, 6 Dec 2001, Jeff V. Merkey wrote:
>
> > On Thu, Dec 06, 2001 at 03:16:13PM -0800, David Lang wrote:
> > > also some applications (i.e. databases) are such that nobody has really
> > > been able to rewrite them into the shared nothing model (although oracle
> > > has attempted it, from what I hear it has problems)
> > >
> > > David Lang
> >
> > OPS (Oracle Parallel Server) is shared nothing.
> >
>
> correct, and from what I have been hearing from my local database folks
> it's significantly less efficiant then a large SMP machine (up intil you
> hit the point where you just can't buy a machine big enough :-)
>
> I'm interested in hearing more if you have had better experiances with it.
>
> David Lang
I worked with the OPS code years back. It came from DEC originally
and is a very old technology. It grew out of disk pinging, where
the messages would be pinged across a shared disk. Some cool features,
but I never saw it scale well beyond 16 nodes. SQL queries are a lot
like HTML requests, so similair approaches work well with them. The code
was not so good, or readable.
Databases are "structured data" applications and present unique problems,
but most data stored on planet earth is "unstructured data", word files,
emails, spreadsheets, etc. The problem of scaling involves different
approaches for these two categories, and the unstructured data problem
is easily solvable and scalable.
I ported Oracle to NetWare SMP in 1995 with Van Okamura (a very fun
project), and SMP scaling was much better. In those days, shared
SCSI was what was around. Writing an SOSD layer for Oracle
was a lot of fun. Working on OPS was also fun, but the code
was not in such good shape. Their method of dealing with
deadlocks was not to. Their approach assumed deadlocks were
infrequent events (which they were) and they used a mathod that would
detect them after the fact rather than before and deal with them
then.
I saw some impressive numbers for TPC-C come out of OPS 4 way clusters,
but more nodes than this (except the N-cube implementation) seemed to
not do so well.
Jeff
On Thu, 2001-12-06 at 22:30, Daniel Phillips wrote:
> On December 6, 2001 09:21 pm, Larry McVoy wrote:
> > On Thu, Dec 06, 2001 at 12:15:54PM -0800, David S. Miller wrote:
> > > If you aren't getting rid of this locking, what is the point?
> > > That is what we are trying to talk about.
> >
> > The points are:
> >
> > a) you have to thread the entire kernel, every data structure which is a
> > problem. Scheduler, networking, device drivers, everything. That's
> > thousands of locks and uncountable bugs, not to mention the impact on
> > uniprocessor performance.
> >
> > b) I have to thread a file system.
>
> OK, this is your central point. It's a little more than just a mmap, no?
> We're pressing you on your specific ideas on how to handle the 'peripheral'
> details.
How about creating one node as "master" and write a "cluster network
filesystem" which uses shared memory as its "network layer".
Then boot all other nodes diskless from these cluster network
filesystems.
You can still have shared mmap (which I believe is Larry's toy point)
between the nodes but you avoid all of the filesystem locking issues,
because you're going over (a hopefully superfast) memory network
filesystem.
Or go iSCSI and attach a network device to each of the cluster node. Or
go 802.1q, attach a virtual network device to each cluster node, pull
all of them out over GigE and let some Cisco outside sort these out
again. :-)
What I don't like about the approach is the fact that all nodes should
share the same file system. One (at least IMHO) does not want this for
at least /etc. The "all nodes the same FS" works fine for your number
cruncher clusters where every node runs more or less the same software.
It does not work for cluster boxes like the Starfire or 390. There you
want to boot totally different OS images on the nodes. No sense in
implementing a "threaded file system" that is not used.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
On Thu, 06 Dec 2001 16:37:36 -0800
[email protected] wrote:
> > If you split things up, you draw _two_ archives, compile and install
> > both.
>
> Actually, that's something of my point.
>
> I think the control to install one or the other, certainly for the
> systems I want to be most reliable (firewalls/other servers), is of
> high benefit, hence my proposing this in the first place.
Only in an environment with little evolution going on. But whats the use of
updating anyway, then?
Another thing that really jumps right into my face from your arguments:
you say "administrator needs to have a way to change core kernel, without
changing any drivers, and is not able to read and understand the source of both
core and drivers, so it is best for him to change as little as possible."
But wait: how does _he_ know then, that a standard update (kernel _and_
drivers, as currently) will not work. I mean, you trust the work of some people
building one set of core and drivers, but do not trust the same people to give
you a newer set of core and drivers? And all this, although you are not able or
willing to have a look at the _sources_ to really make sure.
I am definitely not fond of the proposed MS idea, that anybody can administrate
any server, he only needs to know how to perform mouse-clicks. If you can't
drive a car, you should probably not take the seat at the drivers side.
> All these things tied together means they all stand or fall together
> for most people, it's only people like many on this list or other
> kernel hackers that end up being able to do anything about it.
What is wrong with this idea? If you are joe-user, then take your preferred
distro and live with it (quite well nowadays). If you are an experienced user,
then tune your setup according to your needs. If you are really good at it,
then get yourself a job as an administrator for servers people work and rely on
- and read sources. And last, if you have some ideas, go ahead and write source
and give it to the public to verify and tune its quality. And if your real good
it may well be, that god will take your code and you suddenly become one of the
kernel-driver-maintainers. This is a pretty simple and straight-forward world.
And there is noone coming round the corner and tell you: "btw, we changed the
world just yesterday, everything is easy, only you should throw away your old
code."
> There are many important reasons why those in charge of so many
> production computing environments around the world try to, when
> faced with some broken component, want to *only* change that one
> and not all or even a large subset of them. It is risky.
I really don't get it: if your system works, why upgrade? if your system does
not work: why did you give it to the people in the first place?
> Even if you want to upgrade wholesale, then the ability to rev
> backward something that doesn't work in the new set, but you know
> works in the old form, is very valuable.
Ever heard of lilo? It can boot multiple kernel-images. And guess what: they
are all finding their corresponding modules if you do it right.
> OK, you're telling me that people "should fix it", but my point, and
> one I haven't heard any contradiction to yet, is that often enough
> people don't.
Interesting. I in fact never heard of anyone complaining about a driver (that
is maintained) that does not get fixed if you tell the people about a problem.
If they don't have the hardware to test, simply give it to them.
> My reasoning? Each time driver code is touched, in particular without
> testing done afterward, there is some probability of another bug
> being induced.
There is always another bug. This is fundamental in software development. This
is why it is really important to talk about bugs you came across. If you do not
use new code, no code will ever become better.
> > Can you give a striking example for this? (old driver ok, new driver
> > broken, both included in kernel releases)
>
> Not really striking per se, but 2 off of the top of my head I've had to
> deal with:
>
> -- integrated 10/100 MBit Enet network in a SiS735 motherboard,
> effectively SiS900 chipset. Worked fine in later RH 7.1
> kernel (2.4.3-rhat), but not with 7.2 kernel(s) (2.4.7-rhat &
> 2.4.9-rhat).
Okay, this is my personal tip for administrators: do not use distro-kernels, do
use linus-kernels, and do not update to very fresh ones. If you wanna be
brilliant, read LKML to know whats going on. This is no hint for joe-user.
> -- drivers for the Lucent pcmcia Orinoco series of cards work/
> don't work across different revisions from 2.4.0-ish -> present.
Haha. This is a real good example for real life not matching my ideas, perhaps
david hinds and linus should find some solution for it. If you want to have a
working set of lucent pcmcia you need to draw the latest pcmcia-package and
tools from david and install them on top of standard kernel. This has worked
since the civil war, believe me, I use it everyday with _lots_ of different
kernels and hardware setups. Only annoying part: it is not part of the kernel.
Therefore it is pretty interesting to hear you complaining about a _split away_
drivers' issue. :-)
> My issue with the current process is that it's developer-centric, and
> though I've been able to work past these problems, none of the non-
> kernel hackers I've known would generally care to.
Tell you what, this happened about 2 months ago:
I build a nice and simple hardware for a desktop. It contained Asus Board,
PIII-500, 512MB, ATI graphics card, IDE-10G-hd and ATAPI cdrom, keyboard,
PS/2-mouse and soundblaster . It didn't look all that non-standard.
I tried to install:
win95-orig:
install fails right away, win95 cannot CD-boot
win98:
doesn't install with 512 MB, install fails.
win ME:
doesn't even get recognised by the BIOS as bootable CD
win 2K:
hangs in hardware detection cycle, I switched it off after 3 hours of continous
hd seeking at about 50%.
SuSE 7.2 (Linux):
install takes about 15 minutes, everything works.
What do we learn of this: win scales everybody down to joe-user-level, and you
cannot do a thing against it. I guess it is definitely not developer-centric.
> > To tell the pure truth: nobody cares about anything on w*indoze.
>
> I can't believe you just said that. Maybe nobody *on this list*, but
> in general, this makes it hard to take you at all seriously.
I have seen to many things on windows to come to a different conclusion.
> Also, the model you present above is only suitable for a small fraction
> of users. It is irrelevant to most users if the code is fixable. If
> it doesn't work as is and there is no easy other thing they can try,
> it is effectively broken.
Again, you are talking about joe-user here. If joe-user has a problem, he
should call up the distro-hotline he bought, they will help him with
installation problems (mostly for free). He does not need a compiler or
anything.
And the experienced guy (or girl, hey there are some :-) will have a large
number of options available, including the source and his (her) brain.
Regards,
Stephan
> How about creating one node as "master" and write a "cluster network
> filesystem" which uses shared memory as its "network layer".
Right.
> Then boot all other nodes diskless from these cluster network
> filesystems.
Wrong. Give each node its own private boot fs. Then mount /data.
> You can still have shared mmap (which I believe is Larry's toy point)
> between the nodes but you avoid all of the filesystem locking issues,
> because you're going over (a hopefully superfast) memory network
> filesystem.
There is no network, unless you consider the memory interconnect a
network (I think the hardware guys would raise their eyebrows at
that name).
> What I don't like about the approach is the fact that all nodes should
> share the same file system. One (at least IMHO) does not want this for
> at least /etc.
Read through my other postings, I said that things are private by
default.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
I'm taking mercy on people and trimming down the cc: list ...
>> What I don't like about the approach is the fact that all nodes should
>> share the same file system. One (at least IMHO) does not want this for
>> at least /etc.
>
> Read through my other postings, I said that things are private by
> default.
So if I understand you correctly, you're saying you have a private /etc for
each instance of the sub-OS. Doesn't this make management of the system
a complete pig? And require modifying many user level tools?
M.
On Fri, Dec 07, 2001 at 08:44:03AM -0800, Martin J. Bligh wrote:
> I'm taking mercy on people and trimming down the cc: list ...
>
> >> What I don't like about the approach is the fact that all nodes should
> >> share the same file system. One (at least IMHO) does not want this for
> >> at least /etc.
> >
> > Read through my other postings, I said that things are private by
> > default.
>
> So if I understand you correctly, you're saying you have a private /etc for
> each instance of the sub-OS. Doesn't this make management of the system
> a complete pig? And require modifying many user level tools?
My pay job is developing a distributed source management system which works
by replication. We already have users who put all the etc files in it and
manage them that way. Works great. It's like rdist except it never screws
up and it has merging.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> My pay job is developing a distributed source management system which works
> by replication. We already have users who put all the etc files in it and
> manage them that way. Works great. It's like rdist except it never screws
> up and it has merging.
So would that mean I would need bitkeeper installed in order to change my
password?
And IIRC, bitkeeper is not free either?
M.
On Mon, Dec 03, 2001 at 02:20:38PM +0100, Daniel Phillips wrote:
> You're just supporting the point of view that Linus has been espousing, and
> I personally support: Linux is engineered at a micro level[1] but evolves
> on its own at a macro level.
If this becomes true, then Linux fails. If the coreLinux designers did
not "get" the UNIX design and understand what was good about Plan9, then
Linux would look like IRIX without quality control. And the engineer
formerly known as Linus has admitted as much in past .e.g. with the
comment about UNIX being about "Desgin with a capital D".
> I'll get really worried if Linus wakes up one day and decides that from now
> on he's going to properly engineer every aspect of the Linux kernel. The
> same way I'd feel if Linux got taken over by a committee.
I'm at a loss here. I state that an emphasis on design has been critical
to Linux and you respond that it would be bad if Linus wanted to
personally engineer every aspect of the Linux kernel.
In the english language, the word "design" does not have the same
semantics as "control every detail".
Anyways, enough.
>
> --
> Daniel
>
> [1] In places. All those little warts and occasional pools of sewage are
> clearly not 'engineered'.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Fri, Dec 07, 2001 at 10:04:11AM -0800, Martin J. Bligh wrote:
> > My pay job is developing a distributed source management system which works
> > by replication. We already have users who put all the etc files in it and
> > manage them that way. Works great. It's like rdist except it never screws
> > up and it has merging.
>
> So would that mean I would need bitkeeper installed in order to change my
> password?
No, that's just one way to solve the problem. Another way would be to have
a master/slave relationship between the replicas sort of like CVS. In fact,
you could use CVS.
> And IIRC, bitkeeper is not free either?
Actually it is for this purpose. You can either do open logging (probably
not what you want) or run it in single user mode which doesn't log, you
just lose the audit trail (all checkins look like they are made by root).
If I could figure out a way to allow the use of BK for /etc with out any
restrictions at all, and at the same time prevent people from just putting
all their source in /etc and shutting down our commercial revenue, I'd
do it in a heartbeat. I'd *love it* if when I did an upgrade from Red Hat,
the config files were part of a BK repository and I just did a pull/merge
to join my local changes with whatever they've done. That would be a huge
step in making sys admin a lot less problematic. But this is more than a
bit off topic...
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
>> So would that mean I would need bitkeeper installed in order to change my
>> password?
>
> No, that's just one way to solve the problem. Another way would be to have
> a master/slave relationship between the replicas sort of like CVS. In fact,
> you could use CVS.
I'm not sure that's any less vomitworthy.
Keeping things simple that users and/or sysadmins have to deal with is a
Good Thing (tm). I'd have the complexity in the kernel, where complexity
is pushed to the kernel developers, thanks.
>> And IIRC, bitkeeper is not free either?
>
> (... some slighty twisted concept of free snipped.)
>
> But this is more than a bit off topic...
No it's not that far off topic, my point is that you're shifting the complexity
problems to other areas (eg. system mangement / the application level /
filesystems / scheduler load balancing) rather than solving them.
Martin.
On Fri, Dec 07, 2001 at 10:42:00AM -0800, Martin J. Bligh wrote:
> >> So would that mean I would need bitkeeper installed in order to change my
> >> password?
> >
> > No, that's just one way to solve the problem. Another way would be to have
> > a master/slave relationship between the replicas sort of like CVS. In fact,
> > you could use CVS.
>
> I'm not sure that's any less vomitworthy.
You're right, it's so much better to manage all machines independently
so that they can get out of sync with each other.
Did you even consider that this is virtually identical to the problem
that a network of workstations or servers has? Did it occur to you that
people have solved this problem in many different ways? Or did you just
want to piss into the wind and enjoy the spray?
> Keeping things simple that users and/or sysadmins have to deal with is a
> Good Thing (tm). I'd have the complexity in the kernel, where complexity
> is pushed to the kernel developers, thanks.
Yeah, that's what I want, my password file management in the kernel.
Brilliant. Why didn't I think of that?
> >> And IIRC, bitkeeper is not free either?
> >
> > (... some slighty twisted concept of free snipped.)
> >
> > But this is more than a bit off topic...
>
> No it's not that far off topic, my point is that you're shifting the complexity
> problems to other areas (eg. system mangement / the application level /
> filesystems / scheduler load balancing) rather than solving them.
Whoops, you are so right, in order to work on OS scaling I'd better solve
password file management or the OS ideas are meaningless. Uh huh. I'll
get right on that, thanks for setting me straight here.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> My pay job is developing a distributed source management system which works
> by replication. We already have users who put all the etc files in it and
> manage them that way. Works great. It's like rdist except it never screws
> up and it has merging.
I'm just curious, what about security? Is this done in clear-text?
Sounds dangerous to put /etc/shadow, for example, in clear-text on the
cable.
Sorry for getting off-topic.
Regards,
Daniel
--
Daniel Bergman
Phone: 08 - 55064278
Mobile: 08 - 6311430
Fax: 08 - 59827056
Email: [email protected]
On Fri, Dec 07, 2001 at 08:00:32PM +0100, Daniel Bergman wrote:
> > My pay job is developing a distributed source management system which works
> > by replication. We already have users who put all the etc files in it and
> > manage them that way. Works great. It's like rdist except it never screws
> > up and it has merging.
>
> I'm just curious, what about security? Is this done in clear-text?
> Sounds dangerous to put /etc/shadow, for example, in clear-text on the
> cable.
BitKeeper can, and typically does, use ssh as a transport.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> You're right, it's so much better to manage all machines independently
> so that they can get out of sync with each other.
No it's much better to just have one machine running one instance of
the OS so that it can't get out of sync with itself.
>> Keeping things simple that users and/or sysadmins have to deal with is a
>> Good Thing (tm). I'd have the complexity in the kernel, where complexity
>> is pushed to the kernel developers, thanks.
>
> Yeah, that's what I want, my password file management in the kernel.
> Brilliant. Why didn't I think of that?
No, I want my password file management to be in a one file for the whole
machine. Where it is now. Without requiring syncronisation. If we put the
complexity in the kernel to make the system scale running one OS we
don't have the problem that you're creating at all.
>> No it's not that far off topic, my point is that you're shifting the complexity
>> problems to other areas (eg. system mangement / the application level /
>> filesystems / scheduler load balancing) rather than solving them.
>
> Whoops, you are so right, in order to work on OS scaling I'd better solve
> password file management or the OS ideas are meaningless. Uh huh. I'll
> get right on that, thanks for setting me straight here.
If you don't chop the OS up into multiple instances, you don't have these
problems. If you create the problems, I expect you to solve them.
You're not making the system as a whole scale, you're just pushing the
problems out somewhere else.
Martin.
Hi!
> > My pay job is developing a distributed source management system which works
> > by replication. We already have users who put all the etc files in it and
> > manage them that way. Works great. It's like rdist except it never screws
> > up and it has merging.
>
> I'm just curious, what about security? Is this done in clear-text?
> Sounds dangerous to put /etc/shadow, for example, in clear-text on the
> cable.
This is going over System Area Network. You don't encrypt your PCI, either.
--
"I do not steal MS software. It is not worth it."
-- Pavel Kankovsky
On Tue, Dec 04, 2001 at 09:07:14PM -0800, M. Edward Borasky wrote:
> I don't see how this is a win for me. And it is a win for IBM only if it
I think what you don't seem to realize is that most developers don't
develop because they think it's good for you, or anyone else for that
matter. Every developer has his own motivation, but I doubt that there
are a great majority of them that do it just to please others.
We don't do it for the "greater good", we do it because "it fixes this bug
that keeps hard locking my kernel whenever I play track 2 of the new cd
that came out", or "I guess nobody has written a driver for my new
seti@home-on-pci card processing board, looks like if I want it to work,
I'll have to write one".
I'm not trying to sham the greater good mentality, but I'm just trying to
tell you that most developers are primarily in it for themselves.
> Perhaps effort should be placed into software development processes and
> tools that deny race conditions the right to be born, rather than depending
> on testing on a 16-processor system to find them expeditiously :-). And
You have gcc, no? write some tools. I like doing driver development,
I'll keep doing that until I need a tool to help me out with something,
and then I'll write one. Maybe I'll get lucky and someone else has
already written what I need.
Matthew Fredrickson