Built-in modules review

[Andy Whitcroft]

On Wed, Mar 17, 2010 at 05:18:28PM -0400, Chase Douglas wrote:
> On Wed, Mar 17, 2010 at 4:45 PM, Scott James Remnant <scott at ubuntu.com> wrote:
> > On Wed, 2010-03-17 at 15:24 -0400, Chase Douglas wrote:
> >
> >> True, but the module loading mechanism isn't the real issue here.
> >>
> > It is from my point of view.
> 
> In what way? Is it that the method we used before is too slow even for
> just fuse, would hit everyone regardless of whether they use it, has
> been ripped out of lucid already, some other issue?

The problem is that userspace has to know the names of the kernel
components, and the two are not maintained in lock step.

For the this module goes with this device sceanario the kernel tells
userspace to load a module within itself.  This means that the thing
userspace needs to load, the handle to load it, is passed out of the
kernel and naturally linked intrinsically and correctly with the thing
to be loaded.

In the case of these other sorts of modules like fuse, the name of the
module in the kernel has to be known from outside the kernel.  This
implies an implicit dependancy between the kernel and userspace, the
/etc/modules file in fuse's case, between the kernel and drm-utils for
lvm and the like.  This makes moving between kernel versions fraught
with risk.  The removal of all that information from modules lists and
from udev configuration has been a big step in simplifying dropping in
kernel updates without issues.  A plank in the allowing kernel backports
in the future.

-apw