Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configurationfor distro issues

[david]

On Wed, 18 Jul 2012, Ingo Molnar wrote:

> * david@xxxxxxx <david@xxxxxxx> wrote:
>
> > > Anybody who says "I want to run Fedora without SELINUX
> > > because I do my own security development" is by *definition*
> > > not relevant to the whole feature.
> >
> > Don't mistake the example for the feature. the SELINUX thing
> > is just an example. As Alan Cox commented, taking a distro
> > config and disabling one thing is a common troubleshooting
> > request from kernel developers.
>
> It's still irrelevant:
>
> - if a user chooses a distro config it means that he is using
>   that distro. Disabling an essential component of the distro
>   config, even if a kernel developer asks for it, will likely
>   break that distro and is thus a dumb thing to do. (the
>   typical user will also be unlikely to be *able* to edit a
>   .config and make sure it works.)

that's assuming that everything listed really is essential.

The history of features defaulting to 'Y' in the existing kernel config 
doesn't give me great confidence that reality will be anywhere close to 
this ideal.

> - Furthermore, there's *already* over ten thousand select's in
>   our Kconfig's, and it's already hard at times to disable
>   dependent options.
>
> - I've been using what Linus suggested for many years via
>   private patches to do bootable randconfig testing and the
>   concept works just fine - enabling a distro specific
>   minconfig is absolutely useful, I'm glad it's being pursued
>   upstream as well...
>
> So what you are arguing about is IMO irrelevant, it is
> immaterial to the problem at hand and the concept works just
> fine in practice.

Shrug, you guys have to maintain the result, I'm just a user.

But I don't see why the same logic that kept the kernel installation 
outside of the makefiles and created /sbin/installkernel wouldn't also 
apply here.

using a separate miniconfig in a known place would seem to be less code, 
distribute the work better (as every distro can use it without having to 
patch the same files in the kernel source), and be more flexible.

Flexibility has a way of being leveraged in ways never imagined initially, 
so if it can be gained without complicating the code (and it's 
maintinance), and the initial use case, I always tend to push for the more 
flexible option.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/