Re: [Kgdb-bugreport] [PATCH] Kill kgdb_serial

[George Anzinger]

Tom Rini wrote:
> 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?
> :)

Well, they don't tell :)
> 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).

I am not really suggesting a live switch capability, more like something that is 
set a boot time.
> 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.

I had imagined that it would be rather like a file system.  The stub would pass 
(or it could be a global if you prefer) the index to use into an array of 
interface structures.  Something like:

struct kgdb_interface {
	void (*kgdb_in)(*char)
	:
	:
}

struct kgdb_interface kgdb_io_array[N];
> 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.

I imagine that I would like this.  I would use the eth interface until required 
to use the serial.  I would rather not have to rebuild the kernel to do this....

>

--
George Anzinger   george@xxxxxxxxxx
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/