On 13-Nov-2008, at 4:32 PM, Michal Suchanek wrote:
2008/11/13 Greg A. Woods; Planix, Inc. <woods%planix.ca@localhost>:Sorry if I'm going only by what I've read in this thread an the "kmods" thread and reaching the wrong conclusions -- but I haven't yet seen any direct reference to a more detailed design or specification or requirementsanalysis, etc.Generally there are several uses for loadable kernel modules:
So, OK, can you please explain how your general outline of your view of dynamic run-time loadable kernel modules compares to the specific implementation that's being incorporated at the moment?
- loadable drivers can improve hardware support
Except there have been rumours (as yet unsubstantiated so far as I know, but...) that device drivers can't easily be adapted to work fully and properly in the implementation we're now seeing.
- development of driver is easier if you do not have to reboot every time you modify the driver. It is possible to make some parameters tunable at runtime but if you have to change some logic the possibility to unload and reload helps a lot
That would require that modules be unloadable -- and currently they're not, or so I've come to understand.
- some sort of module autoloading is a good idea. However, Linux had autoloading and they dropped the feature in favour of semi-automatic loading. That is, a userland process attaches somewhere to the kernel and the kernel tells it what feature is requested but missing (PCI/USB id of device to which no driver has bound so far, device major and minor of a block device opened but not present, filesystem type mounted, some special ID for something like POSIX semaphores when the first one is cerated). There is a service running that tries to look up a module which provides the feature or returns a failure if the module is not found or its loading is disabled by the user. People who do not trust autoloading may build a monolithic kernel or disable the service but still have the option to load modules manually. The service can be replaced by a simple script that just tries to load all modules, too.
That's very interesting, but it doesn't seem to look anything like what we're getting now.
To have reliable driver loading form userspace either the userspace support program has to load the drivers actively (ie load everything it can, and drivers that do not attach just fail to load) or there has to be a facility in the kernel that allows enumerating features that are requested but still not provided when such service starts (this will be typically devices to which no driver attached so far but there might be other uses). - automatic module unloading can be done by cron, no need to have kernel support for that
Huh?The kernel must still be in control of knowing what services (and drivers) which it needs. You could have a garbage collection kind of cleanup routine of course, but that's still got to communicate with the kernel to know what's needed and what's no longer referenced.
Also the actually procedure to unload the module _must_, by definition, be inside the kernel. It's kernel code and memory that's being manipulated!
- implementing modules that can be compiled either dynamically loadable or statically linked does not put any burden on people who customize their kernels and are satisfied with the current state - the functionality still can be still included in a statically linked kernel
That depends on the model -- such a goal _must_ be clearly stated in the design or else it will get botched and lost.
Loadable kernel modules are nothing new and the benefits are well known. If you have a real-world requirement that is not covered by current proposal why don't you explicitly state it?
Well, one good example is high-availability systems. They need to be able to unload, reload, and upgrade, various modules and subsystems, and perhaps event the whole core kernel, all without appearing to stop running, and perhaps doing so within some semi-real-time constraints.
As I said, so far the only stated goal seems to be to provide a means of allowing us to un-bloat the binary supplied variant of the "GENERIC" config kernel, which though in and of itself is a laudable goal, it can easily create an implementation which then clashes with the necessary features of implementations which meet other goals that also would require dynamic boot-time or run-time loading of modules (be they drivers, subsystems, or both).
We don't even seem to have agreement amongst portmasters that all ports will gain from this implementation!
The one potentially good thing that's been identified as a requirement of the current implementation is a better and proper definition of a kernel/driver (and kernel/subsystem) A_B_I. This of course assumes that it is indeed a good thing for the core NetBSD code base to better support binary-only vendors of NetBSD-based systems in their ventures to better support those systems in a binary-only world.
--
Greg A. Woods; Planix, Inc.
<woods%planix.ca@localhost>
Attachment:
PGP.sig
Description: This is a digitally signed message part