Re: Availability of kdb
** 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
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
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
** 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
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
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
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
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
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
"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
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
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
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
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
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
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
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 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
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
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
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
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, 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
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
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
"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
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
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
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 > Workshop". I love to watch it, just to count the number of power tools Norm
RE: Availability of kdb
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[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
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
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
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
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
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
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
> "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, ) 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
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
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
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
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
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
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
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, 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
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
> > 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
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
> "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
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
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
[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
[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
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" 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
"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
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
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
"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
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
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
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
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
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
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 addr" 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 addr,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 addr,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 addr,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
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
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, 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
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
"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
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
[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
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: snip 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/
