On Sun, Jul 15, 2012 at 03:09:12PM -0700, david@xxxxxxx wrote:On Mon, 16 Jul 2012, Cyrill Gorcunov wrote:
Replying to David's message (sorry for delay) I fear having a bunch of
miniconfig files will end up in a mess. Maybe (maybe (!) I don't know since
I've no time at moment to read kconfig code and I'm not sure if this
is right direction at all) it would worth to add some new keyword to
kconfig language, say "profile", which would tag symbol to a category
if needed, and these categories included into profiles automatically.
On the other hands this might end up in a mess as well.
I have a couple problems with the approach of modifying the existing
1. how does it handle the case when a profile wants something one
way and the admin wants it another way
Select the profile and then fixup the config the normal way.
If what the admin wants is incompatible with the profile, admin doesn't
select the profile.
the example is the fedora default wanting SELINUX and I want some
Currently, if you run fedora and want something that's not enabled, you
recompile your kernel too, right?
2. since it requires making changes in the upstream kernel source, the
number of people who can make these changes is small.
I think that's moot since you either select the profile or you don't.
3. since all these changes go into the upstream kernel source, changes
to these profiles are going to be visible churn (think of the issues
with the defconfigs for ARM a couple of years ago)
AFAICT, those changes will be needed only for a new distro release and
that happens twice a year, tops.
4. the complexity of tagging all possible profiles is very high.
That's why we start simple.
Even if you limit the profiles to "Linux Distros", how many different
distros are there? Do you really want to have to start arguing over
which distros are large enough to get their profile added to the
upstream kernel source?
That's a valid question; its answer could be defined arbitrarily.
Let's say all distros which make money - more than a certain large
amount - are allowed. :-)
If instead we go with something along the lines of the miniconf
approach, the picture looks very different
1. this approach only sets things one time, after that the person
doing the compile is free to change anything.
Sorry, I don't see the simplification: you need to rebuild your kernel
anyway and before you rebuild it, you can do all the changes you want.
So either you select a profile or you load a miniconfig, it doesn't
really matter how you do it?