Re: Availability of kdb

[Marek Habersack]

** On Sep 19, Marty Fouts scribbled:
> Gene did the instruction set architecture along with some others. I think he
> was also involved in the i/o architecture.
Marty, could you _please_ stop posting to this thread on lkml and _PLEASE_
learn how to snip messages and _DON'T_ quote everything you reply to - this
list's volume is high enough without such noise. Thanks,

marek

 PGP signature

RE: Availability of kdb

[Tigran Aivazian]

On Mon, 18 Sep 2000, Marty Fouts wrote:
> It contains a wee bit of wisdom.

be not wise in thine own eyes, yea, let other man praise thee. ;)

Regards,
Tigran

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Keith Owens]

Please kill this thread.

Linus has stated he does not want a kernel debugger in the standard
kernel.  As the maintainer of kdb I accept that decision and will
maintain kdb outside the kernel.  Any other discussion is just noise.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Availability of kdb

[Marty Fouts]

Gene did the instruction set architecture along with some others. I think he
was also involved in the i/o architecture.

-Original Message-
From: Joel Jaeggli [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 18, 2000 4:59 PM
To: Marty Fouts
Cc: 'Malcolm Beattie'; [EMAIL PROTECTED]
Subject: RE: Availability of kdb

Gene Amdahl I think...


On Mon, 18 Sep 2000, Marty Fouts wrote:

> I think that more people quote Brooks than have read him and that more
> people know him from the Mythical Man Month than from the POO.
>
> He wasn't, by the way, the principle architect of OS/360; he was the
manager
> of the 360 development organization.  I will email a monster cookie to the
> first person who correctly identifies the original architect of OS/360.
>
> And yes, if Linus manages to learn some new lesson from Linux and writes a
> book about it of the endurance of MMM, I'll be shown wrong in my assertion
> about his being remembered.
>
> By the way, my favorite part of the anniversary edition of MMM is Brooks'
> apology to Gries about being wrong about information hiding.
>
> -Original Message-
> From: Malcolm Beattie [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 18, 2000 3:22 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Availability of kdb
>
> Marty Fouts writes:
> > Here's another piece of free advice, worth less than you paid for it: in
> 25
> > years, only the computer history trivia geeks are going to remember you,
> > just as only a very small handful of us now remember who wrote OS/360.
>
> You mean like Fred Brooks who managed the development of OS/360, had
> some innovative ideas about how large software projects should be run,
> whose ideas clashed with contemporary ones, who became a celebrity?
> You don't spot any parallels there? He whose book "Mythical Man Month"
> with "No Silver Bullet" and "The Second System Effect" are quoted
> around the industry decades later? And you think that's only a small
> handful of people?
>
> --Malcolm
>
> --
> Malcolm Beattie <[EMAIL PROTECTED]>
> Unix Systems Programmer
> Oxford University Computing Services
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>

--
--
Joel Jaeggli   [EMAIL PROTECTED]

Academic User Services   [EMAIL PROTECTED]
 PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Availability of kdb

[Joel Jaeggli]

Gene Amdahl I think...


On Mon, 18 Sep 2000, Marty Fouts wrote:

> I think that more people quote Brooks than have read him and that more
> people know him from the Mythical Man Month than from the POO.
> 
> He wasn't, by the way, the principle architect of OS/360; he was the manager
> of the 360 development organization.  I will email a monster cookie to the
> first person who correctly identifies the original architect of OS/360.
> 
> And yes, if Linus manages to learn some new lesson from Linux and writes a
> book about it of the endurance of MMM, I'll be shown wrong in my assertion
> about his being remembered.
> 
> By the way, my favorite part of the anniversary edition of MMM is Brooks'
> apology to Gries about being wrong about information hiding.
> 
> -Original Message-
> From: Malcolm Beattie [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 18, 2000 3:22 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Availability of kdb
> 
> Marty Fouts writes:
> > Here's another piece of free advice, worth less than you paid for it: in
> 25
> > years, only the computer history trivia geeks are going to remember you,
> > just as only a very small handful of us now remember who wrote OS/360.
> 
> You mean like Fred Brooks who managed the development of OS/360, had
> some innovative ideas about how large software projects should be run,
> whose ideas clashed with contemporary ones, who became a celebrity?
> You don't spot any parallels there? He whose book "Mythical Man Month"
> with "No Silver Bullet" and "The Second System Effect" are quoted
> around the industry decades later? And you think that's only a small
> handful of people?
> 
> --Malcolm
> 
> --
> Malcolm Beattie <[EMAIL PROTECTED]>
> Unix Systems Programmer
> Oxford University Computing Services
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

-- 
-- 
Joel Jaeggli   [EMAIL PROTECTED]
Academic User Services   [EMAIL PROTECTED]
 PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Availability of kdb

[Marty Fouts]

I think that more people quote Brooks than have read him and that more
people know him from the Mythical Man Month than from the POO.

He wasn't, by the way, the principle architect of OS/360; he was the manager
of the 360 development organization.  I will email a monster cookie to the
first person who correctly identifies the original architect of OS/360.

And yes, if Linus manages to learn some new lesson from Linux and writes a
book about it of the endurance of MMM, I'll be shown wrong in my assertion
about his being remembered.

By the way, my favorite part of the anniversary edition of MMM is Brooks'
apology to Gries about being wrong about information hiding.

-Original Message-
From: Malcolm Beattie [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 18, 2000 3:22 AM
To: [EMAIL PROTECTED]
Subject: Re: Availability of kdb

Marty Fouts writes:
> Here's another piece of free advice, worth less than you paid for it: in
25
> years, only the computer history trivia geeks are going to remember you,
> just as only a very small handful of us now remember who wrote OS/360.

You mean like Fred Brooks who managed the development of OS/360, had
some innovative ideas about how large software projects should be run,
whose ideas clashed with contemporary ones, who became a celebrity?
You don't spot any parallels there? He whose book "Mythical Man Month"
with "No Silver Bullet" and "The Second System Effect" are quoted
around the industry decades later? And you think that's only a small
handful of people?

--Malcolm

--
Malcolm Beattie <[EMAIL PROTECTED]>
Unix Systems Programmer
Oxford University Computing Services
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Availability of kdb

[Marty Fouts]

Then I suggest you skip the one paragraph at the beginning of my comment
that wasn't appropriately diplomatic and read the portion that you snipped.
It contains a wee bit of wisdom.

-Original Message-
From: Tigran Aivazian [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 18, 2000 1:36 AM
To: Marty Fouts
Cc: 'Larry McVoy'; 'Linus Torvalds'; Oliver Xymoron; Daniel Phillips; Kernel
Mailing List
Subject: RE: Availability of kdb

On Sun, 17 Sep 2000, Marty Fouts wrote:
> I've probably debugged more operating systems under more varied
environments
> than nearly anyone here, having brought up a new OS, compiler, and CPU

yea yea yea, if you are so good then you should be concentrating on giving
your goodness and wisdom and experience to us and not boast about it. For
to give is more blessed than receive.

Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

"J. Dow" wrote:
> 
> Jeff et al who might prefer a kernel debugger,
> 
> One should note that when a person or critter is backed into a corner
> and pressured hard enough that he makes an "over my dead body"
> level statement more pressure is likely to solidify the position rather
> than change it. In the case of a critter it is tied up with survival. With a
> person it is often tied up with "face". At this point Linus has been led
> to making a very strong negative comment about kernel debuggers.
> He is pretty much in a position now that "demands" he not change that
> opinion lest he appear to be a weak leader. We were all foolish to
> back him into a corner.
> 
> I see an image of a penguin. He is wearing a bandana around his
> forehead and cammie's for clothes. He is armed with an impressive
> array of things which carve and cut and things which go bang and
> boom and make holes in other things. He is glariing over the top of
> a foxhole filled with even more such tools screaming, "You'll have that
> kernel debugger in my main Linux build over my cold dead body!"
> 
> Now, who makes the cartoon for that one? (And if the penguin had
> a superficial resemblance to Linus it'd be DELIGHTFUL!)

I think Linus statements are sincere about his development philosophy,
and I have a hard time accepting this characterization of his motives. 
>From what I have heard from several folks who have worked with him for
many years, he has espoused this view relative to kernel debuggers for a
long time.  

Jeff 


> 
> {^_-}Joanne "A crazed maniac herself" Dow, [EMAIL PROTECTED]
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[J. Dow]

From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
> 
> Marty,
> 
> I think they said they could care less about kernel debuggers.  Just go
> write one, use Keith's or ours or whatever, and do what you want with
> your Linux development -- Linus doesn't seem to care if you just make a
> fork of Linux or someone else does with a debugger for your projects. 
> These guys have been debugging and developing their OS over the internet
> for a long time, their debugging methods seem more tied to their
> "telepathic repore" with each other and some very solid and studious
> skills at reviewing code rapidly and a thorough understanding of it. 
> They also have the luxury of taking the world at their own pace with
> Linux evolution and have stated no desire to change their philosophy.  

Jeff et al who might prefer a kernel debugger,

One should note that when a person or critter is backed into a corner
and pressured hard enough that he makes an "over my dead body"
level statement more pressure is likely to solidify the position rather
than change it. In the case of a critter it is tied up with survival. With a
person it is often tied up with "face". At this point Linus has been led
to making a very strong negative comment about kernel debuggers.
He is pretty much in a position now that "demands" he not change that
opinion lest he appear to be a weak leader. We were all foolish to
back him into a corner.

I see an image of a penguin. He is wearing a bandana around his
forehead and cammie's for clothes. He is armed with an impressive
array of things which carve and cut and things which go bang and
boom and make holes in other things. He is glariing over the top of
a foxhole filled with even more such tools screaming, "You'll have that
kernel debugger in my main Linux build over my cold dead body!"

Now, who makes the cartoon for that one? (And if the penguin had
a superficial resemblance to Linus it'd be DELIGHTFUL!)

{^_-}Joanne "A crazed maniac herself" Dow, [EMAIL PROTECTED]


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[yodaiken]

On Sun, Sep 17, 2000 at 08:40:33PM -0700, Larry McVoy wrote:
> On Sun, Sep 17, 2000 at 02:33:40PM -0700, Marty Fouts wrote:
> I'm sort of in the middle.  I know BitKeeper very well, and it's actually
> a larger wad of code than the kernel if you toss out the device drivers.
> About the only thing I ever want a debugger for is a stacktrace back.  If
> you give me that, I usually don't need anything else; and in general, you

There are debuggers that do other stuff too?  I gotta read the adb 
manual some day.

-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Marty,

I think they said they could care less about kernel debuggers.  Just go
write one, use Keith's or ours or whatever, and do what you want with
your Linux development -- Linus doesn't seem to care if you just make a
fork of Linux or someone else does with a debugger for your projects. 
These guys have been debugging and developing their OS over the internet
for a long time, their debugging methods seem more tied to their
"telepathic repore" with each other and some very solid and studious
skills at reviewing code rapidly and a thorough understanding of it. 
They also have the luxury of taking the world at their own pace with
Linux evolution and have stated no desire to change their philosophy.  

Just go grab a debugger, patch and go.  For some things I need to debug,
kdb doesn't cut it, so I have my own tools that are more powerful for
the specialized type of stuff we have to do, but it doesn't seem to
offend anyone if this is how you want to do it.  Just go do it.  

:-)

Jeff


"David S. Miller" wrote:
> 
> Which one of them was %100 distributed where no two of the developers
> were in the same building and the only method of communication was
> electronic?
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Malcolm Beattie]

Marty Fouts writes:
> Here's another piece of free advice, worth less than you paid for it: in 25
> years, only the computer history trivia geeks are going to remember you,
> just as only a very small handful of us now remember who wrote OS/360.

You mean like Fred Brooks who managed the development of OS/360, had
some innovative ideas about how large software projects should be run,
whose ideas clashed with contemporary ones, who became a celebrity?
You don't spot any parallels there? He whose book "Mythical Man Month"
with "No Silver Bullet" and "The Second System Effect" are quoted
around the industry decades later? And you think that's only a small
handful of people?

--Malcolm

-- 
Malcolm Beattie <[EMAIL PROTECTED]>
Unix Systems Programmer
Oxford University Computing Services
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Availability of kdb

[Tigran Aivazian]

On Sun, 17 Sep 2000, Marty Fouts wrote:
> I've probably debugged more operating systems under more varied environments
> than nearly anyone here, having brought up a new OS, compiler, and CPU

yea yea yea, if you are so good then you should be concentrating on giving
your goodness and wisdom and experience to us and not boast about it. For
to give is more blessed than receive.

Regards,
Tigran

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Availability of kdb

[Marty Fouts]

I am amused that you snipped the relevant part of the discussion in order to
take a snipe at the throwaway part.

Do you have any comment on the arguments I've made, or do you just like
sniping?



-Original Message-
From: David S. Miller [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 17, 2000 10:40 PM
To: Marty Fouts
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Availability of kdb

   From: Marty Fouts <[EMAIL PROTECTED]>
   Date:Sun, 17 Sep 2000 22:42:22 -0700

   I've probably debugged more operating systems under more varied
   environments than nearly anyone here

Which one of them was %100 distributed where no two of the developers
were in the same building and the only method of communication was
electronic?

Besides, "My shit doesn't stink because I've done this a 1000
different times for twice as long as anyone here, blah blah" is not of
much value, perhaps you've done it wrong all this time or perhaps each
time it was under circumstances which are much different than the
Linux development model.  This is what my first paragraph was meant to
point out.

I find that I get more respect from people, especially "new ignorant"
people if I don't start any of my arguments with "my shit doesn't
stink because I did this and that... me me me...".

Later,
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]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[David S. Miller]

   From: Marty Fouts <[EMAIL PROTECTED]>
   Date:Sun, 17 Sep 2000 22:42:22 -0700

   I've probably debugged more operating systems under more varied
   environments than nearly anyone here

Which one of them was %100 distributed where no two of the developers
were in the same building and the only method of communication was
electronic?

Besides, "My shit doesn't stink because I've done this a 1000
different times for twice as long as anyone here, blah blah" is not of
much value, perhaps you've done it wrong all this time or perhaps each
time it was under circumstances which are much different than the
Linux development model.  This is what my first paragraph was meant to
point out.

I find that I get more respect from people, especially "new ignorant"
people if I don't start any of my arguments with "my shit doesn't
stink because I did this and that... me me me...".

Later,
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]
Please read the FAQ at http://www.tux.org/lkml/

RE: Availability of kdb

[Marty Fouts]

I agree about needing to know all of the tools in the tool chest, including
the hand ones. Nothing in what I've said about needing to include the
debugger has been an argument against *also* having a full chest of other
tools.

On the other hand, Linus is wrong, and your attempt to defend him is a
non-sequitor.

I've probably debugged more operating systems under more varied environments
than nearly anyone here, having brought up a new OS, compiler, and CPU
concurrently and having debugged everything from card-batch monitors to
fairly large distributed systems.  On any number of occasions, as others
here have noted, a debugger has been essential, and utter knowledge of the
code is of no use, because the code has relied on hardware that is in
reality behaving differently than it is documented to behave.  No amount of
code reading is going to find those cases.

I've also found a lot of problems where the symptoms appear in one subsystem
but are the result of a bug in another.  No amount of reading the code from
the first subsystem is going to find the bug in the second, but those are
the bugs that are going to give you the most headaches without good
debugging tools.

You continue to conflate two related but different parts of the debugging
process.  Identifying what the system *is* doing is different than
identifying what it *should* be doing.  The social-engineering argument
against using debuggers is an argument against  making the mistake of trying
to both jobs with one tool.

In my "perfect" universe, here's how I debug kernels, when I'm not worried
about the hardware being the problem, and the problem is in code written by
someone else:

* Have access to a browsable cross-referenced source tree for the exact
kernel being debugged (in a _really_ perfect world, I'd have specifications
for what the code should be doing, but hey, we're in OS hacking here, so
we'll ignore software engineering things like requirements, specifications,
pre-conditions, "programming with contracts", and stick to
hairy-chested-he-man-debugging)
* Do my best to reduce the test case to the smallest set of actions that
will reproduce the failure  - this may involve using debuggers, logic
analysers, and various "jigs" to help isolate system behavior.
* Loop:
o Read the source code to see if I can understand the failure behavior, in
the process, questions will arise, like "shouldn't this variable be mumble
at this point
o Run the test case under the debugger *while* reading the source code (best
if I can use a remote debugger that interacts with my source code browser)
and use the debugger to validate my assumptions by answering those questions
* the loop is repeated until I have an "aha" moment, which is the point at
which I *think* I see what the code is doing that it shouldn't have done.
* Stop what I'm doing and have a diet coke.  Preferably while reading the
module that I think is misbehaving. (in a _really_ perfect world, while
reading it with the guy who wrote it.)
* Write up and desk check the code that should change the behavior (with the
guy who wrote the original as a code reviewer, if possible)
* Run the regression suite - if the patch works, take it to code review.  If
it passes code review, try to put the test case in the regression suite, if
it can be done.

The debugger is useful, along with visualization tools, trip wires and a
dozen other techniques in solving a very important social engineering
problem that I haven't seen mentioned in this thread: The bug got there
after my team's best effort to write correct code in the first place, an
effort that involves specs, code reviews, coding standards and a number of
other tools.  That means we have a conceptual failure to understand our own
code.  As any proof reader will tell you: mistakes like that that get by are
nearly impossible to catch.

Basically, I use a debugger when I realize that I've developed a perception
block and I want to validate my perception against reality.  Computing is,
after all, an empirical science.

Marty


-Original Message-
From: Larry McVoy [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 17, 2000 8:41 PM
To: Marty Fouts
Cc: 'Linus Torvalds'; Oliver Xymoron; Tigran Aivazian; Daniel Phillips;
Kernel Mailing List
Subject: Re: Availability of kdb

On Sun, Sep 17, 2000 at 02:33:40PM -0700, Marty Fouts wrote:
> Um, for what ever it is worth, if you want to compare "power user"
carpentry
> to "hand tools only" you can actually do it fairly easily on PBS in the
US.
> There used to be a program done by a guy who did everything by hand.  I
> loved to watch it, especially the parts where he cut himself badly because
> there are somethings it is dumb to do with hand tools, but he was stuck
with
> his dumb rule.  There's another show, still on, called "The New Yankee
>

RE: Availability of kdb

[Marty Fouts]

I'm not laboring under the mistaken impression that there is any capital-T
truth in operating system design, nor that there is a capital-R right way to
do things. Nor do I make the mistake of trying to cover up bad ideas about
social-engineering with poorly thought out examples about carpentry, and
then stomp my feet demanding that people who point out the failings of those
metaphors should stop having "silly" ideas and compete with me in some
imaginary game of "goodness."  I don't do drinking games, pissing matches,
or popularity contests, and I'm not impressed by them either.

I'm on this mailing list because the company that I currently work for has
decided to use Linux in its products. I'm trying to figure out how to make
commercial products that will survive in the market place while also finding
a way to give back to the open source community.  I'm going to stay here for
as long as it is in my judgement in my company's interest for me to follow
Linux development, and my belief that I can utilize my company's interest in
Linux to give back to the free software community.

I'm not particularly interested in convincing you. You are inexperienced,
headstrong, and laboring under many of the misapprehensions that come with
celebrity, as well as being intelligent and observant. Experience will teach
you or leave you by the wayside, and that's your karma to cope with. 

I won't bother to offer my critique of the Linux kernel just now, because
I'm fairly sure you aren't interested.

I will from time to time, if my experience happens to intersect with an
active discussion, raise some observations that seem appropriate.  You are
welcome to take from twenty five years of deep experience in the computer
industry what ever lessons you may or to ignore them completely, as is
anyone else.
 
As far as "where I'll be in 10 years," the answer is probably, as it has
been for the last 10 years, "where I was 10 years ago", which is trying to
cope with the latest wunderkind and figure out how to make money off the
process, produce software that I'm not too embarrassed to admit having been
involved with, and occasionally contribute to the free software community -
all while having fun and utterly failing to take myself or any of this
seriously.

Your opinions are worth to me exactly the quality of argument you can raise
to back them - the opinion equivalent of 'show me the code'. Frankly, you
don't argue your case at all effectively, and I'm totally unimpressed by an
approach that amounts to "if you don't like the way we play on my sandlot,
go find your own".

There is no correlation between the level of tool use and the quality of
product produced. Having tools allows you to do things that not having tools
prohibits you from doing, but the bell shaped curve for quality has
maintained pretty much over the course of human tool list.  If you think
that that is a "silly" idea, feel free to rebut it, but don't think that
calling an idea by a demeaning name and demanding that I go off and roll an
operating system is anything more than throwing a tantrum.

Here's another piece of free advice, worth less than you paid for it: in 25
years, only the computer history trivia geeks are going to remember you,
just as only a very small handful of us now remember who wrote OS/360.  Work
hard on having fun, the rest will sort itself out.

Marty (as silly as ever)

 
-Original Message-
From: Linus Torvalds [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 17, 2000 5:49 PM
To: Marty Fouts
Cc: Oliver Xymoron; Tigran Aivazian; Daniel Phillips; Kernel Mailing List
Subject: RE: Availability of kdb


On Sun, 17 Sep 2000, Marty Fouts wrote:
>
> Craftsmanship is in the way you approach what you do, not in the tools you
> use to do it.  And, frankly, if you wish to artificially limit your use of
> tools, all you are doing is hobbling yourself.

You know what?

Start your own kernel (or split one off from Linux - that's what the GPL
is all about), and we'll see where you are in ten years. If kernel
debuggers are so much better, then you'll be quite well off, and you can
prove your silly opinions by _showing_ them right.

In the meantime, I've shown what my opinions are worth. Take a look, any
day. Available at your nearest ftp-site.

Talk is cheap. If you want to convince me, do the WORK.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Larry McVoy]

On Sun, Sep 17, 2000 at 02:33:40PM -0700, Marty Fouts wrote:
> Um, for what ever it is worth, if you want to compare "power user" carpentry
> to "hand tools only" you can actually do it fairly easily on PBS in the US.
> There used to be a program done by a guy who did everything by hand.  I
> loved to watch it, especially the parts where he cut himself badly because
> there are somethings it is dumb to do with hand tools, but he was stuck with
> his dumb rule.  There's another show, still on, called "The New Yankee
> Workshop". I love to watch it, just to count the number of power tools Norm
> Abrams manages to use in a single project.  (I think the most I saw in one
> one hour episode was 40-something.)
> 
> Craftsmanship does *not* come from artificial rules about what tools you are
> allowed to use.  There were hack carpenters when there weren't any power
> tools, and the cabinet makers I know who do the best work (the sort that
> gets them several thousand dollars a piece for small pieces of furniture)
> use every power tool they find appropriate to their work; just as they
> construct and use jigs and rely on all the other "tricks of the trade".
> 
> Craftsmanship is in the way you approach what you do, not in the tools you
> use to do it.  And, frankly, if you wish to artificially limit your use of
> tools, all you are doing is hobbling yourself.

Ahh, now we're having fun.  It just so happens that I can speak to all
of these topics; not only have I seen the shows mentioned, but I have
a shop out the back which has both a pile of power tools and a pile of
antique tools (oldest one that I know of was made around 1837, a great
big spokeshave).  I use all of them regularly, no collector-foo here,
thank you.  I tend to retreat to working with hand tools when all this
geek stuff gets to be a bit much.

Cabinet making craftsmanship absolutely comes from a firm knowledge of
hand tools.  I'll bet you anything you want that the guy who sells that
$3K furniture knows exactly what a Norris is and has used one.  Probably
still does (OK, mebbe it's a Lie-Nielsen these days).

I've also used a number of kernel debuggers - kadb back at Sun, a monitor
back at ETA (amazingly similar in spirit to RT/Linux), SGI's monstrosity,
and probably others.

That said, who gives a hoot what I have or what I have used?  The question
is: does Linus have a point or not?  And the answer is, you bet he does.

Linus is saying that if you need a debugger then you don't know the code.
And if you don't know the code, then you shouldn't be hacking the code.
A debugger does little besides cover up a lack of knowledge.

It's not an easy to take point of view because by definition, most
people don't really know the code so most people want a debugger.
Linus would just as soon that you learn the code well enough that a
debugger becomes pointless.

I'm sort of in the middle.  I know BitKeeper very well, and it's actually
a larger wad of code than the kernel if you toss out the device drivers.
About the only thing I ever want a debugger for is a stacktrace back.  If
you give me that, I usually don't need anything else; and in general, you
shouldn't either.  You should *know* why you got to a particular place,
if you don't know that then how can you fix the bug?

So I'm gonna side with Linus on this one, if you make it hard now, it will
be easier later.  It also increases the quality of the people submitting
patches, which is a good thing.
-- 
---
Larry McVoy  lm at bitmover.com   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Availability of kdb

[Marty Fouts]

Um, for what ever it is worth, if you want to compare "power user" carpentry
to "hand tools only" you can actually do it fairly easily on PBS in the US.
There used to be a program done by a guy who did everything by hand.  I
loved to watch it, especially the parts where he cut himself badly because
there are somethings it is dumb to do with hand tools, but he was stuck with
his dumb rule.  There's another show, still on, called "The New Yankee
Workshop". I love to watch it, just to count the number of power tools Norm
Abrams manages to use in a single project.  (I think the most I saw in one
one hour episode was 40-something.)

Craftsmanship does *not* come from artificial rules about what tools you are
allowed to use.  There were hack carpenters when there weren't any power
tools, and the cabinet makers I know who do the best work (the sort that
gets them several thousand dollars a piece for small pieces of furniture)
use every power tool they find appropriate to their work; just as they
construct and use jigs and rely on all the other "tricks of the trade".

Craftsmanship is in the way you approach what you do, not in the tools you
use to do it.  And, frankly, if you wish to artificially limit your use of
tools, all you are doing is hobbling yourself.

Marty

-Original Message-
From: Linus Torvalds [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 09, 2000 5:35 PM
To: Oliver Xymoron
Cc: Tigran Aivazian; Daniel Phillips; Kernel Mailing List
Subject: Re: Availability of kdb




On Sat, 9 Sep 2000, Oliver Xymoron wrote:
> 
> Tools are tools. They don't make better code. They make better code easier
> if used properly.

I think you missed the point of my original reply completely.

The _technical_ side of the tool in question is completely secondary.

The social engineering side is very real, and immediate.

It's not whether you can use tools to do the work.

It's about what kind of people you get.

You were the one who brought up the power drill analogy. I'll take it, and
run with it, and maybe you can see _my_ point by me taking your analogy
and running with it.

Yes, using a power-drill and other tools makes a lot of carpentry easier.
To the point that a lot of carpenters don't even use their hands much any
more. Almost all the "carpentry" today is 99% automated, and sure, it
works wonderfuly - especially as you in carpentry cannot do it any other
way if you want to mass-produce stuff.

But take a moment to look at it the other way. 

If you want to find the true carpenters today, what do you do? Not just "a
carpenter". But THE carpenter.

I'm saying that maybe you put up a carpentry shop where everything is
lovingly hand-crafted and tools are not considered to be the most
important part - or even necessarily good. And yes, some people
(carpenters in every sense of the word) will be frustrated. They can't use
the power-lathe that they are used to. It doesn't suit them. They _know_
that they are missing something.

But in the end, maybe the rule to only use hand power makes sense. Not
because hand-power is _better_. But because it brings in the kind of
people who love to work with their hands, who love to _feel_ the wood with
their fingers, and because of that their holes are not always perfectly
aligned, not always at the same place. The kind of carpenter that looks at
the grain of the wood, and allows the grain of the wood to help form the
finished product.

The kind of carpenter who, in a word, is more than _just_ a carpenter.

  [ Insert a silent minute to contemplate the beaty of the world here. ]

Go back and read my original reply to this thread.

Really _understand_ the notion of two kinds of people. 

And think about what kind of people you'd like to work with.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[root]

Linus Torvalds wrote:

> On Sun, 17 Sep 2000, Marty Fouts wrote:
> >
> > Craftsmanship is in the way you approach what you do, not in the tools you
> > use to do it.  And, frankly, if you wish to artificially limit your use of
> > tools, all you are doing is hobbling yourself.
>
> You know what?
>
> Start your own kernel (or split one off from Linux - that's what the GPL
> is all about), and we'll see where you are in ten years. If kernel
> debuggers are so much better, then you'll be quite well off, and you can
> prove your silly opinions by _showing_ them right.

Good answer.


>
>
> In the meantime, I've shown what my opinions are worth. Take a look, any
> day. Available at your nearest ftp-site.
>
> Talk is cheap. If you want to convince me, do the WORK.

And I am finding out just how much work indeed.  But I have to say, it's a hell
of a lot cleaner than the NetWare Source Base and alot better organized :-)


>
>
> Linus
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Availability of kdb

[Linus Torvalds]

On Sun, 17 Sep 2000, Marty Fouts wrote:
> 
> Craftsmanship is in the way you approach what you do, not in the tools you
> use to do it.  And, frankly, if you wish to artificially limit your use of
> tools, all you are doing is hobbling yourself.

You know what?

Start your own kernel (or split one off from Linux - that's what the GPL
is all about), and we'll see where you are in ten years. If kernel
debuggers are so much better, then you'll be quite well off, and you can
prove your silly opinions by _showing_ them right.

In the meantime, I've shown what my opinions are worth. Take a look, any
day. Available at your nearest ftp-site.

Talk is cheap. If you want to convince me, do the WORK.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Mike Galbraith]

On Tue, 12 Sep 2000, Jeff V. Merkey wrote:

> 
> Ted,
> 
> I am looking at these sources as well.  One thing I went back and looked
> at was related to a comment from Mike G. I believe regarding drivers
> conflicts with int 0x13 requests potentially hosing the IDE driver.  In

Hmm.. must be a different Mike G.  (can't be from me.. I don't even know
what conflicts you're refering to:)

-Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Ted,

I am looking at these sources as well.  One thing I went back and looked
at was related to a comment from Mike G. I believe regarding drivers
conflicts with int 0x13 requests potentially hosing the IDE driver.  In
MANOS, since DOS is resident underneath the OS, I instrumented the code
a lot like was done in earlier versions of Windows and NT.  I hook the
MSDOS disk interrupts and reprogram the PIC to move the first PIC
interrupt mappings to start at entry 0x28 
in the IDT tables instead of overlaying the first 16 exception entries
which is how DOS leaves them by default.  When I call into DOS, I
restore the previous PIC1 mappings to their previous DOS settings and
restore the DOS IVT to allow the DOS BIOS drivers to service the disk. 
In the MANOS case, DOS has enough smarts to reset the IDE chipset to
it's default values.  I am looking  over the BIOS int 0x13 code, and it
looks like it may be possible to co-host an int 0x13 ext2 driver and the
Linux IDE driver as is done in NetWare today.  I know this is possible
because I do it in MANOS now, and NetWare also supports mutiple IDE
drivers (DOS and NetWare) to share the chipset.

:-)

Jeff

"Theodore Y. Ts'o" wrote:
> 
>Date: Mon, 11 Sep 2000 17:51:20 -0600
>From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
> 
>I support source level in the kernel.  Based on Andi Klein's review, I
>have grabbed ext2utils and am looking at a minimal int 0x13 interface to
>load files into memory.  hardest problem here for Linux is having a tiny
>FS that won't deadlock to load source files.
> 
> You may also want to take a look at libext2fs which is part of
> e2fsprogs.  It has a I/O abstraction which isolates the raw disk I/O
> from the rest of the library.  (There's a unix_io.c and an nt_io.c; in
> fact, there's even a dos_io.c which uses the int 0x13 interface,
> although it'll probably require some reworking of the code to translate
> it away from TurboC.)
> 
> In libext2fs, look at the fileio.c module; once you open the ext2
> filesystem, you open, read, seek, etc. individual ext2 files in the ext2
> filesystem.  I'm not sure the file write code works if it needs to
> extend the file; and it's been the least tested of all of the functions,
> but you wouldn't need this for a kernel debugger anyway.
> 
> - Ted
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Theodore Y. Ts'o]

   Date: Mon, 11 Sep 2000 17:51:20 -0600
   From: "Jeff V. Merkey" <[EMAIL PROTECTED]>

   I support source level in the kernel.  Based on Andi Klein's review, I
   have grabbed ext2utils and am looking at a minimal int 0x13 interface to
   load files into memory.  hardest problem here for Linux is having a tiny
   FS that won't deadlock to load source files.

You may also want to take a look at libext2fs which is part of
e2fsprogs.  It has a I/O abstraction which isolates the raw disk I/O
from the rest of the library.  (There's a unix_io.c and an nt_io.c; in
fact, there's even a dos_io.c which uses the int 0x13 interface,
although it'll probably require some reworking of the code to translate
it away from TurboC.)

In libext2fs, look at the fileio.c module; once you open the ext2
filesystem, you open, read, seek, etc. individual ext2 files in the ext2
filesystem.  I'm not sure the file write code works if it needs to
extend the file; and it's been the least tested of all of the functions,
but you wouldn't need this for a kernel debugger anyway.

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Theodore Y. Ts'o]

On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
>
> Thanks Ted.  I know, but a kernel debugger is one of those nasty pieaces
> of software that can quickly get out of sync if it's maintained
> separately from the tree -- the speed at which changes occur in Linux
> would render it a very difficult project to maintain.  If there's going
> to be one (whichever one it is) it would need to be maintained and
> dragged along with the kernel proper or it would be a maintenance
> nightmare.  Linus' dislike of the kernel debugger concept would also

If the kernel debugger is done right, it won't require massive changes
as Linux continues to change.  Does gdb need to be modified based on the
programs that it debugs?  

I can certainly see that certain kernel debugger modules (say, those
that muck with spinlocks for deadlock debugging) might require updating
as the kernel changes, but the overall design goal for any good kernel
debugger is to minimize the number places where it has to hook into the
real parts of the kernel.  For one thing, this reduces the chance of
"heisenbugs" which disappear once you enable the kernel debugger, since
if adding the kernel debugger modifies the code paths, the bug is much
more likely to go away.  For another, if you want to have the kernel
debugger enabled by default, having lots of hooks into the main parts
kernel makes it much more likely that the whole thing will be a massive
speed/performance hit.

If keeping the kernel debugger outside of the kernel is inspires people
to minimize the number of hooks and patches that are needed to main
parts of the kernel, then that's probably one of the best reasons to
keep it ouside of the mainline kernel distribution.

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Keith Owens wrote:
> 
> On Mon, 11 Sep 2000 16:19:14 -0600,
> "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
> >Who pays you?
> 
> I used to work on kdb in my own time, for free.  Then I joined SGI and
> now I get paid to work on it.  If I left SGI I would continue to work
> on kdb, the original kdb developer left SGI but still contributes.

It's good they see the value of kdb and are willing to do this.  I
commend them.

> 
> >> The kernel debuggers that are kept up to date get used.  The ones that
> >> are used get feedback for kernel changes which keep them up to date.
> >> kdb has taken off precisely because it is being kept up to date with
> >> the kernel.  And if I miss something, I know that people will tell me.
> >
> >I'm sure this is all true.  kdb was just rejected by Linus however, what
> >message does that send to you?
> 
> That Linus does not like kernel debuggers.  This is news?  There are
> several examples of code that Linus did not like originally but enough
> people wanted them and they eventually got included in the kernel.
> Complaining to Linus does nothing, "show me the code".

You know where the code is -- go look at it.

> 
> >kdb is about 1/100th the size of the MANOS debugger in terms of source
> >code size, and isn't a hacked in after thought like kdb.  It uses task
> >gates and other tables beneath the OS that just are not there in kdb and
> >that will impinge on architectural freedom for Linus.  It also uses
> >nested task gates, and requires changes to the xcall layer in Linux to
> >plug it in.
> 
> kdb is not a hacked in after thought.  It was designed from scratch as
> a minimalist kernel debugger which coexists with the existing kernel
> design.  Note "minimalist", adding kdb to a kernel has little effect on
> the running kernel, the biggest impact is the symbol table (adds 20-30%
> to loaded kernel size) and the last branch recording in the page fault
> handler which probably slows page faulting slightly, although I have
> not measured it.

I support source level in the kernel.  Based on Andi Klein's review, I
have grabbed ext2utils and am looking at a minimal int 0x13 interface to
load files into memory.  hardest problem here for Linux is having a tiny
FS that won't deadlock to load source files.

> 
> kdb does a reasonable job at the binary level which is exactly what it
> was designed to do.  If you have to change the kernel design to
> incorporate a debugger then you seriously need to think if your
> debugger design is suitable.
> 
> >If Linus doesn't support the concept, it could be a lot of
> >work.  I know my code, you know yours -- Linus habit of breaking things
> >as he puts in new and better features that you stated aealier is true,
> >so where does that leave us?
> 
> In exactly the same position as every other kernel developer.  Nobody
> promised us that kernel APIs would remain stable in development
> kernels, if it breaks we fix it in the next patch.  This is the Linux
> development model, everyone else lives with it.

I have to look at long term support.  We get very busy around here and
spending money I will do if it makes sense.  I do appreciate your
input.  

Jeff

> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

The code is at vger.timpanogas.org.  If you want to review it, it's
there.  We are posting another MANOS kernel with full VM end of the
month.  The version Darren and I are hacking on now has the debugger
broken out as a module as a prelude to put it in Linux.  I am working on
your kdb stubs in 2.4 to put it in.  Darren is finishing the VM
subsystem.

Jeff

Keith Owens wrote:
> 
> On Mon, 11 Sep 2000 16:24:32 -0600,
> "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
> >Keith,
> >
> >If you are volunteering to maintain the MANOS debugger after I hack it
> >into Linux, then I accept.  I'll give you an ftp and telnet account on
> >vger.timpanogas.org and you can run with it.
> 
> How on earth did you make that jump?  I maintain kdb because I like it
> and it has a lot of my code in it.  MANOS is your code, you maintain
> it or persuade people to help you maintain it.  Show people the code
> and see if they use it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Keith Owens]

On Mon, 11 Sep 2000 16:24:32 -0600, 
"Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
>Keith,
>
>If you are volunteering to maintain the MANOS debugger after I hack it
>into Linux, then I accept.  I'll give you an ftp and telnet account on
>vger.timpanogas.org and you can run with it.

How on earth did you make that jump?  I maintain kdb because I like it
and it has a lot of my code in it.  MANOS is your code, you maintain
it or persuade people to help you maintain it.  Show people the code
and see if they use it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Keith Owens]

On Mon, 11 Sep 2000 16:19:14 -0600, 
"Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
>Who pays you?  

I used to work on kdb in my own time, for free.  Then I joined SGI and
now I get paid to work on it.  If I left SGI I would continue to work
on kdb, the original kdb developer left SGI but still contributes.

>> The kernel debuggers that are kept up to date get used.  The ones that
>> are used get feedback for kernel changes which keep them up to date.
>> kdb has taken off precisely because it is being kept up to date with
>> the kernel.  And if I miss something, I know that people will tell me.
>
>I'm sure this is all true.  kdb was just rejected by Linus however, what
>message does that send to you?

That Linus does not like kernel debuggers.  This is news?  There are
several examples of code that Linus did not like originally but enough
people wanted them and they eventually got included in the kernel.
Complaining to Linus does nothing, "show me the code".

>kdb is about 1/100th the size of the MANOS debugger in terms of source
>code size, and isn't a hacked in after thought like kdb.  It uses task
>gates and other tables beneath the OS that just are not there in kdb and
>that will impinge on architectural freedom for Linus.  It also uses
>nested task gates, and requires changes to the xcall layer in Linux to
>plug it in.

kdb is not a hacked in after thought.  It was designed from scratch as
a minimalist kernel debugger which coexists with the existing kernel
design.  Note "minimalist", adding kdb to a kernel has little effect on
the running kernel, the biggest impact is the symbol table (adds 20-30%
to loaded kernel size) and the last branch recording in the page fault
handler which probably slows page faulting slightly, although I have
not measured it.

kdb does a reasonable job at the binary level which is exactly what it
was designed to do.  If you have to change the kernel design to
incorporate a debugger then you seriously need to think if your
debugger design is suitable.

>If Linus doesn't support the concept, it could be a lot of
>work.  I know my code, you know yours -- Linus habit of breaking things
>as he puts in new and better features that you stated aealier is true,
>so where does that leave us?

In exactly the same position as every other kernel developer.  Nobody
promised us that kernel APIs would remain stable in development
kernels, if it breaks we fix it in the next patch.  This is the Linux
development model, everyone else lives with it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Keith,

If you are volunteering to maintain the MANOS debugger after I hack it
into Linux, then I accept.  I'll give you an ftp and telnet account on
vger.timpanogas.org and you can run with it.

:-)

Jeff

"Jeff V. Merkey" wrote:
> 
> Who pays you?
> 
> Keith Owens wrote:
> >
> > On Mon, 11 Sep 2000 09:46:15 -0600,
> > "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
> > >Thanks Ted.  I know, but a kernel debugger is one of those nasty pieaces
> > >of software that can quickly get out of sync if it's maintained
> > >separately from the tree -- the speed at which changes occur in Linux
> > >would render it a very difficult project to maintain.
> >
> > Bullshit.  It takes me about 30 minutes for most 2.4 kernel patches to
> > see if kdb needs to be changed.  A combination of a decent source
> > control system (PRCS, ftp://ftp.XCF.Berkeley.EDU/pub/prcs) to merge and
> > compare source branches, a little bit of Perl to standardize the patch
> > and tkdiff to compare the old and new patches tells me very quickly if
> > I need to release a new kdb patch.  If the kernel changes might have
> > affected kdb then I compile and test, 1-5 hours depending on the extent
> > of the kernel changes.  Most of the time I don't bother compiling.
> 
> Who is paying for this, BTW.  Who pays your salary?
> 
> >
> > The kernel debuggers that are kept up to date get used.  The ones that
> > are used get feedback for kernel changes which keep them up to date.
> > kdb has taken off precisely because it is being kept up to date with
> > the kernel.  And if I miss something, I know that people will tell me.
> 
> I'm sure this is all true.  kdb was just rejected by Linus however, what
> message does that send to you?
> 
> >
> > >Linus' dislike of the kernel debugger concept would also
> > >assure that it would not be considered in design decisions moving
> > >forward, which is probably the biggest disuader in the whole debate.
> >
> > Irrelevant.  Linus can change any kernel interface in the developing
> > kernels at any time and does.  Half the time this breaks existing
> > kernel code, never mind external patches.  But we manage to keep up to
> > date with API changes.  kdb is very low level, no I/O, restricted VFS
> > and SMP dependencies.  My biggest problem is gcc changes, not the
> > kernel.
> >
> > >I don't spend money on things I believe are destined to fail.  Until Linus
> > >changes his mind, there's no point ...
> >
> > Destined to fail?  Tell that to all the people downloading and using
> > kdb and watch them laugh.
> 
> kdb is about 1/100th the size of the MANOS debugger in terms of source
> code size, and isn't a hacked in after thought like kdb.  It uses task
> gates and other tables beneath the OS that just are not there in kdb and
> that will impinge on architectural freedom for Linus.  It also uses
> nested task gates, and requires changes to the xcall layer in Linux to
> plug it in.  If Linus doesn't support the concept, it could be a lot of
> work.  I know my code, you know yours -- Linus habit of breaking things
> as he puts in new and better features that you stated aealier is true,
> so where does that leave us?
> 
> Jeff
> 
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Who pays you?  

Keith Owens wrote:
> 
> On Mon, 11 Sep 2000 09:46:15 -0600,
> "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
> >Thanks Ted.  I know, but a kernel debugger is one of those nasty pieaces
> >of software that can quickly get out of sync if it's maintained
> >separately from the tree -- the speed at which changes occur in Linux
> >would render it a very difficult project to maintain.
> 
> Bullshit.  It takes me about 30 minutes for most 2.4 kernel patches to
> see if kdb needs to be changed.  A combination of a decent source
> control system (PRCS, ftp://ftp.XCF.Berkeley.EDU/pub/prcs) to merge and
> compare source branches, a little bit of Perl to standardize the patch
> and tkdiff to compare the old and new patches tells me very quickly if
> I need to release a new kdb patch.  If the kernel changes might have
> affected kdb then I compile and test, 1-5 hours depending on the extent
> of the kernel changes.  Most of the time I don't bother compiling.

Who is paying for this, BTW.  Who pays your salary?  

> 
> The kernel debuggers that are kept up to date get used.  The ones that
> are used get feedback for kernel changes which keep them up to date.
> kdb has taken off precisely because it is being kept up to date with
> the kernel.  And if I miss something, I know that people will tell me.

I'm sure this is all true.  kdb was just rejected by Linus however, what
message does that send to you?

> 
> >Linus' dislike of the kernel debugger concept would also
> >assure that it would not be considered in design decisions moving
> >forward, which is probably the biggest disuader in the whole debate.
> 
> Irrelevant.  Linus can change any kernel interface in the developing
> kernels at any time and does.  Half the time this breaks existing
> kernel code, never mind external patches.  But we manage to keep up to
> date with API changes.  kdb is very low level, no I/O, restricted VFS
> and SMP dependencies.  My biggest problem is gcc changes, not the
> kernel.
> 
> >I don't spend money on things I believe are destined to fail.  Until Linus
> >changes his mind, there's no point ...
> 
> Destined to fail?  Tell that to all the people downloading and using
> kdb and watch them laugh.

kdb is about 1/100th the size of the MANOS debugger in terms of source
code size, and isn't a hacked in after thought like kdb.  It uses task
gates and other tables beneath the OS that just are not there in kdb and
that will impinge on architectural freedom for Linus.  It also uses
nested task gates, and requires changes to the xcall layer in Linux to
plug it in.  If Linus doesn't support the concept, it could be a lot of
work.  I know my code, you know yours -- Linus habit of breaking things
as he puts in new and better features that you stated aealier is true,
so where does that leave us?

Jeff



> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Keith Owens]

On Mon, 11 Sep 2000 09:46:15 -0600, 
"Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
>Thanks Ted.  I know, but a kernel debugger is one of those nasty pieaces
>of software that can quickly get out of sync if it's maintained
>separately from the tree -- the speed at which changes occur in Linux
>would render it a very difficult project to maintain.

Bullshit.  It takes me about 30 minutes for most 2.4 kernel patches to
see if kdb needs to be changed.  A combination of a decent source
control system (PRCS, ftp://ftp.XCF.Berkeley.EDU/pub/prcs) to merge and
compare source branches, a little bit of Perl to standardize the patch
and tkdiff to compare the old and new patches tells me very quickly if
I need to release a new kdb patch.  If the kernel changes might have
affected kdb then I compile and test, 1-5 hours depending on the extent
of the kernel changes.  Most of the time I don't bother compiling.

The kernel debuggers that are kept up to date get used.  The ones that
are used get feedback for kernel changes which keep them up to date.
kdb has taken off precisely because it is being kept up to date with
the kernel.  And if I miss something, I know that people will tell me.

>Linus' dislike of the kernel debugger concept would also
>assure that it would not be considered in design decisions moving
>forward, which is probably the biggest disuader in the whole debate.

Irrelevant.  Linus can change any kernel interface in the developing
kernels at any time and does.  Half the time this breaks existing
kernel code, never mind external patches.  But we manage to keep up to
date with API changes.  kdb is very low level, no I/O, restricted VFS
and SMP dependencies.  My biggest problem is gcc changes, not the
kernel.

>I don't spend money on things I believe are destined to fail.  Until Linus
>changes his mind, there's no point ...

Destined to fail?  Tell that to all the people downloading and using
kdb and watch them laugh.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Rik van Riel]

On Mon, 11 Sep 2000, Jamie Lokier wrote:
> Jeff V. Merkey wrote:

> > In NetWare, we didn't care if the page was touched or not since we
> > used our own bits in field bits 11-9 to store page specific stuff,
> > like whether the page was dirty or not.
> 
> Linux does actually look at both bits, but the optimisation
> still applies.  Accessed in particular -- ptes are mapped on
> page faults so you know the page is about to be accessed.

The main difference between Linux and Netware here is the
fact that Linux has a real userland, which can touch the
pages on its own without going through the kernel.

This causes "spontaneously" dirtied or accessed pages,
meaning that we really want to use the hardware bits ...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Rik van Riel]

On Mon, 11 Sep 2000, Jamie Lokier wrote:
> Rik van Riel wrote:
> > The main difference between Linux and Netware here is the
> > fact that Linux has a real userland, which can touch the
> > pages on its own without going through the kernel.
> > 
> > This causes "spontaneously" dirtied or accessed pages,
> > meaning that we really want to use the hardware bits ...
> 
> Of course you don't _have_ to do things that way with a real
> userland. You can take page faults and update your own bits.  I
> think some of the ports actually do this.

Meaning you have to blindly unmap pages and see if they get
faulted back in again. I believe you need to do this trick
with the VAX (and OpenBSD and NetBSD still use this method).

> But we prefer the hardware, even though in some cases
> software-driven faults give better guidance to the paging
> heuristics.

The difference is a locked cycle vs. handling a page fault.
This isn't a very hard choice to make ;)

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jamie Lokier]

Rik van Riel wrote:
> The main difference between Linux and Netware here is the
> fact that Linux has a real userland, which can touch the
> pages on its own without going through the kernel.
> 
> This causes "spontaneously" dirtied or accessed pages,
> meaning that we really want to use the hardware bits ...

Of course you don't _have_ to do things that way with a real userland.
You can take page faults and update your own bits.  I think some of the
ports actually do this.

But we prefer the hardware, even though in some cases software-driven
faults give better guidance to the paging heuristics.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Val Henson]

