On Feb 10, 2008, at 12:39 AM, Andrew Doran wrote:
Hi, 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' will need special handling, and this may be another reason to keep it out of thedictionary, 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 themodule 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.
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.
Right.
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 likeputting 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. Thesystem 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'thave 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 just mentioned).
On the subject of version checks, right now NetBSD version numbers looksomething like the following: major.minor.patchlevelMy 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, ormajor+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.)
Thanks.