> This includes things like having "breakpoint reservations" (discussed > earlier) and just generally trying to add lots of infrastructure to make > kgdb "fit in" to the kernel.
I think that part is actually mostly ok now (old kgdb stubs were much worse in this regard) I still think the ultimative proof for this would be working "modprobe kgdb" though. > > The fact is, not having kgdb enabled should have _zero_ impact on the > kernel, but the implication is also that when you *do* enable kgdb, that > shouldn't change anything visible either: the rest of the kernel should While agreed in theory there are some exceptions: any time an oops happens or a crash dump would happen automatically kgdb should definitely do something very visible. Unfortunately that's not always the case currently (see earlier comments on the notifier priority) > So kgdb in my opinion will *have* to step on some other kernel > infrastructure. I also think that things like timeouts are not something > the client should do - if a kgdb lock never gets through, then it should > be the debugging end that should just react to ^C and tough titties: it's > not like there's a whole lot to be done. The problem here is that the timeout we were talking about is not integrated into the kgdb event loop, it is rather the loop that protects the event loop. If you hang there all input from the outside will be ignored. > So keep the damn thing really simple, and don't try to handle every > possible thing. We expect the debugger side to have a person with some > flexibility on it. If you want areally simple kgdb the best option would be re-porting the really simple (tm) 2.4 era x86-64 kgdb stub I did long ago. It had a small fraction of the code size of the current code, but was also missing a lot of features of course. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
