[Top][All Lists]

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

Re: [WIP PATCH] linux-initrd: Allow own set of kernel modules.

From: Ludovic Courtès
Subject: Re: [WIP PATCH] linux-initrd: Allow own set of kernel modules.
Date: Thu, 28 Jul 2016 17:32:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Tomáš Čech <address@hidden> skribis:

> On Thu, Jul 28, 2016 at 03:05:34PM +0200, Ludovic Courtès wrote:
>>Tomáš Čech <address@hidden> skribis:
>>> * gnu/system/linux-initrd.scm(base-initrd): Add `linux-modules'
>>>   parameter. Rename former `linux-modules' to
>>>   `default-linux-modules'. Introduce used-linux-modules to make the code
>>>   more readable.
>>> ---
>>>  gnu/system/linux-initrd.scm | 12 +++++++++---
>>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>> diff --git a/gnu/system/linux-initrd.scm b/gnu/system/linux-initrd.scm
>>> index bbaa5c0..4934c92 100644
>>> --- a/gnu/system/linux-initrd.scm
>>> +++ b/gnu/system/linux-initrd.scm
>>> @@ -138,6 +138,7 @@ MODULES and taken from LINUX."
>>>                        qemu-networking?
>>>                        (virtio? #t)
>>>                        volatile-root?
>>> +                      (linux-modules #f)
>>>                        (extra-modules '()))
>>>    "Return a monadic derivation that builds a generic initrd, with kernel
>>>  modules taken from LINUX.  FILE-SYSTEMS is a list of file-systems to be
>>It seems to serve the same purpose as #:extra-modules, no?
> It gives me full control over the modules and not just appending to default 
> set.
>  #f --> default-kernel-modules (as it is now)
>  '(some extraordinary special modules for other purpose) --> it will use this 
> set
>  '() --> it will use no module at all (my typical usecase)

Oh, OK.  I had assumed that the last use case didn’t exist ;-), which is
why we have #:extra-modules instead of just #:modules.

> But yes, it makes `extra-modules' useless.
> I'd like to find a way, how to make default-kernel-modules available
> as some lazy evaluated list (because what will go there is decided
> when base-initrd is evaluated).

What about this: instead of adding #:linux-modules to ‘base-initrd’,
let’s split ‘base-initrd’ into two procedures:

  1. ‘raw-initrd’ wouldn’t do anything high-level and wouldn’t try to
     guess what modules are needed;

  2. ‘base-initrd’ would keep the interface it currently has, but would
     be rewritten in terms of ‘raw-initrd’:

       (define (base-initrd …)
         ;; …
         (raw-initrd file-system
                     #:linux-modules the-full-list-of-modules))

How does that sound?


reply via email to

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