Messages in this thread | | | Date | Tue, 2 Mar 2004 16:52:38 -0700 | From | Tom Rini <> | Subject | Re: [Kgdb-bugreport] [PATCH] Kill kgdb_serial |
| |
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.
-- Tom Rini http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |