On Thu, Jul 19, 2012 at 10:06:44AM -0700, Linus Torvalds wrote:
On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov
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, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org