One way of increasing signal to noise ratio (place in .procmailrc):

:0
* ^FROM.*jmerkey@timpanogas\.com
/dev/null

On Mon, Sep 11, 2000 at 03:53:48PM -0400, [EMAIL PROTECTED] wrote:
> On Mon, 11 Sep 2000, Jeff V. Merkey wrote:

> Now will you stop trying to incite pointless riots and allow those of us
> who are trying to use linux-kernel as a useful means of communicating
> development issues a chance for a decent signal to noise ratio?

-VAL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

[EMAIL PROTECTED] wrote:

> Now will you stop trying to incite pointless riots and allow those of us
> who are trying to use linux-kernel as a useful means of communicating
> development issues a chance for a decent signal to noise ratio?
> 
> -ben

Ben,

Read the thread before getting out your shotgun and pointing it at me. 
Rik asked me a question, I answered it.  It wasn't related to any code
-- if he asks me a question again, I'll answer it.  

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

I'll give it some thought.  Most of Linux has better paging than NetWare
already -- NetWare is pretty simple in this respect.  THe process
mapping stuff in Netware (PCB's are mapped to recursively point to
themselves with a global brach table) is unique, but not as good as
what's in Linux.

:-)

Jeff

Jamie Lokier wrote:
> 
> Jeff V. Merkey wrote:
> > One of the best references that describes the bus transaction model for
> > Intel in "plain english"  is the Pentium Pro Processor System
> > Architecture Manual by Tom Shanley of Mindshare, Inc., Addison Wesley,
> > ISBN: 0-201-47953-2.  It explains a very good detail how the cache
> > controllers and MESI works on Intel.
> 
> Agreed, it is a very informative book.  More detail than you need unless
> you're cloning the chips ;-)  Full of good ideas, especially for anyone
> interested in memory hierarchies.
> 
> > In NetWare, we didn't care if the page was touched or not since we
> > used our own bits in field bits 11-9 to store page specific stuff,
> > like whether the page was dirty or not.
> 
> Linux does actually look at both bits, but the optimisation still
> applies.  Accessed in particular -- ptes are mapped on page faults so
> you know the page is about to be accessed.
> 
> > We saw a 4% performance improvement for Network I/O by avoiding the
> > "hidden" locking in Intel's architecture.  You should check if you need
> > this bit, and if not, always create the PTE with it set.  I don't know
> > how much it would help Linux.  NetWare is well optimized for Intel
> > processors and any little thing that increased bus memory utilization
> > was very noticeable on NetWare, since it supports such huge user loads
> > already.
> >
> > :-)
> 
> Use Linux.  Grok Linux.  Read the source and weep :-)
> But thanks for the tip :-)
> 
> Btw, any good tips you have on effective paging heuristics -- now they
> _would_ be useful I'm sure.  Linux paging is still rather experimental
> after all these years.  As in, it works but could do better.
> 
> -- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[kernel]

On Mon, 11 Sep 2000, Jeff V. Merkey wrote:

> If you need to know if the page has been accessed, you can clear this
> bit when a page is first mapped, and when someone touches it, the
> hardware will set this bit.  It set's it by doing a R/M/W operation on

We've set the accessed bit for a long time.  From asm-i388/pgtable.h:

#define PAGE_SHARED __pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | 
_PAGE_ACCESSED)
#define PAGE_COPY   __pgprot(_PAGE_PRESENT | _PAGE_USER | _PAGE_ACCESSED)
#define PAGE_READONLY   __pgprot(_PAGE_PRESENT | _PAGE_USER | _PAGE_ACCESSED)

Now will you stop trying to incite pointless riots and allow those of us
who are trying to use linux-kernel as a useful means of communicating
development issues a chance for a decent signal to noise ratio?

-ben

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jamie Lokier]

Jeff V. Merkey wrote:
> One of the best references that describes the bus transaction model for
> Intel in "plain english"  is the Pentium Pro Processor System
> Architecture Manual by Tom Shanley of Mindshare, Inc., Addison Wesley,
> ISBN: 0-201-47953-2.  It explains a very good detail how the cache
> controllers and MESI works on Intel.

Agreed, it is a very informative book.  More detail than you need unless
you're cloning the chips ;-)  Full of good ideas, especially for anyone
interested in memory hierarchies.

