GNU bug report logs - #30604
[PATCH 0/4] Load Linux module only when supported hardware is present.

Previous Next

Full log

View this message in rfc822 format

From: ludo <at> gnu.org (Ludovic Courtès)
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: 30604 <at> debbugs.gnu.org
Subject: [bug#30604] [PATCH v10 5/6] linux-initrd: Provide our own 'modprobe' program.
Date: Tue, 13 Mar 2018 11:51:42 +0100

Hello,

Danny Milosavljevic <dannym <at> scratchpost.org> skribis:

> On Mon, 12 Mar 2018 23:14:59 +0100
> ludo <at> gnu.org (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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.