Built-in modules review

Chase Douglas chase.douglas at canonical.com
Wed Mar 17 18:59:54 UTC 2010


On Wed, Mar 17, 2010 at 2:50 PM, Scott James Remnant <scott at ubuntu.com> wrote:
> On Wed, 2010-03-17 at 14:48 -0400, Chase Douglas wrote:
>
>> On Wed, Mar 17, 2010 at 2:31 PM, Scott James Remnant <scott at ubuntu.com> wrote:
>> > On Tue, 2010-03-16 at 15:08 +0000, Andy Whitcroft wrote:
>> >
>> >> Filesystems: we currently have all of the ext2,3,4 filesystems builtin,
>> >> plus all of the diagnostics filesystems (procfs et al), and also fuse.
>> >> Other than FUSE these are all boot essential.  I believe FUSE is
>> >> required for automounting which needs confirmation.  No changes
>> >> required.
>> >>
>> > FUSE is built-in because we have no way of loading it
>> > otherwise; /dev/fuse would not exist without the module loaded, and fuse
>> > is generally used by user processes which don't have permission to
>> > modprobe.
>>
>> Is this because fuse is broken as a module, or because it just needs
>> to be loaded at boot because users can't do it without an escalation
>> of privileges? If it's the latter then why can't we load it
>> dynamically at boot time?
>>
> Load it dynamically by doing what?
>
> We have two module loading facilities:
>
>  - load because a kernel uevent contains a MODALIAS string that expands
>   to the module name (ie. load on hardware)
>
>  - load because the user opens the device node (load on demand)
>
> Since fuse has no hardware, and no device node until loaded, neither of
> these methods works.

The last time I worried about something like this was when I was
running gentoo a few years ago and you had to ensure that nvidia was
loaded before X started. There was some /etc file that was read at
boot time to load the modules listed within. Do we have anything like
that?

I think making fuse dynamic would be useful because fuse is a fairly
new technology that I could see people wanting to develop on or use a
newer version of without having to recompile their kernel.

-- Chase




More information about the kernel-team mailing list