[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120719173800.GE8469@zod.bos.redhat.com>
Date: Thu, 19 Jul 2012 13:38:00 -0400
From: Josh Boyer <jwboyer@...hat.com>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Steven Rostedt <rostedt@...dmis.org>,
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>,
Fedora Kernel Team <kernel-team@...oraproject.org>
Subject: Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 06:30:47PM +0100, Alan Cox wrote:
>
> > Well, yes. I was thinking it would be more like:
> >
> > distro/Kconfig.fedora
> > menuconfig FEDORA
> > if FEDORA
> > config FEDORA_16
> > select WHATEVER
> > config FEDORA_17
>
> Nope you need
>
> distro/everyarchtheyship/everykernelvarianttkeyship(smp,largemem,arm
> boards)/Kconfig
>
> which for some distros is over 20 per release and the end user wouldn't
> have a cat in hells chance of knowing which to pick.
I wasn't include arch-specific options in the "minimal distro config"
stuff. That doesn't seem minimal to me. I was thinking more along the
lines of "distro X needs CGROUPS, SELINUX, HOTPLUG, DEVTMPFS, namespace
stuff". Stuff that they need that is basically architecture
independent that the distro userspace needs.
Having the distro provide files that select architecture specific
options and variations of that really doesn't seem any better than what
most of them do already, which is just ship the whole damn config file
in /boot (or some other location).
> For the end user case you need the distro to plonk the right file in the
> right place and be done with it, once they do that the rest is
> bikeshedding a ten line Makefile rule.
If people want the distros to plonk some architecture+distro specific
minimal config file down as part of the packaging, I guess that's a
thing that could be done. I'd honestly wonder if maintaining X number
of those in the packaging is something the distro maintainers would
really like to do, but one can always hope.
josh
--
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