On Sun, Nov 2, 2014 at 3:37 AM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote:
> On Thu, 30 Oct 2014, Geert Uytterhoeven wrote:
>> On Thu, Oct 30, 2014 at 12:49 AM, Tim Bird <tim.bird@xxxxxxxxxxxxxx> wrote:
>> > The way the feature is expressed in the current code is that a
>> > set of drivers are marked for deferred initialization (I'll refer
>> > to this as issue 0). Then, at boot: 1) most drivers are initialized
>> > normally, 2) user space is started, and then 3) user space indicates
>> > to the kernel that the deferred drivers should be initialized.
>>
>> One (IMHO important) point in the current implementation is that the call
>> to free_initmem() is also delayed until after initialization of the
>> deferred drivers.
>>
>> This is different from modular drivers, which are loaded after free_initmem().
>
> This is because modules have their __initmem sections freed right after
> each module is initialized.
I know.
But it means _all_ init sections are kept until userspace kicks the deferred
initcalls, and they have completed.
> The deferred initcalls could also have a separate initmem section which
> freeing is also deferred. But I don't think it makes such a big
> difference in the end.
Yes, it can be handled.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
