From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 13 06:51:47 2018 Received: (at 30604) by debbugs.gnu.org; 13 Mar 2018 10:51:47 +0000 Received: from localhost ([127.0.0.1]:58132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evhX1-0003qJ-EI for submit@debbugs.gnu.org; Tue, 13 Mar 2018 06:51:47 -0400 Received: from hera.aquilenet.fr ([185.233.100.1]:58830) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evhWz-0003q9-FD for 30604@debbugs.gnu.org; Tue, 13 Mar 2018 06:51:46 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 33E53125F4; Tue, 13 Mar 2018 11:51:44 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmJFb8LwayUe; Tue, 13 Mar 2018 11:51:43 +0100 (CET) Received: from ribbon (vpn-0-27.aquilenet.fr [IPv6:2a0c:e300:4:27::]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 1D0A01128C; Tue, 13 Mar 2018 11:51:43 +0100 (CET) From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: Danny Milosavljevic Subject: Re: [bug#30604] [PATCH v10 5/6] linux-initrd: Provide our own 'modprobe' program. References: <87ina1qxic.fsf@gnu.org> <20180312123918.22645-1-ludo@gnu.org> <20180312123918.22645-5-ludo@gnu.org> <20180312210936.7f89a29c@scratchpost.org> <87h8plkkkc.fsf@gnu.org> <20180313100539.442c4aa9@scratchpost.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 23 =?utf-8?Q?Vent=C3=B4se?= an 226 de la =?utf-8?Q?R?= =?utf-8?Q?=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Tue, 13 Mar 2018 11:51:42 +0100 In-Reply-To: <20180313100539.442c4aa9@scratchpost.org> (Danny Milosavljevic's message of "Tue, 13 Mar 2018 10:27:06 +0100") Message-ID: <87zi3cp7sx.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 30604 Cc: 30604@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) Hello, Danny Milosavljevic skribis: > On Mon, 12 Mar 2018 23:14:59 +0100 > ludo@gnu.org (Ludovic Court=C3=A8s) wrote: > >> > One of the devnames created statically is the one for btrfs, so not wr= iting or >> > using devnames is not going to end well.=20=20 >>=20 >> We=E2=80=99re fine because btrfs, 9p, overlay, etc. all have an =E2=80= =9Cfs-btrfs=E2=80=9D, >> =E2=80=9Cfs-9p=E2=80=9D, etc. alias, which shows up in =E2=80=9Cmodules.= alias=E2=80=9D. No need for >> =E2=80=9Cmodules.devname=E2=80=9D AFAICS. > > The other filesystems are not such a problem - but BTRFS has its own snap= shotting/ > 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=3Dbtrfs-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 =E2=80=9Cfs-btrfs=E2=80=9D or =E2=80= =9Cblock-major-xxx=E2=80=9D before? >> > (I'd also copy the modules.builtin (from Linux). >> > Also, what happens if we load a module which has as dependency a buil= tin? >> > Will we try to load the builtin as a .ko file and fail the entire thi= ng?)=20=20 >>=20 >> The dependency of a builtin is necessarily a builtin,=20 > > Yes. > >>and the kernel won=E2=80=99t invoke modprobe for a builtin, will it?=20=20 > > 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 comp= licate > the kernel by these checks when there are like 8 callers in total - and a= ll on init) Right, and the worst that can happen is that modprobe will fail, but that=E2=80=99s fine because the functionality is already there anyway. Ludo=E2=80=99.