[Kgdb-bugreport] Re: PPC KGDB changes and some help?

[George A. <ge...@mv...>]

Tom Rini wrote:
> On Thu, Jan 22, 2004 at 09:25:19AM -0600, Hollis Blanchard wrote:
> 
>>On Jan 22, 2004, at 9:07 AM, Tom Rini wrote:
>>
>>>On Wed, Jan 21, 2004 at 03:12:25PM -0800, George Anzinger wrote:
>>>
>>>
>>>>A question I have been meaning to ask:  Why is the arch/common 
>>>>connection
>>>>via a structure of addresses instead of just calls?  I seems to me 
>>>>that
>>>>just calling is a far cleaner way to do things here.  All the struct 
>>>>seems
>>>>to offer is a way to change the backend on the fly.  I don't thing we 
>>>>ever
>>>>want to do that.  Am I missing something?
>>>
>>>I imagine it's a style thing.  I don't have a preference either way.
>>
>>I think we in PPC land have gotten used to that "style" because we have 
>>one kernel that supports different "platforms", i.e. it selects the 
>>appropriate code at runtime as George says. In general that's a little 
>>bit slower and a little bit bigger.
>>
>>Unless you need to choose among PPC KGDB functions at runtime, which I 
>>don't think you do, you don't need it...
> 
> 
> That's certainly true, so if (and if I understand Georges question
> right) Amit wants to change kgdb_arch into a set of required functions,
> with stubs in, say, kernel/kgdbdummy.c, (and just keep the flags / etc
> in the struct), that's fine with me.

Something like that.  I would make use of the weak external to handle the stub 
connection, i.e. the common code would define the stubs as weak functions.  The 
linker will choose a normal over a weak so it makes the right connection.
> 

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