Kai Henningsen wrote:
> A classical memory corruption bug, and like most late-effect bugs hell to
> find without some sort of support for poking around in the actual program
> state.
Agreed. My usual debugging procedure is as follows:
1. try to reproduce the problem
2. make an educated
[EMAIL PROTECTED] (Ingo Molnar) wrote on 05.09.00 in
<[EMAIL PROTECTED]>:
> On Tue, 5 Sep 2000, Andi Kleen wrote:
>
> > I don't really believe that. It is as easy to add a silly NULL pointer
> > check based on a oops as it is after a debugging session (and it is
> > even likely you chose the
[EMAIL PROTECTED] (Ingo Molnar) wrote on 05.09.00 in
<[EMAIL PROTECTED]>:
> debugging tools are not necesserily the most important goal to help the
> Linux kernel. IMO we rather need people who have a deeper understanding of
> things - even if this makes support a bit harder. If it was up to
[EMAIL PROTECTED] (David S. Miller) wrote on 05.09.00 in
<[EMAIL PROTECTED]>:
> I don't want this
> to start happening, and automated debugging/profiling tools tend to
> encourage people to operate in such a way.
Somehow I suddenly get the impression we're talking past each others.
Since
[EMAIL PROTECTED] (Ingo Molnar) wrote on 05.09.00 in
[EMAIL PROTECTED]:
On Tue, 5 Sep 2000, Andi Kleen wrote:
I don't really believe that. It is as easy to add a silly NULL pointer
check based on a oops as it is after a debugging session (and it is
even likely you chose the simple fix
[EMAIL PROTECTED] (Ingo Molnar) wrote on 05.09.00 in
[EMAIL PROTECTED]:
debugging tools are not necesserily the most important goal to help the
Linux kernel. IMO we rather need people who have a deeper understanding of
things - even if this makes support a bit harder. If it was up to the
[EMAIL PROTECTED] (David S. Miller) wrote on 05.09.00 in
[EMAIL PROTECTED]:
I don't want this
to start happening, and automated debugging/profiling tools tend to
encourage people to operate in such a way.
Somehow I suddenly get the impression we're talking past each others.
Since when
Ingo Molnar wrote:
> > They seem focused on keeping us in the dark ages. We need tools to make
> > it faster and easier for folks to perform kernel development and make
> > field support of Linux easier.
>
> tools can sometimes bring the dark ages faster than anything else.
However, if Jeff
Ingo Molnar wrote:
They seem focused on keeping us in the dark ages. We need tools to make
it faster and easier for folks to perform kernel development and make
field support of Linux easier.
tools can sometimes bring the dark ages faster than anything else.
However, if Jeff would
On Thu, 7 Sep 2000, Jeff V. Merkey wrote:
> [...] so it takes me longer to ponder and digest things -- [...]
i'll quote a few 'digesting' comments of you:
- about the Linux networking code:
" [...] what a mess indeed. "
- about Linux itself:
" The lack of a Kernel Debugger and other basic
Ingo,
I did read it. You have to understand, I'm not a young guy but an old
man, so it takes me longer to ponder and digest things -- not because
I'm slower, but becasue I'm older. I used to blindy charge at anything
when a red flag was waved in front of my face in my youth. As I got
older,
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> Ingo Molnar wrote:
> > > Your arguments are personal, not technical. [...]
> >
> > no, my arguments are technical, but are simply focused towards the
> > conceptual (horizontal) development of Linux, not the vertical
> > development of Linux
Jeff, please read Linus' mail for an explanation about the dangers of
kernel debuggers.
Ingo
On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
>
> Ingo,
>
> KDB is a user mode debugger designed to debug user space apps that's
> been hacked to run with a driver. It's not designed as a
I loose track at times Stephen -- sorry. I was talking about kgdb with
this statement.
:-)
Jeff
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Wed, Sep 06, 2000 at 09:44:54AM -0600, Jeff V. Merkey wrote:
> >
> > KDB is a user mode debugger designed to debug user space apps that's
> > been
Hi,
On Wed, Sep 06, 2000 at 09:44:54AM -0600, Jeff V. Merkey wrote:
>
> KDB is a user mode debugger designed to debug user space apps that's
> been hacked to run with a driver.
Absolutely not true. You're probably thinking about kgdb, the gdb
stub for remote kernel source level debugging.
> And I bet the lessons learned and the issues involved in those nights
> with printk will never leave your brain, you will remember precisely
> in the future next time you see the same types of symptoms what kinds
> of things to look for and where.
>
> This is what a debugger does not do for
On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
> Mike Galbraith wrote:
> >
> > On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
> >
> > > Ingo,
> > >
> > > KDB is a user mode debugger designed to debug user space apps that's
> > > been hacked to run with a driver. It's not designed as a kernel level
> >
On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
Mike Galbraith wrote:
On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
Ingo,
KDB is a user mode debugger designed to debug user space apps that's
been hacked to run with a driver. It's not designed as a kernel level
debugger and in real
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
Ingo Molnar wrote:
Your arguments are personal, not technical. [...]
no, my arguments are technical, but are simply focused towards the
conceptual (horizontal) development of Linux, not the vertical
development of Linux (drivers) and
Ingo,
I did read it. You have to understand, I'm not a young guy but an old
man, so it takes me longer to ponder and digest things -- not because
I'm slower, but becasue I'm older. I used to blindy charge at anything
when a red flag was waved in front of my face in my youth. As I got
older,
On Thu, 7 Sep 2000, Jeff V. Merkey wrote:
[...] so it takes me longer to ponder and digest things -- [...]
i'll quote a few 'digesting' comments of you:
- about the Linux networking code:
" [...] what a mess indeed. "
- about Linux itself:
" The lack of a Kernel Debugger and other basic
Jeff, please read Linus' mail for an explanation about the dangers of
kernel debuggers.
Ingo
On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
Ingo,
KDB is a user mode debugger designed to debug user space apps that's
been hacked to run with a driver. It's not designed as a kernel
I loose track at times Stephen -- sorry. I was talking about kgdb with
this statement.
:-)
Jeff
"Stephen C. Tweedie" wrote:
Hi,
On Wed, Sep 06, 2000 at 09:44:54AM -0600, Jeff V. Merkey wrote:
KDB is a user mode debugger designed to debug user space apps that's
been hacked to run
Hi,
On Wed, Sep 06, 2000 at 09:44:54AM -0600, Jeff V. Merkey wrote:
KDB is a user mode debugger designed to debug user space apps that's
been hacked to run with a driver.
Absolutely not true. You're probably thinking about kgdb, the gdb
stub for remote kernel source level debugging.
kdb
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
PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for
>Attempting to change people's habits by making it hard to debug.
>
> Hard work now leads to less work later.
Mike Galbraith wrote:
>
> On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
>
> >
> > Ingo,
> >
> > KDB is a user mode debugger designed to debug user space apps that's
> > been hacked to run with a driver. It's not designed as a kernel level
> > debugger and in real world situations has tons of
On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
>
> Ingo,
>
> KDB is a user mode debugger designed to debug user space apps that's
> been hacked to run with a driver. It's not designed as a kernel level
> debugger and in real world situations has tons of shortcomings period.
?!? KDB is a
On Wed, 6 Sep 2000, Ingo Molnar wrote:
> but the other IKD components, like the soft lockup detector, kernel
> tracer, leak detector and other goodies, are clearly intrusive. It's
> also a pain (and distraction) to 'drag' all that functionality along
> in a developer kernel - i'm sure Mike can
On Wed, 6 Sep 2000, Damien Miller wrote:
> On Tue, 5 Sep 2000, David S. Miller wrote:
>
> >> (What means 'social engineering attempts'?)
> >
> >Attempting to change people's habits by making it hard to debug.
> >
> > Hard work now leads to less work later.
>
> Lots of people (myself
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,
>
"David S. Miller" wrote:
>
>Date: Tue, 5 Sep 2000 23:55:07 -0600
>From: Richard Gooch <[EMAIL PROTECTED]>
>
>> (What means 'social engineering attempts'?)
>
>Attempting to change people's habits by making it hard to debug.
>
> Hard work now leads to less work later.
This is
"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
On Wed, 6 Sep 2000, J. Dow wrote:
> 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 quote David here,
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.
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
>"Mike A. Harris" wrote:
>
>Here Mike, we need to update your email signature block to reflect your
>new avocation (this is where I try to be your mega-buddy). I think the
>reason I'm so obtuse is that God gave me such a thick skin (or perhaps a
>thick
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. That having said, i *did*
author and integrate one of
On Tue, 5 Sep 2000, David S. Miller wrote:
>> (What means 'social engineering attempts'?)
>
>Attempting to change people's habits by making it hard to debug.
>
> Hard work now leads to less work later.
Lots of people (myself included) would like to be able to debug and
generally hack
>Attempting to change people's habits by making it hard to debug.
>
> Hard work now leads to less work later.
Hard work now leads to less work full stop
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the
"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.
>
>
On Tue, 5 Sep 2000, Richard Gooch wrote:
> Mike Galbraith writes:
> > > Surely there must be some useful features that can be included in the
> > > kernel without uglyfing it or slowing it down (configed out)? Leaving
> > > aside the social engineering attempts, of course :-)
> >
> > They can
Alexander Viro wrote:
>
> "Make it easy" is OK, unless it is followed by "for lusers". And anyone
> saying that code reviews are not practical can go and fuck himself. He
> will, anyway. Code reviews are MUST. I have no problems with folks who
> want to have debugger in addition to that. I
Date: Tue, 5 Sep 2000 23:55:07 -0600
From: Richard Gooch <[EMAIL PROTECTED]>
> (What means 'social engineering attempts'?)
Attempting to change people's habits by making it hard to debug.
Hard work now leads to less work later.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
"Mike A. Harris" wrote:
Here Mike, we need to update your email signature block to reflect your
new avocation (this is where I try to be your mega-buddy). I think the
reason I'm so obtuse is that God gave me such a thick skin (or perhaps a
thick
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,
PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for
Attempting to change people's habits by making it hard to debug.
Hard work now leads to less work later.
Hard work
-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
On Wed, 6 Sep 2000, J. Dow wrote:
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 quote David here,
"David S. Miller" wrote:
Date: Tue, 5 Sep 2000 23:55:07 -0600
From: Richard Gooch [EMAIL PROTECTED]
(What means 'social engineering attempts'?)
Attempting to change people's habits by making it hard to debug.
Hard work now leads to less work later.
This is so true.
On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
Ingo,
KDB is a user mode debugger designed to debug user space apps that's
been hacked to run with a driver. It's not designed as a kernel level
debugger and in real world situations has tons of shortcomings period.
?!? KDB is a minimalist
Mike Galbraith wrote:
On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
Ingo,
KDB is a user mode debugger designed to debug user space apps that's
been hacked to run with a driver. It's not designed as a kernel level
debugger and in real world situations has tons of shortcomings
On Wed, 6 Sep 2000, Ingo Molnar wrote:
but the other IKD components, like the soft lockup detector, kernel
tracer, leak detector and other goodies, are clearly intrusive. It's
also a pain (and distraction) to 'drag' all that functionality along
in a developer kernel - i'm sure Mike can
On Wed, 6 Sep 2000, Damien Miller wrote:
On Tue, 5 Sep 2000, David S. Miller wrote:
(What means 'social engineering attempts'?)
Attempting to change people's habits by making it hard to debug.
Hard work now leads to less work later.
Lots of people (myself included) would
On Tue, 5 Sep 2000, Richard Gooch wrote:
Mike Galbraith writes:
Surely there must be some useful features that can be included in the
kernel without uglyfing it or slowing it down (configed out)? Leaving
aside the social engineering attempts, of course :-)
They can all be
"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
Date: Tue, 5 Sep 2000 23:55:07 -0600
From: Richard Gooch [EMAIL PROTECTED]
(What means 'social engineering attempts'?)
Attempting to change people's habits by making it hard to debug.
Hard work now leads to less work later.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To
Attempting to change people's habits by making it hard to debug.
Hard work now leads to less work later.
Hard work now leads to less work full stop
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ
On Tue, 5 Sep 2000, David S. Miller wrote:
(What means 'social engineering attempts'?)
Attempting to change people's habits by making it hard to debug.
Hard work now leads to less work later.
Lots of people (myself included) would like to be able to debug and
generally hack the
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 (plug having written parts of it),
yet i wouldnt want to see it in the kernel. That having said, i *did*
author and integrate one of
Mike Galbraith writes:
> On Tue, 5 Sep 2000, Richard Gooch wrote:
> > Ingo Molnar writes:
> >
> > > The reference kernel should be IMO 'untainted' though. Believe me,
> > > during the 2.3.2x pagecache rewrite my kernel was hacked with ad-hoc
> > > debugging code beyond recognition - eg.
On Tue, 5 Sep 2000, Richard Gooch wrote:
> Ingo Molnar writes:
>
> > The reference kernel should be IMO 'untainted' though. Believe me,
> > during the 2.3.2x pagecache rewrite my kernel was hacked with ad-hoc
> > debugging code beyond recognition - eg. automatic checksumming of
> > every
: [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 01:43:47 +0100 (BST)
From: Alex Buell <[EMAIL PROTECTED]>
> Only, with the former, I get to restart the application everytime it
> croaks, with the latter (modules excluded) I have to reboot. This is
> much more time consuming and means you really have
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> Perhaps you would like to describe how you do debug the kernel? I ask
> this because I use printf more often than anything else when
> debugging userland code and I often use printk when debugging the
> kernel.
I can't speak for DaveM, but... the
On Tue, 5 Sep 2000, poke wrote:
>> Only, with the former, I get to restart the application everytime it
>> croaks, with the latter (modules excluded) I have to reboot. This is
>> much more time consuming and means you really have to be much smarter
>> about what checks and printk statements you
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
> Only, with the former, I get to restart the application everytime it
> croaks, with the latter (modules excluded) I have to reboot. This is
> much more time consuming and means you really have to be much smarter
> about what checks and printk statements you put in where... the hope
> is with
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> Only, with the former, I get to restart the application everytime it
> croaks, with the latter (modules excluded) I have to reboot. This is
> much more time consuming and means you really have to be much smarter
> about what checks and printk
Ingo Molnar writes:
>
> On Tue, 5 Sep 2000, Richard Gooch wrote:
>
> > everyone has to start from nothing. But if the learning/development
> > curve is too steep, or the process is too frustrating, you are going
> > to lose a proportion of the potential gurus. You can't push people in
> > a
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.
Date: Tue, 05 Sep 2000 17:29:10 -0600
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
"David S. Miller" wrote:
> Ummm... circa April 15th, 1998 ;-)))
They've got some newer stuff. The best way to get the latest numbers
would be to call Craig Miller 801-861-7000 ([EMAIL
On Wed, 6 Sep 2000, Kurt Roeckx wrote:
> A (better?) kernel debugger could help (certain) people to help improve
> the long term health, because they can't (or don't want) to use what's
> available,
like, brain?
> or just think they can't easely do it with them. It could help
> certain
"David S. Miller" wrote:
>
>Date: Tue, 05 Sep 2000 17:08:03 -0600
>From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
>
>Go visit their website and review the materials directy -- these
>are their claims -- not mine. It's www.novell.com.
>
> Ummm... circa April 15th, 1998 ;-)))
Date: Tue, 05 Sep 2000 17:08:03 -0600
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
Go visit their website and review the materials directy -- these
are their claims -- not mine. It's www.novell.com.
Ummm... circa April 15th, 1998 ;-)))
Later,
David S. Miller
[EMAIL PROTECTED]
-
To
David,
Go visit their website and review the materials directy -- these are
their claims -- not mine. It's www.novell.com.
"David S. Miller" wrote:
>
>Date: Tue, 05 Sep 2000 12:15:52 -0600
>From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
>
>It's got the highest numbers for any web
On Tue, Sep 05, 2000 at 05:30:46PM +0200, Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
>
> > A kernel debugger will reduce development costs. No one cares what's
> > underneath, [...]
>
> this is the point where IMO your argument gets flawed, and where you are
> apparently
Date: Tue, 05 Sep 2000 12:15:52 -0600
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
It's got the highest numbers for any web server on the planet on
Intel.
What is your metric for this claim? Last I checked Linux held the
record for the current version of specweb, specweb99.
Maybe
On Tue, 5 Sep 2000, Richard Gooch wrote:
> everyone has to start from nothing. But if the learning/development
> curve is too steep, or the process is too frustrating, you are going
> to lose a proportion of the potential gurus. You can't push people in
> a direction they don't want to go.
Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
>
> > [...] You guys can argue til your blue in the face as to why a kernel
> > debugger in Linux is bad -- [...]
>
> you havent yet replied to our arguments in substance, so i certainly will
> not continue arguing - with whom,
On Sun, 3 Sep 2000, Andre Hedrick wrote:
> But there is no Copyright license in patch code.
On Mon, 4 Sep 2000, Mike A. Harris wrote:
> I was under the understanding a "patch" to something GPL, means
> the "patch" is also GPL.
when IBM started working with the apache group their lawyers did a
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> > no, my arguments are technical, but are simply focused towards the
> > conceptual (horizontal) development of Linux, not the vertical
> > development of Linux (drivers) and support issues.
>
> They seem focused on keeping us in the dark ages. [...]
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:
Jeff> Ingo Molnar wrote:
>> you dont contribute a bit to the generic kernel and the kernel
>> infrastructure itself.
Jeff> I contribute code, time, and $$$, Ingo.
HAve you contributed code to anything but your own private project
All the stuff on our website and ftp servers is free Linux code and it
runs in the kernel. Novell's customers have been downloading it for
over a year. At any point, Linux is free to take it and use it. Lots
of Linux users already are.
Jeff
Jes Sorensen wrote:
>
> > "Jeff" == Jeff V
Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
>
> > A kernel debugger will reduce development costs. No one cares what's
> > underneath, [...]
>
> this is the point where IMO your argument gets flawed, and where you are
> apparently ignoring our arguments. With utmost
Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
>
> > I think the disconnect for you here is that you assume the Linux world
> > will remain constant [...]
>
> > [...] Just because Linux puts everything in user space does not mean
> > that's how the whole world should be.
> IMO there was only one historically hard spinlock-related problem that
> needed solving, this is the 'locks up hard' problem (which is solved). The
> rest was never really an debugging obstacle, 99% of the spinlock related
> bugs manifest themselves in clear, unambiguous lockups.
Then why are
Amen Brother.
Alan Cox wrote:
>
> > IMO there was only one historically hard spinlock-related problem that
> > needed solving, this is the 'locks up hard' problem (which is solved). The
> > rest was never really an debugging obstacle, 99% of the spinlock related
> > bugs manifest themselves
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> > > I think the disconnect for you here is that you assume the Linux world
> > > will remain constant [...]
> >
> > > [...] Just because Linux puts everything in user space does not mean
> > > that's how the whole world should be. There's a lot of
On Tue, 5 Sep 2000, Alan Cox wrote:
> Then why are we still finding obscure lock ordering bugs in 2.2 ?
> Finding them when they bite you is easy, finding the obscure ones when
> they dont generally bite is much harder - thats where debugging
> kernels that trap and dump lock lists for order
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> Jes Sorensen wrote:
> > HAve you contributed code to anything but your own private project
> > which you have just declared to be withdrawn so you can go stick it
> > into your own custom OS? I don't remember seeing you contribute code
> > to any
[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
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> A kernel debugger will reduce development costs. No one cares what's
> underneath, [...]
this is the point where IMO your argument gets flawed, and where you are
apparently ignoring our arguments. With utmost respect, we *do* care about
what's
1 - 100 of 279 matches
Mail list logo
