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

[George Anzinger <george@mvista.com>]

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@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml