To make it worthwhile, __init code would have to be loaded in a
separate page so it can be discarded after use. Also any symbols in
__init must be discarded immediately after module initialization.
Could probably do it by splitting each module into permanent and __init
code within insmod, loading as two separate modules, calling
module->init() then discarding the __init "module". That would only
affect modutils, not the kernel.
The appearance of __init sections in a module will require a new
version of modutils to handle it. Users will have to upgrade modutils
before they can boot any kernel that supports __init for modules.
Since all module sizes are rounded up to pages, adding __init support
will only save kernel storage on some modules. We will only save
storage on those modules where moving some data to __init reduces the
size of the rest of the module below a page boundary.
I worry that some code currently marked as __init might be incorrect
for modules. In a monolithic kernel, all initialization is done once
only. But for modules, a high level module can be loaded, unloaded and
reloaded. Each time it is loaded it can call the lower module's
initilization code which prevents the lower level module using __init.
See ethdev_init() in 8390.c for an example. All module code would have
to be checked for breakage on second and subsequent loads.
Since __init support for modules will force users to upgrade modutils,
might break incorrectly coded modules and is not guaranteed to save any
kernel storage - is it worth adding?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/