Le Sat, 7 Feb 2004 19:33:54 -0800
Bill Studenmund a ecrit :
[...]
> > The user will have several choices:
> > 
> > Case 1, good'old GENERIC_LAPTOP:
> > 
> > ex* at pci? device ? function ?
> > ex* at cardbus? cardslot ?
> > 
> > ===> No module is created
> > 
> > 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.
> > 
> > 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.
> 
> 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.

The issue here is that prefixing a device instance by 'module' will make
every possible modules: the module for the driver itself, and all its
direct dependencies that nothing statically compiled depend on.

> 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
> depended on other subsystems could easily register a dependence on them.
>  
> I'm mainly thinking of audio drivers, but usb would probably fit, and I
> bet there will be more with time.

Even though the user has some control (I'd hope so :) over what modules
are created, their content will not usually change.

There is code, though, that will merge modular attributes in the case a
file is shared by several modules.  It is there so that making modules in
such case will still work, but it should be considered a bug when it
happens.  We should ship with a set of files.* that describe modules which
are tied to unique attribute names.

That way, for an attribute, either it is statically compiled, or not
compiled at all, or in a module.  When it is in a module, the module name
will always be the same.

There are already issues with our current monolithic kernel: need-count is
not available to LKMs (neither is need-flag, but if you lack the symbols,
you know it's not there).

> 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
> users what they need to use my driver, I'll find I have to support
> something "different." Also, if I choose to modularize things
> differently, and end-user will be irritated I want them to change. If I
> do things differently from a different 3rd-party vendor, we end up with
> drivers that can't be mutually loaded.

Once we progress in the modularisation direction, we will have something
such as GENERIC.MODULES which will do about the same as FreeBSD's GENERIC:
compile all possible modules.  Therefore we will have a standard set of
modules, as in "on the install media".

But anyway, I don't think it will be an issue for 3rd-party vendors.  When
I think about the next step (I mean, the Next Step), which is an in-kernel
linker, I would prefer if module dependencies were expressed in terms of
attributes and/or symbols.

Thus, the 3rd-party module will be compiled with a set of dependencies,
and the linker will be able to tell whether the attributes or symbols are
available, and point the user to the module to be loaded if something is
not there.

There will be a lot of work on the design of this, for sure.

-- 
Quentin Garnier - cube@NetBSD.org
The NetBSD Project - http://www.NetBSD.org/