Messages in this thread | | | Date | Tue, 4 Apr 2006 13:25:46 -0700 | From | Andrew Morton <> | Subject | Re: 2.6.17-rc1-mm1: KEXEC became SMP-only |
| |
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().
- 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/
| |