[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: MODULAR: Add support for load-time options
On Feb 10, 2008, at 12:39 AM, Andrew Doran wrote:
On Sat, Feb 09, 2008 at 09:40:22AM +0100, Julio M. Merino Vidal wrote:
I'm also unsure if this makes sense. (If it does not, 'force'
special handling, and this may be another reason to keep it out of
dictionary, as mentioned above.)
Cool. One of the main things that I'd like to see is the kernel
to load modules without intervention from userspace. When
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
would have to load that too and pass it in. My ideal would be to
propery list loaded from the file system by the kernel, and allow
to override values or provide additional ones.
Hmm, interesting. However, I don't think that the two ideas (load a
file from the file system, and pass properties from modload)
conflict. If you want, in the end, to allow modload to override
values or provide additional ones, how do you do it? Based on this
proposal, what I'd do is: let the kernel load the dictionary from the
file system (more on this below) and, if the user has provided a new
dictionary from modload, merge its contents with those of the one
loaded from the file system overriding any already-present values.
(So, we can now do this for modload and later implement the load of
properties from the file system.)
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
loader (kern_module.c). In some ways, passing it in as a property
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
make most decisions. I kind of like it as a seperate command but I
have a strong opinion.
The thing that worries me about having force load as a separate
command is that we may eventually need to add other load-time options
that do not really make sense as part of the module's properties.
For example, what you mentioned above makes me think that we may also
want to add a flag to tell the kernel "do not load the properties
file from the file system at all, and instead use only the properties
I'm providing you now". If we find that we need additional flags
such as these ones, we'll be adding new commands and thus loads of
combinations: normal load, load + force, load + no properties, load +
force + no properties, etc. I see force and similar flags as
modifiers of the command, so they should be passed as parameters.
I also agree that putting force in the properties is in the wrong
domain (more so when you think of other properties such as the one I
On the subject of version checks, right now NetBSD version numbers
something like the following:
My thinking is that if minor is 99 then it's a -current kernel/
we'd call the entire version number signficant: if it differs in
don't load the module. If a release branch then we'd check only
major+minor. I'm open to suggestions..
That makes sense and is simple enough. Maybe this is not the
greatest option, but will serve us well for now, I think. (We are
not really committed (yet) to a stable kernel API, so... strict
checks are OK.)
Main Index |
Thread Index |