[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues

On Thu, Jul 19, 2012 at 07:53:10PM +0200, Borislav Petkov wrote:
> 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@amd64.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.

I proposed something that would solve some of this - but not during
compile time but rather during boot-time
(interestingly enough hpa was first to propose it 10 years ago :-)

The goal is turn built-in components in well, unloadable components.
That way you won't have at least that much stuff laying around not being
used. Not the full silver bullet, but at least it gets some of this
stuff out of the way and you don't have to worry about the extra
stuff that was built-in.

Reply to: