From: Jesper Juhl <jj@chaosbits.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Jones <davej@redhat.com>,
Greg Kroah-Hartman <greg@kroah.com>,
Ubuntu Kernel Team <kernel-team@lists.ubuntu.com>,
Debian Kernel Team <debian-kernel@lists.debian.org>,
OpenSUSE Kernel Team <opensuse-kernel@opensuse.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Simplifying kernel configuration for distro issues
Date: Sat, 14 Jul 2012 00:33:51 +0200 (CEST) [thread overview]
Message-ID: <alpine.LNX.2.00.1207140014070.10676@swampdragon.chaosbits.net> (raw)
In-Reply-To: <CA+55aFxw8pY1KMjobp=dKJd+g4B9KGhe4+fsfSPA3ofCGVhkPQ@mail.gmail.com>
On Fri, 13 Jul 2012, Linus Torvalds wrote:
> So this has long been one of my pet configuration peeves: as a user I
> am perfectly happy answering the questions about what kinds of
> hardware I want the kernel to support (I kind of know that), but many
> of the "support infrastructure" questions are very opaque, and I have
> no idea which of the them any particular distribution actually depends
> on.
>
> And it tends to change over time. For example, F14 (iirc) started
> using TMPFS and TMPFS_POSIX_ACL/XATTR for /dev. And starting in F16,
> the initrd setup requires DEVTMPFS and DEVTMPFS_MOUNT. There's been
> several times when I started with my old minimal config, and the
> resulting kernel would boot, but something wouldn't quite work right,
> and it can be very subtle indeed.
>
> Similarly, the distro ends up having very particular requirements for
> exactly *which* security models it uses and needs, and they tend to
> change over time. And now with systemd, CGROUPS suddenly aren't just
> esoteric things that no normal person would want to use, but are used
> for basic infrastructure. And I remember being surprised by OpenSUSE
> suddenly needing the RAW table support for netfilter, because it had a
> NOTRACK rule or something.
>
> The point I'm slowly getting to is that I would actually love to have
> *distro* Kconfig-files, where the distribution would be able to say
> "These are the minimums I *require* to work". So we'd have a "Distro"
> submenu, where you could pick the distro(s) you use, and then pick
> which release, and we'd have something like
>
> - distro/Kconfig:
>
> config DISTRO_REQUIREMENTS
> bool "Pick minimal distribution requirements"
>
> choice DISTRO
> prompt "Distribution"
> depends on DISTRO_REQUIREMENTS
>
> config FEDORA
> config OPENSUSE
> config UBUNTU
> ...
>
> endchoice
>
[...]
We are going to end up with a million+ (or something like that) "config
<RANDOM_FOO_DISTRO>" options that are going to have to be kept up-to-date
regularly...
Do we really want that?
Maybe we do, maybe we don't - I'm not saying anything either way - just
pointing it out.
I like the general idea - let a user pick the "make my distro work" option
and then tweak from there. But, with hundreds (thousands?) of distroes out
there, is it realy doable? Will we be able to keep things updated
properly?
Perhaps a better aproach (and this is going to be controversial, so I'll
put on my flame-repelling underwear now) would be to severely limit the
number of available options.
KConfig is a mess (IMHO) - there's no telling what a given Linux kernel
will support on any given distro on any given arch - there's no known
mimimum.
How about we start cutting down on the options and start saying "a Linux
system will provide feature x and y - always ...".
Stuff like (and I'm just pulling random stuff out here) - ASLR, seccomp,
250HZ minimum etc etc.. We could cut the KConfig options down to 10% of
what they are now if we just made a few (hard) choices about some things
that would always be there that everyone could count on. If people want
to deviate from the default minimum, sure, let them, but put it under
*custom*, *embedded*, *specialized distro*, *you know what you are doing*
menu options.
Configurabillity is good, but only to a certain degree - I think we could
bennefit from removing a *lot* of options and instead just decreeing that
"a linux system has this"..
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
next prev parent reply other threads:[~2012-07-13 22:33 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-13 20:37 [RFC] Simplifying kernel configuration for distro issues Linus Torvalds
2012-07-13 20:54 ` Myklebust, Trond
2012-07-13 21:41 ` [opensuse-kernel] " richard -rw- weinberger
2012-07-14 10:37 ` Borislav Petkov
2012-07-14 12:12 ` Pekka Enberg
2012-07-14 12:43 ` Cyrill Gorcunov
2012-07-14 17:48 ` Borislav Petkov
2012-07-14 18:51 ` Cyrill Gorcunov
2012-07-14 19:51 ` david
2012-07-19 14:42 ` Steven Rostedt
2012-07-19 16:48 ` Borislav Petkov
2012-07-19 17:02 ` Steven Rostedt
2012-07-19 17:34 ` Borislav Petkov
2012-07-19 17:57 ` Steven Rostedt
2012-07-19 18:09 ` Borislav Petkov
2012-07-19 17:06 ` Linus Torvalds
2012-07-19 17:53 ` Borislav Petkov
2012-07-19 18:42 ` Konrad Rzeszutek Wilk
2012-07-15 10:14 ` Borislav Petkov
2012-07-15 10:17 ` Pekka Enberg
2012-07-15 21:18 ` Borislav Petkov
2012-07-15 21:48 ` Cyrill Gorcunov
2012-07-15 22:09 ` david
2012-07-15 22:22 ` Cyrill Gorcunov
2012-07-15 23:06 ` david
2012-07-16 8:24 ` Borislav Petkov
2012-07-16 16:43 ` david
2012-07-16 16:50 ` Linus Torvalds
2012-07-16 19:26 ` david
2012-07-16 20:56 ` Linus Torvalds
2012-07-16 22:21 ` david
2012-07-18 7:04 ` Ingo Molnar
2012-07-18 8:42 ` david
2012-07-18 9:13 ` Ingo Molnar
2012-07-17 8:03 ` Geert Uytterhoeven
2012-07-19 16:01 ` Michal Marek
2012-07-16 17:01 ` Alan Cox
2012-07-16 17:05 ` david
2012-07-13 21:02 ` Dave Jones
2012-07-13 21:17 ` Linus Torvalds
2012-07-13 22:26 ` Josh Boyer
2012-07-19 15:26 ` Steven Rostedt
2012-07-19 15:43 ` Linus Torvalds
2012-07-19 16:12 ` Steven Rostedt
2012-07-19 15:45 ` Josh Boyer
2012-07-19 16:08 ` Steven Rostedt
2012-07-19 17:19 ` Josh Boyer
2012-07-19 17:30 ` Alan Cox
2012-07-19 17:38 ` Josh Boyer
2012-07-19 21:13 ` Ben Hutchings
2012-07-20 2:44 ` david
2012-07-19 17:33 ` Steven Rostedt
2012-07-19 17:41 ` Alan Cox
2012-07-19 17:56 ` Josh Boyer
2012-07-19 18:13 ` Steven Rostedt
2012-07-19 18:36 ` Josh Boyer
2012-07-19 21:04 ` david
2012-07-19 22:35 ` Josh Boyer
2012-07-19 22:49 ` Steven Rostedt
2012-07-21 20:47 ` valdis.kletnieks
2012-07-19 18:20 ` Paul Bolle
2012-07-19 18:22 ` Josh Boyer
2012-07-19 18:49 ` Geert Uytterhoeven
2012-07-19 18:55 ` Paul Bolle
2012-07-19 21:30 ` Geert Uytterhoeven
2012-07-13 21:29 ` Geert Uytterhoeven
2012-07-13 21:50 ` Paul Bolle
2012-07-13 21:55 ` Dave Jones
2012-07-13 22:11 ` Tony Luck
2012-07-13 22:20 ` Paul Bolle
2012-07-13 23:07 ` Frank Rowand
2012-07-13 21:06 ` Khalid Aziz
2012-07-13 21:17 ` Casey Schaufler
2012-07-13 21:20 ` Linus Torvalds
2012-07-13 22:13 ` david
2012-07-13 21:59 ` Hans de Bruin
2012-07-13 22:33 ` Jesper Juhl [this message]
2012-07-13 22:46 ` david
2012-07-14 9:44 ` Olivier Galibert
2012-07-14 4:18 ` Ben Hutchings
2012-07-14 12:35 ` Josh Boyer
2012-07-19 1:48 ` Steven Yong
2012-07-20 9:47 ` Jiri Kosina
2012-07-20 10:26 ` Sam Ravnborg
2012-07-18 9:55 Tom Gundersen
2012-07-22 20:10 ` David Greaves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LNX.2.00.1207140014070.10676@swampdragon.chaosbits.net \
--to=jj@chaosbits.net \
--cc=davej@redhat.com \
--cc=debian-kernel@lists.debian.org \
--cc=greg@kroah.com \
--cc=kernel-team@lists.ubuntu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=opensuse-kernel@opensuse.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.