> In NetWare, we didn't care if the page was touched or not since we
> used our own bits in field bits 11-9 to store page specific stuff,
> like whether the page was dirty or not.

Linux does actually look at both bits, but the optimisation still
applies.  Accessed in particular -- ptes are mapped on page faults so
you know the page is about to be accessed.

> We saw a 4% performance improvement for Network I/O by avoiding the
> "hidden" locking in Intel's architecture.  You should check if you need
> this bit, and if not, always create the PTE with it set.  I don't know
> how much it would help Linux.  NetWare is well optimized for Intel
> processors and any little thing that increased bus memory utilization
> was very noticeable on NetWare, since it supports such huge user loads
> already.
> 
> :-)

Use Linux.  Grok Linux.  Read the source and weep :-)
But thanks for the tip :-)

Btw, any good tips you have on effective paging heuristics -- now they
_would_ be useful I'm sure.  Linux paging is still rather experimental
after all these years.  As in, it works but could do better.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jamie Lokier]

Rik van Riel wrote:
> > The person writing and updating page table entries in NetWare
> > 4.1 was clearing the accessed bit in the PTE and did not know
> > that the processor would assert a hidden R/M/W operation and
> > assert a bus lock to set this bit everytime someone cleared it
> > -- it made performance drop 4% from NetWare 3.X and noone knew
> > why.
> 
> Hmmm, this sounds like an `interesting' incident that we need
> to know more about. Currently Linux may have some problems with
> the PTE modifying code so if you have any details about how
> exactly you are supposed to modify a PTE, we'd like to know ;)

It's not related to the races.

When the x86 sets the Accessed bit in a page table (due to an access ;-)
or the Dirty bit (due to writing), it does a LOCKed read-modify-write
cycle to update the bit in the page table.

This locked cycle is only done when the bit actually needs to be update.
(To be honest I thought it always did a locked cycle although it's
obviously better not to).

Locked cycles have a certain cost as you know, so if possible avoid
them.  This means if you don't need to monitor Accessed or Dirty, set
the bits you're not interested in when you initialise the pte.

Linux does actually look at both bits.  However, quite often a pte is
set up in response to a page fault.  Then you _know_ the page is about
to be accessed so it's worth setting Accessed.  If it's a write fault,
you're pretty confident it's going to be dirtied too so may as well set
Dirty.

Amazingly (doesn't Jeff read any of our code?), Linux implements both
these optimisations and has done as far back as I remember looking at
the source.  That would be about 6 years, 1.0.x days.  I don't think a
debugger was used ;-)

  1. Accessed: See def. of PAGE_* in .
 _PAGE_ACCESSED is set on all new ptes by default.

  2. Dirty: See comment "This silly early PAGE_DIRTY setting removes a
 race due to the bad i386 page protection..." in memory.c.  I don't
 see the race but I do see it as an optimisation :-)

have a nice day,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Allright, You've convinced me.  I'll do it.  It will require consierable
support moving forward.

:-)

Jeff

Miles Lane wrote:
> 
> On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
> 
> >
> >
> > "Theodore Y. Ts'o" wrote:
> >
> > >
> > > If you come up with robust, easy to patch source-code-level debugger for
> > > Linux, some people will use it, and some people won't.  If it's better
> > > than kdb, eventually it'll displace kdb as the external kernel debugger
> > > of choice.   As with all things, the cardinal rule in this community
> > > still applies: "show me the code".
> > >
> > > - Ted
> >
> > Thanks Ted.  I know, but a kernel debugger is one of those nasty pieaces
> > of software that can quickly get out of sync if it's maintained
> > separately from the tree -- the speed at which changes occur in Linux
> > would render it a very difficult project to maintain.  If there's going
> > to be one (whichever one it is) it would need to be maintained and
> > dragged along with the kernel proper or it would be a maintenance
> > nightmare.  Linus' dislike of the kernel debugger concept would also
> 
> I agree with Ted.  If your debugger is a highly effective, easy-to-use tool,
> people will use it and help you with improving it. If the distributions
> include it, then developers building software with "stable" kernels will
> use it for checking code that interacts with their kernels in ways that
> cause trouble.  This would be very valuable.
> 
> This means you get to focus on supporting released kernels.  This might be
> a viable way for you to build a user base.  This could eventually lead to
> use with the development kernel and the growth of support for keeping
> the debugger in sync with the kernel's architectural changes.
> 
> I am a Linux tester, not a kernel developer, so this is
> "for what it's worth."
> 
> Miles
> 
> > assure that it would not be considered in design decisions moving
> > forward, which is probably the biggest disuader in the whole debate.  I
> > don't spend money on things I believe are destined to fail.  Until Linus
> > changes his mind, there's no point ...
> >
> > Jeff
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > Please read the FAQ at http://www.tux.org/lkml/
> >
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Miles Lane]

On Mon, 11 Sep 2000, Jeff V. Merkey wrote:

> 
> 
> "Theodore Y. Ts'o" wrote:
> 
> > 
> > If you come up with robust, easy to patch source-code-level debugger for
> > Linux, some people will use it, and some people won't.  If it's better
> > than kdb, eventually it'll displace kdb as the external kernel debugger
> > of choice.   As with all things, the cardinal rule in this community
> > still applies: "show me the code".
> > 
> > - Ted
> 
> Thanks Ted.  I know, but a kernel debugger is one of those nasty pieaces
> of software that can quickly get out of sync if it's maintained
> separately from the tree -- the speed at which changes occur in Linux
> would render it a very difficult project to maintain.  If there's going
> to be one (whichever one it is) it would need to be maintained and
> dragged along with the kernel proper or it would be a maintenance
> nightmare.  Linus' dislike of the kernel debugger concept would also

I agree with Ted.  If your debugger is a highly effective, easy-to-use tool,
people will use it and help you with improving it. If the distributions 
include it, then developers building software with "stable" kernels will 
use it for checking code that interacts with their kernels in ways that 
cause trouble.  This would be very valuable.

This means you get to focus on supporting released kernels.  This might be 
a viable way for you to build a user base.  This could eventually lead to 
use with the development kernel and the growth of support for keeping 
the debugger in sync with the kernel's architectural changes.

I am a Linux tester, not a kernel developer, so this is 
"for what it's worth."

Miles

> assure that it would not be considered in design decisions moving
> forward, which is probably the biggest disuader in the whole debate.  I
> don't spend money on things I believe are destined to fail.  Until Linus
> changes his mind, there's no point ...
> 
> Jeff
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Gary Lawrence Murphy]

> "A" == Alexander Viro <[EMAIL PROTECTED]> writes:

A> As for the "greater social good" (or world domination, for that
A> matter) - excuse me, but quite a few of us couldn't care
A> less. 

Thanks for the comment, and please don't feel guilty about it, it is a
perfectly valid reason for Linux. It is also what I suspected by
looking at the structure of the code: IMHO, Linux (ie the kernel) is
the _ultimate_ "user friendly" software product ... _iff_ you consider
the "users" as the programmers themselves.  I know of no other piece of
software which gives its users such depth of community.

I also frequently see vetos and approvals on this list where the final
rationale is social rather than technical.  There is no fault or evil
in this, and social reasons are important to ensuring the community
functions. Just so long as we all understand that this is the purpose
of Linux. In a very early interview (c.1993?), Linus gave a list of
requirements which begins with Linux being fun to work on for himself,
and then for other developers. For some, it is.

You might say Linux has succeeded because it is a 'playground' for
developers, a place where they _like_ to contribute and where there
are no project managers, marketing or QA people saying "you must do
this and that by next Tuesday".  

This is perfectly fine.  The playground atmosphere sets it apart from
its more staid and serious competition. Linux need not set out to rule
or save the world. It is a gift, and we can take it or leave it as we
wish. 

But ... wouldn't we avoid a lot of these technical merit discussions
of this or that method or technique (kdb, reiserfs, &c) if we were
more open about its purpose?

-- 
Gary Lawrence Murphy <[EMAIL PROTECTED]>: office voice/fax: 01 519 4222723
T(!c)Inc Business Innovation through Open Source http://www.teledyn.com
M:I-3 - Documenting the Linux kernel: http://kernelbook.sourceforge.net
"You don't play what you know; you play what you hear." --- Miles Davis
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Jamie,

I referenced a great book an an email to Rik Van Reil.  It's got a great
explanation of this stuff.  

:-)

Jeff

Jamie Lokier wrote:
> 
> Jeff V. Merkey wrote:
> > This means it completely unnecessary to assert LOCK# for the unlock
> > case, since there are no ordering issues persay - the other processors
> > are spinning on the lock already and cannot get through.
> 
> Yes I know I left out the context.  Doesn't change what I'm about to
> say.  Erm, this does not appear to address ordering between the spinlock
> and access to _other_ memory locations.  I know you're right and your
> information is very interesting, but it doesn't appear to address the
> point...  only knowledge of processor ordering tells us that `movb' for
> spin-unlock always flushes prior pending writes before unlocking.
> 
> That's something that comes from manuals etc. and indeed, the _bugs_ in
> that show up on the scopes (circa 1994 as you said).
> 
> -- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Rik,

One of the best references that describes the bus transaction model for
Intel in "plain english"  is the Pentium Pro Processor System
Architecture Manual by Tom Shanley of Mindshare, Inc., Addison Wesley,
ISBN: 0-201-47953-2.  It explains a very good detail how the cache
controllers and MESI works on Intel.

The PTE is layed out on Intel:

63   36 3512 11  9 8 7 6
5 4 3 2 1 0
Reserved(0)|  24 bits of page addr   |  
^  

|
  
Page Accessed

If you need to know if the page has been accessed, you can clear this
bit when a page is first mapped, and when someone touches it, the
hardware will set this bit.  It set's it by doing a R/M/W operation on
the PTE in memory and asserts LOCK# invisibly to the OS above -- you
will see it on a bus analyzer issuing a memory write transaction and
asserting LOCK#.  If you don't care about this bit, when you map in
pages, and create a new PTE, it's wise to set the bit yourself when you
fill out the table.  If you don't, the hardware will perform a locked
memory write (just like a spinlock) the first time someone touches the
page the PTE refers to.  In NetWare, we didn't care if the page was
touched or not since we used our own bits in field bits 11-9 to store
page specific stuff, like whether the page was dirty or not.  The same
applies to other types of descriptors that have an accessed bit as
well.  What we were doing is always clearing this bit during PTE
updates, and were getting all these hidden locks that caused performance
to drop.  

We saw a 4% performance improvement for Network I/O by avoiding the
"hidden" locking in Intel's architecture.  You should check if you need
this bit, and if not, always create the PTE with it set.  I don't know
how much it would help Linux.  NetWare is well optimized for Intel
processors and any little thing that increased bus memory utilization
was very noticeable on NetWare, since it supports such huge user loads
already.

:-)

Jeff







Rik van Riel wrote:
> 
> On Sun, 10 Sep 2000, Jeff V. Merkey wrote:
> 
> > The person writing and updating page table entries in NetWare
> > 4.1 was clearing the accessed bit in the PTE and did not know
> > that the processor would assert a hidden R/M/W operation and
> > assert a bus lock to set this bit everytime someone cleared it
> > -- it made performance drop 4% from NetWare 3.X and noone knew
> > why.
> 
> Hmmm, this sounds like an `interesting' incident that we need
> to know more about. Currently Linux may have some problems with
> the PTE modifying code so if you have any details about how
> exactly you are supposed to modify a PTE, we'd like to know ;)
> 
> regards,
> 
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
>-- Miguel de Icaza, UKUUG 2000
> 
> http://www.conectiva.com/   http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Rik van Riel]

On Sun, 10 Sep 2000, Jeff V. Merkey wrote:

> The person writing and updating page table entries in NetWare
> 4.1 was clearing the accessed bit in the PTE and did not know
> that the processor would assert a hidden R/M/W operation and
> assert a bus lock to set this bit everytime someone cleared it
> -- it made performance drop 4% from NetWare 3.X and noone knew
> why.

Hmmm, this sounds like an `interesting' incident that we need
to know more about. Currently Linux may have some problems with
the PTE modifying code so if you have any details about how
exactly you are supposed to modify a PTE, we'd like to know ;)

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jamie Lokier]

Jeff V. Merkey wrote:
> This means it completely unnecessary to assert LOCK# for the unlock
> case, since there are no ordering issues persay - the other processors
> are spinning on the lock already and cannot get through.

