Built-in modules review
chase.douglas at canonical.com
Wed Mar 17 21:56:57 UTC 2010
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.
More information about the kernel-team