Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
- To: Linus Torvalds <email@example.com>
- Cc: Steven Rostedt <firstname.lastname@example.org>, Cyrill Gorcunov <email@example.com>, Pekka Enberg <firstname.lastname@example.org>, richard -rw- weinberger <email@example.com>, "Myklebust, Trond" <Trond.Myklebust@netapp.com>, Dave Jones <firstname.lastname@example.org>, Greg Kroah-Hartman <email@example.com>, Ubuntu Kernel Team <firstname.lastname@example.org>, Debian Kernel Team <email@example.com>, OpenSUSE Kernel Team <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, Ingo Molnar <firstname.lastname@example.org>, Sasha Levin <email@example.com>, Asias He <firstname.lastname@example.org>
- Subject: Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
- From: Borislav Petkov <email@example.com>
- Date: Thu, 19 Jul 2012 19:53:10 +0200
- Message-id: <20120719175310.GF23393@aftab.osrc.amd.com>
- In-reply-to: <CA+55aFxX41pGnHcc17A=VBnW+03LEwkwATiZWObbPgD9Ap37Xg@mail.gmail.com>
- References: <CA+55aFxw8pY1KMjobp=dKJd+g4B9KGhe4+fsfSPA3ofCGVhkPQ@mail.gmail.com> <firstname.lastname@example.org> <CAFLxGvxxWodD97=78218wc+tuigAFsNK_PdroDfb4BWTZoxxUw@mail.gmail.com> <20120714103716.GD26559@liondog.tnic> <CAOJsxLGHQuuXqDD-1SNhL7Ly1-heCYFLzqj3SLh4xzmP9NR5GQ@mail.gmail.com> <20120714124332.GA4093@moon> <20120714174827.GA13319@aftab.osrc.amd.com> <20120719144217.GC16873@home.goodmis.org> <20120719164807.GD23393@aftab.osrc.amd.com> <CA+55aFxX41pGnHcc17A=VBnW+03LEwkwATiZWObbPgD9Ap37Xg@mail.gmail.com>
On Thu, Jul 19, 2012 at 10:06:44AM -0700, Linus Torvalds wrote:
> On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov <email@example.com> 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
> 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.
> 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).
So there are some not-so-obscure situations, judging by your examples
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551