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

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

On Wed, 18 Jul 2012, Ingo Molnar wrote:

* david@lang.hm <david@lang.hm> 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

Reply to: