Re: [git pull] kgdb-light -v10

[Andi Kleen <andi@firstfloor.org>]

> 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