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

[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.


> 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.


> 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.


//Peter