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

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


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 : Sun Apr 23 2000 - 21:00:20 EST