Re: kgdb support in vanilla 2.6.2

[George Anzinger <george@mvista.com>]

Andrew Morton wrote:
~
>>>
>>>I wouldn't support inclusion of i386 kgdb until it has had a lot of
>>>cleanup, possible de-featuritisification and some thought has been applied
>>>to splitting it into arch and generic bits.  It's quite a lot of work.
>>> 
>>>
>>
>>Amit has started at least the third activity--he has split much of kgdb
>>into arch and generic bits.
> 
> 
> Yes.
> 
> 
>>Could you elaborate a little on the first two?
>>
>>What major kinds of cleanup are we talking about?  Style issues?
> 
> 
> Coding style compliance, reduction of ifdefs, etc.  Reduction of patch
> footprint.  There are a few features in the patch in -mm which I am not
> aware of anyone having used.
> 
> 
>>What features (or classes of features) do you find excessive?  Would
>>it be sufficient to add a few config items to control subfeatures
>>of kgdb?
>>
> 
> 
> People have added timestamping infrastructure, stack overflow testing and
> inbuilt assertion frameworks to various gdb stubs at various times.  We
> need to take a look at such things and really convice ourselves that
> they're worthwhile.  Personally, I'd only be interested in the basic stub.
> 
Well, I have NEVER had a stack overflow, but then it is only a few lines. 
Likewise the assertions I think can go in favor of BUG and friends.

The timestamping I added at a time when the alternative that was suggested was 
LTT, which, at the time did not even come close to touching what I needed to do. 
  The timestamp code is designed to catch things that can only be observed when 
running close to real speed.  Especially on SMP systems, relative arrival times 
at spinlocks and friends can be very useful.  Would there be less objection if 
we removed the configure option for it ;)

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