On Sat, 22 Apr 2000, Keith Owens wrote:
> * modprobe needs to be updated whenever a new /lib/modules/`uname -r`
> directory is added or third party code is installed.
> All things considered, the cons outweigh the pros. In particular the
> need to update user space (modprobe) whenever a new modules/...
> directory is added is annoying and guarantees version skew.
This is only partially true. Two lines in /etc/conf.modules or
modules.conf will allow you to keep your existing search path as well as
add a new one. So an update to the utility is not required. Of course,
newer versions of modprobe would have an expanded list of directories
built-in, but that would not conflict with explicitly listing them in a
configuration file.
> I suggest :-
>
> (1) Store all kernel modules in /lib/modules/`uname -r`/kernel.
How would you deal with the namespace collision issues that arise from
this?
> (2) modutils looks for modules/.../kernel first, then the old names
> (block, ide, usb etc.) then all directories.
'all directories'? That sounds like a potential security issue....
> (3) make modules_install erases everything in modules/.../kernel before
> installing the new modules.
In general, this is probably a good thing. That is, deleting the old
modules in /lib/modules/`uname -r`/* before copying the new ones in place.
I've been bitten a few times where I basically had to do that manually to
prevent depmod -a from complaining.
> That preserves most of the pros. The only one we lose is "Users can
> tell from the directory what type of module they are looking at".
> Given the number of modules that are not currently categorized, I can
> live with that.
I think the better solution to this is to categorize those modules which
are not categorized.
> This method preserves backward compatibility, automatically scans all
> new subdirectories without user space changes and guarantees that the
> installed kernel modules will match your latest compile.
I don't like the idea of automatically scanning all subdirectories when
we're talking about dynamically linking code into the kernel. This just
sounds like a security hole waiting to happen.
Matt Dharm
-- Matthew Dharm Home: mdharm@one-eyed-alien.net Senior Engineer, QCP Inc. Work: mdharm@qualcomm.comI think the problem is there's a nut loose on your keyboard. -- Greg to Customer User Friendly, 1/5/1999
- 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/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:20 EST