The design is to do this from config.in, not to modularise so you can select
on boot. Is that what you were asking?
> - By just allowing redirecting setup_memory_region you don't allow for
> architectures that don't have the 384K memory hole.
True. The split has been evolved only far enough to let me slot in the
voyager port fairly easily, and it has a 384K hole too. The idea is more to
begin the framework, so others can adapt it as more machine types come along.
Like all abstractions, unless they're tightly bound to the actual use, they
can become unwieldy and unusable very quickly as you abstract out things that
no-one is ever going to want. I erred on the side of utility.
> - setup_arch.h is nasty. What code it has depends on what it is
> defined
> when it is included. Couldn't 2 headers to this job better? Or
> better yet
> can't you just use function calls?
I agree with both of these. The main problem with the memory setup calls is
that most of them are static. I could export them and do overrides, like I do
for everything else, but as someone who also debugs the kernel, I like static
functions because they tell me the use is tightly isolated. I could easily do
two files, it was just looking more messy.
I'll see if I can export some of the setup.c internals and re-arrange this in
a more orderly way.
> - The hooks you add aren't used and are so generic it isn't obvious
> what
> they are supposed do from their names.
All of them are used if you look at the additional voyager stuff, what names
would you like to be more explicit?
> And of course you don't look at allowing different firmware
> implementations, but I'm doing that, so it is covered. :)
actually, I've silently ignored all the boot problems as well.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/