Re: Need people to help with kernel updates

[Leo Famulari <leo@famulari.name>]

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

On Sat, Oct 07, 2023 at 08:31:58PM +0200, Wilko Meyer wrote:
> I could imagine myself helping with these tasks. Practically this means,
> that, whenever a new linux-libre minor update is being released, the
> versions in linux-libre-* packages in gnu/packages/linux.scm have to be
> bumped/a patch has to be sent?

Yes, the hashes of the kernel source code and linux-libre's "deblobbing"
scripts have to be updated. I have some scripts that fetch and calculate
the hashes (attached).

> Also: Is there anything to know/to have in mind when generating a new
> kernel config for major releases?

My workflow is to check out the upstream source code, copy the previous
version's configuration file into the source tree, create a development
environment with `guix shell -D linux-libre`, and then do `make
oldconfig`.

The idea with a distro kernel configuration is to make it as generically
useful as possible. That means enabling support for all kinds of
hardware and picking sensible defaults (which are usually the upstream
default).

I use the cateee.net website to get a little more info about things I
don't understand, and use Google and LKML to go beyond if necessary.
Cateee.net has references for every kernel configuration option. For
example:

https://cateee.net/lkddb/web-lkddb/HSA_AMD.html

If I'm really puzzled I ask on IRC or the mailing list, but this is a
"best effort" kind of task. In my several years with Guix, the kernel
config has occasionally received feedback.

I'm not a kernel developer or expert. The upstream defaults for kernel
'settings' are sensible. We usually differ from the defaults by enabling
support for lots of hardware.

> How's the coverage for different ISA? Do the current CI jobs also cover
> all the architectures we seem to support:
> 
> '("x86_64-linux" "i686-linux" "armhf-linux"
>     "aarch64-linux" "powerpc64le-linux" "riscv64-linux")

There's a 'kernel-updates' jobset for ci.guix.gnu.org that builds off
the 'kernel-updates' Git branch:

https://ci.guix.gnu.org/jobset/kernel-updates
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/modules/sysadmin/services.scm?id=8fa8d6affb7702fa81c795de5625c7b7938fae85#n359

And qa.guix.gnu.org will build any patches that are submitted to the
mailing list.

To be honest, I only pay attention to x86_64-linux and i686-linux. The
build farm don't reliably build the kernel packages for other
architectures (not even the source code!) on the build farm and nobody
has stepped up to make sure the kernel packages build there.

My impression is that x86_64-linux is by far the most popular platform
for Guix users, and then aarch64-linux, and then the rest.

My understanding of kernels for aarch64-linux is that the 'generic'
kernel packages work better for users than the packages built with the
Guix kernel configs, and that's fine. The 'generic' kernel configs are
generated automatically.

Architectural support is a problem of the type "What came first: the
chicken or the egg?" So, if anyone wants to improve support for these
other architectures, you'll be making an egg from scratch, in the hope
that people will start using the kernels :)

> or are there cases where it could be beneficial to build locally first
> using:
> 
> guix build -s $ISA linux-libre
> 
> for certain ISAs? I could use my workstation for this, if there's a
> benefit to it.

I don't do this, but it wouldn't hurt! I just use the resources on CI
and QA. I do build my own x86_64-linux kernels for my own machines, as a
minor "full test", but that's not expected to join in this work.

> How would the communication around this be organized? If n>=2 people are
> trying to work on the same set of tasks duplication may happen.

I invite you to choose, email or IRC :)

To summarize, this work needs regular but brief attention. There's not
much feedback from the community, so we do our best and make sure the
basics work before pushing (reboot and connect to the internet). I'm
eager to help grow the community of people working on this, and can help
answer questions and give advice about things like the configs.

Leo

[-- Attachment #2: linux-libre packaging scripts.tar.xz --]
[-- Type: application/octet-stream, Size: 33153 bytes --]