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

[Zachary Amsden <zach@vmware.com>]

Eric W. Biederman wrote:
>
> If all you are doing is this one little clean up we can probably stop here.
> But this looks like a start on getting a vmi or xen subarch working.
>   

Yes, that is certainly part of the purpose.  But the subarch layer 
really should be cleaned up, and getting rid of code duplication seems 
like a good first step.

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

This gets rid of both the code duplication and makes it somewhat more 
obvious what is going on - plus it is easy to extend to other functions, 
and as a bonus feature, you don't need to change any code in other 
subarchitectures if you need to add a new hook.


Zach