Availability of kdb From: Daniel Phillips (news-innominate.list.linux.kernel@innominate.de) Date: Wed Sep 06 2000 - 13:11:32 EST Mike Galbraith wrote: > > On Wed, 6 Sep 2000, Damien Miller wrote: > > > Tools like a KDB would make the kernel a lot more accessible to the > > time-poor. > > Kdb is available to all. I think it should be _integrated_ mostly > because of the (potential) improvement in bug report quality. Well, yes and no. As maintained by SGI, kdb is up to date: ftp://oss.sgi.com/www/projects/kdb/download/ix86/kdb-v1.3-2.4.0-test8-pre4.gz As maintained in the official ikd package, kdb is unusuably out of date, at least for me: ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/ikd/v2.4/2.4.0-test2-ikd2.bz2 Q: If kdb were a kernel option, would the official version be out of date, the way it is now? A: no. Q: If kdb were a kernel option, would Linus be called on to fix it when it breaks? A: no, obviously not, Linus is too busy Q: Who would fix it then? A: Whoever breaks it. Q: What if Linus breaks it? A: That's a special case. I personally will drop whatever I'm doing and try to fix it. I will cordially invite J. Dow, J. Merkey, R. Gootch, and various other degenerate powertool lovers to help. Q: Would kdb in the kernel result in more bugs getting fixed faster? A: Yes, no doubt Q: Do we need more bugs fixed faster? A: Yes, we need that desperately. Q: Would kdb in the kernel give us more eyes on the bugs, making them even shallower than they already are? A: Why, yes it would. Q: Will kdb make your kernel bigger or slow it down? A: Not if you don't use it. Q: Is kdb a big patch? A: It's only 93K, zipped. Q: Then why isn't kdb in the kernel? A: Uh... -- Daniel "With enough Q's and A's, all arguments are shallow" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb From: Tigran Aivazian (tigran@veritas.com) Date: Wed Sep 06 2000 - 13:31:53 EST Daniel, very nice monologue, thanks. It would be great to know Linus' opinion. I mean, I knew Linus' opinion of some years' ago but perhaps it changed? He is a living being and not some set of rules written in stone so perhaps current stability/highquality of kdb suggests to Linus that it may be (just maybe) acceptable into official tree? (hence I cc'd Linus, please forgive me (Linus) if you don't want to hear about kdb again) Regards, Tigran On Wed, 6 Sep 2000, Daniel Phillips wrote: > Mike Galbraith wrote: > > > > On Wed, 6 Sep 2000, Damien Miller wrote: > > > > > Tools like a KDB would make the kernel a lot more accessible to the > > > time-poor. > > > > Kdb is available to all. I think it should be _integrated_ mostly > > because of the (potential) improvement in bug report quality. > > Well, yes and no. As maintained by SGI, kdb is up to date: > ftp://oss.sgi.com/www/projects/kdb/download/ix86/kdb-v1.3-2.4.0-test8-pre4.gz > > As maintained in the official ikd package, kdb is unusuably out of > date, at least for me: > ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/ikd/v2.4/2.4.0-test2-ikd2.bz2 > > Q: If kdb were a kernel option, would the official version be out of > date, the way it is now? > A: no. > > Q: If kdb were a kernel option, would Linus be called on to fix it > when it breaks? > A: no, obviously not, Linus is too busy > > Q: Who would fix it then? > A: Whoever breaks it. > > Q: What if Linus breaks it? > A: That's a special case. I personally will drop whatever I'm doing > and try to fix it. I will cordially invite J. Dow, J. Merkey, R. > Gootch, and various other degenerate powertool lovers to help. > > Q: Would kdb in the kernel result in more bugs getting fixed faster? > A: Yes, no doubt > > Q: Do we need more bugs fixed faster? > A: Yes, we need that desperately. > > Q: Would kdb in the kernel give us more eyes on the bugs, making them > even shallower than they already are? > A: Why, yes it would. > > Q: Will kdb make your kernel bigger or slow it down? > A: Not if you don't use it. > > Q: Is kdb a big patch? > A: It's only 93K, zipped. > > Q: Then why isn't kdb in the kernel? > A: Uh... > > -- > Daniel > > "With enough Q's and A's, all arguments are shallow" > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb From: Linus Torvalds (torvalds@transmeta.com) Date: Wed Sep 06 2000 - 14:52:29 EST On Wed, 6 Sep 2000, Tigran Aivazian wrote: > > very nice monologue, thanks. It would be great to know Linus' opinion. I > mean, I knew Linus' opinion of some years' ago but perhaps it changed? He > is a living being and not some set of rules written in stone so perhaps > current stability/highquality of kdb suggests to Linus that it may be > (just maybe) acceptable into official tree? I don't like debuggers. Never have, probably never will. I use gdb all the time, but I tend to use it not as a debugger, but as a disassembler on steroids that you can program. None of the arguments for a kernel debugger has touched me in the least. And trust me, over the years I've heard quite a lot of them. In the end, they tend to boil down to basically: - it would be so much easier to do development, and we'd be able to add new things faster. And quite frankly, I don't care. I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing. Apparently, if you follow the arguments, not having a kernel debugger leads to various maladies: - you crash when something goes wrong, and you fsck and it takes forever and you get frustrated. - people have given up on Linux kernel programming because it's too hard and too time-consuming - it takes longer to create new features. And nobody has explained to me why these are _bad_ things. To me, it's not a bug, it's a feature. Not only is it documented, but it's _good_, so it obviously cannot be a bug. "Takes longer to create new features" - this one in particular is not a very strong argument for having a debugger. It's not as if lack of features or new code would be a problem for Linux, or, in fact, for the software industry as a whole. Quite the reverse. My biggest job is to say "no" to new features, not trying to find them. Oh. And sure, when things crash and you fsck and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger. Quite frankly, I'd rather weed out the people who don't start being careful early rather than late. That sounds callous, and by God, it _is_ callous. But it's not the kind of "if you can't stand the heat, get out the the kitchen" kind of remark that some people take it for. No, it's something much more deeper: I'd rather not work with people who aren't careful. It's darwinism in software development. It's a cold, callous argument that says that there are two kinds of people, and I'd rather not work with the second kind. Live with it. I'm a bastard. I have absolutely no clue why people can ever think otherwise. Yet they do. People think I'm a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings or lost hours of work if it just results in what I consider to be a better system. And I'm not just saying that. I'm really not a very nice person. I can say "I don't care" with a straight face, and really mean it. I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_. It's partly "source vs binary", but it's more than that. It's not that you have to look at the sources (of course you have to - and any good debugger will make that _easy_). It's that you have to look at the level _above_ sources. At the meaning of things. Without a debugger, you basically have to go the next step: understand what the program does. Not just that particular line. And quite frankly, for most of the real problems (as opposed to the stupid bugs - of which there are many, as the latest crap with "truncate()" has shown us) a debugger doesn't much help. And the real problems are what I worry about. The rest is just details. It will get fixed eventually. I do realize that others disagree. And I'm not your Mom. You can use a kernel debugger if you want to, and I won't give you the cold shoulder because you have "sullied" yourself. But I'm not going to help you use one, and I wuld frankly prefer people not to use kernel debuggers that much. So I don't make it part of the standard distribution, and if the existing debuggers aren't very well known I won't shed a tear over it. Because I'm a bastard, and proud of it! Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb From: Jeff V. Merkey (jmerkey@timpanogas.com) Date: Wed Sep 06 2000 - 15:18:11 EST Linus Torvalds wrote: > Apparently, if you follow the arguments, not having a kernel debugger > leads to various maladies: > - you crash when something goes wrong, and you fsck and it takes forever > and you get frustrated. > - people have given up on Linux kernel programming because it's too hard > and too time-consuming > - it takes longer to create new features. > > And nobody has explained to me why these are _bad_ things. They are bad because they cost people money that could be spent more productively in other areas due to the lengthening of the development process and the support costs. Which Linux companies are profitable? **NONE**. The only people making money are hardware vendors and it's a model like SUN's, where you get a free "machine driver" with every system you buy. > > To me, it's not a bug, it's a feature. Not only is it documented, but it's > _good_, so it obviously cannot be a bug. > > > Oh. And sure, when things crash and you fsck and you didn't even get a > clue about what went wrong, you get frustrated. Tough. There are two kinds > of reactions to that: you start being careful, or you start whining about > a kernel debugger. A lot of problems are related to other people code, new hardware, etc. How do you tell a customer who is giving you money to "be careful" when their system crashes and the field service rep hasn't a clue as to what's wrong? I've been supporting computer customers for over 20 years, and this is not an answer that will give them warm and fuzzy feelings about using your solution if you have no way of solving problems quickly. Like any tool, it is there to streamline and improve the time to resolve problems -- and increase customer confidence in the solution. > > Quite frankly, I'd rather weed out the people who don't start being > careful early rather than late. That sounds callous, and by God, it _is_ > callous. But it's not the kind of "if you can't stand the heat, get out > the the kitchen" kind of remark that some people take it for. No, it's > something much more deeper: I'd rather not work with people who aren't > careful. It's darwinism in software development. Then it may be that corporate America weeds out Linux over time if the costs of supporting it and developing on it are prohibitive -- Wall Street has already come to this conclusion which is why all the Linux Companies are being downgraded by the analysts and investors are leary. Try coordinating a project with 1000 engineers without knowing how much time things will take? These are the types of issues this helps, the business case for Linux .... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb From: Alan Cox (alan@lxorguk.ukuu.org.uk) Date: Wed Sep 06 2000 - 15:47:59 EST > Apparently, if you follow the arguments, not having a kernel debugger > leads to various maladies: > - you crash when something goes wrong, and you fsck and it takes forever > and you get frustrated. 'It crashed.' [Spend hour teaching and end user to patch kdb] 'It crashed, it says foo, but this fsck took hours so I dont have time to help more' [Bug goes unfixed for 2 months because it only happens on a revision 8 card which the maintainer doesnt] > - people have given up on Linux kernel programming because it's too hard > and too time-consuming Programming isnt the problem to me - its debugging. I get a lot of awful patches that have good debugging behind them. That debugging is the valuable part. I used to reach each of Andrea's patches to find out what the bug was rather than how he fixed it for example (nowdays I tend to apply his patches of course) For things like driver debugging its the only way to work. Hardware simply does not work like the manual says and no amount of Zen contemplation will ever make you at one with a 3c905B ethernet card. In many ways good crash dump tools and tracebacks (oopses do not count) are the valuable bit - remote gdb happens to be a passable crash dump tool Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb From: Daniel Phillips (news-innominate.list.linux.kernel@innominate.de) Date: Wed Sep 06 2000 - 15:54:52 EST Linus Torvalds wrote: > > And quite frankly, for most of the real problems (as opposed to the stupid > bugs - of which there are many, as the latest crap with "truncate()" has > shown us) a debugger doesn't much help. And the real problems are what I > worry about. The rest is just details. It will get fixed eventually. Yes, no doubt you agree that stepping through the code with a source level debugger even once would have caught this one: > >> Code; c012cae6 <block_truncate_page+d2/1c8> <===== >> 0: 8b 00 movl (%eax),%eax <===== > >Offset 0 is ->b_next... Huh? It should be ->b_this_page, no? > But that fits with your argument that debugging the kernel should not be easy, so there is no inconsistency. As long as having the kernel progress quickly doesn't matter to you, there's no inconsistency there either. It progresses fast enough for me. Right now, I'm debugging exactly the way you like to, and by coincidence, exactly the same code. If I wanted to, I could install sgi's kdb patch and do this more efficiently, but what the heck. Maybe tomorrow. I'm more than adequately entertained. I'm fortunate to be in the position where rapid forward progress just doesn't affect my paycheck. I can think about the things I like to think about, work on the problems that interest me. I have a dream job. Others are not so fortunate. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb From: Linus Torvalds (torvalds@transmeta.com) Date: Wed Sep 06 2000 - 16:03:06 EST In article <39B6A683.3F75DC9D@timpanogas.com>, Jeff V. Merkey <jmerkey@timpanogas.com> wrote: >Linus Torvalds wrote: > >> Apparently, if you follow the arguments, not having a kernel debugger >> leads to various maladies: >> - you crash when something goes wrong, and you fsck and it takes forever >> and you get frustrated. >> - people have given up on Linux kernel programming because it's too hard >> and too time-consuming >> - it takes longer to create new features. >> >> And nobody has explained to me why these are _bad_ things. > >They are bad because they cost people money that could be spent more >productively in other areas due to the lengthening of the development >process and the support costs. Ehh.. Explain to me again why I should care? Read my posting again. Read the "I'm a bastard" part twice. Realize that in the end, I don't care who speds money, time, and effort. In the end, I think that we're better off _without_ code that hasn't been thought through. More code, more people, more money. Why should I think they are good things? The people, the projects, the companies that come though that test of fire victorious are not only stronger for it, but more importantly, they are the kind of people, projects adn companies who DID get through. Dedicated. Smart. And careful. Think of rabbits. And think of how the wolf helps them in the end. Not by being nice, no. But the rabbits breed, and they are better for having to worry a bit. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb From: Dan Hollis (goemon@anime.net) Date: Wed Sep 06 2000 - 16:11:50 EST On Wed, 6 Sep 2000, Alan Cox wrote: > For things like driver debugging its the only way to work. Hardware simply does > not work like the manual says and no amount of Zen contemplation will ever > make you at one with a 3c905B ethernet card. This is probably the best argument for a kernel debugger. Adding debug code (printk, if/then/BUG() etc) to track down a driver bug sometimes changes behaviour enough to turn it into a heisenbug. In these cases a kernel debugger is the best way to swat it. -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb From: Linus Torvalds (torvalds@transmeta.com) Date: Wed Sep 06 2000 - 16:33:36 EST On Wed, 6 Sep 2000, Daniel Phillips wrote: > Linus Torvalds wrote: > > > > And quite frankly, for most of the real problems (as opposed to the stupid > > bugs - of which there are many, as the latest crap with "truncate()" has > > shown us) a debugger doesn't much help. And the real problems are what I > > worry about. The rest is just details. It will get fixed eventually. > > Yes, no doubt you agree that stepping through the code with a source > level debugger even once would have caught this one: No I definitely do not agree. In fact, I would never have seen that problem with _any_ debugger. It simply would not have happened for me. And guess what? I saw the bug without any debugger within minutes of having been told what the problem was. A debugger would not have helped. And that is the case in 99% of all cases. In most cases the people who see the problem aren't the same people who can debug them. Giving such a person a debugger doesn't help. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/ Re: Availability of kdb From: Linus Torvalds (torvalds@transmeta.com) Date: Wed Sep 06 2000 - 16:36:48 EST On Wed, 6 Sep 2000, Dan Hollis wrote: > On Wed, 6 Sep 2000, Alan Cox wrote: > > For things like driver debugging its the only way to work. Hardware simply does > > not work like the manual says and no amount of Zen contemplation will ever > > make you at one with a 3c905B ethernet card. > > This is probably the best argument for a kernel debugger. > > Adding debug code (printk, if/then/BUG() etc) to track down a driver bug > sometimes changes behaviour enough to turn it into a heisenbug. In these > cases a kernel debugger is the best way to swat it. Ehh? And exactly _how_ would a debugger help it. Especially as Alan quoted an example of a driver bug that didn't get fixed for several months because the maintainer didn't have the hardware. What would a debugger have done? Are you _seriously_ expecting that non-programmers start using kernel debuggers to send in good bug-reports? Grow up, get a clue, and smell the roses. Not going to happen. Especially as a kernel debugger tends to require a second machine, and even then you only get to break automatically on events that would have caused a kernel oops anyway. Otherwise you need to know a hell of a lot more, like setting breakpoints etc. Testing is important for device drivers. Debuggers are not. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb From: Jeff V. Merkey (jmerkey@timpanogas.com) Date: Wed Sep 06 2000 - 16:28:26 EST Linus Torvalds wrote: > > In article <39B6A683.3F75DC9D@timpanogas.com>, > Jeff V. Merkey <jmerkey@timpanogas.com> wrote: > >Linus Torvalds wrote: > > > >> Apparently, if you follow the arguments, not having a kernel debugger > >> leads to various maladies: > >> - you crash when something goes wrong, and you fsck and it takes forever > >> and you get frustrated. > >> - people have given up on Linux kernel programming because it's too hard > >> and too time-consuming > >> - it takes longer to create new features. > >> > >> And nobody has explained to me why these are _bad_ things. > > > >They are bad because they cost people money that could be spent more > >productively in other areas due to the lengthening of the development > >process and the support costs. > > Ehh.. > > Explain to me again why I should care? > > Read my posting again. Read the "I'm a bastard" part twice. Realize > that in the end, I don't care who speds money, time, and effort. In the > end, I think that we're better off _without_ code that hasn't been > thought through. > > More code, more people, more money. Why should I think they are good > things? > > The people, the projects, the companies that come though that test of > fire victorious are not only stronger for it, but more importantly, they > are the kind of people, projects adn companies who DID get through. > Dedicated. Smart. And careful. > > Think of rabbits. And think of how the wolf helps them in the end. Not > by being nice, no. But the rabbits breed, and they are better for having > to worry a bit. You know those huge, sharp teeth on the wolf? Want to make them longer and sharper? Put in a kernel debugger, Linus, and the wolf will be even more ferocious. I appreciate the honest, open response, BTW. Jeff > > Linus > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb From: Linus Torvalds (torvalds@transmeta.com) Date: Wed Sep 06 2000 - 16:41:58 EST On Wed, 6 Sep 2000, Jeff V. Merkey wrote: > > > > Think of rabbits. And think of how the wolf helps them in the end. Not > > by being nice, no. But the rabbits breed, and they are better for having > > to worry a bit. > > You know those huge, sharp teeth on the wolf? Want to make them longer > and sharper? Put in a kernel debugger, Linus, and the wolf will be even > more ferocious. I appreciate the honest, open response, BTW. No, no. The debugger is akin to giving the _rabbits_ a bazooka. The poor wolf doesn't get any sharper teeth. Yeah, it sure helps against wolves. They explode in pretty patterns of read drops flying _everywhere_. Cool. But it doesn't help against a rabbit gene pool that is slowly deteriorating because there is nothing to keep them from breeding, and no darwin to make sure that it's the fastest and strongest that breeds. You mentioned how NT has the nicest debugger out there. Contemplate it. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb From: Jeff V. Merkey (jmerkey@timpanogas.com) Date: Wed Sep 06 2000 - 16:47:46 EST Linus Torvalds wrote: > > On Wed, 6 Sep 2000, Jeff V. Merkey wrote: > > > > > > Think of rabbits. And think of how the wolf helps them in the end. Not > > > by being nice, no. But the rabbits breed, and they are better for having > > > to worry a bit. > > > > You know those huge, sharp teeth on the wolf? Want to make them longer > > and sharper? Put in a kernel debugger, Linus, and the wolf will be even > > more ferocious. I appreciate the honest, open response, BTW. > > No, no. > > The debugger is akin to giving the _rabbits_ a bazooka. The poor wolf > doesn't get any sharper teeth. > > Yeah, it sure helps against wolves. They explode in pretty patterns of > read drops flying _everywhere_. Cool. Darren had to help me get up off the floor I was laughing so hard when I saw this. 10 points dude, good response....:-) > > But it doesn't help against a rabbit gene pool that is slowly > deteriorating because there is nothing to keep them from breeding, and no > darwin to make sure that it's the fastest and strongest that breeds. > > You mentioned how NT has the nicest debugger out there. MANOS has the nicest debugger at present -- and soon you will have it too. Thay say that in human men, only 1% of our sperm are capable of fertilizing an egg, as opposed to chimpanzees and other primates, whiose sperm is almost 98% viable. Scientists state this is because since human evolution is no longer governed by natural selection but by social norms, men with inferior sperm were able to reproduce in ages past in the context of human society and that's why all human males have weak sperm these days -- nothing to weed out abberant genes -- which is why there's male pattern baldness, heart disease, etc. in the human gene pool today. I will give this some thought. What Alan said about hardware is valid, however, no matter how much Zen meditation one does, it does not make you "one with the 3C509 card". Hardware problems require a debugger or logic analyzer to fix. I never heard of anyone correcting timing problems with a PCI chipset by reviewing the chipset layouts :-) :-) :-) :-) Jeff > > Contemplate it. > > Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb From: Alan Cox (alan@lxorguk.ukuu.org.uk) Date: Wed Sep 06 2000 - 17:01:48 EST > Ehh? And exactly _how_ would a debugger help it. > > Especially as Alan quoted an example of a driver bug that didn't get fixed > for several months because the maintainer didn't have the hardware. > > What would a debugger have done? Let the end user give me essential answers on what was happening at the failure point. Think of it as a crash dump tool with extra controls > Testing is important for device drivers. Debuggers are not. When was the last time you wrote a device driver for some warped piece of PCI technology that didn't work like the book says and for which you can neither get more info or pop over to the next cubicle and ask the hardware designer ? Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb From: Linus Torvalds (torvalds@transmeta.com) Date: Wed Sep 06 2000 - 17:15:17 EST On Wed, 6 Sep 2000, Alan Cox wrote: > > > > What would a debugger have done? > > Let the end user give me essential answers on what was happening at the failure > point. Think of it as a crash dump tool with extra controls Sure. I just don't see many end-users single-stepping through interrupt handlers etc. But yes, there probably are a few. But problems that tend to be hard to debug are things that don't happen all the time. Or require special timing to happen. And I don't think you'll find that those are very easy to attach to with a debugger either. So the guy at the debugger end has to be really good. Basically, I'd hate to depend on that. > When was the last time you wrote a device driver for some warped piece of PCI > technology that didn't work like the book says and for which you can neither > get more info or pop over to the next cubicle and ask the hardware designer ? That would be the CardBus controller. Yeah, still fighting that one, but we solved another bug today. Richard Gooch would have been able to use a debugger for that one, but I don't know what he could have done with one in that case. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/