Messages in this thread | | | Date | Tue, 04 Apr 2006 12:23:24 -0700 | From | Zachary Amsden <> | Subject | Re: 2.6.17-rc1-mm1: KEXEC became SMP-only |
| |
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 - 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/
| |