From: "Horst von Brand" <[EMAIL PROTECTED]>
> Problem is:
>
> - Debugging code has to be written, integrated and debugged. It has to be
> designed for collecting certain types of data. If you get the data to be
> collected wrong, it is useless (and as you don't know what bugs you are
>
> > A good debugger is a very
> > good leveraging agent. I can cut a 2x4 with a largish pocket knife,
> > in theory. (I have never wasted the time.) In a pinch I have cut a
> > 2X4 with a hand saw. I can see that if I wanted to do this for any
> > serious work power tools are required. The same
-BEGIN PGP SIGNED MESSAGE-
To do this, we need to be taught how. Where are the manuals
for these potential power saws? What books do we read? What courses
do we take? What websites do we visit? In short, wheres the beef?
Where does one learn the theory and concepts that go into
Mike Jagdis wrote:
> I disagree. No one here is dumb enough to use a wholely inappropriate
> tool for a particular task. But using a debugger is often (but not
> always) like sawing bits off your 2x4 until it happens to fit the
> gap. What you need to do is to understand the problem parameters,
>
"J. Dow" <[EMAIL PROTECTED]> said:
[...]
> I note again that the same arguement applies vis a vis printk
> and desk checks with a paper and pencil. The printk leverages
> the capable person's time. The kernel debugger leverages
> the capable person's time. What IS this urge to be handicapped
>
> What IS this urge to be handicapped
> when trying to debug the most important pieces of what gets
> delivered on the distribution CDROMs. Is it, "I'm so hairy chested
> that I can code with one metaphorical arm tied behind my
> equally cliched back?"
There are those that like to visualize
From: "Ingo Molnar" <[EMAIL PROTECTED]>
> > If the Kernel Debugger creates faulty solutions through lack of
> > thinking, and asking why, then surely printk is at least as bad
> > because it allows somebody to view the operation of the kernel through
> > a keyhole darkly. [...]
>
> i'd like to
From: "Ingo Molnar" <[EMAIL PROTECTED]>
>
> On Tue, 5 Sep 2000, Richard Gooch wrote:
>
> > Would you classify IKD as a pile of warts you wouldn't want to see in
> > the kernel?
>
> the quality of IKD is IMO excellent ( having written parts of it),
> yet i wouldnt want to see it in the kernel.
"David S. Miller" wrote:
>
> From: Chris Wedgwood <[EMAIL PROTECTED]>
>
>Right now as I see it (pretending everything is black and white);
>you, Dave, Linus and a few other people[1] are more than happy with
>debugging aids as they exist right now in a stock kernel.
>
>
What IS this urge to be handicapped
when trying to debug the most important pieces of what gets
delivered on the distribution CDROMs. Is it, "I'm so hairy chested
that I can code with one metaphorical arm tied behind my
equally cliched back?"
There are those that like to visualize things
"J. Dow" [EMAIL PROTECTED] said:
[...]
I note again that the same arguement applies vis a vis printk
and desk checks with a paper and pencil. The printk leverages
the capable person's time. The kernel debugger leverages
the capable person's time. What IS this urge to be handicapped
when
Mike Jagdis wrote:
I disagree. No one here is dumb enough to use a wholely inappropriate
tool for a particular task. But using a debugger is often (but not
always) like sawing bits off your 2x4 until it happens to fit the
gap. What you need to do is to understand the problem parameters,
-BEGIN PGP SIGNED MESSAGE-
To do this, we need to be taught how. Where are the manuals
for these potential power saws? What books do we read? What courses
do we take? What websites do we visit? In short, wheres the beef?
Where does one learn the theory and concepts that go into
A good debugger is a very
good leveraging agent. I can cut a 2x4 with a largish pocket knife,
in theory. (I have never wasted the time.) In a pinch I have cut a
2X4 with a hand saw. I can see that if I wanted to do this for any
serious work power tools are required. The same logic
"David S. Miller" wrote:
From: Chris Wedgwood [EMAIL PROTECTED]
Right now as I see it (pretending everything is black and white);
you, Dave, Linus and a few other people[1] are more than happy with
debugging aids as they exist right now in a stock kernel.
However, there
: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS
for Linux
Date: Wed, 6 Sep 2000 12:00:13 +1200
From: Chris Wedgwood <[EMAIL PROTECTED]>
Right now as I see it (pretending everything is black and white);
you, Dave, Linus and a few other people[1] are more than
On Wed, Sep 06, 2000 at 12:31:55PM +1200, Chris Wedgwood wrote:
> Perhaps you would like to describe how you do debug the kernel? I ask
I find that rebooting the machine and cursing myself is one of the
most effective kernel debugging methods.
--
Date: Wed, 6 Sep 2000 12:31:55 +1200
From: Chris Wedgwood <[EMAIL PROTECTED]>
Face it Dave -- you are just smarter than many of the rest of us.
I would actually assert that I am not, and that I know the things I do
for reasons other than "talent", and I think the best way to describe
Date: Wed, 6 Sep 2000 12:00:13 +1200
From: Chris Wedgwood <[EMAIL PROTECTED]>
Right now as I see it (pretending everything is black and white);
you, Dave, Linus and a few other people[1] are more than happy with
debugging aids as they exist right now in a stock kernel.
[EMAIL PROTECTED] (Jeff V. Merkey) writes:
>> Yes, it seems so. So you're telling us that this entire thread is joke on
>> your part? If not, then please show me the joke above or, for the future,
>> mark your "jokes" somehow in the text so that dumbsticks like myself
>can
>> uderstand the
Alex Buell wrote:
>
> On Tue, 5 Sep 2000 08:38:38 -0400 (EDT) Tue, 5 Sep 00 13:45:17 BST,
> you wrote:
>
> >Sorry, but I just don't take anything he says too seriously
> >anymore... it's either trolling, or arguing mostly, or babbling
> >about how much better other OS's are, but not actually
On Tue, 5 Sep 2000 08:38:38 -0400 (EDT) Tue, 5 Sep 00 13:45:17 BST,
you wrote:
>Sorry, but I just don't take anything he says too seriously
>anymore... it's either trolling, or arguing mostly, or babbling
>about how much better other OS's are, but not actually using them
>for some reason...
I
Marek Habersack wrote:
>
> ** On Sep 05, Jeff V. Merkey scribbled:
> > > > Linux is more buggy than NT, but at least the source code comes with it
> > > > so there's no excuse for not getting soeone to fix it
> > > Excuse me for adding my irrelevant 0.2$ - but what are you doing with
** On Sep 05, Jeff V. Merkey scribbled:
> > > Linux is more buggy than NT, but at least the source code comes with it
> > > so there's no excuse for not getting soeone to fix it
> > Excuse me for adding my irrelevant 0.2$ - but what are you doing with Linux
> > then?? Why don't you just
Marek Habersack wrote:
>
> ** On Sep 05, Jeff V. Merkey scribbled:
> >
> > Linux is more buggy than NT, but at least the source code comes with it
> > so there's no excuse for not getting soeone to fix it
> Excuse me for adding my irrelevant 0.2$ - but what are you doing with Linux
>
** On Sep 05, Jeff V. Merkey scribbled:
>
> Linux is more buggy than NT, but at least the source code comes with it
> so there's no excuse for not getting soeone to fix it
Excuse me for adding my irrelevant 0.2$ - but what are you doing with Linux
then?? Why don't you just stick with NT
On Tue, Sep 05, 2000 at 01:03:49PM +0200, Ingo Molnar wrote:
> one problem is developer laziness ;-) We could as well include debugging
> code so that experienced people like you can fix easy / moderate bugs
> quicker. But the problem is that in this case people are not forced to
> understand the
Amen,
The main issue for me is also for support. It's really nice to have an
integrated kernel debugger so if a customer has a problem, you can send
out trained folks to track stuff down more quickly since they can poke
around the system. It's also great for diagnosing customer problems
"David S. Miller" wrote:
> This is what a debugger does not do for you. The debugger allows you
> to be lazy, step around, "oh yeah check for NULL" and never have to
> _think_ about what you're doing or the changes you're making or even
> if the same bug might be elsewhere.
>
> This is why
> This is what a debugger does not do for you. The debugger allows you
> to be lazy, step around, "oh yeah check for NULL" and never have to
> _think_ about what you're doing or the changes you're making or even
> if the same bug might be elsewhere.
I don't really believe that. It is as easy to
Linux is more buggy than NT, but at least the source code comes with it
so there's no excuse for not getting soeone to fix it
Jeff
Bob Taylor wrote:
>
> In message <[EMAIL PROTECTED]>, "Jeff V. Merkey"
> writes:
> cc: [EMAIL PROTECTED]
> >
> >
> > Jes Sorensen wrote:
> > >
> >
> > >
Linux is more buggy than NT, but at least the source code comes with it
so there's no excuse for not getting soeone to fix it
Jeff
Bob Taylor wrote:
In message [EMAIL PROTECTED], "Jeff V. Merkey"
writes:
cc: [EMAIL PROTECTED]
Jes Sorensen wrote:
Yeah I bet NT also has
** On Sep 05, Jeff V. Merkey scribbled:
Linux is more buggy than NT, but at least the source code comes with it
so there's no excuse for not getting soeone to fix it
Excuse me for adding my irrelevant 0.2$ - but what are you doing with Linux
then?? Why don't you just stick with NT and
Marek Habersack wrote:
** On Sep 05, Jeff V. Merkey scribbled:
Linux is more buggy than NT, but at least the source code comes with it
so there's no excuse for not getting soeone to fix it
Excuse me for adding my irrelevant 0.2$ - but what are you doing with Linux
then?? Why
** On Sep 05, Jeff V. Merkey scribbled:
Linux is more buggy than NT, but at least the source code comes with it
so there's no excuse for not getting soeone to fix it
Excuse me for adding my irrelevant 0.2$ - but what are you doing with Linux
then?? Why don't you just stick with NT
Marek Habersack wrote:
** On Sep 05, Jeff V. Merkey scribbled:
Linux is more buggy than NT, but at least the source code comes with it
so there's no excuse for not getting soeone to fix it
Excuse me for adding my irrelevant 0.2$ - but what are you doing with Linux
then??
On Tue, 5 Sep 2000 08:38:38 -0400 (EDT) Tue, 5 Sep 00 13:45:17 BST,
you wrote:
Sorry, but I just don't take anything he says too seriously
anymore... it's either trolling, or arguing mostly, or babbling
about how much better other OS's are, but not actually using them
for some reason...
I just
Alex Buell wrote:
On Tue, 5 Sep 2000 08:38:38 -0400 (EDT) Tue, 5 Sep 00 13:45:17 BST,
you wrote:
Sorry, but I just don't take anything he says too seriously
anymore... it's either trolling, or arguing mostly, or babbling
about how much better other OS's are, but not actually using
Date: Wed, 6 Sep 2000 12:31:55 +1200
From: Chris Wedgwood [EMAIL PROTECTED]
Face it Dave -- you are just smarter than many of the rest of us.
I would actually assert that I am not, and that I know the things I do
for reasons other than "talent", and I think the best way to describe
it
On Wed, Sep 06, 2000 at 12:31:55PM +1200, Chris Wedgwood wrote:
Perhaps you would like to describe how you do debug the kernel? I ask
I find that rebooting the machine and cursing myself is one of the
most effective kernel debugging methods.
--
This is what a debugger does not do for you. The debugger allows you
to be lazy, step around, "oh yeah check for NULL" and never have to
_think_ about what you're doing or the changes you're making or even
if the same bug might be elsewhere.
I don't really believe that. It is as easy to add
"David S. Miller" wrote:
This is what a debugger does not do for you. The debugger allows you
to be lazy, step around, "oh yeah check for NULL" and never have to
_think_ about what you're doing or the changes you're making or even
if the same bug might be elsewhere.
This is why Linus does
Amen,
The main issue for me is also for support. It's really nice to have an
integrated kernel debugger so if a customer has a problem, you can send
out trained folks to track stuff down more quickly since they can poke
around the system. It's also great for diagnosing customer problems
Date: Wed, 6 Sep 2000 12:00:13 +1200
From: Chris Wedgwood [EMAIL PROTECTED]
Right now as I see it (pretending everything is black and white);
you, Dave, Linus and a few other people[1] are more than happy with
debugging aids as they exist right now in a stock kernel.
However,
TED]]
Sent: Monday, September 04, 2000 5:04 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for
Linux
Date:Sat, 02 Sep 2000 15:58:50 -0600
From: "Jeff V. Merkey" <[
Date: Tue, 5 Sep 2000 01:13:51 +0100 (BST)
From: Alan Cox <[EMAIL PROTECTED]>
> This is why Linus does not allow a debugging facility like this into
> the kernel, so people spend time _thinking_ when they go hunting down
> bugs.
I spend my time thinking. But I prefer to spend
> This is why Linus does not allow a debugging facility like this into
> the kernel, so people spend time _thinking_ when they go hunting down
> bugs.
I spend my time thinking. But I prefer to spend it thinking about the bug
not about finding it and how long fsck takes. There are only a few
Date:Sat, 02 Sep 2000 15:58:50 -0600
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
I can only assume the reason for this is one of control, and that
there are no valid technical reasons for it. I have spent more
nights with printk() than I care to.
And I bet the lessons
Date: Tue, 5 Sep 2000 01:13:51 +0100 (BST)
From: Alan Cox [EMAIL PROTECTED]
This is why Linus does not allow a debugging facility like this into
the kernel, so people spend time _thinking_ when they go hunting down
bugs.
I spend my time thinking. But I prefer to spend it
Date:Sat, 02 Sep 2000 15:58:50 -0600
From: "Jeff V. Merkey" [EMAIL PROTECTED]
I can only assume the reason for this is one of control, and that
there are no valid technical reasons for it. I have spent more
nights with printk() than I care to.
And I bet the lessons
This is why Linus does not allow a debugging facility like this into
the kernel, so people spend time _thinking_ when they go hunting down
bugs.
I spend my time thinking. But I prefer to spend it thinking about the bug
not about finding it and how long fsck takes. There are only a few things
> contributing member of Linux for quite some time, however, the
> architecture of Linux is unnatural to Novell's and Microsoft's
> technologies and Linux is at present incapable of providing the same
> level of Networking capability available with Windows 2000 or NetWare to
> enterprise
In message <[EMAIL PROTECTED]>, "Jeff V. Merkey"
writes:
cc: [EMAIL PROTECTED]
>
>
> Jes Sorensen wrote:
> >
>
> > Yeah I bet NT also has a wonderful graphical click click wush wush
> > environment for it that allows you to spend all your time `improving'
> > your rsi instead of getting
In message [EMAIL PROTECTED], "Jeff V. Merkey"
writes:
cc: [EMAIL PROTECTED]
Jes Sorensen wrote:
Yeah I bet NT also has a wonderful graphical click click wush wush
environment for it that allows you to spend all your time `improving'
your rsi instead of getting real work done.
"Jeff V. Merkey" wrote:
I've got a lot of responses to this. Any companies out there who have
job postings and the need for some talented networking engineers in
Utah, please send us the info so we can post it on our website. If
there's Linux work, these guys can do what we did, and learn
Andi Kleen wrote:
> > It works today, but won't in the future. At some point, real sleep
> > locks will be needed for SMP tuning since you can give them prioities
> > and put deadlock detection into the sleep locks for apps. Priority
> > inheritance allows you to bump the priority of folks
> > line and executes very simple commands like read memory etc.). I don't
> > see much point in debugging that.
>
> Uless of course you need to debug the serial driver -- then you're
> fucked.
Wrong. Please RTFM on the gdb stubs. If you are going to get into an argument
doing your research
Andi Kleen wrote:
>
> On Sat, Sep 02, 2000 at 04:01:24PM -0600, Jeff V. Merkey wrote:
>
> >
> > Of course not. Linux does not have a kernel debugger, or it would use
> > them. That's what they are used for -- debugging running tasks from a
> > kernel debugger that has it's own task gates.
On Sat, Sep 02, 2000 at 04:01:24PM -0600, Jeff V. Merkey wrote:
>
>
> Andi Kleen wrote:
> >
> > On Sat, Sep 02, 2000 at 03:34:47PM -0600, Jeff V. Merkey wrote:
> > >
> > > KDB is putrid. Can it debug double faults? NO. Can it debug complex
> > > register and numeric evaluation statements
Andi Kleen wrote:
>
> On Sat, Sep 02, 2000 at 03:34:47PM -0600, Jeff V. Merkey wrote:
> >
> > KDB is putrid. Can it debug double faults? NO. Can it debug complex
> > register and numeric evaluation statements like IF ((EAX == 1) &&
> > [ESP-4] == 0x3000)? NO. Can it debug nested task gate
Alan Cox wrote:
>
> Remote gdb on Linux - yes and I can do my debugging source level. Unfortunately
> Linus seems to have a one man campaign against putting sensible debugging into
> his kernel.
>
> The tools exist and they should be in the x86 tree as well as sparc etc where
> with other
Jes Sorensen wrote:
>
> Yeah I bet NT also has a wonderful graphical click click wush wush
> environment for it that allows you to spend all your time `improving'
> your rsi instead of getting real work done. Have you ever looked at NT
> device driver code? I have, it's not pretty at all so I
On Sat, Sep 02, 2000 at 03:34:47PM -0600, Jeff V. Merkey wrote:
>
> KDB is putrid. Can it debug double faults? NO. Can it debug complex
> register and numeric evaluation statements like IF ((EAX == 1) &&
> [ESP-4] == 0x3000)? NO. Can it debug nested task gate exceptions?
remote gdb does
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:
Jeff> KDB is putrid. Can it debug double faults? NO. Can it debug
Jeff> complex register and numeric evaluation statements like IF ((EAX
Jeff> == 1) && [ESP-4] == 0x3000)? NO. Can it debug nested task gate
Jeff> exceptions? NO. Can
> KDB is putrid. Can it debug double faults? NO. Can it debug complex
> register and numeric evaluation statements like IF ((EAX == 1) &&
> [ESP-4] == 0x3000)? NO. Can it debug nested task gate exceptions?
> NO. Can it debug SMP locks races? NO. Can it debug priority inversion
> problems
KDB is putrid. Can it debug double faults? NO. Can it debug complex
register and numeric evaluation statements like IF ((EAX == 1) &&
[ESP-4] == 0x3000)? NO. Can it debug nested task gate exceptions?
NO. Can it debug SMP locks races? NO. Can it debug priority inversion
problems in sleep
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:
Jeff> TRG has reprioritized it's long term objectives, and due to
Jeff> resource constraints and short term schedules, the Open Source
Jeff> NDS and Open Source NTFS File System projects are being
Jeff> withdrawn from the Linux
TRG has reprioritized it's long term objectives, and due to resource
constraints and short term schedules, the Open Source NDS and Open
Source NTFS File System projects are being withdrawn from the Linux
Initiative. These projects will be MANOS only, and any interested party
is free to acquire
TRG has reprioritized it's long term objectives, and due to resource
constraints and short term schedules, the Open Source NDS and Open
Source NTFS File System projects are being withdrawn from the Linux
Initiative. These projects will be MANOS only, and any interested party
is free to acquire
"Jeff" == Jeff V Merkey [EMAIL PROTECTED] writes:
Jeff TRG has reprioritized it's long term objectives, and due to
Jeff resource constraints and short term schedules, the Open Source
Jeff NDS and Open Source NTFS File System projects are being
Jeff withdrawn from the Linux Initiative. These
KDB is putrid. Can it debug double faults? NO. Can it debug complex
register and numeric evaluation statements like IF ((EAX == 1)
[ESP-4] == 0x3000)? NO. Can it debug nested task gate exceptions?
NO. Can it debug SMP locks races? NO. Can it debug priority inversion
problems in
"Jeff" == Jeff V Merkey [EMAIL PROTECTED] writes:
Jeff KDB is putrid. Can it debug double faults? NO. Can it debug
Jeff complex register and numeric evaluation statements like IF ((EAX
Jeff == 1) [ESP-4] == 0x3000)? NO. Can it debug nested task gate
Jeff exceptions? NO. Can it debug SMP
Jes Sorensen wrote:
Yeah I bet NT also has a wonderful graphical click click wush wush
environment for it that allows you to spend all your time `improving'
your rsi instead of getting real work done. Have you ever looked at NT
device driver code? I have, it's not pretty at all so I can
On Sat, Sep 02, 2000 at 04:01:24PM -0600, Jeff V. Merkey wrote:
Andi Kleen wrote:
On Sat, Sep 02, 2000 at 03:34:47PM -0600, Jeff V. Merkey wrote:
KDB is putrid. Can it debug double faults? NO. Can it debug complex
register and numeric evaluation statements like IF ((EAX ==
Andi Kleen wrote:
On Sat, Sep 02, 2000 at 04:01:24PM -0600, Jeff V. Merkey wrote:
Of course not. Linux does not have a kernel debugger, or it would use
them. That's what they are used for -- debugging running tasks from a
kernel debugger that has it's own task gates. If you have
"Jeff V. Merkey" wrote:
I've got a lot of responses to this. Any companies out there who have
job postings and the need for some talented networking engineers in
Utah, please send us the info so we can post it on our website. If
there's Linux work, these guys can do what we did, and learn
76 matches
Mail list logo
