From: "Ludovic Courtès" <ludo@gnu.org>
To: Brian Cully <bjc@spork.org>
Cc: 55231@debbugs.gnu.org, Brian Cully <bjc@kublai.com>
Subject: [bug#55231] [PATCH v1] initrd: Allow extra search paths with ‘initrd-extra-module-paths’
Date: Fri, 03 Jun 2022 09:27:14 +0200 [thread overview]
Message-ID: <87fskmky0d.fsf@gnu.org> (raw)
In-Reply-To: <87a6aug4p2.fsf@ditto.jhoto.spork.org> (Brian Cully's message of "Thu, 02 Jun 2022 16:40:36 -0400")
Hi,
Brian Cully <bjc@spork.org> skribis:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> I wonder if we could reuse the ‘kernel-loadable-modules’ field for
>> this
>> purpose instead of introducing a new field. We’d need to pass it to
>> the
>> initrd procedures and have them search in there in addition to the
>> kernel package, pretty much like this patch already does actually.
>
> This sounds like it could be made to work as you suggest. My feeling
> is that the two contexts are slightly different, though, as the Linux
> modules are a superset of the initrd modules,
Right. Here, we want the initrd machinery to search for modules in any
place where they can be found, which is either ‘kernel’ or
‘kernel-loadable-modules’.
One could define ‘initrd-extra-module-paths’ to be different from
‘kernel-loadable-modules’, for example if you can be sure the module
will be loaded from the initrd and not after, but in general both are
likely to have the same value, no?
>> Nitpick: the GNU convention is to use “path” to denote “search
>> paths”,
>> and other “file”, “file name”, or similar. In this case, that’d be
>> “kernel module” or “Linux module”.
>
> I struggled with this a fair amount, actually. What these file-likes
> actually represent is an element of a search path, even if they come
> in the odd form of a file-like object, which is why I used
> ‘path’. ‘file’ seems wrong, as it implies (to me) that it’s the
> ‘initrd-extra-module-files’ option itself that would include the
> module, rather than the ‘initrd-modules’ option.
Hmm right, you have a point! :-)
> When I get some time (hopefully soon!) I’ll try to thread
> ‘kernel-loadable-modules’ through instead and see how far I can get
> with that approach. Do you think the documentation for it will need to
> be updated to specify that it’s also used as a search path for initrd
> building? Or maybe the better option is to update the documentation
> for ‘initrd-modules’ to say that it uses ‘kernel-loadable-modules’ as
> input?
I think you should update the documentation in the commit that changes
things, so that the patch is self-contained.
It may be enough to state in the documentation of the ‘initrd-modules’
field that its value is a list of module names that are searched for in
‘kernel’ and ‘kernel-loadable-modules’.
WDYT?
Thanks,
Ludo’.
next prev parent reply other threads:[~2022-06-03 7:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-02 19:11 [bug#55231] [PATCH v1] initrd: Allow extra search paths with ‘initrd-extra-module-paths’ Brian Cully via Guix-patches via
2022-05-02 22:03 ` Maxime Devos
2022-05-02 22:53 ` Brian Cully via Guix-patches via
2022-05-13 19:46 ` Kaelyn via Guix-patches via
2022-05-13 20:25 ` Maxime Devos
2022-05-21 19:12 ` [bug#55231] [PATCH v2] " Brian Cully via Guix-patches via
2022-06-01 15:54 ` [bug#55231] [PATCH v1] " Ludovic Courtès
2022-06-02 20:40 ` Brian Cully via Guix-patches via
2022-06-03 7:27 ` Ludovic Courtès [this message]
2022-05-30 20:14 ` Kaelyn via Guix-patches via
2022-06-02 21:23 ` Kaelyn via Guix-patches via
2022-06-17 1:51 ` [bug#55231] [PATCH v2 1/2] Allows copying of out-of-tree modules to the Linux initrd Brian Cully via Guix-patches via
2022-06-17 20:34 ` [bug#55231] [PATCH v1] initrd: Allow extra search paths with ‘initrd-extra-module-paths’ Ludovic Courtès
2022-06-18 19:11 ` [bug#55231] [PATCH v3 1/2] Allows copying of out-of-tree modules to the Linux initrd Brian Cully via Guix-patches via
2022-06-18 19:11 ` [bug#55231] [PATCH v3 2/2] doc: ‘initrd-modules’ will search ‘kernel-loadable-modules’ Brian Cully via Guix-patches via
2022-06-18 20:34 ` Maxime Devos
2022-06-18 20:43 ` Brian Cully via Guix-patches via
2022-06-18 22:34 ` Maxime Devos
2022-06-18 23:11 ` Brian Cully via Guix-patches via
2022-06-19 12:05 ` Maxime Devos
2022-06-21 12:34 ` [bug#55231] [PATCH v1] initrd: Allow extra search paths with ‘initrd-extra-module-paths’ Kaelyn via Guix-patches via
2022-06-24 13:28 ` [bug#55231] [PATCH v4 1/2] Allows copying of out-of-tree modules to the Linux initrd Brian Cully via Guix-patches via
2022-06-24 13:28 ` [bug#55231] [PATCH v4 2/2] doc: ‘initrd-modules’ will search ‘kernel-loadable-modules’ Brian Cully via Guix-patches via
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fskmky0d.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=55231@debbugs.gnu.org \
--cc=bjc@kublai.com \
--cc=bjc@spork.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.