Custom kernel

Custom kernel

[Dmitri Anikin]

[-- Attachment #1: Type: text/plain, Size: 108 bytes --]

Hello,

Is it possible to pass custom patches and kernel config file to be used for linux-libre package?

[-- Attachment #2: Type: text/html, Size: 409 bytes --]

Re: Custom kernel

[Ludovic Courtès]

Hello Dmitri,

"Dmitri Anikin" <anarki@teknik.io> skribis:

> Is it possible to pass custom patches and kernel config file to be used for linux-libre package?

It is possible, yes.

If you look at (gnu packages linux), you’ll find this:

  (define* (kernel-config arch #:key variant)
    "Return the absolute file name of the Linux-Libre build configuration file
  for ARCH and optionally VARIANT, or #f if there is no such configuration."
     …)

  (define* (make-linux-libre version hash supported-systems
                             #:key
                             ;; A function that takes an arch and a variant.
                             ;; See kernel-config for an example.
                             (extra-version #f)
                             (configuration-file #f)
                             (defconfig "defconfig")
                             (extra-options %default-extra-linux-options)
                             (patches (list %boot-logo-patch)))
    (package
      …))

and later:

  (define-public linux-libre
    (make-linux-libre "4.8.11"
                      "04h3n3lw563i4yhxfkxrrwjvafd3af730l1ih9kqv7qwkm0psy7r"
                      %intel-compatible-systems
                      #:configuration-file kernel-config))

Currently ‘make-linux-libre’ is not public, but we could probably make
it public (David, WDYT?).  In the meantime, in your own module, you can
do:

  (define make-linux-libre
    ;; It’s private but I wanna use it anyway!
    (@@ (gnu packages linux) make-linux-libre))

HTH!

Ludo’.

Re: Custom kernel

[Dmitri Anikin]

December 2, 2016 2:50 PM, ludo@gnu.org wrote:
> Hello Dmitri,
> 
> "Dmitri Anikin" <anarki@teknik.io> skribis:
> 
>> Is it possible to pass custom patches and kernel config file to be used for linux-libre package?
> 
> It is possible, yes.
> 
> If you look at (gnu packages linux), you’ll find this:
> 
> (define* (kernel-config arch #:key variant)
> "Return the absolute file name of the Linux-Libre build configuration file
> for ARCH and optionally VARIANT, or #f if there is no such configuration."
> …)
> 
> (define* (make-linux-libre version hash supported-systems
> #:key
> ;; A function that takes an arch and a variant.
> ;; See kernel-config for an example.
> (extra-version #f)
> (configuration-file #f)
> (defconfig "defconfig")
> (extra-options %default-extra-linux-options)
> (patches (list %boot-logo-patch)))
> (package
> …))
> 
> and later:
> 
> (define-public linux-libre
> (make-linux-libre "4.8.11"
> "04h3n3lw563i4yhxfkxrrwjvafd3af730l1ih9kqv7qwkm0psy7r"
> %intel-compatible-systems
> #:configuration-file kernel-config))
> 
> Currently ‘make-linux-libre’ is not public, but we could probably make
> it public (David, WDYT?). In the meantime, in your own module, you can
> do:
> 
> (define make-linux-libre
> ;; It’s private but I wanna use it anyway!
> (@@ (gnu packages linux) make-linux-libre))
> 
> HTH!
> 
> Ludo’.

When I try guix build -f linux.scm --no-build-hook I get this error
>source is under 'linux-4.8'
>applying '/gnu/store/yp9xzrpkcsy7x9qrnhna5zycb4h1qvl8-reiser4-for-linux-4.8.0.patch'...
>applying '/gnu/store/dhq2gd73qaqirc6a4pj5yr537s76sj36-patch-4.8-pf8.patch'...
>builder for `/gnu/store/r6lja7k5y2984kbzzkz94fzsmbhfbs9g-linux-libre-4.8-gnu.tar.xz.drv' failed to produce output path `/gnu/store/x7bpi24wn99xf79vsf28mblnihxxdfid-linux-libre-4.8-gnu.tar.xz'
>@ build-failed /gnu/store/r6lja7k5y2984kbzzkz94fzsmbhfbs9g-linux-libre-4.8-gnu.tar.xz.drv - 1 builder for `/gnu/store/r6lja7k5y2984kbzzkz94fzsmbhfbs9g-linux-libre-4.8-gnu.tar.xz.drv' failed to produce output path `/gnu/store/x7bpi24wn99xf79vsf28mblnihxxdfid-linux-libre-4.8-gnu.tar.xz'
>cannot build derivation `/gnu/store/zganmnxjjxs1w1wc19r4nd03xw7fbs24-linux-libre-anarki-4.8.drv': 1 dependencies couldn't be built
>guix build: error: build failed: build of `/gnu/store/zganmnxjjxs1w1wc19r4nd03xw7fbs24-linux-libre-anarki-4.8.drv' failed

Re: Custom kernel

[Ludovic Courtès]

"Dmitri Anikin" <anarki@teknik.io> skribis:

> December 2, 2016 2:50 PM, ludo@gnu.org wrote:
>> Hello Dmitri,
>> 
>> "Dmitri Anikin" <anarki@teknik.io> skribis:
>> 
>>> Is it possible to pass custom patches and kernel config file to be used for linux-libre package?
>> 
>> It is possible, yes.
>> 
>> If you look at (gnu packages linux), you’ll find this:
>> 
>> (define* (kernel-config arch #:key variant)
>> "Return the absolute file name of the Linux-Libre build configuration file
>> for ARCH and optionally VARIANT, or #f if there is no such configuration."
>> …)
>> 
>> (define* (make-linux-libre version hash supported-systems
>> #:key
>> ;; A function that takes an arch and a variant.
>> ;; See kernel-config for an example.
>> (extra-version #f)
>> (configuration-file #f)
>> (defconfig "defconfig")
>> (extra-options %default-extra-linux-options)
>> (patches (list %boot-logo-patch)))
>> (package
>> …))
>> 
>> and later:
>> 
>> (define-public linux-libre
>> (make-linux-libre "4.8.11"
>> "04h3n3lw563i4yhxfkxrrwjvafd3af730l1ih9kqv7qwkm0psy7r"
>> %intel-compatible-systems
>> #:configuration-file kernel-config))
>> 
>> Currently ‘make-linux-libre’ is not public, but we could probably make
>> it public (David, WDYT?). In the meantime, in your own module, you can
>> do:
>> 
>> (define make-linux-libre
>> ;; It’s private but I wanna use it anyway!
>> (@@ (gnu packages linux) make-linux-libre))
>> 
>> HTH!
>> 
>> Ludo’.
>
> When I try guix build -f linux.scm --no-build-hook I get this error
>>source is under 'linux-4.8'
>>applying '/gnu/store/yp9xzrpkcsy7x9qrnhna5zycb4h1qvl8-reiser4-for-linux-4.8.0.patch'...
>>applying '/gnu/store/dhq2gd73qaqirc6a4pj5yr537s76sj36-patch-4.8-pf8.patch'...
>>builder for `/gnu/store/r6lja7k5y2984kbzzkz94fzsmbhfbs9g-linux-libre-4.8-gnu.tar.xz.drv' failed to produce output path `/gnu/store/x7bpi24wn99xf79vsf28mblnihxxdfid-linux-libre-4.8-gnu.tar.xz'

If you look higher in the build log, there’s probably an error message
from ‘patch’ indicating that it failed to apply one of the patches.
Could you check that?

You can access the full log by opening the file returned by:

  guix build --log-file /gnu/store/r6lja7k5y2984kbzzkz94fzsmbhfbs9g-linux-libre-4.8-gnu.tar.xz.drv

HTH!

Ludo’.

Re: Custom kernel

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> "Dmitri Anikin" <anarki@teknik.io> skribis:
>
>> Is it possible to pass custom patches and kernel config file to be used for linux-libre package?
>
> It is possible, yes.
>
> If you look at (gnu packages linux), you’ll find this:
>
>   (define* (kernel-config arch #:key variant)
>     "Return the absolute file name of the Linux-Libre build configuration file
>   for ARCH and optionally VARIANT, or #f if there is no such configuration."
>      …)
>
>   (define* (make-linux-libre version hash supported-systems
>                              #:key
>                              ;; A function that takes an arch and a variant.
>                              ;; See kernel-config for an example.
>                              (extra-version #f)
>                              (configuration-file #f)
>                              (defconfig "defconfig")
>                              (extra-options %default-extra-linux-options)
>                              (patches (list %boot-logo-patch)))
>     (package
>       …))
>
> and later:
>
>   (define-public linux-libre
>     (make-linux-libre "4.8.11"
>                       "04h3n3lw563i4yhxfkxrrwjvafd3af730l1ih9kqv7qwkm0psy7r"
>                       %intel-compatible-systems
>                       #:configuration-file kernel-config))
>
> Currently ‘make-linux-libre’ is not public, but we could probably make
> it public (David, WDYT?).  In the meantime, in your own module, you can
> do:
>
>   (define make-linux-libre
>     ;; It’s private but I wanna use it anyway!
>     (@@ (gnu packages linux) make-linux-libre))

I think we should avoid exporting 'make-linux-libre' in its current
form.  Although it was an improvement in some ways over what we had
previously, I've found it to be an inadequate interface in many
respects, and in my opinion it needs to be redesigned.  I don't have
time to make a case now, but in practice it leads to redundancy.  For
example, when I recently added security fixes to linux-libre, I needed
to add the patches in two separate places, and every time I update the
version, I need to update two places as well.

     Thanks,
       Mark

Re: Custom kernel

[David Craven]

>> Currently ‘make-linux-libre’ is not public, but we could probably make
>> it public (David, WDYT?).  In the meantime, in your own module, you can
>> do.

> I think we should avoid exporting 'make-linux-libre' in its current
> form.  Although it was an improvement in some ways over what we had
> previously, I've found it to be an inadequate interface in many
> respects, and in my opinion it needs to be redesigned.  I don't have
> time to make a case now, but in practice it leads to redundancy.

I agree that there is room for improvement. But I don't think it's as
easy as it may seem...

> For example, when I recently added security fixes to linux-libre, I needed
> to add the patches in two separate places, and every time I update the
> version, I need to update two places as well.

I believe this was on purpose to avoid having to rebuild two kernels every time.

I was impatient to get this stuff into master because my linux libre
arm kernel wasn't building on the beagle bone black (not enough RAM).
I think some more patience could have made things better =P

Re: Custom kernel

[Mark H Weaver]

I wrote:
>> For example, when I recently added security fixes to linux-libre, I needed
>> to add the patches in two separate places, and every time I update the
>> version, I need to update two places as well.

David Craven <david@craven.ch> responded:
> I believe this was on purpose to avoid having to rebuild two kernels
> every time.

My understanding is that most stable kernel updates contain security
fixes.  In any case, upstream has a deliberate policy of refusing to
specify which updates are security-critical, so we must assume that they
all are.  I'm not comfortable leaving non-Intel kernels with unpatched
security flaws.

> I was impatient to get this stuff into master because my linux libre
> arm kernel wasn't building on the beagle bone black (not enough RAM).
> I think some more patience could have made things better =P

Yes, of course, that makes sense.  I very much appreciate your work on
this.

     Thanks,
       Mark

Re: Custom kernel

[Ludovic Courtès]

Hello!

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> "Dmitri Anikin" <anarki@teknik.io> skribis:
>>
>>> Is it possible to pass custom patches and kernel config file to be used for linux-libre package?
>>
>> It is possible, yes.
>>
>> If you look at (gnu packages linux), you’ll find this:
>>
>>   (define* (kernel-config arch #:key variant)
>>     "Return the absolute file name of the Linux-Libre build configuration file
>>   for ARCH and optionally VARIANT, or #f if there is no such configuration."
>>      …)
>>
>>   (define* (make-linux-libre version hash supported-systems
>>                              #:key
>>                              ;; A function that takes an arch and a variant.
>>                              ;; See kernel-config for an example.
>>                              (extra-version #f)
>>                              (configuration-file #f)
>>                              (defconfig "defconfig")
>>                              (extra-options %default-extra-linux-options)
>>                              (patches (list %boot-logo-patch)))
>>     (package
>>       …))
>>
>> and later:
>>
>>   (define-public linux-libre
>>     (make-linux-libre "4.8.11"
>>                       "04h3n3lw563i4yhxfkxrrwjvafd3af730l1ih9kqv7qwkm0psy7r"
>>                       %intel-compatible-systems
>>                       #:configuration-file kernel-config))
>>
>> Currently ‘make-linux-libre’ is not public, but we could probably make
>> it public (David, WDYT?).  In the meantime, in your own module, you can
>> do:
>>
>>   (define make-linux-libre
>>     ;; It’s private but I wanna use it anyway!
>>     (@@ (gnu packages linux) make-linux-libre))
>
> I think we should avoid exporting 'make-linux-libre' in its current
> form.

Makes sense.

> Although it was an improvement in some ways over what we had
> previously, I've found it to be an inadequate interface in many
> respects, and in my opinion it needs to be redesigned.  I don't have
> time to make a case now, but in practice it leads to redundancy.  For
> example, when I recently added security fixes to linux-libre, I needed
> to add the patches in two separate places, and every time I update the
> version, I need to update two places as well.

Looking at 6b2921c3acf2cc808128af97784929365f8582af, it seems that
patches lead to modifications in only one place (the ‘make-linux-libre’
call site), no?

There seems to be redundancy here though:

--8<---------------cut here---------------start------------->8---
;; Avoid rebuilding kernel variants when there is a minor version bump.
(define %linux-libre-version "4.8.13")
(define %linux-libre-hash "1n1bhasqih8acag2glwaqsh76avpinvchvwg6g4q1pfm2vs1499x")
--8<---------------cut here---------------end--------------->8---

But it’s a defect that not really due to ‘make-linux-libre’ per se.

Thanks,
Ludo’.

Re: Custom kernel

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Hello!
>
> Mark H Weaver <mhw@netris.org> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Currently ‘make-linux-libre’ is not public, but we could probably make
>>> it public (David, WDYT?).  In the meantime, in your own module, you can
>>> do:
>>>
>>>   (define make-linux-libre
>>>     ;; It’s private but I wanna use it anyway!
>>>     (@@ (gnu packages linux) make-linux-libre))
>>
>> I think we should avoid exporting 'make-linux-libre' in its current
>> form.
>
> Makes sense.
>
>> Although it was an improvement in some ways over what we had
>> previously, I've found it to be an inadequate interface in many
>> respects, and in my opinion it needs to be redesigned.  I don't have
>> time to make a case now, but in practice it leads to redundancy.  For
>> example, when I recently added security fixes to linux-libre, I needed
>> to add the patches in two separate places, and every time I update the
>> version, I need to update two places as well.
>
> Looking at 6b2921c3acf2cc808128af97784929365f8582af, it seems that
> patches lead to modifications in only one place (the ‘make-linux-libre’
> call site), no?

If you look more carefully at 6b2921c3acf2cc808128af97784929365f8582af,
you'll see that I had to apply the patches in two places, and if we had
more kernel variants for other machines, it would have been more than
two places.

The problem is that there are multiple 'make-linux-libre' call sites for
the same kernel version, and each of them needs to be passed various
subfields of the 'source'.

There's no straightforward way to 'inherit' from a master 'linux-libre'
package and then override some of those parameters that are passed to
'make-linux-libre'.

       Mark

Re: Custom kernel

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hello!
>>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> ludo@gnu.org (Ludovic Courtès) writes:
>>>
>>>> Currently ‘make-linux-libre’ is not public, but we could probably make
>>>> it public (David, WDYT?).  In the meantime, in your own module, you can
>>>> do:
>>>>
>>>>   (define make-linux-libre
>>>>     ;; It’s private but I wanna use it anyway!
>>>>     (@@ (gnu packages linux) make-linux-libre))
>>>
>>> I think we should avoid exporting 'make-linux-libre' in its current
>>> form.
>>
>> Makes sense.
>>
>>> Although it was an improvement in some ways over what we had
>>> previously, I've found it to be an inadequate interface in many
>>> respects, and in my opinion it needs to be redesigned.  I don't have
>>> time to make a case now, but in practice it leads to redundancy.  For
>>> example, when I recently added security fixes to linux-libre, I needed
>>> to add the patches in two separate places, and every time I update the
>>> version, I need to update two places as well.
>>
>> Looking at 6b2921c3acf2cc808128af97784929365f8582af, it seems that
>> patches lead to modifications in only one place (the ‘make-linux-libre’
>> call site), no?
>
> If you look more carefully at 6b2921c3acf2cc808128af97784929365f8582af,
> you'll see that I had to apply the patches in two places, and if we had
> more kernel variants for other machines, it would have been more than
> two places.

I did see that :-), but there could have been a variable holding the
list of patches for 4.8; that would have significantly reduced
duplication.

> The problem is that there are multiple 'make-linux-libre' call sites for
> the same kernel version, and each of them needs to be passed various
> subfields of the 'source'.
>
> There's no straightforward way to 'inherit' from a master 'linux-libre'
> package and then override some of those parameters that are passed to
> 'make-linux-libre'.

Yeah, I agree this is not ideal… just not *that* bad either.  ;-)

Ludo’.