Hello,
first, thanks much for the proposal.

Some thoughts:

>> Case 2:
>> 
>> module ex* at pci? device ? function ? module ex* at cardbus? cardslot
>> ?
>> 
>> ===> 3 modules are created:  ex.ko, ex_pci.ko and ex_cardbus.ko.

There should be a way to embed in the ex_pci.ko module the information that it
depends on the ex attribute, and in a similar way, to embed in ex.ko the
information that it:
- provides ex
- depends on arp, ether, ifnet, mii, mii_bitbang

>> 
>> Case 3:
>> 
>> module ex* at pci? device ? function ? ex* at cardbus? cardslot ?
>> 
>> ===> only one module is created, since attribute ex_cardbus is static
>> and
>>      depends on attribute ex.  The module name is ex_pci.ko.

There should be a way for the running kernel to tell all the attributes it has
compiled in. That way you know the kernel has attribute ex and you can safely
load ex_pci.ko which depends on it, without loading any other LKM.

If such information is embedded in the LKMs themselves (and in the kernel),
there will be no need for a "depmod" utility (like in Linux, see below) and for
separately maintained dependency information (which could get out of sync).

Also, the dependencies should be at attribute level (ex_pci.ko needs ex), not at
module level (i.e. ex_pci.ko needs ex.ko - NOT!), because the functionality you
need may be compiled in the kernel.

Is the ELF format extensible enough to have the dependency information in a
special section?

> 
> My concern is that by having multiple module options, we create a
> support morass. If this implementation is the direction we all want to
> go, I'd rather have it than nothing.
> 
> But I think we'd be better served if we came up with some standard way
> to carve the kernel up into modules. Among other things, drivers that

As I understand it, there would be a standard way - because for each attribute,
there would be a module.

> depended on other subsystems could easily register a dependence on them.

As I understand it, they already can - by registering dependency on attributes.

> I'm mainly thinking of audio drivers, but usb would probably fit, and I
> bet there will be more with time.
> 
> We will need a standard set of modules to be able to really support
> 3rd-party modules. If I as a vendor can't be sure about how to tell

I think there should be a standard set of attributes. If the code for those
attributes is statically linked into the kernel or provided in a module
shouldn't matter, no?

> 
> I appreciate that you're working on this. Please keep doing it!

I also appreciate it. But please, do it well, not like Linux.

> 
> As an aside, I think we can learn a lot from Linux here. From what I
> understand, they did some very unpleasant things at first, and have
> itterated; we should learn from their mistakes and successes. How do

I don't see much improvement. But maybe in the 2.6 kernel there is some - I
haven't tried it yet.

> they handle this?

As I understand it (if there are Linux gurus here, feel free to correct me, I'm
not a kernel expert), the dependency in Linux LKMs are at symbol level. There is
a tool (depmod) which computes dependencies from a set of modules (by resolving
symbols) and creates a file describing dependencies at module level (which
modules does a given module need). (It also reads symbols from the kernel via
/proc/ksyms, or it can use a saved copy of /proc/ksyms). I often saw problems
with unresolved dependencies for reasons that I didn't have neither knowledge
nor patience to investigate.

The depmod utility is run on every boot to regenerate dependency information, in
case something changes. This is slow (at least on Debian). From the manual page
of depmod, there is an option which causes depmod to not recompute dependencies
if the LKMs were not changed, but Debian doesn't seem to use it.

The file generated by depmod is the used by the modprobe utility, which loads
modules and takes care of loading their prerequisites transitively.

All this is sometimes annoying. But true _horror_ begins with autoloading,
specifically with autoloading of hardware drivers. The problem is, if you access
/dev/sd*, the sd driver must be autoloaded. (No problem yet). But you probably
need a driver for your SCSI adapter (problem starts!). How can the modprobe
utility know what SCSI HBA driver do you need? There's plenty of them, all are
suitable for attaching a SCSI disk! This is "solved" by having the SCSI bus
driver depend on a pseudo-driver scsi_hostadapter, and having in
/etc/modules.conf a line like

alias scsi_hostadapter    aic7xxx

which tells that when a LKM need scsi_hostadapter, aic7xxx should be loaded.
Same issue with soundcards (what driver should be loaded if you access
/dev/audio? Just look at the "alias sound-slot-0 ..." line). Same issue with
NICs (what driver should be loaded if you use eth0?), etc. The result is that
dynamic autoconfiguration DOES NO LONGER WORK. The configuration becomes
stateful. There must be a program which scans your hardware at each change and
writes correct entries to /ec/module.conf . (In RedHat, this program (called
kudzu) is run on every boot, in case you change your HW).

Dynamic loading of network protocols and filesystems doesn't seem to have such
problems, because in this case it's always clear what functionality you want.

The only solution is to load all the hardware drivers for the hardware you have.
It wastes some memory, if you don't use this hardware, but this shouldn't do
much harm. How this should be done is another question.

> 
> Take care,

Yes, when dealing with LKMs, care should be _really_ taken.

Bye	Pavel