Message-ID: <alpine.DEB.2.02.1207191357360.20176@asgard.lang.hm>
Date:	Thu, 19 Jul 2012 14:04:11 -0700 (PDT)
From:	david@...g.hm
To:	Josh Boyer <jwboyer@...hat.com>
cc:	Steven Rostedt <rostedt@...dmis.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Jones <davej@...hat.com>,
	Greg Kroah-Hartman <greg@...ah.com>,
	Ubuntu Kernel Team <kernel-team@...ts.ubuntu.com>,
	Debian Kernel Team <debian-kernel@...ts.debian.org>,
	OpenSUSE Kernel Team <opensuse-kernel@...nsuse.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Fedora Kernel Team <kernel-team@...oraproject.org>
Subject: Re: [RFC] Simplifying kernel configuration for distro issues

On Thu, 19 Jul 2012, Josh Boyer wrote:

> On Thu, Jul 19, 2012 at 02:13:40PM -0400, Steven Rostedt wrote:
>> On Thu, 2012-07-19 at 13:56 -0400, Josh Boyer wrote:
>>
>>> Distros aren't stationary things.
>>
>> Exactly my point.
>>
>>>   I mean, some of them certainly aim
>>> for that goal, but userspace and kernels get upgraded all the time.  So
>>> if this distro-Kconfig file is provided by some package _other_ than the
>>> kernel the distros are going to have a bit of a hassle keeping track of
>>> it.
>>
>> How about a directory called /usr/share/Linux/Kconfig.d/
>>
>> Then have anything installed that needs to work correctly put in its
>> minimum (must have) requirement configs of the kernel.
>>
>> Say you are running Debian, and decide to try out systemd. If you set up
>> your system to run that it would add a file called:
>>
>> /usr/share/Linux/Kconfig.d/systemd.conf
>>
>> or something, and this would select things like CGROUPS and the like. We
>> could make the kernel build select all, or individual files in this
>> directory. All for the 'make my distro work' or individual for a 'I want
>> part of my distro to work' option.
>
> That sounds like a pretty good idea, aside from the fact that now your
> config is determined by 1) what is currently installed on your system
> and 2) people that don't maintain the kernel.
>
> 1 is obviously a great thing once you have a stable working set of
> packages you use daily, but wouldn't it kind of suck to have to rebuild
> the kernel just to install some new package?  I mean... say you wanted
> to now use an NFS mount, but you didn't have nfs-utils previously
> installed.  So you install it, and it plops the kconfig file in
> /usr/share but oops, you have to rebuild the kernel and reboot because
> that module isn't built.  Of course I'm extrapolating possibly the worst
> usage case here, but it will still happen.

the alturnative to this is what? compile everything just in case you need 
it some time in the future?

we already have some tools (vmware) that check for the proper kernel 
config when they startup, and if the appropriate stuff isn't there they 
ask for the root password and compile the modules.

> 2... yeah.  I don't really know if that is going to pan out, but I am
> ever hopeful.  I'd be mostly concerned with people that are coding
> userspace applications using every whiz-bang kernel feature.  Or not
> paying attention at all to the kernel after the initial file creation
> and the options going stale (don't follow renames, etc).

it would be determined by the distro maintainers who maintain the kernel 
config for that distro.

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

Powered by blists - more mailing lists