Re: PPC KGDB changes and some help?
From: George Anzinger
Date: Thu Jan 22 2004 - 16:56:58 EST
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 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/