Re: [PATCH][RFC] disable built-in modules V2

[Malcolm Rowe]

Magnus Damm writes:
> > Regardless of anything else, won't this break booting with initcall_debug on
> > PPC64/IA64 machines? (see the definition of print_fn_descriptor_symbol() in
> > kallsyms.h)
>
> Correct, thanks for pointing that out. The code below is probably better: 
>
>  static void __init do_initcalls(void)
>  {
>         initcall_t *call;
> @@ -547,6 +558,9 @@ static void __init do_initcalls(void)
>         for (call = __initcall_start; call < __initcall_end; call++) {
>                 char *msg; 
>
> +               if (!*call)
> +                       continue;
> +
>                 if (initcall_debug) {
>                         printk(KERN_DEBUG "Calling initcall 0x%p", *call);
>                         print_fn_descriptor_symbol(": %s()", (unsigned
> long) *call);

Yes, that looks more sensible. It hides the fact that the initcall ever 
existed, rather than explicitly telling you that it's been skipped, but I 
don't imagine that that's ever going to cause a problem in practice (i.e., I 
don't think anyone would ever enable "force_ohci1394=off" by mistake and 
also without noticing). 


> And I guess the idea of replacing the initcall pointer with NULL will
> work both with and without function descriptors, right? So we should
> be safe on IA64 and PPC64.

I think so, though I don't really know a great deal about this area. 


An IA64 descriptor is of the form { &code, &data_context }, and a function 
pointer is a pointer to such a descriptor. Presumably, setting a function 
pointer to NULL will either end up setting the pointer-to-descriptor to NULL 
or the code pointer to NULL, but either way, I would expect the 'if 
(!*call)' comparison to work as intended. 


Best thing would be to get someone on IA64 and/or PPC64 to check this for 
you. Also might be worth checking that the patch works as intended with 
CONFIG_MODULES=n (assuming you haven't already). 


Regards,
Malcolm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/