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

[david@lang.hm]

On Mon, 16 Jul 2012, Linus Torvalds wrote:

> On Mon, Jul 16, 2012 at 12:26 PM,  <david@lang.hm> 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