[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120719175310.GF23393@aftab.osrc.amd.com>
Date: Thu, 19 Jul 2012 19:53:10 +0200
From: Borislav Petkov <bp@...64.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Cyrill Gorcunov <gorcunov@...nvz.org>,
Pekka Enberg <penberg@...nel.org>,
richard -rw- weinberger <richard.weinberger@...il.com>,
"Myklebust, Trond" <Trond.Myklebust@...app.com>,
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>
Subject: Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for
distro issues
On Thu, Jul 19, 2012 at 10:06:44AM -0700, Linus Torvalds wrote:
> On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov <bp@...64.org> wrote:
> >
> > Seriously, this helps only in the cases where the stuff the distro
> > actually needs is in modules. So, there probably are obscure situations
> > where you need to enable stuff which is bool and not M.
>
> Sadly, not obscure at all.
>
> Most of the *drivers* are modules, but most of the "distro config"
> options are indeed booleans (or, if tristate, =y).
>
> Even driver-wise, there are some things that are often =y, even though
> you generally don't want them.
Tell me about it. I'm always pissed off when someone thinks his stuff is
very important and sets his sacred option to be =y/=m by default so the
wider audience can at least compile-test it while the majority of the
machines don't actually need it.
A more coarse-grained config where most of the stuff is off by default
could take care of that probably.
> PCMCIA? Not even *laptops* have that shit any more, but having
> built-in cardbus support almost certainly helps in a distro kernel for
> booting of certain odder cases.
Yeah, distros need the one-size-fits-all thing so they have to enable
*everything*.
> Xen support? Odd partition tables? All the different AGP versions?
> Many of us couldn't care less, but again, it makes sense in the actual
> distro kernel, even if it does *not* necessarily make sense in a
> personalized one.
Yep.
> So doing "make allmodconfig" is certainly a workable thing (modulo the
> modules that you need for stuff you hadn't happened to use), but it's
> not wonderful.
Oh and I always aim to build distro kernels on a big machine -
allmodconfig build is no fun on a tiny laptop. So would it be better
to have better profiled kernels, obviating the need for an almost full
build? Hell yeah!
> I also hate having to enable support for modules. A non-modular build
> is quicker to build and avoids some security issues. Some drivers
> don't work well built-in (they load firmware etc too early), but imho
> it's worth doing if you can, and it's something we should make easy
> for people to do because of the security side (of course, per-build
> randomly generated keys and signed modules with the keys deleted after
> the build would be reasonably equivalent from a security standpoint,
> but we're not there yet).
Agreed.
So there are some not-so-obscure situations, judging by your examples
above. Ho-humm.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
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