Yes I know I left out the context.  Doesn't change what I'm about to
say.  Erm, this does not appear to address ordering between the spinlock
and access to _other_ memory locations.  I know you're right and your
information is very interesting, but it doesn't appear to address the
point...  only knowledge of processor ordering tells us that `movb' for
spin-unlock always flushes prior pending writes before unlocking.

That's something that comes from manuals etc. and indeed, the _bugs_ in
that show up on the scopes (circa 1994 as you said).

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Jamie Lokier wrote:
> 
> Jeff V. Merkey wrote:
> > The best info I know of is to get an analyser that plugs into the
> > processor socket (like an american arium) and enable branch trace
> > messaging to monitor the interaction between the processor and the cache
> > controllers.  You get info that's not in any Intel book just watching
> > the thing run.  Nasty complicated stuff.  They explain some of it in the
> > cache controller architecture manuals -- these are public.
> 
> I still don't see how processor traces will tell me what ordering
> guarantees I can rely on across the range of processors.

On the unlock case ordering doesn't really matter, except in the case of
"hotlocking" when several processors are all hitting the same spinlock
and blocking at it a lot, and whether you use "lock bts" or "mov "
does not matter, even in this case BTW, since there's no guarantee
enforced in the hardware as to which processor will get the lock next --
it's arbitrary.  

The assumption made here is that when the lock has been taken and is
already owned, everyone is already spinning on it and blocked anyway. 
If you unlock with a "mov ,0" the cache controllers will update
the other cache lines after the write propogates, and another processor
will succeed in getting the lock.  It doesn't matter if it shows up
right away accross everyone's cache lines (which is does anyway) -- one
of the processors will take the lock and get through as soon as the
R/M/W cycle completed (unless of course the lock field is not dword
aligned, in which case, a split bus transaction may occur and show up on
the bus as two atomic transactions instead of one -- Although from what
I have seen on an analyzer, Intel will hold LOCK# lead driven low until
both cycles complete).  This means it completely unnecessary to assert
LOCK# for the unlock case, since there are no ordering issues persay -
the other processors are spinning on the lock already and cannot get
through.

Which processor updates it's cache line first will "kick" the cache
controller into signalling the others, and from what I have observed, it
seems random enough to ensure fairness to processors waiting on the
lock.  Early ca-1994 Intel SMP systems (like Tricord) had some problems
with the "mov ,0" method due to timing problems with their own MBC
chips they used on processor boards and I saw similiar problems with
DEC's IOAPIC clone chipsets early on, but these problems got fixed over
time.  There is a side affect from the "mov ,0" method where it's
possible for a particular processor to never get the lock if they are
all "hotlocking" on the same lock in memory and spin 1,000,000 times or
something do to early hardware designs, but I have not seen this problem
since mid-1994 on any Intel SMP system.  

:-)

Jeff



> 
> -- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jamie Lokier]

Lars Marowsky-Bree wrote:
> > I still don't see how processor traces will tell me what ordering
> > guarantees I can rely on across the range of processors.
> 
> It will tell you when your assumptions were wrong.

Indeed.  Like testing, but better.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Lars Marowsky-Bree]

On 2000-09-11T18:11:11,
   Jamie Lokier <[EMAIL PROTECTED]> said:

> I still don't see how processor traces will tell me what ordering
> guarantees I can rely on across the range of processors.

It will tell you when your assumptions were wrong.

Sincerely,
Lars Marowsky-Brée <[EMAIL PROTECTED]>
Development HA

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jamie Lokier]

Jeff V. Merkey wrote:
> The best info I know of is to get an analyser that plugs into the
> processor socket (like an american arium) and enable branch trace
> messaging to monitor the interaction between the processor and the cache
> controllers.  You get info that's not in any Intel book just watching
> the thing run.  Nasty complicated stuff.  They explain some of it in the
> cache controller architecture manuals -- these are public.

I still don't see how processor traces will tell me what ordering
guarantees I can rely on across the range of processors.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

The best info I know of is to get an analyser that plugs into the
processor socket (like an american arium) and enable branch trace
messaging to monitor the interaction between the processor and the cache
controllers.  You get info that's not in any Intel book just watching
the thing run.  Nasty complicated stuff.  They explain some of it in the
cache controller architecture manuals -- these are public.

:-)

Jeff

Jamie Lokier wrote:
> 
> > I won't use a Linus example in the future since this seems to turn off
> > some folks reason centers and they go into "attack mode".
> 
> Thanks Jeff, I heard that.
> 
> I got a lot of useful info from that 3 week long thread, but it's still
> a bit confusing.  A decent document from Intel or their competitors
> would still be good...
> 
> -- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jamie Lokier]

> I won't use a Linus example in the future since this seems to turn off
> some folks reason centers and they go into "attack mode".

Thanks Jeff, I heard that.

I got a lot of useful info from that 3 week long thread, but it's still
a bit confusing.  A decent document from Intel or their competitors
would still be good...

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

"Theodore Y. Ts'o" wrote:

> 
> If you come up with robust, easy to patch source-code-level debugger for
> Linux, some people will use it, and some people won't.  If it's better
> than kdb, eventually it'll displace kdb as the external kernel debugger
> of choice.   As with all things, the cardinal rule in this community
> still applies: "show me the code".
> 
> - Ted

Thanks Ted.  I know, but a kernel debugger is one of those nasty pieaces
of software that can quickly get out of sync if it's maintained
separately from the tree -- the speed at which changes occur in Linux
would render it a very difficult project to maintain.  If there's going
to be one (whichever one it is) it would need to be maintained and
dragged along with the kernel proper or it would be a maintenance
nightmare.  Linus' dislike of the kernel debugger concept would also
assure that it would not be considered in design decisions moving
forward, which is probably the biggest disuader in the whole debate.  I
don't spend money on things I believe are destined to fail.  Until Linus
changes his mind, there's no point ...

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Jamie,

I should have never brought this example up.  The thread "spin_unlock()
optimization" that went on for three weeks with Intel and the whole
planet getting into the fray speaks for itself, and anyone wanting to
search the kernel archives can do so and for their own opinion.  I won't
use a Linus example in the future since this seems to turn off some
folks reason centers and they go into "attack mode".  I wasn't intending
to offend, just cite an example for Al Viro relative to why code reviews
alone don't give all the perspectives on the whole topic of a kernel
debugger in Linux.

:-)

Jeff

Jamie Lokier wrote:
> 
> Jeff V. Merkey wrote:
> > To cite a Linux specific example, let's take the issue with the memory
> > write for a spin_unlock().  Linus seemed to have trouble grasping why
> > a simple ' mov , 0' would work as opposed to a 'lock dec
> > '
> 
> No logic analyser will tell you the subtleties of _why_ it works.
> You'll see MESI working, you'll see processor ordering in your test
> cases, but that doesn't tell you whether processor ordering works.
> 
> > Anyone who has ever spent late nights with an American Arium Analyzer
> > profiling memory bus transactions on a PPro knows that MESI [...] will
> > correctly propogate via the processor caches a write to a locked
> > location with a correct load and stor oder without any problems of
> > locking concurrency.
> 
> Wrong.  They observe no locking problems with their particular test
> cases.  The logic analyser doesn't tell you that no code sequence will
> exhibit a locking problem.  It also doesn't mean that no future
> processor will exhibit the problem.
> 
> Instead of using a bus analyzer to see that there's no _symptom_, the
> kernel developers looked at Intel's specifications.  A guy from Intel
> helped with that.  Eventually it was confirmed that Intel does actually
> guarantee 'movb' works for spin-unlock.
> 
> At the same time, a few folks ran tests on a number of processors to see
> if the ordering specifications were really followed.  A lot of
> misunderstanding and confusion did result from that.
> 
> Some tests failed, but they were actually the wrong tests for
> spin-unlock, which is ok with 'movb'.  They were the right tests for
> some other subtle ordering problems though.
> 
> In the process, many of us learned a lot about x86 read-write ordering
> rules.  Through this, other bugs were found.  See __set_task_state for
> example.
> 
> If someone had just use the logic analyser, we'd never have constructed
> the wrong threading tests, and we probably wouldn't have spotted the
> task_state bug.
> 
> > Linus' apparently did not understand this, or he would have
> > immediately realized that double locking was always generating a
> > second non-cacheable memory reference for every lock being taken and
> > released.
> 
> Erm, I think we _all_ knew about the second memory reference...
> But non-cacheable?  On a PPro lock operations are cacheable.
> 
> > The person writing and updating page table entries in NetWare 4.1 was
> > clearing the accessed bit in the PTE and did not know that the
> > processor would assert a hidden R/M/W operation and assert a bus lock
> > to set this bit everytime someone cleared it -- it made performance
> > drop 4% from NetWare 3.X and noone knew why.  This performance problem
> > would have never been found without this tool.  2 years of code
> > reviews did not find it -- an American Ariun Analyser with a kernel
> > debugger to stop and start and instrument the code with writing custom
> > stubs all over the place did.
> 
> The kernel developers have known about those R/M/W "hidden cycles"
> forever.  See any standard Pentium textbook (or even 386/486 for that
> matter).
> 
> Heck, even _I_ know this stuff and I've never programmed any page table
> code, just read those parts of the kernel.
> 
> > Folks who just rely on code reviews never see this level of
> > interaction, and conversely, do not have the understanding of hardware
> > behavior underneath an OS to optimize it well.
> 
> Apparently your engineers didn't read the textbooks.
> 
> -- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Theodore Y. Ts'o]

   Date:Sun, 10 Sep 2000 17:06:17 -0600
   From: "Jeff V. Merkey" <[EMAIL PROTECTED]>

   One of the principal architects at Compaq called me Friday after
   reading Linus' email about not caring about commercial or support
   issues for commercialization of Linux on this topic-- his right -- it
   had the anticipated impact I would expect, and it's rippling through
   the industry.  This topic on kernel debuggers and Linux kernel
   development philosophy has been an unknown to a lot of folks in the
   commercial software world for a long time and now Linus has made some
   things very clear.

   Since Linus has rejected kdb there's every indication he will reject
   any other kernel debugger submissions -- also his right.  I think my
   time would be better spent completing the merge of the Linux code
   base onto MANOS since moving the debugger over to Linux seems to not
   be something Linus would adopt and it's contrary to his development
   philosophy, so it's probably a complete waste of my time.

Remember, there's a big difference between what's in the "official" tree
as distributed by Linus, and what people actually use in distributions.
For example, just about every distribution I know uses NFS patches that
never made it into the 2.2 tree because of Alan's concerns about
backwards compatibility.  (A commendable concern, but when just about
everyone is using the patch, the discrepancy between what most users who
are using a precompiled kernel see and what they get if they try to
compile a kernel on their own --- since they're likely not to know about
the required NFS patches if they what to be comptible with other Unix
systems --- is something I'd concerned more important.  But then again,
I'm not in charge of the 2.2 kernel; that's Alan's call.)

So it wouldn't surprise me that if someone kept a well-matained kernel
debugger and crash dumping patch (such as the one by SGI) if most
commercial distributions included them as a matter of course.

It's important not to get *too* badly fixated over what's in the
"official blessed Linux kernel distribution which has the holy penguin
pee on it."

   If I get time to create a patch for Linux, I'll put it up.  kdb seems
   to be already there, so folks can use it on Linux for now, and I'll
   stick to printk() and code reviews for my debugging on Linux.

If you come up with robust, easy to patch source-code-level debugger for
Linux, some people will use it, and some people won't.  If it's better
than kdb, eventually it'll displace kdb as the external kernel debugger
of choice.   As with all things, the cardinal rule in this community
still applies: "show me the code".

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Martin Dalecki]

Gary Lawrence Murphy wrote:
 
> The analogy to typing hex codes or toggling code at the console is
> also apt.  Unix ascended over Multix in no small part because of C,
> which drew sneers from the trad programmer of the day. Personally, I
> tend to debug intuitively based on my knowledge of code, but not
> exclusively.  In my 25 years in this business, I have seen amazing
> things done with debuggers, things that had stumped whole teams of
> very good programmers. Intuition still plays a vital role, but gdb in
> the right hands can prove things that would take months of code
> tweaking to do by hand.

Maybe it's that just 25 years in this industry made you for Alzheimer,
since
you should know that the first versions of UNIX where actually written
in
plain assembler. So C certainly isn't what made for it's success in
first place.
And then please just compare C with any other modern programming
language like 
pascal/modula/java/C++/objective/C/ADA or anything elese. From all of
them
C is the most "assembler alike" language and still the most widely used
for OS programming out there: BeOS, NT, UNIX, QNX, VMS, CP/M, DOS, Mach, 
and so on and so on.

Second: GDB is DREADFULL in terms of user friendliness...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Mike Porter]

> > But in the end, maybe the rule to only use hand power makes sense. Not
> > because hand-power is _better_. But because it brings in the kind of
> > people who love to work with their hands, who love to _feel_ the wood with
> > their fingers, and because of that their holes are not always perfectly
> > aligned, not always at the same place. The kind of carpenter that looks at
> > the grain of the wood, and allows the grain of the wood to help form the
> > finished product.
> > 
> > The kind of carpenter who, in a word, is more than _just_ a carpenter.
> > 
> >   [ Insert a silent minute to contemplate the beaty of the world here. ]
> 
> Properly contemplated and I wonder at the hypocrisy of using a compiler
> or an assembler instead of carefully hand crafted bits on a blank disk.

Taking his base analogy, it's no different that setting up a shop
that uses iron planes, or wood planes, or adzes, or maybe reverting
all the way back to simple stone tools.  You draw the line
somewhere to attact a certain type of person interesting in
producing a certain result.

Besides, I assume anyone working on the kernel can get a debugger
patch and be running in a few minutes.  Or maybe not?  I've never
downloaded a kernel debugger.

Mike (who likes iron planes, iron chisels and drill presses)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Alexander Viro]

On 11 Sep 2000, Gary Lawrence Murphy wrote:

> > "H" == Horst von Brand <[EMAIL PROTECTED]> writes:
> 
> H> In the end, this is Linus' game. If you want to play, you'll
> H> have to pay the admission price he sets. 
> 
> Is it fair to ask about the purpose of Linux?  
> 
> The purpose I most often hear talks about world domination and about
> having the best O/S on the maximum number of platforms, with appeals
> to "open source" to ensure quality control and technical progress.
> That goal says nothing about the grain of the wood or the vanity of
> the carpenter. It is all about being of service to a greater social
> good.  Maybe I misunderstood.
> 
> The analogy to typing hex codes or toggling code at the console is
> also apt.  Unix ascended over Multix in no small part because of C,
> which drew sneers from the trad programmer of the day. Personally, I

That's "Multics" and while I agree that C is nicer than PL/I, the latter
is _not_ an assembler or autocode. Multics was written in HLL.

As for the "greater social good" (or world domination, for that matter)
- excuse me, but quite a few of us couldn't care less. It's a decent UNIX,
there is a lot of things making that kernel more interesting than other
ones and it's fun to work on. FSF is -> that way, if you need the "social
good" crap - take Hurd and enjoy the featuritis-ridden bloatware.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Gary Lawrence Murphy]

> "H" == Horst von Brand <[EMAIL PROTECTED]> writes:

H> In the end, this is Linus' game. If you want to play, you'll
H> have to pay the admission price he sets. 

Is it fair to ask about the purpose of Linux?  

The purpose I most often hear talks about world domination and about
having the best O/S on the maximum number of platforms, with appeals
to "open source" to ensure quality control and technical progress.
That goal says nothing about the grain of the wood or the vanity of
the carpenter. It is all about being of service to a greater social
good.  Maybe I misunderstood.

The analogy to typing hex codes or toggling code at the console is
also apt.  Unix ascended over Multix in no small part because of C,
which drew sneers from the trad programmer of the day. Personally, I
tend to debug intuitively based on my knowledge of code, but not
exclusively.  In my 25 years in this business, I have seen amazing
things done with debuggers, things that had stumped whole teams of
very good programmers. Intuition still plays a vital role, but gdb in
the right hands can prove things that would take months of code
tweaking to do by hand.

I'll risk yet another metaphor ;) ...

While composing music, I can use a pen and staff paper and work out
harmonic and melogic lines at a piano, but I limit myself. With much
respect to the pre-digital composers, this work is prohibitively
tedious and demands a vibrant imagination when you must produce 102
parts for an orchestra, and this method severely restricted the
harmonic sense of pre-electronic composition as they grafted the
wave-form harmonics of the piano to all other instruments. Harry Partch
took us one step towards a different sense of harmony, but had to
rest on ideal and imaginary instruments because he could not manage
the complexity of instrument timbres using manual methods.

Also, if I want to be modern, if I need to step outside the
euro-centric equal-tempered scale and classical rhythm, notation
quickly becomes a handicap (see John Cage's "Notations").  Using
software tools, I gain fine control, I can more rapidly experiment
with scenarios, and I can manage many orders of magnitude more
complexity.  I find the same is true with software tools.

Tools should serve and extend the body, not enslave the mind.  Yes, I
can walk to my nearest village and yes I will see more fine detail of
nature if I walk and will excercise my heart, but my bicycle makes it
practical to do this 20km trek as a day trip, and a car makes it
possible to go shopping.  

It all depends on my purpose.

-- 
Gary Lawrence Murphy <[EMAIL PROTECTED]>: office voice/fax: 01 519 4222723
T(!c)Inc Business Innovation through Open Source http://www.teledyn.com
M:I-3 - Documenting the Linux kernel: http://kernelbook.sourceforge.net
"You don't play what you know; you play what you hear." --- Miles Davis
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jamie Lokier]

Jeff V. Merkey wrote:
> To cite a Linux specific example, let's take the issue with the memory
> write for a spin_unlock().  Linus seemed to have trouble grasping why
> a simple ' mov , 0' would work as opposed to a 'lock dec
> '

No logic analyser will tell you the subtleties of _why_ it works.
You'll see MESI working, you'll see processor ordering in your test
cases, but that doesn't tell you whether processor ordering works.

> Anyone who has ever spent late nights with an American Arium Analyzer
> profiling memory bus transactions on a PPro knows that MESI [...] will
> correctly propogate via the processor caches a write to a locked
> location with a correct load and stor oder without any problems of
> locking concurrency.

Wrong.  They observe no locking problems with their particular test
cases.  The logic analyser doesn't tell you that no code sequence will
exhibit a locking problem.  It also doesn't mean that no future
processor will exhibit the problem.

Instead of using a bus analyzer to see that there's no _symptom_, the
kernel developers looked at Intel's specifications.  A guy from Intel
helped with that.  Eventually it was confirmed that Intel does actually
guarantee 'movb' works for spin-unlock.

At the same time, a few folks ran tests on a number of processors to see
if the ordering specifications were really followed.  A lot of
misunderstanding and confusion did result from that.

Some tests failed, but they were actually the wrong tests for
spin-unlock, which is ok with 'movb'.  They were the right tests for
some other subtle ordering problems though.

In the process, many of us learned a lot about x86 read-write ordering
rules.  Through this, other bugs were found.  See __set_task_state for
example.

If someone had just use the logic analyser, we'd never have constructed
the wrong threading tests, and we probably wouldn't have spotted the
task_state bug.

> Linus' apparently did not understand this, or he would have
> immediately realized that double locking was always generating a
> second non-cacheable memory reference for every lock being taken and
> released.

Erm, I think we _all_ knew about the second memory reference...
But non-cacheable?  On a PPro lock operations are cacheable.

> The person writing and updating page table entries in NetWare 4.1 was
> clearing the accessed bit in the PTE and did not know that the
> processor would assert a hidden R/M/W operation and assert a bus lock
> to set this bit everytime someone cleared it -- it made performance
> drop 4% from NetWare 3.X and noone knew why.  This performance problem
> would have never been found without this tool.  2 years of code
> reviews did not find it -- an American Ariun Analyser with a kernel
> debugger to stop and start and instrument the code with writing custom
> stubs all over the place did.

The kernel developers have known about those R/M/W "hidden cycles"
forever.  See any standard Pentium textbook (or even 386/486 for that
matter).

Heck, even _I_ know this stuff and I've never programmed any page table
code, just read those parts of the kernel.

> Folks who just rely on code reviews never see this level of
> interaction, and conversely, do not have the understanding of hardware
> behavior underneath an OS to optimize it well.

Apparently your engineers didn't read the textbooks.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Marco Colombo]

On Wed, 6 Sep 2000, Linus Torvalds wrote:

> 
> 
> On Wed, 6 Sep 2000, Marco Colombo wrote:
> > 
> > As you said, the are two kinds of reactions. I don't understand why you
> > think that the presence of a debugger will *prevent* people from doing
> > the Right Thing and "think about problems another way". Are debuggers so
> > evil? Will a KDB option in the standard tarball seduce ALL the smart guys
> > , and even YOU, and lead you all to the Dark Side? Do you believe a
> > debugger has such a power?
> 
> Go back. Read the mail again.
> 
> Read the part about weeding out the people who are not careful.
> 
> Think about it. 
> 
> Carefully.

I've done.

I understand you want to implement a filter. You are not trying to increase
the quality of Linux kernel developers as a group, you're just implementing
a 'high level' filter on your mailbox (something procmail is not able to
handle yet), just letting only the people you like in. In that, yes,
you're a bastard. B-) Your right, anyway.

I also understand your 'rabbits' arguments. You don't buy me with them.
Human brains are quite different from rabbits. All historical attempts
to improve them *by selection* failed soundly. You simply don't make people
better *reducing* their freedom. A good programmer is a good programmer
no matter how many debuggers are available out there. I do believe that
Linux kernel programming is NOT the place to start learing programming
at all. So, most kernel newbie are already experienced programmers.
They may have the kind of "taste" you like or not, but hardly you're 
going to change thier habits.  The ones with a bad taste won't be able
to produce patches / bug fixes anyway, so what's the deal? Even if
this is just a mail filter, it is not an effective one. Programmers
who are not careful, the ones you don't like, are not going to produce
anything. With or without a debugger.  And even if they produce bad
patches, you, or some of the guys you like, will look at them, just 
to see where the bug is, and produce better ones.

Of course, all this under the statement that 'you include into your
tarballs whatever you like'. I'm not advocating the inclusion of anything
into the "standard" kernel. I'm just replying to your arguments. 
[ I put this sentence last since I'm a bastard, too... B-) ]

> 
>   Linus
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

.TM.
-- 
  /  /   /
 /  /   /   Marco Colombo
___/  ___  /   /  Technical Manager
   /  /   /  ESI s.r.l.
 _/ _/  _/ [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Henning P. Schmiedehausen]

[EMAIL PROTECTED] (Jeff V. Merkey) writes:

[ Jeff V. Merkey, super man ]

Huh. Once again, none of your facts is straight or correct:


>Famous double YY's of history:

>Good:

[...]
>Albert Einstein


--- cut ---
http://www.aip.org/history/einstein/einbrain.htm

Was Einstein's Brain Different? 

Of course it was-people's brains are as different as their faces. In
his lifetime many wondered if there was anything especially different
in Einstein's. He insisted that on his death his brain be made
available for research. When Einstein died in 1955, pathologist Thomas
Harvey quickly preserved the brain and made samples and sections. He
reported that he could see nothing unusual. The variations were within
the range of normal human variations. There the matter rested until
1999. Inspecting samples that Harvey had carefully preserved, Sandra
F. Witelson and colleagues discovered that Einstein's brain lacked a
particular small wrinkle (the parietal operculum) that most people
have. Perhaps in compensation, other regions on each side were a bit
enlarged-the inferior parietal lobes. These regions are known to have
something to do with visual imagery and mathematical thinking. Thus
Einstein was apparently better equipped than most people for a certain
type of thinking. Yet others of his day were probably at least as well
equipped -Henri Poincaré and David Hilbert, for example, were
formidable visual and mathematical thinkers, both were on the trail of
relativity, yet Einstein got far ahead of them. What he did with his
brain depended on the nurturing of family and friends, a solid German
and Swiss education, and his own bold personality.
--- cut ---

Can't read nothing about "Double-YY" and "third brain" here. 

BTW: The "frequency" is about 1 in 1000 men, not one in 30 million.
(http://www.aaa.dk/turner/engelsk/Xyyen.htm)

Regards
Henning (married to a M.D.)

-- 
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]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Henning P. Schmiedehausen]

[EMAIL PROTECTED] (Jeff V. Merkey) writes:

>They are bad because they cost people money that could be spent more
>productively in other areas due to the lengthening of the development

You still miss the point.

Most kernel developers don't give a damn about money. If you're in
kernel development for money, you're in the wrong game. If you want to
"weed out Linux" from "corporate America", remember

a) this is a free world after all

b) you came to Linux, not Linux to you

c) there is still "corporate France", "corporate Germany", "corporate China"
   to "weed out" "corporate America" once you made a wrong decision. 
   see also "Novell, Inc., Osborne, Inc., Commodore, Inc., Atari, Inc." 
   Why do you think that Microsoft is hiring a "Product Manager Linux". They
   sure as hell won't miss such a decision by accident.

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]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Marco Colombo]

On Sun, 10 Sep 2000, Jeff V. Merkey wrote:

> Since Linus has rejected kdb there's every indication he will reject any other
> kernel debugger submissions -- also his right.  I think my time would be better
> spent completing the merge of the Linux code base onto MANOS since moving the
> debugger over to Linux seems to not be something Linus would adopt and it's
> contrary to his development philosophy, so it's probably a complete waste of my
> time.

You seem to miss the implications of GPL. There's nothing Linus can do
to prevent you from distributing your debugger, both as a patch and
as a part of the kernel, as long as you don't break GPL.
So it won't be 'a complete waste of time'. If your debugger is useful
(and you seem to believe strongly it is), people will start using it anyway,
Linus blessing it or not.

You may notice that *very few* systems out there run a vanilla (Linus')
kernel. They run [a kernel including] many patches which are not 
Linus-blessed. It takes some work if you want to be really up to date
with the lastest vanilla release. But for many systems I run I'm just
quite happy with RedHat updates. As many others are happy with Suse 
reiser-enabled kernels, I believe.

If you don't want to hear from Linus (and others) about how useless/useful
debuggers are, just don't ask them. Post a link to your patch here on l-k,
WITHOUT asking for inclusion. If you do so, I doubt Linus will ever say
a word about that.

> If I get time to create a patch for Linux, I'll put it up.  kdb seems to be
> already there, so folks can use it on Linux for now, and I'll stick to printk()
> and code reviews for my debugging on Linux.

Jeff, there's on think I don't really understand. If the lack of a kernel
debugger does slows YOUR delopment time under Linux down so much, why
don't you take time to write your own debugger (or integrate the one
you already wrote) just for YOU? We'll be glad to see it under GPL,
of course, but that's your choice. Since you seem to think that a debugger
will have an huge impact on development time, you and your company will
have a *great* advantage over competitors when you release it.

> 
> :-)
> 
> Jeff.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

.TM.
-- 
  /  /   /
 /  /   /   Marco Colombo
___/  ___  /   /  Technical Manager
   /  /   /  ESI s.r.l.
 _/ _/  _/ [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

"Jeff V. Merkey" wrote:

> "David S. Miller" wrote:
>
> >Date:Sun, 10 Sep 2000 18:14:03 -0600
> >From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
> >
> >Linus' apparently did not understand this, or he would have
> >immediately realized that double locking was always generating a
> >second non-cacheable memory reference for every lock being taken
> >and released.
> >
> > Jeff, after working together with Linus for 6 or so years myself, I
> > would make a large wager that Linus understands these issues much
> > better than even you.
> >
> > But then again, as previously stated, I don't take you very seriously,
> > but I fear that there are a few on this list who still do.
> >
> > Later,
> > David S. Miller
> > [EMAIL PROTECTED]
>
> David,
>
> You shouldn't fault me because I worked on commercial software for so
> long.  I did the hardware profiling of this stuff in 1993 -- long before
> Linux was even doing SMP.I spent many sleepless nights in Building F
> on the Provo campus comparing 'mov   , 0' and "lock bts, ' to
> see what would happen.  Long before you guys had even written your first
> spinlock ..
>
> Jeff

Also -- your loyalty is admirable -- but that's all it is.

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

"David S. Miller" wrote:

>Date:Sun, 10 Sep 2000 18:14:03 -0600
>From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
>
>Linus' apparently did not understand this, or he would have
>immediately realized that double locking was always generating a
>second non-cacheable memory reference for every lock being taken
>and released.
>
> Jeff, after working together with Linus for 6 or so years myself, I
> would make a large wager that Linus understands these issues much
> better than even you.
>
> But then again, as previously stated, I don't take you very seriously,
> but I fear that there are a few on this list who still do.
>
> Later,
> David S. Miller
> [EMAIL PROTECTED]

David,

You shouldn't fault me because I worked on commercial software for so
long.  I did the hardware profiling of this stuff in 1993 -- long before
Linux was even doing SMP.I spent many sleepless nights in Building F
on the Provo campus comparing 'mov   , 0' and "lock bts, ' to
see what would happen.  Long before you guys had even written your first
spinlock ..

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[David S. Miller]

   Date:Sun, 10 Sep 2000 18:14:03 -0600
   From: "Jeff V. Merkey" <[EMAIL PROTECTED]>

   Linus' apparently did not understand this, or he would have
   immediately realized that double locking was always generating a
   second non-cacheable memory reference for every lock being taken
   and released.

Jeff, after working together with Linus for 6 or so years myself, I
would make a large wager that Linus understands these issues much
better than even you.

But then again, as previously stated, I don't take you very seriously,
but I fear that there are a few on this list who still do.

Later,
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]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Alexander Viro wrote:

> On Sun, 10 Sep 2000, Jeff V. Merkey wrote:
>
> > already there, so folks can use it on Linux for now, and I'll stick to printk()
> > and code reviews for my debugging on Linux.
>
> Jeff, does it mean that you do not use code reviews on other projects?
>
> It's not that hard to answer - just 1 bit of information. The question
> being:
> Do you use code reviews in work on MANOS?

Yes, everyone does.  But there's a class of problems, like hardware and SMP bugs,
where a debugger can help you locate a bug more quickly or profile and observe
performance issues without needing to write tons of code to instrument this type of
monitoring.  I wrote MANOS soley with code reviews, but projects earlier in my
career, I used a lot of tools, like an American Arium Logic Analyser with an Inverse
Assembler and a decent kernel debugger.  The tools gave me the ability to rapidly
master and solve problems that were related to early SMP hardware, and gave me an
understanding.

To cite a Linux specific example, let's take the issue with the memory write for a
spin_unlock().  Linus seemed to have trouble grasping why a simple  ' mov,
0' would work as opposed to a 'lock dec '  Anyone who has ever spent late
nights with an American Arium Analyzer profiling memory bus transactions on a PPro
knows that MESI will correctly propogate via the processor caches a write to a
locked location with a correct load and stor oder without any problems of locking
concurrency.  Linus' apparently did not understand this, or he would have
immediately realized that double locking was always generating a second
non-cacheable memory reference for every lock being taken and released.

There's also hidden latencies in interrupts on Intel.  I know this because I have
watched bus transactions with an analyser and seen an interrupt generate reads of
the IDE, GDT,LDT, PDE, and other tables.  NetWare had a coding error I fixed with
this tool that noone had ever even noticed or caught with a code review.  The person
writing and updating page table entries in NetWare 4.1 was clearing the accessed bit
in the PTE and did not know that the processor would assert a hidden R/M/W operation
and assert a bus lock to set this bit everytime someone cleared it -- it made
performance drop 4% from NetWare 3.X and noone knew why.  This performance problem
would have never been found without this tool.2 years of code reviews did not
find it -- an American Ariun Analyser with a kernel debugger to stop and start and
instrument the code with writing custom stubs all over the place did.

Folks who just relay on code reviews never see this level of interaction, and
conversely, do not have the understnading of hardware behavior underneath an OS to
optimize it well.  That's my case for good tools in an OS.The performance of
Linux vs. NetWare and NT in LAN environments proves this point well.

:-)

Jeff.





>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Paul Jakma]

arrgghh jeff...

On Sun, 10 Sep 2000, Jeff V. Merkey wrote:

> One of the principal architects at Compaq called me Friday after
> reading Linus' email about not caring about commercial or support
> issues for commercialization of Linux on this topic-- his right

yes it his right. he cares about the 'goodness' of the kernel. The
commercial and support issues he doesn't care about - that's the
domain of redhat/suse/compaq/etc../etc... and timpanogas (if you so
choose).

if you need debugger -> add it to your local tree/ship with a
debugger to your customers.

> contrary to his development philosophy, so it's probably a
> complete waste of my time.
> 

linux kernel hackers do the worrying about 'goodness'

but there is *nothing* that stops commerce adding tweaks to help with
support issues! (RedHat/SuSE/etc kernels are heavily patched and
tweaked!)

> Jeff.

-- 
Paul Jakma  [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
C'est magnifique, mais ce n'est pas l'Informatique.
-- Bosquet [on seeing the IBM 4341]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Alexander Viro]

On Sun, 10 Sep 2000, Jeff V. Merkey wrote:

> already there, so folks can use it on Linux for now, and I'll stick to printk()
> and code reviews for my debugging on Linux.

Jeff, does it mean that you do not use code reviews on other projects?

It's not that hard to answer - just 1 bit of information. The question
being:
Do you use code reviews in work on MANOS?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Nathan Paul Simons wrote:

> On Sun, Sep 10, 2000 at 12:15:31AM -0700, J. Dow wrote:
> > Properly contemplated and I wonder at the hypocrisy of using a compiler
> > or an assembler instead of carefully hand crafted bits on a blank disk.
>
> i think you miss the point.  i think that Linus is trying to say
> something along the lines of "A hacker does for love what others would not do
> for money."  Think about it; who would you rather work with: someone who is
> there because they enjoy the work, truly thrive in the environment, and is
> pleasant to be around -or- someone who does it just because they're paid, they
> "only work here" and would prefer a debugger because it means they don't have
> to think as hard.
>

One of the principal architects at Compaq called me Friday after reading Linus'
email about not caring about commercial or support issues for commercialization
of Linux on this topic-- his right -- it had the anticipated impact I would
expect, and it's rippling through the industry.  This topic on kernel debuggers
and Linux kernel development philosophy has been an unknown to a lot of folks in
the commercial software world for a long time and now Linus has made some things
very clear.

Since Linus has rejected kdb there's every indication he will reject any other
kernel debugger submissions -- also his right.  I think my time would be better
spent completing the merge of the Linux code base onto MANOS since moving the
debugger over to Linux seems to not be something Linus would adopt and it's
contrary to his development philosophy, so it's probably a complete waste of my
time.

If I get time to create a patch for Linux, I'll put it up.  kdb seems to be
already there, so folks can use it on Linux for now, and I'll stick to printk()
and code reviews for my debugging on Linux.

:-)

Jeff.



>
> --
> Nathan Paul Simons, Programmer for FSMLabs
> http://www.fsmlabs.com/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Bob Taylor]

In message <[EMAIL PROTECTED]>, Nathan Paul 
Simons writes:
> On Sun, Sep 10, 2000 at 12:15:31AM -0700, J. Dow wrote:
> > Properly contemplated and I wonder at the hypocrisy of using a compiler
> > or an assembler instead of carefully hand crafted bits on a blank disk.
> 
>   i think you miss the point.  i think that Linus is trying to say
> something along the lines of "A hacker does for love what others would not do
> for money."  Think about it; who would you rather work with: someone who is
> there because they enjoy the work, truly thrive in the environment, and is
> pleasant to be around -or- someone who does it just because they're paid, the
>y
> "only work here" and would prefer a debugger because it means they don't have
> to think as hard.

If this is what Linus *actually* means then why didn't he *say* 
so? I personally believe this is what he meant.

Bob

-- 
+---+
| Bob Taylor Email: [EMAIL PROTECTED]|
|---|
| Like the ad says, at 300 dpi you can tell she's wearing a |
| swimsuit. At 600 dpi you can tell it's wet. At 1200 dpi you   |
| can tell it's painted on. I suppose at 2400 dpi you can tell  |
| if the paint is giving her a rash. (So says Joshua R. Poulson)|
+---+


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Nathan Paul Simons]

On Sun, Sep 10, 2000 at 12:15:31AM -0700, J. Dow wrote:
> Properly contemplated and I wonder at the hypocrisy of using a compiler
> or an assembler instead of carefully hand crafted bits on a blank disk.

i think you miss the point.  i think that Linus is trying to say
something along the lines of "A hacker does for love what others would not do
for money."  Think about it; who would you rather work with: someone who is
there because they enjoy the work, truly thrive in the environment, and is
pleasant to be around -or- someone who does it just because they're paid, they
"only work here" and would prefer a debugger because it means they don't have
to think as hard.

-- 
Nathan Paul Simons, Programmer for FSMLabs
http://www.fsmlabs.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Linus Torvalds]

On Sun, 10 Sep 2000, J. Dow wrote:
> > 
> >   [ Insert a silent minute to contemplate the beaty of the world here. ]
> 
> Properly contemplated and I wonder at the hypocrisy of using a compiler
> or an assembler instead of carefully hand crafted bits on a blank disk.

You know, Dow, if I were to see any code from you, rather than just hot
air, I might be more inclined to listen.

Yeah, if you want a carpenter that works with his _teeth_, then go right
ahead.

Feel free to ignore my arguments. But _please_ also feel free to stop
filling my mailbox with inane and stupid comments.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Aki M Laukkanen]

On Sun, 10 Sep 2000, Horst von Brand wrote:
> I've found more bugs by "working half crippled" (as you call it). I do
> agree with Linus that people who rely mainly on debuggers for finding and
> fixing bugs are on the whole bad programmers, I've had to deal with more

I've resisted from participating this thread but as it seems to drag forever,
what the heck (probably a bad move). Your argument has the flaw that all
programmers using debuggers are bad programmers, programmers who have
no self-discipline, no guts to actually find out what was wrong. Just as any
tool, debuggers can be abused but they should not be condemned on that basis
alone. 

On another note, I think even those bad, lazy programmers are intelligent
enough to find kdb on the net and patch it into their kernels. The mere
availability of the tools then should be enough for explosion of bad code
but has this happened? On the other hand, those people who are not
knowledgeable enough to mess with patches, system administrators or end
users have no access to the tools when they need it. For example for a 
driver author who is trying to debug a problem he can't reproduce by
himself, it would be useful to instruct the bug reporter to enter the
debugger, execute these commands and mail the results back to himself.
Debugger would simply be a tool to get wider knowledge of the kernel state
than a simple oops dump. 

Dave Miller explains his methods for finding and fixing bugs in the code
which seem logical enough but who gets to decide what's enough knowledge of
the kernel state? Currently it is oops and nothing but the oops. If taken
to its logical extreme, one could argue that oopses should be removed too.
Afterall they perform the same function as printing the register
dump and the stack backtrace in a debugger would.

-- 
D.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Horst von Brand]

"J. Dow" <[EMAIL PROTECTED]> said:

[...]

> And for my severely depreciated $0.02 I am becoming concerned
> that these guys are more concerned about some macho ideal of
> generating programs while half crippled than about having things
> work properly and maintainably no matter what gets in the way.

The problem is that yes, debuggers are useful tools. But they are _not_
general-purpose tools, very far from it. Yes, I've found my share of bugs
in programs using debuggers. But by far (I'd say by some 10 times or so)
I've found more bugs by "working half crippled" (as you call it). I do
agree with Linus that people who rely mainly on debuggers for finding and
fixing bugs are on the whole bad programmers, I've had to deal with more
than enough students working that way and just applying random symptom
fixes until the program didn't crash anymore or even did finally pass a
(very limited) set of testcases. It is rare cases where a debugger is of
real help, and for a kernel even more rare cases than in the heaven of
userland programming, where no other thread messes up your variables, and
where execution is deterministic.

Please remember that Linus' workload is staggering as it is; if you throw
in 20 times as many patches as he gets today, of which 99% are bandaids
over the symtoms of the bug, nothing at all will get done.

> Art has flaws in it that have been painted over, often two or three
> times. I grew up with a giant painting of Beethoven along side the
> dinner table. It had been presented to my step-grandfather by
> the Leipzig Symphony Orchestra. It captured the brooding artist
> wonderfully. And in humid weather you could see his third hand,
> the one the artist didn't like and painted over.

Yep. linux-1.0 is long history. There might be a few lines of it
surviving somewhere in the current kernel...

> For all the zen meditation on code I begin to wonder how many of
> the fixes really are fixes or painted over features that didn't quite
> work out. It worries me no small bit.

Check the result: Does it feel like a cobbled up mess that just happens to
work by chance? AFAIKS, the result shows that Linus' development strategy
works extremely well most of the time. You might not like parts of it, it
isn't exactly politically correct, and isn't buzzword-compliant either, but
it works.

In the end, this is Linus' game. If you want to play, you'll have to pay the
admission price he sets. As it is GPL, you could fork the kernel, add a GUI
debugger to it, and open your own shop.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Daniel Phillips]

Linus Torvalds wrote:
> 
> It's not whether you can use tools to do the work.
> 
> It's about what kind of people you get.

This makes a lot of sense.  Stop there and you are done.  But...

> ...in the end, maybe the rule to only use hand power makes sense. Not
> because hand-power is _better_. But because it brings in the kind of
> people who love to work with their hands, who love to _feel_ the wood with
> their fingers, and because of that their holes are not always perfectly
> aligned, not always at the same place. The kind of carpenter that looks at
> the grain of the wood, and allows the grain of the wood to help form the
> finished product.

This argument would make a lot more sense if we were still building
wooden airplanes.  But our wooden airplane is already built, and it
flys great.  Now we are going on to build a metal airplane which we
hope will fly higher and faster.  Yes, the old tools and techniques
still work, but they aren't necessarily well-suited to the task.

Arguing that hand tools are somehow better than power tools is... just
an argument.  It does not matter which kind of tool is better, because
both are available.  In contrast, the social engineering part does
matter - after all, would you want to attract someone to kernel
development who refused to use a tool just because it didn't come
pre-installed?  And look at the quality of the people now working on
the kernel - something has been done right.  

The result of this thread is that at least one participant (Jeff) has
been inspired to build a new-and-better kernel debugger for Linux.  If
that work comes to fruition (1) I will most happily use it and (2) the
discussion was worth it.  I don't give a rat's fuzzy behind who won
the argument.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Andrew Morton]

Michael Elizabeth Chastain wrote:
> 
> Rather than discussing what he's said, I ask: OK, if an integrated kernel
> debugger is inimical to developing more gurus, what contributions would
> Linus welcome?
> 
> More documentation, so that more people can understand more deeply?
> 
> Cleanup patches, to reduce the complexity that people have to wade through?
> Linus already seems very friendly to such patches (except when he's
> trying to push out a stable release).
> 
> More commentary with submitted patches?  Russ Nelson used to write linux
> kernel patch summaries, and so did I.  It would be a lot easier if
> the people who wrote the patches wrote that commentary, and if it
> were kept with the patches or near the patches.
> 
> A source control system so that curious people could do the equivalent of
> "cvs annotate" and figure out who wrote particular pieces?

Comments.  You know, these things:

/* Stuff goes here */

Comments communicate the design intent.  Code communicates the
implementation.  The process of finding discrepancies between these is
known as "debugging".

The process of divining the design intent from the implementation is
known as "a waste of time", and is frequently impossible because of
information loss.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Michael Elizabeth Chastain]

OK, I give in, I'll post some opinions in this advocacy-like thread.

One of the original connotations of "hacker" was someone who made
furniture with an axe.

There is a difference between a debugger and a compiler.  A compiler
never substitutes for understanding.  In fact, I gain more understanding
from reading C source code than I would from reading handcrafted machine
code or handcrafted assembly code.

Lastly, I believe Linus has said two things: (1) he prefers to work with
people who deeply understand the part of Linux that they work on, and (2)
he believes that an integrated kernel debugger would be detrimental to
(1).

Rather than discussing what he's said, I ask: OK, if an integrated kernel
debugger is inimical to developing more gurus, what contributions would
Linus welcome?

More documentation, so that more people can understand more deeply?

Cleanup patches, to reduce the complexity that people have to wade through?
Linus already seems very friendly to such patches (except when he's
trying to push out a stable release).

More commentary with submitted patches?  Russ Nelson used to write linux
kernel patch summaries, and so did I.  It would be a lot easier if
the people who wrote the patches wrote that commentary, and if it
were kept with the patches or near the patches.

A source control system so that curious people could do the equivalent of
"cvs annotate" and figure out who wrote particular pieces?

Michael Elizabeth Chastain

"love without fear"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[John Alvord]

On Sun, 10 Sep 2000 00:23:43 -0700, "J. Dow" <[EMAIL PROTECTED]>
wrote:

>From: "Stephen E. Clark" <[EMAIL PROTECTED]>
>
>> Linus Torvalds wrote:
>> >
>> > On Sat, 9 Sep 2000, Oliver Xymoron wrote:
>> > >
>> > > Tools are tools. They don't make better code. They make better code easier
>> > > if used properly.
>> >
>> > I think you missed the point of my original reply completely.
>> >
>> > The _technical_ side of the tool in question is completely secondary.
>> >
>> > The social engineering side is very real, and immediate.
>> ...
>>
>> > Linus
>> >
>>
>> Then why don't we get rid of the compilers and assemblers and go back to
>> the old way of doing it
>> all - coding on the bare metal. Believe it or not at one time it was
>> done this way. Imagine where
>> we would be if everyone had said lets not invent tools to make ourselves
>> more productive.
>>
>> My $.02
>>
>> Steve Clark
>
>And for my severely depreciated $0.02 I am becoming concerned
>that these guys are more concerned about some macho ideal of
>generating programs while half crippled than about having things
>work properly and maintainably no matter what gets in the way.
>Art has flaws in it that have been painted over, often two or three
>times. I grew up with a giant painting of Beethoven along side the
>dinner table. It had been presented to my step-grandfather by
>the Leipzig Symphony Orchestra. It captured the brooding artist
>wonderfully. And in humid weather you could see his third hand,
>the one the artist didn't like and painted over.
>
>For all the zen meditation on code I begin to wonder how many of
>the fixes really are fixes or painted over features that didn't quite
>work out. It worries me no small bit.
>
> and here I thought macho didnt' fit well with people who
>used their brains. I see it is as alive and well here as on the
>streets of East LA.
>
>{O.O}

How can anyone judge that a debugger was used in development of a
patch, along with system understanding, Linux knowledge, etc? The
changed code stands along with no provenance. If it reflects a shallow
understanding, it will be rejected. If it is a deep elegant fix, that
will stand on its merits.

john alvord
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[J. Dow]

From: "Stephen E. Clark" <[EMAIL PROTECTED]>

> Linus Torvalds wrote:
> >
> > On Sat, 9 Sep 2000, Oliver Xymoron wrote:
> > >
> > > Tools are tools. They don't make better code. They make better code easier
> > > if used properly.
> >
> > I think you missed the point of my original reply completely.
> >
> > The _technical_ side of the tool in question is completely secondary.
> >
> > The social engineering side is very real, and immediate.
> ...
>
> > Linus
> >
>
> Then why don't we get rid of the compilers and assemblers and go back to
> the old way of doing it
> all - coding on the bare metal. Believe it or not at one time it was
> done this way. Imagine where
> we would be if everyone had said lets not invent tools to make ourselves
> more productive.
>
> My $.02
>
> Steve Clark

And for my severely depreciated $0.02 I am becoming concerned
that these guys are more concerned about some macho ideal of
generating programs while half crippled than about having things
work properly and maintainably no matter what gets in the way.
Art has flaws in it that have been painted over, often two or three
times. I grew up with a giant painting of Beethoven along side the
dinner table. It had been presented to my step-grandfather by
the Leipzig Symphony Orchestra. It captured the brooding artist
wonderfully. And in humid weather you could see his third hand,
the one the artist didn't like and painted over.

For all the zen meditation on code I begin to wonder how many of
the fixes really are fixes or painted over features that didn't quite
work out. It worries me no small bit.

 and here I thought macho didnt' fit well with people who
used their brains. I see it is as alive and well here as on the
streets of East LA.

{O.O}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[J. Dow]

From: "Linus Torvalds" <[EMAIL PROTECTED]>
> Yes, using a power-drill and other tools makes a lot of carpentry easier.
> To the point that a lot of carpenters don't even use their hands much any
> more. Almost all the "carpentry" today is 99% automated, and sure, it
> works wonderfuly - especially as you in carpentry cannot do it any other
> way if you want to mass-produce stuff.
> 
> But take a moment to look at it the other way. 
> 
> If you want to find the true carpenters today, what do you do? Not just "a
> carpenter". But THE carpenter.
> 
> I'm saying that maybe you put up a carpentry shop where everything is
> lovingly hand-crafted and tools are not considered to be the most
> important part - or even necessarily good. And yes, some people
> (carpenters in every sense of the word) will be frustrated. They can't use
> the power-lathe that they are used to. It doesn't suit them. They _know_
> that they are missing something.
> 
> But in the end, maybe the rule to only use hand power makes sense. Not
> because hand-power is _better_. But because it brings in the kind of
> people who love to work with their hands, who love to _feel_ the wood with
> their fingers, and because of that their holes are not always perfectly
> aligned, not always at the same place. The kind of carpenter that looks at
> the grain of the wood, and allows the grain of the wood to help form the
> finished product.
> 
> The kind of carpenter who, in a word, is more than _just_ a carpenter.
> 
>   [ Insert a silent minute to contemplate the beaty of the world here. ]

Properly contemplated and I wonder at the hypocrisy of using a compiler
or an assembler instead of carefully hand crafted bits on a blank disk.

{o.o}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Linus Torvalds wrote:

> 
> I think you missed the point of my original reply completely.
> 
> The _technical_ side of the tool in question is completely secondary.
> 
> The social engineering side is very real, and immediate.
> 
> It's not whether you can use tools to do the work.
> 
> It's about what kind of people you get.
>

Linus,

I think everyone respects your opinion here, but it's the difference
between a paintbrush and a spray can.  Some artists paint with a camel
hair brush, some paint with a spray can (like an air  brush artist does)
-- graffitti artists are even more crude, and use a spray can and a
concrete wall.  

Putting in kdb or anything else as a config option for "make config"
won't matter one way or the other relative to the development or
"weeding out" of kernel developers.  After all, you may want someone
around who looks up at the sky every once and a while for asteroids
heading towards earth.   

One thing that will happen if you do this is that Linux kernel evolution
will explode, since the debugger will act a lot like ultra-violet
radiation, and cause myriad Linux mutations to appear rapidly.  Darwinsm
relies on two principals to work - random mutations, and environmental
pressure.  Your analogy describes only one side -- encironmental
pressure, while on the other you are limiting the process of mutation.  

If you require that all Linux kernel work be "aryan" (not meant to
offend anyone in Germany), and all Linux code must have blue eyes and
blonde hair, this process will not promote the other side of the
equation, since the process of mutation is in essence halted.  Breeding
with dogs and horses over centuries has proven this.  Pure bred dogs
suffer from a long list of genetic maladies due to in-breeding and
line-breeding, such a abiotrophy, ataxia, and other problems.

:-)

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Stephen E. Clark]

Linus Torvalds wrote:
> 
> On Sat, 9 Sep 2000, Oliver Xymoron wrote:
> >
> > Tools are tools. They don't make better code. They make better code easier
> > if used properly.
> 
> I think you missed the point of my original reply completely.
> 
> The _technical_ side of the tool in question is completely secondary.
> 
> The social engineering side is very real, and immediate.
...

> Linus
> 

Then why don't we get rid of the compilers and assemblers and go back to
the old way of doing it
all - coding on the bare metal. Believe it or not at one time it was
done this way. Imagine where
we would be if everyone had said lets not invent tools to make ourselves
more productive.

My $.02

Steve Clark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Oliver Xymoron]

On Sat, 9 Sep 2000, Linus Torvalds wrote:

> On Sat, 9 Sep 2000, Oliver Xymoron wrote:
> > 
> > Tools are tools. They don't make better code. They make better code easier
> > if used properly.
> 
> I think you missed the point of my original reply completely.
[...]
> It's about what kind of people you get.
[...]
> If you want to find the true carpenters today, what do you do? Not just "a
> carpenter". But THE carpenter.
> 
> I'm saying that maybe you put up a carpentry shop where everything is
> lovingly hand-crafted and tools are not considered to be the most
> important part - or even necessarily good. And yes, some people
> (carpenters in every sense of the word) will be frustrated. They can't use
> the power-lathe that they are used to. It doesn't suit them. They _know_
> that they are missing something.

No. You set out to create a product you care about and create an
environment where good taste and talent (with or without particular tools)
is valued and shared. Outside of the debugger maintenance issue, that's
more or less what I see here today.

> But in the end, maybe the rule to only use hand power makes sense. Not
> because hand-power is _better_. But because it brings in the kind of
> people who love to work with their hands, who love to _feel_ the wood with
> their fingers, and because of that their holes are not always perfectly
> aligned, not always at the same place. The kind of carpenter that looks at
> the grain of the wood, and allows the grain of the wood to help form the
> finished product.
> 
> The kind of carpenter who, in a word, is more than _just_ a carpenter.
> 
>   [ Insert a silent minute to contemplate the beaty of the world here. ]
> 
> Go back and read my original reply to this thread.
> 
> Really _understand_ the notion of two kinds of people. 
 
I think I do. I also understand that half of the fun of producing any
program is to make something of utility, not a pure work of art. 'Show me
the code' means create something that works and don't spend the next 10  
years doing it, no?

> And think about what kind of people you'd like to work with.

The primary mechanism for "selecting for" and encouraging those traits is
code review, not barriers to entry. Add an IKD build option and
maintainers will suddenly start accepting "this seems to fix it but I have
no idea why" patches? I don't think this follows.

More likely is that slightly more programmers, and therefore slightly more
potentially good programmers will get their feet wet in the kernel source
by attempting to debug their own problems. 
  
--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Oliver Xymoron]

[reposted for the benefit of anyone wondering what Linus was replying to]

On Sat, 9 Sep 2000, Oliver Xymoron wrote:

> On Sat, 9 Sep 2000, Linus Torvalds wrote:
> 
> > I use revision control at work. We use CVS on steroids - CVS with a lo tof
> > the extensions available, and with a "mad scientists helper" program
> > called "igor".
> [...]
> > And with a chip that _includes_ a compiler, we have some debuggers that I
> > don't think exist anywhere else on the planet. Which turns out very useful
> > when the first version of the silicon doesn't actually act the way we
> > thought it would ;)
> 
> I figured as much on both counts, actually - I was mostly razzing you.
>  
> > So I've seen both. And I still don't think they make for better code. They
> > sometimes make for more expedient release schedules. Which is not the same
> > thing at all.
> 
> I think the only one who's argued from the release schedule POV is Jeff
> Merkey. The rest are arguing that debuggers are sometimes useful tools[1].
> 
> Tools are tools. They don't make better code. They make better code easier
> if used properly. Companies are using drills and lathes and table saws and
> power sanders to produce furniture that doesn't compare to antiques made
> with hand tools[2]. Does this mean we should make everything by hand? No,
> it just means we need to be focused on craftsmanship rather than cost.
> I think the current development culture already has that focus.
> 
> Fact is, the kernel debugging tools are, just like drivers, best
> maintained with the kernel proper. 
> 
> Either DM or AV referred to K&P's _Practice of Programming_ (p118) in
> defense of the avoiding debugger argument. If you have it handy, give that
> chapter a read. They devote pretty much their entire chapter on debugging
> to the printf school and most of the book lines up with your code quality
> philosophy but they still conclude that "a debugger can be of enormous
> value, however, and you should certainly include one in your debugging
> toolkit.."
> 
> [1] Compare TM's core debuggers to the usefulness of something like IKD
> for early work on a new port.
> 
> [2] Note that you're only looking at the antiques that were built well
> enough to be around for comparison.
> 
> --
>  "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 
> 
> 

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Linus Torvalds]

On Sat, 9 Sep 2000, Oliver Xymoron wrote:
> 
> Tools are tools. They don't make better code. They make better code easier
> if used properly.

I think you missed the point of my original reply completely.

The _technical_ side of the tool in question is completely secondary.

The social engineering side is very real, and immediate.

It's not whether you can use tools to do the work.

It's about what kind of people you get.

You were the one who brought up the power drill analogy. I'll take it, and
run with it, and maybe you can see _my_ point by me taking your analogy
and running with it.

Yes, using a power-drill and other tools makes a lot of carpentry easier.
To the point that a lot of carpenters don't even use their hands much any
more. Almost all the "carpentry" today is 99% automated, and sure, it
works wonderfuly - especially as you in carpentry cannot do it any other
way if you want to mass-produce stuff.

But take a moment to look at it the other way. 

If you want to find the true carpenters today, what do you do? Not just "a
carpenter". But THE carpenter.

I'm saying that maybe you put up a carpentry shop where everything is
lovingly hand-crafted and tools are not considered to be the most
important part - or even necessarily good. And yes, some people
(carpenters in every sense of the word) will be frustrated. They can't use
the power-lathe that they are used to. It doesn't suit them. They _know_
that they are missing something.

But in the end, maybe the rule to only use hand power makes sense. Not
because hand-power is _better_. But because it brings in the kind of
people who love to work with their hands, who love to _feel_ the wood with
their fingers, and because of that their holes are not always perfectly
aligned, not always at the same place. The kind of carpenter that looks at
the grain of the wood, and allows the grain of the wood to help form the
finished product.

The kind of carpenter who, in a word, is more than _just_ a carpenter.

  [ Insert a silent minute to contemplate the beaty of the world here. ]

Go back and read my original reply to this thread.

Really _understand_ the notion of two kinds of people. 

And think about what kind of people you'd like to work with.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 06.09.00 in 
<[EMAIL PROTECTED]>:

> On Wed, 6 Sep 2000, Tigran Aivazian wrote:
> >
> > very nice monologue, thanks. It would be great to know Linus' opinion. I
> > mean, I knew Linus' opinion of some years' ago but perhaps it changed? He
> > is a living being and not some set of rules written in stone so perhaps
> > current stability/highquality of kdb suggests to Linus that it may be
> > (just maybe) acceptable into official tree?
>
> I don't like debuggers. Never have, probably never will. I use gdb all the
> time, but I tend to use it not as a debugger, but as a disassembler on
> steroids that you can program.
>
> None of the arguments for a kernel debugger has touched me in the least.
> And trust me, over the years I've heard quite a lot of them. In the end,
> they tend to boil down to basically:
>
>  - it would be so much easier to do development, and we'd be able to add
>new things faster.

That's never been my argument. My argument has always been "it's far  
easier to *understand* tough bugs with a debugger".

BTDTGTTS. *Easy* bugs don't *need* a debugger to fix.

Tough bug: a place where reality doesn't match your understanding.

In which case, you often need to go exploring. Which is roughly 100 times  
as fast with a debugger compared to, say, printk. (Think about it. You get  
a new idea what to look at, you insert a new printk, you recompile, you  
reboot, you re-trigger the bug. Whereas if you're running a debugger, you  
just examine a different piece of memory.)

Often you look at various different places before you finally locate the  
one that's giving you the missing clue.

> And quite frankly, I don't care. I don't think kernel development should
> be "easy". I do not condone single-stepping through code to find the bug.
> I do not think that extra visibility into the system is necessarily a good
> thing.

Well, it's pretty certainly never a *bad* thing.

> To me, it's not a bug, it's a feature. Not only is it documented, but it's
> _good_, so it obviously cannot be a bug.

Sorry, you haven't shown it's good either. All the claims about it weeding  
out poor techniques I've seen lacked any serious support.

There's one thing that can make for debugger abuse (but in fact can abuse  
any other debugging technique just as well): management pressure.

But "management pressure" does not seem to apply to Linux kernel  
development in any meaningful way. Everybody wo looks even remotely like a  
Linux kernel development manager (such as the Messiers Torvalds, Cox,  
Miller, and so on) already understands about good and bad bugfixes, and  
how "we must get this out to the customer or lose $$$" is a bad argument.

>  My biggest job is to say
> "no" to new features, not trying to find them.

So, if someone with a debugger creates a bad patch, nobody is forcing you  
to accept that patch.

> Oh. And sure, when things crash and you fsck and you didn't even get a
> clue about what went wrong, you get frustrated. Tough. There are two kinds
> of reactions to that: you start being careful, or you start whining about
> a kernel debugger.

I don't even see that a debugger makes all that much difference in *that*  
scenario. When you have a bug that corrupts the fs, how is a debugger  
magically going to remove that corruption?!

What it can do is make you understand what's going on faster. And that  
*is* a good thing. Always.

> Quite frankly, I'd rather weed out the people who don't start being
> careful early rather than late. That sounds callous, and by God, it _is_
> callous. But it's not the kind of "if you can't stand the heat, get out
> the the kitchen" kind of remark that some people take it for. No, it's
> something much more deeper: I'd rather not work with people who aren't
> careful. It's darwinism in software development.

Except that "careful" doesn't seem even remotely relevant to the question.  
I certainly don't see how a debugger lets you be less careful.

> I'm a bastard. I have absolutely no clue why people can ever think
> otherwise. Yet they do. People think I'm a nice guy, and the fact is that
> I'm a scheming, conniving bastard who doesn't care for any hurt feelings
> or lost hours of work if it just results in what I consider to be a better
> system.

But it doesn't. I'm pretty convinced that in this point, you're entirely  
barking up the wrong tree.

> I happen to believe that not having a kernel debugger forces people to
> think about their problem on a different level than with a debugger. I

I happen to believe that this is just plain wrong.

> think that without a debugger, you don't get into that mindset where you
> know how it behaves, and then you fix it from there. Without a debugger,
> you tend to think about problems another way. You want to understand
> things on a different _level_.

Maybe you do - I certainly don't.

In fact, it's often been exactly the other way around for me. With a  
working debugger, I can und

Re: Availability of kdb

[Oliver Xymoron]

On Wed, 6 Sep 2000, Linus Torvalds wrote:

> Apparently, if you follow the arguments, not having a kernel debugger
> leads to various maladies:
>  - you crash when something goes wrong, and you fsck and it takes forever
>and you get frustrated.
>  - people have given up on Linux kernel programming because it's too hard
>and too time-consuming
>  - it takes longer to create new features.
> 
> And nobody has explained to me why these are _bad_ things.

There are those, but there are others, most of which are so obvious[1]
we're not mentioning them, assuming you're familiar with them too. I
usually eschew debuggers as well, but I'm beginning to suspect that you've
spent so much of your programming life immersed in the kernel that you
haven't used a debugger enough to know what sorts of things it's actually
good for. Not all the world's a nail, but there are times when the bigger
hammer approach is the right one.

One of these days you should give revision control a try too. Not to
mention bug tracking. :P

[1] eg I've found many a compiler bug in 5 minutes of single stepping that
days of eyeballing source and adding printfs failed to discover. 

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Michael Elizabeth Chastain]

> There are people today that refuse to use computers for writeing,
> and they have good arguments, ...

Harken back to David Miller, who wrote about occupying his hands
with something to keep them the hell off the keyboard while he is
meditating on a screen full of code.

One of my debugging tools is a printer.  I print out bunches of
source code and trace files and then I go to a room *without* any
computers in it and I read for a while.

And I still write a lot of source code with pen and paper.

Michael Elizabeth Chastain

"love without fear"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Patrick J. LoPresti]

Linus Torvalds <[EMAIL PROTECTED]> writes:

> Sure. I just don't see many end-users single-stepping through
> interrupt handlers etc.
> 
> But yes, there probably are a few.

I think you would be surprised, and I speak as someone who has found
and fixed race conditions in your kernel.

There are more Linux users who are competent with x86 hardware and SMP
issues than there are Linux developers.  A *lot* more.

When these technically savvy users have a problem, they want to
diagnose it as best they can and then hand it off to a kernel expert
to analyse and to fix.  They wish they had the time to understand the
kernel deeply and come up with the "right" solution, but they don't;
and the expert can do the job ten times faster anyway.

If you give us better diagnostic tools, your kernel *will* improve
faster.  Whether this benefit outweighs the cost is, of course, up to
you.

 - Pat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Andrew Scott]

On 6 Sep 2000, at 14:03, Linus Torvalds wrote:

> In article <[EMAIL PROTECTED]>,

> >Linus Torvalds wrote:
> 
> Think of rabbits. And think of how the wolf helps them in the end. Not
> by being nice, no. But the rabbits breed, and they are better for having
> to worry a bit.

No matter how much they think about it, or how smart they are, 
they'll alway be food for wolves unless they develop the ability to 
use tools. It isn't smarts and thinking, though they certainly help, 
it's the ability to make and use tools that does it.  

There are all kinds of tools. In many cases you don't need to use 
them. War and Peace was written with a pen. There are people today 
that refuse to use computers for writeing, and they have good 
arguments, but if Tolstoy was born today, he'd probably use a Word 
processor, and he'd probably have written a sequel! It probably 
wouldn't have been the same book, though, and this is not to say it 
would be any better or worse. At least one writer that I'm aware of, 
output slowed considerably when he switched to a word processor 
because it became so easy to edit, that he spent much more time 
tweaking his work.

Most of the people who write and don't use a word processing 'tool' 
are people who didn't grow up with them.

Linux is really just a hobby for a few people. The sort of people who 
insist on climbing cliffs without safety gear. This is ok. It's your 
hobby, but I think that people should understand that it _is_ a hobby.



--Mailed via Pegasus 3.12 & Mercury 1.44---
[EMAIL PROTECTED]Fax (617)373-2942
Andrew Scott   Tel (617)373-5278   _
Northeastern University--138 Meserve Hall / \   /
College of Arts & Sciences-Deans Office  / \ \ /
Boston, Ma. 02115   /   \_/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[Chris Meadors]

Now that is what I want on a t-shirt.  ;)

On Thu, 7 Sep 2000, Peter Samuelson wrote:

> [Now, centuries-old theological arguments may well be of supreme
> importance in some ways -- an undeniably subjective and personal
> judgment -- but in terms of Linux kernel development they are usually
> considered even more off-topic than the latest clever AC quote.]

-- 
Two penguins were walking on an iceburg.  The first one said to the
second, "you look like you are wearing a tuxedo."  The second one said,
"I might be..."
  --David Lynch, Twin Peaks

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[J. Dow]

Timur,
> Well, if it really is just his hobby, then he shouldn't be chanting the "World
> Domination" mantra.  Either Linux belongs to Linus, in which case it's
> irrelevant outside his personal world, or it is a tool for all computer users.
> If Linus really doesn't care who uses his OS, then he should not be
encouraging
> community participation, and he shouldn't be accepting speaking engagements at
> major conventions where business users attend to decide whether Linux is for
> them or not.

Shh, you're not supposed to notice that man behind the curtain
over there that your annoying little doggy found.

{^_-}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[J. Dow]

From: "Horst von Brand" <[EMAIL PROTECTED]>

> "J. Dow" <[EMAIL PROTECTED]> said:
> 
> [...]
> 
> > The point is that WITH a debugger you have to take that step as well.
> > A person without the self discipline to do that is still a child and should
> > not be in this business. The debugger gives you a better picture of what
> > is actually happening. If that leverage is considered to be a bad thing
> > I am surprised and dismayed. A bloody LOT of personal experience 
> > and technological bloody noses suggests it is a very good thing.
> 
> This is true as long as the debugger hooks have no (or very minimal) impact
> on the instrumented system. Impossible (or very nearly so) in the case of a
> massively parallel program like the kernel. Where it is possible it has
> been done, in general. General hooks into the distributed subsystems inside
> the kernel are only a bit easier to maintain than the instrumented code,
> and they impact its performance, stability and readability.

Oh bat doodoo. In the first place you use a debug build with the debugger
built in for debugging. You run a real build without the debugger for
production. In the second place since you have the sense to do the
aforementioned good practice you keep in mind that there are interactions
involved to indicate whether the problem goes away or not and how the
problem manifestation changes with the debugger present. In the third
place if you are reduced to printk you can have even worse timing issues
than with a well constructed debugger.

If you have that well constructed debugger you have a patch to install it.
If there is a "make debugged" and "make nondebugged" command in
the kernel Makefile and the debugger is not patched in for most people
until they issue the "make debugged" command you have exactly what
you have now with the addition of a debugger for which there is a huge
incentive to maintain it.

Heck, run up proposed patches in the debugger, confirm your desk
analysis of what they do, THEN install the patches into the kernel
formally. (And for Ghu's sake make it a source level debugger if you
want it to work right.)

> You did not build a logic analyzer and circuit simulator into each and
> every transmitter you built, did you?

I built in the test points these tools attached to in each and every module
of each and every radio. Except obviously the simulator was used before
hand to predict circuit performance. If you design for proper testpoints
there is little or no affect on operation and a great improvement in ease
of maintenance and tuneup.

> I've used debuggers too, and do so sometimes to check on stuff I write when
> I'm truly stumped, but in general I stay away from them. I (try to) write
> stuff in modular, cleanly separate parts with (I hope) well understood
> interactions. That makes isolating bugs easy enough without a detailed
> step-by-step following of the program, at least most of the time. Debuggers
> _can_ be useful, no question about that. But you can also waste a huge
> amount of time with them. They just give you _one_ very narrow picture of
> what is going on, and that picture is from a quite useless perspective most
> of the time.

That design approach plus a good debugger can reach the finished line
of clean completed and debugged (to the same level) code quicker than
without the good debugger. The times I have most loved the debugger are
when the code generated is very different from the code laid down either
due to a typo I continually overlooked (I am human  -  I think) or a compiler
bug. Sometimes it actually adds time to development if I didn't NEED to run
that debugger based verification that what I intended is what appeared.
(Sadly I don't quite have the self-discipline to make that run EVERY time
and even worse sometimes I have not had the debugger to work with.)
So far I have noticed that the debuggers catch a wider range of issues
than the desk analysis.

{^_^}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[Peter Samuelson]

  [Tigran]
> > I like this one even better:
> > 
> > "Little children, keep yourselves from idols" -- St John, Ist century.

[rgooch]
> Hm. Does that apply also to all the statues of saints, the virgin
> mother and all those crosses with Jesus that you find in churches,
> hanging off people's necks and in some places on every street corner?

Why, yes it does, IMO.  In fact ... [snaps fingers] you appear to have
rediscovered a centuries-old argument, and the single biggest problem
many of us Protestants have with Roman Catholic doctrine & practice.

[Now, centuries-old theological arguments may well be of supreme
importance in some ways -- an undeniably subjective and personal
judgment -- but in terms of Linux kernel development they are usually
considered even more off-topic than the latest clever AC quote.]

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[Michal Jaegermann]

Jamie Lokier wrote:
> World Domination is my hobby too :-)

Now, that is THE T-shirt!  What should be added?  A flock of penguins
in an attack mode. :-)

  --mj
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[lamont]

On Thu, 7 Sep 2000, Alexander Viro wrote:
> On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote:
> > scale in the end.  We'll either see forking, see another OS like FreeBSD
> > fill the void, or (worst case) Solaris.
> 
> Somehow I doubt that arguments from marketshare/field circus/etc. peppered
> with threats of coprorat world turning to Solaris, etc. will win you much
> love from FreeBSD core team.

First of all I'm not trying to threaten anyone.  Second of all, I'm not
trying to affect FreeBSD at all.  I'm pointing out there's a
void.  FreeBSD could fill that void.  Or they could choose not to.

> I _really_ doubt that they will make any
> effect on the development decisions. You see, these guys are bastards
> too - comes with the territory. So are NetBSD and OpenBSD folks - try to
> speak to Theo that way and you will realize that Linus _is_ a nice guy,
> after all.

I've gotten into flamewars with Theo on comp.security.unix before.  You
don't need to explain that to me either.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/