Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Please read if you use x86 -current

On 13-Nov-2008, at 4:32 PM, Michal Suchanek wrote:

2008/11/13 Greg A. Woods; Planix, Inc. <>:

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 requirements
analysis, 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


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

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.

Attachment: PGP.sig
Description: This is a digitally signed message part

Home | Main Index | Thread Index | Old Index