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

Attachments

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