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

From: david
Date: Mon Jul 16 2012 - 18:22:00 EST


On Mon, 16 Jul 2012, Linus Torvalds wrote:

On Mon, Jul 16, 2012 at 12:26 PM, <david@xxxxxxx> wrote:

Some of the proposed ways to implement the minimum distro kernel would not
allow you to override the distro defaults because they would be implemented
by setting dependancies, not by selecting options that you as the user could
then unselect.

The sanest thing to do is just a list of "select" statements. And in
any case it would have to depend on the "distro config" entry, so EVEN
THEN you could just create the Kconfig file, then edit out the distro
config thing, and then do whatever you want.

So I don't see why you're arguing. Even if it is very much a "if you
select the FEDORA_X kconfig option, that will automatically force all
those other options on", I don't see why you are so upset. Just set
it, generate your kconfig, and then edit to file to NOT set the distro
config. Then you can do whatever the hell you want.

What I'm upset about is simply the fact that EVEN IF your arguments
were valid (and I don't think they are: see above for trivial fix) I
think your arguments are bogus, for the simple reason that what you
ask for isn't even what the whole "distro minconfig" is at all about.
It's about normal users who absolutely DO NOT want to edit the config.
People who want to say "I know I have intel/amd/nvidia graphics,
standard USB, and no CD-ROM drive". They couldn't care *less* about
SELINUX, and in fact that very issue is why we should have this.

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.

I am not that familiar with the internals of kconfig, but my understanding was that if you select feature X that then turns on A, B, and C, if you then edit the .config file to remove feature X features A, B, and C will be turned off the next time you do a make *config. If this is not the case, then it's not as horrible as I was thinking.

However, there's still the question of how many different variations of how many different distros are you going to accept into the upstream kernel. How many different versions of Fedora are you going to be willing to have in the menu? This seems to me to be the defconfig problem multiplied by many distros and many versions of each distro. If we can eliminate this combinational explosion by referencing something outside of the kernel tree, it seems to me that it's a big win.

As Alan Cox put it in code

make distroconfig
[cp /etc/system-kconfig(.$ARCH?) .config
make oldconfig]

make menuconfig (if you want to customise)

with the distros providing /etc/system-kconfig files seems far more scalable as well as far more flexible than either setting up a lot of dependancies for new tags or adding a field to every option to make it part of some profile.

This approach works both for the users who just want to say "I know I have intel/amd/nvidia graphics, standard USB, and no CD-ROM drive", for the users who know a bit more, but want to start with a known point, and for the production sysadmins who want to use the same mechanism for other purposes (standardizing builds for systems as kernel versions move forward)

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/