Hello, Sorry for the delay - last weeks were a bit hectic for me (and nothing will change till Friday when I'm off for holiday! :-)
On Thu, 2011-12-01 at 02:06 +0000, Rusty Russell wrote: > > Yes, this was my initial idea as well. The only problem I faced is the > > fact that there is no "between levels"... It's easy to add parameters > > parsing _at_ any particular level, but hard to do this _after_ level A > > and _before_ level B. The initcalls section simply contains all the > > calls, ordered by the level - the only "separated" level is the pre-SMP > > early one. And order within one level is determined by the link order, > > so I can't guarantee parsing the parameters as the first call of a level > > (nor as the last call of the previous level). > > Yeah, that's why I suggested changing the linker script. Sounded a bit scary, but turned out to be much less intrusive that I expected... I'll post the proposal in a second. > > /* This is the fundamental function for registering boot/module > > parameters. */ > > -#define __module_param_call(prefix, name, ops, arg, isbool, perm) \ > > +#define __module_param_call(prefix, name, ops, arg, isbool, late, perm) > > \ > > /* Default value instead of permissions? */ \ > > static int __param_perm_check_##name __attribute__((unused)) = \ > > BUILD_BUG_ON_ZERO((perm) < 0 || (perm) > 0777 || ((perm) & 2)) \ > > Might as well change isbool to "flags", since we have to fix callers > anyway. Sure thing, done. > > diff --git a/init/main.c b/init/main.c > > index 217ed23..ce89a53 100644 > > --- a/init/main.c > > +++ b/init/main.c > > @@ -407,7 +407,7 @@ static int __init do_early_param(char *param, char *val) > > > > void __init parse_early_options(char *cmdline) > > { > > - parse_args("early options", cmdline, NULL, 0, do_early_param); > > + parse_args("early options", cmdline, NULL, 0, 0, 0, do_early_param); > > It'd be nice to replace the early param stuff too, but that's probably a > separate patch. As is getting rid of the old __setup() calls everywhere > ;) I promise to look into it next year ;-) > But so far, it looks good! Cool, have a look at the patches following this mail then. I hope they make some sense, however it's unlikely I'll get them ready for 3.3 (unless they already are? ;-) because of my holidays. Maybe at least they could be linux-next-ed to see what did I break? Cheers! Paweł _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization