Re: [gentoo-dev] Idea: User centric kernel configuration

[Gerion Entrup]

Am Donnerstag, 11. März 2021, 17:41:45 CET schrieb Peter Stuge:
> Hi,
>
> Gerion Entrup wrote:
> > the Linux kernel has _a lot of_ configuration options, way too many to configure them by hand.
>
> I actually disagree strongly with that; I think it's important to
> actively decide what kernels include, and I routinely do, but of
> course not everyone will. I've made sure to include a kernel build
> when teaching systems administration courses and would again.
>
> As the kernel becomes more complex the threshold for the first
> configuration also rises, but it's still completely possible to learn
> what you need in order to successfully configure your own kernel.
> I guess it's on the order of a weekend project given some basic
> understanding of computer architecture and programming.

I think, we mean two different things here. I for myself also configured
my own kernel(s) for years. I also actively teach students to do so.
However, I have never looked into all 18000 configuration options. I
don't understand them all (by far).

Actually, most of the times, I do a `make localmodconfig`, click through
various subsystems and activate what I think that it is useful or sounds
nice. Then, to update a kernel, I use `make oldconfig` and answer the
questions as good as I can (taking the default otherwise).

If my kernel is not capable to do something (for example run docker
containers), I take a look in the Gentoo Wiki and "copy" the options
into my own config.

But for me, this is not an informed decision. Of course, I learn
something in this process, maybe also more than a precompiled kernel
user, but I have by far not created a minimal config or even begin
to understand all subsystems and different configuration options.

I'm sure that this is similar to most Gentoo users.

BTW, here is a project to create a minimal config (kind of "ideal"
config) based on a "golden run" [1]. However, I have not compared such
a config with my own homegrown config.


> > This requires a mapping between user oriented "features" and the kernel
> > internal configuration options.
>
> So the challenge here is that the kernel is disjoint from user space,
> and while the kernel API remains stable over time consumer requirements
> such as "docker" or "cryptsetup" will mean different things for
> different versions of particular user space software.
>
>
> > Do you think that it is useful and feasible to combine these two mechanisms?
>
> AFAIK there's no generic method for formal kernel requirements in user
> space packages and there's also no sanctioned method for quering
> kernel capabilities. The only thing available is /proc/config if that
> was enabled in the kernel build, and there are of course reasons to
> leave it out, and it only applies to the particular running kernel,
> e.g. useless for cross-compilation. There, it would be possible to
> read the kernel configuration file if the kernel source code is
> available when the userspace package is being built, but that's not
> guaranteed.
>
> In Gentoo, linux-info.eclass provides linux_config_exists() to do all
> of this, but order to become a widespread success there would have to
> be one method for upstreams to maintain these requirements as part of
> their packages, rather than forcing the burden on package maintainers
> to repeat the same detective task in every single distribution.
>
> I think it would be very useful to create something generic for that,
> but that's certainly no small task.
>
> And realistically I only see it succeeding if Linux Foundation decides
> to push it onto the world.

Sorry, I may have expressed this not clearly. I guess, we actually have
the same opinion here. I don't want to do this mapping automatically. I
don't want a "fully automatic" config or touch any (user space) ebuilds.

My idea is to patch Kconfig (as part of gentoo-sources) to provide the
same "features" (i.e. mappings) that are already present in the Gentoo
wiki.

For example this could result in this installation description for Docker
(within the Wiki):
"To enable kernel support for Docker, enable
'Gentoo Linux -> Support for user space programs -> Docker'"

This Kconfig flag than depends on all options that are needed for proper
Docker support (as already described in the Wiki) like cgroups etc..

This would allow users to configure there kernels the same way as before
but with some additional convenience shortcuts.

Of course, this is a high maintenance burden for the kernel package
maintainers. Therefore, this mechanism maybe can be automated:
Grep the wiki pages for kernel config snippets and automatically
condense that in a Kconfig readable configuration option.


> > A possible way could be to automatically extract the kernel config
> > flags from the wiki pages and map them to Kconfig options.
>
> At very best that will only be valid for some particular point in time,
> like current CONFIG_CHECK in ebuilds using linux_config_exists() are
> only valid for particular package versions. At worst it's plain wrong
> because the requirements have to be reverse-engineered downstream.

Of course, the already existing kernel config snippets in the Wiki are
best effort. My idea is to combine these snippets directly with Kconfig.


Best regards,
Gerion

[1] https://vamos.informatik.uni-erlangen.de/trac/undertaker/wiki/UndertakerTailor