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

From: Andrew Morton (andrewm@uow.edu.au)
Date: Fri Apr 21 2000 - 23:05:16 EDT

  • Next message: Keith Owens: "Re: [RFC] Flat /lib/modules/`uname -r`"

    Keith Owens wrote:
    >
    > The segregation of modules into separate subdirectories under
    > /lib/modules/`uname -r` has pros and cons.
    >

    I like it.

    To integrate 3c575_cb back into 3c59x, Linus suggested that there be a
    symlink in /lib/modules/.../pcmcia/3c575_cb.o to ../net/3c59x.o. This
    caused a bit of grief because it's quite hard to know whether the user
    really wants the 3c575 driver. The presence of the pcmcia directory
    isn't a reliable indicator under some circumstances. Messy. So putting
    it all in a flat directory simplifies moving things about like this.

    That being said, the modutils toolchain should able to cope with modules
    which are symlinked to other modules for back-compatibility reasons.

    The PCMCIA tools package appears to have knowledge of the directories
    under /lib/modules/.../, so Dave will be impacted..

    As was mentioned earlier today, the mapping from (for example)
    "3CCFE575CT Cyclone CardBus" to "3c59x.o" is very unobvious at present.
    How is a poor user to know?

    I believe you're working on a tool to troll the modules, pulling out PCI
    device IDs? I didn't see that feature mentioned in your most recent
    announcement. Have you given any thought to extending this to create
    the full association between:

      Human readable device name(s)
      PCI identifiers
      module name

    It looks damn hard at present, and then there are non-PCI drivers... 

    -- 
-akpm-

    -
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 - 23:10:26 EDT