Linux kernel config maintainablility

Linux kernel config maintainablility

[David Craven]

Hi,

So I'm trying to get a linux-libre-kernel for arm going. For arm there
is a multi_v7_defconfig we can use. I looked at the existing kernel
configs we have and can't make heads or tails of them. My question is
are any kernel options needed specifically for guixsd? And can we make
it more readable/explicit by using a defconfig + adding the guixsd
specific configs separately? This would allow people like me to
understand what's actually needed to get guixsd working ;-)

Re: Linux kernel config maintainablility

[Ludovic Courtès]

Hi!

David Craven <david@craven.ch> skribis:

> So I'm trying to get a linux-libre-kernel for arm going. For arm there
> is a multi_v7_defconfig we can use. I looked at the existing kernel
> configs we have and can't make heads or tails of them. My question is
> are any kernel options needed specifically for guixsd? And can we make
> it more readable/explicit by using a defconfig + adding the guixsd
> specific configs separately? This would allow people like me to
> understand what's actually needed to get guixsd working ;-)

guix-daemon needs CONFIG_DEVPTS_MULTIPLE_INSTANCES=y and that’s about
it.  GuixSD doesn’t have any unusual requirements.

Now, I agree that storing full config files makes it hard to understand
what non-default settings are used.  NixOS has a nicer way to express
this, but long ago people thought it might be fragile:

  https://lists.gnu.org/archive/html/guix-devel/2014-06/msg00108.html
  https://lists.gnu.org/archive/html/guix-devel/2014-09/msg00370.html
  https://lists.gnu.org/archive/html/guix-devel/2014-07/msg00044.html
  https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel/linux-4.7.nix
  https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel/generic.nix
  https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel/generate-config.pl

Thoughts?

Ludo’.

Re: Linux kernel config maintainablility

[David Craven]

Hi Ludo,

> I was hoping we could come up with a way to generate a kernel config,
> either based on ‘allmodconfig’ or something like what NixOS does [0],
> but I’ve become pretty convinced that this would be difficult at best.

What difficulties did you encounter with using allmodconfig as a basis?

> NixOS has a nicer way to express this, but long ago people thought it might be fragile.

I agree that how nixos does it seems a little fragile. From what I've
heard the kernel settings and their defaults change frequently with
each release. This is why I think relying on the kernel devs to
provide reasonable defaults makes more sense IMO.

I'd like to make it easy to build custom kernels, I remember using an
auto detect config feature a while back when using arch. But before
working on that I need to actually transition to guixsd...

Re: Linux kernel config maintainablility

[Ludovic Courtès]

Hi David,

David Craven <david@craven.ch> skribis:

>> I was hoping we could come up with a way to generate a kernel config,
>> either based on ‘allmodconfig’ or something like what NixOS does [0],
>> but I’ve become pretty convinced that this would be difficult at best.
>
> What difficulties did you encounter with using allmodconfig as a basis?

I forgot the details, but maybe the list archive has some info.

>> NixOS has a nicer way to express this, but long ago people thought it might be fragile.
>
> I agree that how nixos does it seems a little fragile. From what I've
> heard the kernel settings and their defaults change frequently with
> each release. This is why I think relying on the kernel devs to
> provide reasonable defaults makes more sense IMO.
>
> I'd like to make it easy to build custom kernels, I remember using an
> auto detect config feature a while back when using arch. But before
> working on that I need to actually transition to guixsd...

Heh.  :-)

Ludo’.

Re: Linux kernel config maintainablility

[David Craven]

Hi Ludo,

>> What difficulties did you encounter with using allmodconfig as a basis?

> I forgot the details, but maybe the list archive has some info.

Changing what already works doesn't make sense. For arm and new
platforms I think we can go down the defconf route, since it's really
simple now...