Gentoo Archives: gentoo-dev

From: Gerion Entrup <gerion.entrup@×××××.de>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Idea: User centric kernel configuration
Date: Fri, 12 Mar 2021 18:04:59
Message-Id: 4097645.ejJDZkT8p0@gump
In Reply to: Re: [gentoo-dev] Idea: User centric kernel configuration by Mike Pagano
1 Am Freitag, 12. März 2021, 17:40:02 CET schrieb Mike Pagano:
2 >
3 > On 3/12/21 11:34 AM, Gerion Entrup wrote:
4 > > Am Donnerstag, 11. März 2021, 17:41:45 CET schrieb Peter Stuge:
5 > >> Hi,
6 > >>
7 > >> Gerion Entrup wrote:
8 > >>> the Linux kernel has _a lot of_ configuration options, way too many to configure them by hand.
9 > >>
10 > >> I actually disagree strongly with that; I think it's important to
11 > >> actively decide what kernels include, and I routinely do, but of
12 > >> course not everyone will. I've made sure to include a kernel build
13 > >> when teaching systems administration courses and would again.
14 > >>
15 > >> As the kernel becomes more complex the threshold for the first
16 > >> configuration also rises, but it's still completely possible to learn
17 > >> what you need in order to successfully configure your own kernel.
18 > >> I guess it's on the order of a weekend project given some basic
19 > >> understanding of computer architecture and programming.
20 > >
21 > > I think, we mean two different things here. I for myself also configured
22 > > my own kernel(s) for years. I also actively teach students to do so.
23 > > However, I have never looked into all 18000 configuration options. I
24 > > don't understand them all (by far).
25 > >
26 > > Actually, most of the times, I do a `make localmodconfig`, click through
27 > > various subsystems and activate what I think that it is useful or sounds
28 > > nice. Then, to update a kernel, I use `make oldconfig` and answer the
29 > > questions as good as I can (taking the default otherwise).
30 > >
31 > > If my kernel is not capable to do something (for example run docker
32 > > containers), I take a look in the Gentoo Wiki and "copy" the options
33 > > into my own config.
34 > >
35 > > But for me, this is not an informed decision. Of course, I learn
36 > > something in this process, maybe also more than a precompiled kernel
37 > > user, but I have by far not created a minimal config or even begin
38 > > to understand all subsystems and different configuration options.
39 > >
40 > > I'm sure that this is similar to most Gentoo users.
41 > >
42 > > BTW, here is a project to create a minimal config (kind of "ideal"
43 > > config) based on a "golden run" [1]. However, I have not compared such
44 > > a config with my own homegrown config.
45 > >
46 > >
47 > >>> This requires a mapping between user oriented "features" and the kernel
48 > >>> internal configuration options.
49 > >>
50 > >> So the challenge here is that the kernel is disjoint from user space,
51 > >> and while the kernel API remains stable over time consumer requirements
52 > >> such as "docker" or "cryptsetup" will mean different things for
53 > >> different versions of particular user space software.
54 > >>
55 > >>
56 > >>> Do you think that it is useful and feasible to combine these two mechanisms?
57 > >>
58 > >> AFAIK there's no generic method for formal kernel requirements in user
59 > >> space packages and there's also no sanctioned method for quering
60 > >> kernel capabilities. The only thing available is /proc/config if that
61 > >> was enabled in the kernel build, and there are of course reasons to
62 > >> leave it out, and it only applies to the particular running kernel,
63 > >> e.g. useless for cross-compilation. There, it would be possible to
64 > >> read the kernel configuration file if the kernel source code is
65 > >> available when the userspace package is being built, but that's not
66 > >> guaranteed.
67 > >>
68 > >> In Gentoo, linux-info.eclass provides linux_config_exists() to do all
69 > >> of this, but order to become a widespread success there would have to
70 > >> be one method for upstreams to maintain these requirements as part of
71 > >> their packages, rather than forcing the burden on package maintainers
72 > >> to repeat the same detective task in every single distribution.
73 > >>
74 > >> I think it would be very useful to create something generic for that,
75 > >> but that's certainly no small task.
76 > >>
77 > >> And realistically I only see it succeeding if Linux Foundation decides
78 > >> to push it onto the world.
79 > >
80 > > Sorry, I may have expressed this not clearly. I guess, we actually have
81 > > the same opinion here. I don't want to do this mapping automatically. I
82 > > don't want a "fully automatic" config or touch any (user space) ebuilds.
83 > >
84 > > My idea is to patch Kconfig (as part of gentoo-sources) to provide the
85 > > same "features" (i.e. mappings) that are already present in the Gentoo
86 > > wiki.
87 > >
88 > > For example this could result in this installation description for Docker
89 > > (within the Wiki):
90 > > "To enable kernel support for Docker, enable
91 > > 'Gentoo Linux -> Support for user space programs -> Docker'"
92 > >
93 > > This Kconfig flag than depends on all options that are needed for proper
94 > > Docker support (as already described in the Wiki) like cgroups etc..
95 > >
96 > > This would allow users to configure there kernels the same way as before
97 > > but with some additional convenience shortcuts.
98 > >
99 > > Of course, this is a high maintenance burden for the kernel package
100 > > maintainers. Therefore, this mechanism maybe can be automated:
101 > > Grep the wiki pages for kernel config snippets and automatically
102 > > condense that in a Kconfig readable configuration option.
103 > >
104 > >
105 > >>> A possible way could be to automatically extract the kernel config
106 > >>> flags from the wiki pages and map them to Kconfig options.
107 > >>
108 > >> At very best that will only be valid for some particular point in time,
109 > >> like current CONFIG_CHECK in ebuilds using linux_config_exists() are
110 > >> only valid for particular package versions. At worst it's plain wrong
111 > >> because the requirements have to be reverse-engineered downstream.
112 > >
113 > > Of course, the already existing kernel config snippets in the Wiki are
114 > > best effort. My idea is to combine these snippets directly with Kconfig.
115 > >
116 > >
117 > > Best regards,
118 > > Gerion
119 > >
120 > > [1] https://vamos.informatik.uni-erlangen.de/trac/undertaker/wiki/UndertakerTailor
121 > >
122 >
123 >
124 > Hello,
125 >
126 > If I am reading this correctly, you are looking for something like we
127 > have for systemd and openrc where you select something and we preselect
128 > a bunch of required/suggested kernel configs options.
129 >
130 > I'm happy to add this to gentoo-sources for Docker based on the
131 > expertise of the gentoo developer individuals in the project.
132 >
133 > Probably a bug to track this would be the best way for me to implement.
134 >
135 > Or am I totally off base on your request?
136
137 You are right, but Docker is just an example. Ideally, this would exist
138 for every wiki page that explains which kernel config options need to be
139 set to make XY possible.
140
141 Gerion

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] Idea: User centric kernel configuration Mike Pagano <mpagano@g.o>