Re: [RFC] Flat /lib/modules/`uname -r`

From: Matthew Dharm (mdharm-kernel@one-eyed-alien.net)
Date: Fri Apr 21 2000 - 20:45:04 EDT

  • Next message: kumon@flab.fujitsu.co.jp: "Re: namei() query"

    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.com

    I 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 : Fri Apr 21 2000 - 21:00:20 EDT