Quite frankly, if kgdb starts doing somethign "fancy", there is no way
I'll merge it.
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.
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
simply not _possibly_ be able to even tell or care (which is why
breakpoint reservations are out - they are against the whole point of
debugging a unmodified kernel).
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.
In other words: I think the kgdb patches have become a lot more palatable
over the last week, but I think so exactly because they have gotten
smaller and less invasive. Anything that evokes any discussion AT ALL
should just be removed. It really should be that simple.
[ The exception being that I think hw breakpoint support should be added
back in - never mind that it won't work if the "native kernel" also uses
them. Tough.
If the debugger screws up the hw breakpoint state, that's a debugger
error. I'd hope that the remote debugger *defaults* to just re-writing
the instruction stream for that reason, but if you want to do a data
breakpoint, you simply *have* to use the hw breakpoints for kgdb.
And you just need to live with the fact that it simply won't be possible
to do if the client wants to use hw breakpoints too. If the client
starts using hw breakpoints - tough titties, it takes them. ]
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.
Linus
--
