On Mon, Feb 09, 2004 at 09:00:17AM -0800, Bill Studenmund wrote:
> On Sun, Feb 08, 2004 at 10:35:19AM +0100, Quentin Garnier wrote:
> > 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.
> 
> Hmmm.....
> 
> So if I had just:
> 
> module ex* at pci? device ? function ?
> 
> do I get both ex.ko and ex_pci.ko?

Yes.

[...]
> > 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).
> 
> I think need-count won't quite fit. As I recall, it's for static 
> allocation of driver resources. For an lkm, we can either embed a value 
> (in the lkm), or we can push to move drivers away from it.

There are only about 70 uses of needs-count, and I bet a lot of them are
questionable.  Others could be avoided using cloning devices (e.g., loop
device).

Quentin Garnier.