In message <20021118073247.A10109@adam.yggdrasil.com> you write:
> The following untested patch adds subdirectory support to
> module-init-tools-0.6/modprobe.c. I really need this for tools that I
> use for building initial ramdisks to do things like select all SCSI
> and IDE drivers without having to release a new version of the ramdisk
> maker every time a new SCSI or IDE driver is added. The patch is a net
> addition of four lines to modprobe.c.
Hmm, I'm not entirely convinced. Moving back into subdirs introduces
a namespace which isn't really there. However, as you say, it's
trivial.
> I am sorry I was not able to test this change, but it would be
> a lot of work for me to bring up a system without module device ID
> table support. I know your ChangeLog says that support is coming. I
> wonder if it would break your module utilities to leave the old macros
> device ID macros in place and let people run the existing depmod.
I'm actually tempted to push your patch for the moment, since it might
be a week before device ID support is tested and polished enough to go
in, with everything else I am doing. OTOH, the current method exposes
kernel internals to external userspace programs, which is why I do it
differently.
> I also worry about about the latency of reading the
> kernel symbols for all modules every time modprobe is called. If I
> want to have all of the modules installed, that's at least 1143
> modules on x86, and this might be the standard installation of a Linux
> distribution. Here again, the existing depmod program could be used.
Yes, it's a fairly obvious optimization: I'd be very interesting in
timing measurements. Another method is to use
/var/cache/modprobe/`uname-r`.dep and use it if available and more
recent than any module (removes the requirement for depmod).
> Finally, I am skeptical of the benefits being worth the cost
> of putting an ELF relocator and symbol table parser in the kernel.
>From the (just posted) FAQ:
Q: Doesn't putting linking code into the kernel just add bloat?
A: The total linking code is about 200 generic lines, 100
x86-specific lines. The ia64 linking code is about 500 lines (it's
the most complex). Richard Henderson has a great suggestion for
simplifying it furthur, which I'm implementing now. "insmod" is
now a single portable system call, meaning insmod can be written in
about 20 lines of code.
The previous code had to implement the two module loading
system calls, the module querying system call, and the /proc/ksyms
output, required a little more code than the current x86 linker.
Q: Why not just fix the old code?
A: Because having something so intimate with the kernel in userspace
greatly restricts what changes the kernel can make. Moving into
the kernel means I have implemented modversions, typesafe
extensible module parameters and kallsyms without altering
userspace in any way. Future extensions won't have to worry about
the version of modutils problem.
Hope that clarifies,
Rusty,
-- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - 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:26 EST