On Thu, Jan 21, 2016 at 11:52 AM, H. Peter Anvin <h...@zytor.com> wrote: > On 01/21/16 11:50, H. Peter Anvin wrote: >> >> Right... we already do that. >> >> I don't even think you need to initialize any tables. At least on i386, >> we have to do this in assembly code. However, it is just a simple table >> walk. :) >> > > It might make more sense to make subarch its own table, though, although > I haven't looked at your code in enough detail to say.
The gist of it: void x86_init_fn_early_init() { for_each_table_entry(init_fn, X86_INIT_FNS) { if supported subarc init_fn->early_init(); } void x86_init_fn_setup_arch() { for_each_table_entry(init_fn, X86_INIT_FNS) { if supported subarc init_fn->setup_archt(); } Right now the code defines just an init routine at the stage for x86_64_start_reservations(), we call the callback early_init(), ie setup_arch() doesn't exist yet. Since certain routines can run on either Xen or bare-metal we allow a bitwise OR for the subarch as a bitmask. I'll think a bit more about how to use subarch for a table, but can't fit it yet. I'd like to later revise kfree'ing unused sections, and a table per subarch might be nice for that, but otherwise this flow seems easy to follow, so if we can kfree sections within a table we could still accomplish that later. Luis