On Thu, Sep 27, 2007 at 04:42:55PM +0900, Hiroyuki Bessho wrote:
> Bill Stouder-Studenmund wrote:
> >On Sun, Sep 23, 2007 at 01:54:37AM +0900, Hiroyuki Bessho wrote:
> >  
> >>At Tue, 18 Sep 2007 13:21:11 -0700,
> >>Bill Stouder-Studenmund wrote:
> >>    
> >>>      
> >>>>  I think we can allow users to say
> >>>>
> >>>>module       ne0	at isa? port 0x280 irq 9
> >>>>module "nex" ne1	at isa? port 0x290 irq 10
> >>>>module "nex" ne2	at isa? port 0x300 irq 11
> >>>>
> >>>>  In this case, module ne.o has ne and ne_isa driver codes and a
> >>>>device instance ne0. Module nex.o will have only config(9) glue staff
> >>>>to probe port 0x290 and 0x300 and attach ne1 and/or ne2 because ne and
> >>>>ne_isa related codes are in module ne.o.  I'm not 100% sure this works
> >>>>yet, but I guess that allowing users to specify module name for
> >>>>devices will provide good way for some configuration.  And if it
> >>>>works, config(1) can detect that module nex.o depends on module ne.o
> >>>>and can submit some useful information.
> >>>>        
> >>>Why would we want to support this option? I don't see the benefit to making 
> >>>something like the "nex" module.
> >>>      
> >>  I'm afraid this "nex" was not a good example for optional module
> >>name after `module' keyword.  I thought we'd better to allow users to
> >>change how to "group" the codes into modules. (Sorry that I can't
> >>think of a better English word than "group".  I mean which codes go to
> >>which module.)  I was afraid that whatever rules we define, users might
> >>want the other way.
> >>    
> >
> >Group is probably a good word. However I'm not sure why we want to support 
> >this. Why will users care exactly what is in which module?
> >
> >If we're really supporting modules, we also need a way (beyond the scope
> >of exactly what you're talking about here but rather directly enabled by
> >what you're talking about here) of loading the right modules. A way that a
> >daemon or startup tool can notice we need driver X loaded into the kernel.
> >For direct-attach busses (PCI), we can match the locators in user space to
> >get a candidate list, then let the modules in the kernel figure it out.
> >For indirect busses (ISA), we can load modules and see if they attach.
> >
> >The upshot is I fail to see why users will care what code is in exactly which 
> >module. Assuming the drivers the user wants are in there, what more will be 
> >needed?
> >  
>  OK, I gave up to convince you to think allowing optional module names is a 
> very useful feature, as I couldn't think
> of stronger examples.  Anyway it's optional and if we make good enough rules to 
> satisfy all users,  no one will use it.
> 

If module names are standartized (no optional module names) it becomes
easy to add module dependencies. The dependencies in the statically
compiled kernel are done using attributes, so let's just use it for
modules too, with every module having the same (file)name as the attribute
that it implements. Automatic resolving of dependencies at load time is
then easy. If you want to give modules arbitrary optional names, you would
probably need some extra file with dependencies (ala modules.dep on linux)
which you would have to regenerate and then resolving dependencies become
more complicated.

For combining more modules in one file, ar(1) could be used, if such
feature is found desirable.

Pavel