[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1207151459480.20176@asgard.lang.hm>
Date: Sun, 15 Jul 2012 15:09:12 -0700 (PDT)
From: david@...g.hm
To: Cyrill Gorcunov <gorcunov@...nvz.org>
cc: Borislav Petkov <bp@...64.org>, Pekka Enberg <penberg@...nel.org>,
richard -rw- weinberger <richard.weinberger@...il.com>,
"Myklebust, Trond" <Trond.Myklebust@...app.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Dave Jones <davej@...hat.com>,
Greg Kroah-Hartman <greg@...ah.com>,
Ubuntu Kernel Team <kernel-team@...ts.ubuntu.com>,
Debian Kernel Team <debian-kernel@...ts.debian.org>,
OpenSUSE Kernel Team <opensuse-kernel@...nsuse.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>,
Sasha Levin <levinsasha928@...il.com>,
Asias He <asias.hejun@...il.com>,
Pavel Emelyanov <xemul@...allels.com>
Subject: Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration
for distro issues
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
kconfig files
1. how does it handle the case when a profile wants something one way and
the admin wants it another way
the example is the fedora default wanting SELINUX and I want some other
LSM
2. since it requires making changes in the upstream kernel source, the
number of people who can make these changes is small.
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)
4. the complexity of tagging all possible profiles is very high.
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?
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.
2. since the changes are a local file, separate from the upstream source,
issues like who can provide the config, what distros will accept it,
complexity in having many different options, etc all vanish
3. by simply combining miniconfig files, you can combine sets of
pre-defined options
David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists