unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
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’.




  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

  List information: https://guix.gnu.org/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).