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

[George Anzinger <george@mvista.com>]

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...

As to KGDB_MORE and KGDB_OPTIONS, they were put in for those who want to change 
the "O" option.  I feel it should NOT be changed, but I recognize that some 
folks want to reduce the optimizer distortions.  I opted for a generalized 
capability to cover all bases...

KGDB_TS is for code developers.  I invented it to give a poor mans LTT and it 
has served me well.  I am not sure we need to be able to turn it off, however.

The stack overflow thing is, I think, now in the kernel AND I have never had a 
machine behave so badly that it actually caught one.  It can go.
> 

-- 
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