Re: 2.6.17-rc1-mm1: KEXEC became SMP-only

[Andrew Morton <akpm@osdl.org>]

Zachary Amsden <zach@vmware.com> wrote:
>
> > If this is really a prelude to introducing more subarchitectures we
>  > need to fix the infrastructure, so it is obvious what is going on.
>  > I would really like to see a machine vector, so we could compile in
>  > multiple subarchitectures at the same time.  That makes building
>  > a generic kernel easier, and the requirement that the we need
>  > to build a generic kernel makes the structure of the subarchiteture
>  > hooks hierarchical and you wind up with code whose dependencies
>  > are visible.  Instead of the current linker and preprocessor magic.
>  > Functions named hook are impossible to comprehend what they
>  > are supposed to do while reading through the code.
>  >   
> 
>  I see your point.  Are you thinking of something like:
> 
>  struct subarch_hooks subarch_hook_vector = {
>       .machine_power_off = machine_power_off,
>       .machine_halt = machine_halt,
>       .machine_irq_setup = machine_irq_setup,
>       .machine_subarch_setup = machine_subarch_probe
>       ...
>  };
> 
>  And machine_subarch_probe can dynamically change this vector if it 
>  confirms that the platform is appropriate?

I don't recall anyone expressing any desire for the ability to set these
things at runtime.  Unless there is such a requirement I'd suggest that the
best way to address Eric's point is to simply rename the relevant functions
from foo() to subarch_foo().