Hi,
On Thu, 21 Nov 2002, Adam J. Richter wrote:
> Can you tell me what problem in the existing userland module
> code (i.e., before 2.5.48) modulefs solves? Does it actually make
> the kernel smaller? Can you give me an example?
Previous insmod knows too much about kernel internals, it has to fill in
kernel structures, which makes changing this structure a real pain. Part
of the relocation work can be moved to kbuild, what makes insmod simpler
and gives us better control over the module layout. See the mini module
loader I posted last week.
> 1. Please take Petr's advice and just make module removal
> occur when you rmdir the directory. Making the removal happen in
> two stages introduces additioal states that have to be defined, such
> as the state where the "module unmap" command has been received
> but the module's directory has been removed. What if somebody else
> wants to load the same module again at this time? Either you will
> get flakiness in facilities that rely on automatic kernel module
> loading or modprobe has to be modified to deal with that
> possibility and perhaps try to do the remove itself.
Synchronizing multiple insmod is needed in user space anyway, this doesn't
make the kernel side more complex.
> 2. I would really like insmod to be able to flock modules (or
> do something similar). This would increment the reference count on a
> module until insmod would exit (or would do an execve, I suppose).
> This would eliminate a race when insmod is loading a module that
> references symbols in other modules. I don't think flock is actually
> propagated down the vfs layer, so perhaps some other primitive could be
> used. Perhaps just holding open an open file descriptor on each of
> the modules in question would be a better interface.
I don't know what you're trying to do here, but it sounds like you're
mixing user space and kernel space problems here.
> 3. It's not a modulefs thing, but you might want to consider
> moving all symbol management to user space, including that for the
> core kernel symbols. The symbol tables can be maintained in user
> files by the insmod and rmmod programs, they could even be inferred
> from the module's start address and the module's .o in the file
> system. If people really want to store this data to be stored in
> kernel memory, they can allocate extra space where the module is
> actually loaded and their favorite symbol table format there.
This is planned, symbols are only needed by kksymoops, otherwise they
don't have to be kept in memory all the time.
> 4. Regarding what I said about leaving symbol tracking to
> user space, I'd like to add a note about reliability. It is not
> necessary for rmmod to reliably remove symbols from these tables.
> insmod can check for symbols that map to places that are no longer
> allocated to modules and remove stale symbols before attempting to
> load a new module.
That's a mostly user space problem and I'd rather do this right, why
should I keep invalid symbols?
> 5. You should not need to do anything special in modfs
> to support init sections. That can be done by loading two separate
> modules and then removing the one corresponding to an init section.
I doubt that's a good idea, mostly also because of the following point.
> 6. For module_init functions, consider taking a pointer to
> an array of init functions and a count. That would be compatible
> with the system for built-in kernel object files, so it would
> eliminate a difference in linux/include/init.h. You could also do
> the same for module_exit functions. This change would also
> allow linking .o's together more or less arbitrarily into single
> modules, which would allow loading of modules that have reference
> loops among them.
Reference loops are never a good idea, if object files are that closely
related, create a single module. Multiple init/exit functions are no good
idea either, in which order should they be executed? If it's really one
module than also keep it one module.
> 7. Instead of module parameters, consider just supporting
> __setup() declarations used in kernel objects. These would then
> process a string that you'd pass. insmod might want to prepend the
> contents of /proc/cmdline to that string so that people could pass
> command lines at the boot prompt even if the driver they wanted to
> talk to were a module. This change would eliminate another difference
> between module and core kernel objects. Ultimately, I would like
> eliminate any compilation difference between kernel and module
> objects. This would allow deferring the decision about what should be
> in modules and what should be in the kernel until link time. Not only
> would this slightly simplify the build process and modules' source
> code,
Kernel parameter unification might actually be one of the few good parts
from Rusty's loader, but I have to look at, when it's working again.
> but it would also allow binary distributions for a wider
> variety of uses.
What does this mean???
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:39 EST