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
