[bug#30604] [PATCH v10 5/6] linux-initrd: Provide our own 'modprobe' program.

[Ludovic Courtès]

Hello,

Danny Milosavljevic <address@hidden> skribis:

> On Mon, 12 Mar 2018 23:14:59 +0100
> address@hidden (Ludovic Courtès) wrote:
>
>> > One of the devnames created statically is the one for btrfs, so not 
>> > writing or
>> > using devnames is not going to end well.  
>> 
>> We’re fine because btrfs, 9p, overlay, etc. all have an “fs-btrfs”,
>> “fs-9p”, etc. alias, which shows up in “modules.alias”.  No need for
>> “modules.devname” AFAICS.
>
> The other filesystems are not such a problem - but BTRFS has its own 
> snapshotting/
> multivolume functionality - and it's possible that someone accesses 
> /dev/btrfs-control
> "too early" for that.
>
> I applied your patches to a fresh clone of guix master now, ran the 
> btrfs-root-os
> system check, and indeed I get (tried two rounds, happened both times):
>
> $ make TESTS=btrfs-root-os check-system
> [...]
> Scanning for Btrfs filesystems
> WARNING: failed to open /dev/btrfs-control, skipping device registration: No 
> suy
> ERROR: there are 1 errors while registering devices
> File system check on /dev/vda2 failed; spawning Bourne-like REPL
> GNU Guile 2.2.3
> Copyright (C) 1995-2017 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.

Do you see a modprobe invocation for “fs-btrfs” or “block-major-xxx”
before?

>> > (I'd also copy the modules.builtin (from Linux).
>> >  Also, what happens if we load a module which has as dependency a builtin?
>> >  Will we try to load the builtin as a .ko file and fail the entire thing?) 
>> >  
>> 
>> The dependency of a builtin is necessarily a builtin, 
>
> Yes.
>
>>and the kernel won’t invoke modprobe for a builtin, will it?  
>
> I've read Linux's __request_module and I can't find where they
> pre-check anything - neither whether there's already a builtin
> nor whether it's loaded already.
>
> They probably don't check.  But I'll read it again, more carefully...
>
> (request_module isn't that popular so it makes sense for them not to 
> complicate
> the kernel by these checks when there are like 8 callers in total - and all 
> on init)

Right, and the worst that can happen is that modprobe will fail, but
that’s fine because the functionality is already there anyway.

Ludo’.