On Tue, Mar 02, 2004 at 03:46:19PM -0800, George Anzinger wrote:
Tom Rini wrote:
On Tue, Mar 02, 2004 at 11:31:43PM +0100, Pavel Machek wrote:
Hi!
Tom Rini wrote:
Hello. The following interdiff kills kgdb_serial in favor of function
names. This only adds a weak function for kgdb_flush_io, and documents
when it would need to be provided.
It looks like you are also dumping any notion of building a kernel that can choose which method of communication to use for kgdb at run time. Is this so?
Yes, as this is how Andrew suggested we do it. It becomes quite ugly if
you try and allow for any 2 of 3 methods.
I do not think that having kgdb_serial is so ugly. Are there any other
uglyness associated with that?
More precisely:
http://lkml.org/lkml/2004/2/11/224
Andrew seems to be comming from the point of view of a developer rather than a developer/ maintainer.
So, the counter argument is the user who is sending the thing into the field and wants to send just one binary kernel to all locations. But then he needs to debug some problem that will work fine over the lan and later one that requires an early connection which the lan can not, as yet, do. I agree that for you or me, this is not an issue, but what of the IT folks...
The IT person should be beaten for shipping KGDB on a production system?
:)
Regardless, it's not that we offer (nor does the -mm version, from what
I read of it) eth or serial at any point, it simply allows for serial to
be used and a switchover to eth. And if kgdb is attached at the time,
it's a 'fun' gdb session (or at least is was when I was trying it out in
-mm and then in my own version).
The real problem is that you start getting quite complex when you allow
for a system to be kgdb eth, or 8250, or some arch serial driver, or
some other I/O driver, and so on. PPC has 3, and I don't see it getting
smaller from there.
And with both of those points, I don't think it's worth the trouble that
point 2 is, given the limitations of point 1.