Built-in modules review

[Chase Douglas]

On Wed, Mar 17, 2010 at 5:35 PM, Andy Whitcroft <apw at canonical.com> wrote:
> 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.

Though I'm not entirely convinced of arguments other than speed, I
can't think of any silver bullet for this issue.

I'm still not crazy about statically compiling it in, but it's likely
to be better than the opposite in the long run.

-- Chase