Re: MODULAR: Add support for load-time options

[Andrew Doran <ad%netbsd.org@localhost>]

Hi,

On Sat, Feb 09, 2008 at 09:40:22AM +0100, Julio M. Merino Vidal wrote:

> The patch below changes the new modular framework to allow the user  
> to pass arbitrary options to the module at load time.  This is done  
> by using a proplib dictionary.
> 
> modload is changed to allow setting load-time variables, adding one  
> flag for each supported variable type.  (I tried using a single flag  
> and specifying the type as part of its value, but that seemed too  
> confusing.)  So modload's syntax is now:
> 
> Usage: modload [-b var=boolean] [-f] [-i var=integer] [-s var=string]
>        <module_name>
> 
> As part of this change, I've also killed MODCTL_FORCELOAD; in my  
> opinion, this made little sense as a separate command.  It should  
> just be an option to MODCTL_LOAD.  Now there are two ways to better  
> handle that: either pass in a 'force' property in the new dictionary  
> (as the code does), or stick a boolean in the syscall's arguments.   
> I'm yet unsure as to what the best approach can be.  On the one hand,  
> keeping it in the dictionary make things simpler and does not treat  
> the 'force' property as anything special.  On the other hand, 'force'  
> is something specific to the kernel, and not something the final  
> modules should see, hence it may make more sense to keep it out of  
> the dictionary.
> 
> At last, the current code is passing down the dictionary to any  
> modules loaded as dependencies (yeah, I know they don't work at the  
> moment).

I'll see if I can fix the dependency issue, I don't think it will take long.

> I'm also unsure if this makes sense.  (If it does not, 'force' will need
> special handling, and this may be another reason to keep it out of the
> dictionary, as mentioned above.)
> 
> Any comments?

Cool. One of the main things that I'd like to see is the kernel being able
to load modules without intervention from userspace. When discussing the
module stuff with Jared one of his ideas was that we could include
properties in the file system alongside the module, eg 'module' and
'module.prop' or whatever. If the boot blocks load the module, then they
would have to load that too and pass it in. My ideal would be to have the
propery list loaded from the file system by the kernel, and allow 'modload'
to override values or provide additional ones.

I think that the property list shouldn't be passed down to dependent
modules; if you need to do something irregular like a forced load then
convenience is not a concern and you can do it by hand.

The original idea was for forceload to only be meaningful for the module
loader (kern_module.c). In some ways, passing it in as a property seems like
putting the info into the wrong domain, since it's really a control
operation, yet I guess that modules may want to know about it too. The
system call interface is dumb by design since I was hoping for the kernel to
make most decisions. I kind of like it as a seperate command but I don't
have a strong opinion.

On the subject of version checks, right now NetBSD version numbers look
something like the following:

        major.minor.patchlevel

My thinking is that if minor is 99 then it's a -current kernel/module and
we'd call the entire version number signficant: if it differs in any way
don't load the module. If a release branch then we'd check only major, or
major+minor. I'm open to suggestions..

Thanks,
Andrew