guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Danny Milosavljevic
Subject: [bug#30604] [PATCH v10 5/6] linux-initrd: Provide our own 'modprobe' program.
Date: Tue, 13 Mar 2018 10:27:06 +0100

Hi Ludo,

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.
(can't evaluate anything here)

> > (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)

>Thanks for the insightful review!

You're welcome :)

Attachment: pgpcHSy4BTp9J.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]