[RFC] Simplifying kernel configuration for distro issues

[Linus Torvalds]

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

and then depending on the DISTRO config, we'd include one of the
distro-specific ones with lists of supported distro versions and then
the random config settings for that version:

 - distro/Kconfig.suse:

    config OPENSUSE_121
        select OPENSUSE_11
        select IP_NF_RAW  # ..

 - distro/Kconfig.Fedora:

    config FEDORA_16
        select FEDORA_15
        select DEVTMPFS               # F16 initrd needs this
        select DEVTMPFS_MOUNT  # .. and expects the kernel to mount
DEVTMPFS automatically
        ...

    config FEDORA_17
        select FEDORA_16
        select CGROUP_xyzzy
        ...

and the point would be that it would make it much easier for a normal
user (and quite frankly, I want to put myself in that group too) to
make a kernel config that "just works".

Sure, you can copy the config file that came with the distro, but it
has tons of stuff that really isn't required. Not just in hardware,
but all the debug choices etc that are really a user choice. And it's
really hard to figure out - even for somebody like me - what a minimal
usable kernel is.

And yes, I know about "make localmodconfig". That's missing the point
for the same reason the distro config is missing the point.

Comments? It doesn't have to start out perfect, but I think it would
*really* help make the kernel configuration much easier for people.

In addition to the "minimal distro settings", we might also have a few
"common platform" settings, so that you could basically do a "hey, I
have a modern PC laptop, make it pick the obvious stuff that a normal
person needs, like USB storage, FAT/VFAT support, the core power
management etc". The silly stuff that you need, and that
"localyesconfig" actually misses because if you haven't inserted a USB
thumb drive, you won't necessarily have the FAT module loaded, but we
all know you do want it in real life. But that's really independent
issue, so let's keep it to just distro core things at first, ok?

Would something like this make sense to people? I really think that
"How do I generate a kernel config file" is one of those things that
keeps normal people from compiling their own kernel. And we *want*
people to compile their own kernel so that they can help with things
like bisecting etc. The more, the merrier.

                    Linus

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[Myklebust, Trond]

On Fri, 2012-07-13 at 13:37 -0700, 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
>
> and then depending on the DISTRO config, we'd include one of the
> distro-specific ones with lists of supported distro versions and then
> the random config settings for that version:
>
>  - distro/Kconfig.suse:
>
>     config OPENSUSE_121
>         select OPENSUSE_11
>         select IP_NF_RAW  # ..
>
>  - distro/Kconfig.Fedora:
>
>     config FEDORA_16
>         select FEDORA_15
>         select DEVTMPFS               # F16 initrd needs this
>         select DEVTMPFS_MOUNT  # .. and expects the kernel to mount
> DEVTMPFS automatically
>         ...
>
>     config FEDORA_17
>         select FEDORA_16
>         select CGROUP_xyzzy
>         ...
>
> and the point would be that it would make it much easier for a normal
> user (and quite frankly, I want to put myself in that group too) to
> make a kernel config that "just works".
>
> Sure, you can copy the config file that came with the distro, but it
> has tons of stuff that really isn't required. Not just in hardware,
> but all the debug choices etc that are really a user choice. And it's
> really hard to figure out - even for somebody like me - what a minimal
> usable kernel is.
>
> And yes, I know about "make localmodconfig". That's missing the point
> for the same reason the distro config is missing the point.
>
> Comments? It doesn't have to start out perfect, but I think it would
> *really* help make the kernel configuration much easier for people.
>
> In addition to the "minimal distro settings", we might also have a few
> "common platform" settings, so that you could basically do a "hey, I
> have a modern PC laptop, make it pick the obvious stuff that a normal
> person needs, like USB storage, FAT/VFAT support, the core power
> management etc". The silly stuff that you need, and that
> "localyesconfig" actually misses because if you haven't inserted a USB
> thumb drive, you won't necessarily have the FAT module loaded, but we
> all know you do want it in real life. But that's really independent
> issue, so let's keep it to just distro core things at first, ok?
>
> Would something like this make sense to people? I really think that
> "How do I generate a kernel config file" is one of those things that
> keeps normal people from compiling their own kernel. And we *want*
> people to compile their own kernel so that they can help with things
> like bisecting etc. The more, the merrier.
>
>                     Linus

We could at least make selection of a minimal set of drivers for the
more common virtualised platforms a lot easier.
Right now, you need to hunt through 30+ different menus in order to find
what you need to run in a basic KVM virtual machine...

Cheers
  Trond
--
Trond Myklebust
Linux NFS client maintainer

NetApp
[hidden email]
www.netapp.com

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[Dave Jones]

On Fri, Jul 13, 2012 at 01:37:41PM -0700, Linus Torvalds wrote:

 > 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".

As long as you don't mind these being added after the fact, I suppose
it would be workable.  The reason I say that is sometimes, it even catches *us*
by surprise.  We recently found out our virtualisation guys started
using sch_htb for example, and we inadvertantly broke it when we moved
its module to a 'not always installed' kernel subpackage. (and before that, 9PFS..)

People don't tell us anything, but somehow expect things to keep working.

 > In addition to the "minimal distro settings", we might also have a few
 > "common platform" settings, so that you could basically do a "hey, I
 > have a modern PC laptop, make it pick the obvious stuff that a normal
 > person needs, like USB storage, FAT/VFAT support, the core power
 > management etc".

I wish defconfig was actually something useful like this, instead of..
what the hell is it exactly ? No-one even seems to agree, other than
"random selection of options, many of which were removed n years ago"

        Dave


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[Khalid Aziz]

On 07/13/2012 02:37 PM, Linus Torvalds wrote:

>
> Would something like this make sense to people? I really think that
> "How do I generate a kernel config file" is one of those things that
> keeps normal people from compiling their own kernel. And we *want*
> people to compile their own kernel so that they can help with things
> like bisecting etc. The more, the merrier.
>
This is a great idea. 7-8 years ago I used to be able to create a
minimally configured kernel from upstream and run my Debian/Ubuntu/...
install with it. It got much harder in a hurry and now it takes too much
work to figure out how to configure upstream kernel to make it work with
distro. It is a 3-5 hour compile to start with distro config file and that
is just too painful. I will help with testing configs or helping sort
through the config options.

--
Khalid Aziz
[hidden email]


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[Casey Schaufler]

On 7/13/2012 1:37 PM, 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".

Oh dear. I would expect Fedora to say that they require SELinux,
thereby making it unusable by anyone doing LSM development. It
would also make it more difficult for the people who don't want
any LSM (e.g. everyone sane) to configure the kernel they want.

This is the example that I see because of my particular biases.
I expect that there are similar things that distros do in other
areas that will have the same effect. The distro developers may
have decided that a feature is too cool to live without and
include it in their configuration even when it's not really
necessary. Plus, do you really think that they're going to
clean things out of their configuration when they decide that
they no longer need them?

>  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
>
> and then depending on the DISTRO config, we'd include one of the
> distro-specific ones with lists of supported distro versions and then
> the random config settings for that version:
>
>  - distro/Kconfig.suse:
>
>     config OPENSUSE_121
>         select OPENSUSE_11
>         select IP_NF_RAW  # ..
>
>  - distro/Kconfig.Fedora:
>
>     config FEDORA_16
>         select FEDORA_15
>         select DEVTMPFS               # F16 initrd needs this
>         select DEVTMPFS_MOUNT  # .. and expects the kernel to mount
> DEVTMPFS automatically
>         ...
>
>     config FEDORA_17
>         select FEDORA_16
>         select CGROUP_xyzzy
>         ...
>
> and the point would be that it would make it much easier for a normal
> user (and quite frankly, I want to put myself in that group too) to
> make a kernel config that "just works".
>
> Sure, you can copy the config file that came with the distro, but it
> has tons of stuff that really isn't required. Not just in hardware,
> but all the debug choices etc that are really a user choice. And it's
> really hard to figure out - even for somebody like me - what a minimal
> usable kernel is.
>
> And yes, I know about "make localmodconfig". That's missing the point
> for the same reason the distro config is missing the point.
>
> Comments? It doesn't have to start out perfect, but I think it would
> *really* help make the kernel configuration much easier for people.
>
> In addition to the "minimal distro settings", we might also have a few
> "common platform" settings, so that you could basically do a "hey, I
> have a modern PC laptop, make it pick the obvious stuff that a normal
> person needs, like USB storage, FAT/VFAT support, the core power
> management etc". The silly stuff that you need, and that
> "localyesconfig" actually misses because if you haven't inserted a USB
> thumb drive, you won't necessarily have the FAT module loaded, but we
> all know you do want it in real life. But that's really independent
> issue, so let's keep it to just distro core things at first, ok?
>
> Would something like this make sense to people? I really think that
> "How do I generate a kernel config file" is one of those things that
> keeps normal people from compiling their own kernel. And we *want*
> people to compile their own kernel so that they can help with things
> like bisecting etc. The more, the merrier.
>
>                     Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [hidden email]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[Linus Torvalds]

On Fri, Jul 13, 2012 at 2:02 PM, Dave Jones <[hidden email]> wrote:
>
> As long as you don't mind these being added after the fact, I suppose
> it would be workable.  The reason I say that is sometimes, it even catches *us*
> by surprise.  We recently found out our virtualisation guys started
> using sch_htb for example, and we inadvertantly broke it when we moved
> its module to a 'not always installed' kernel subpackage. (and before that, 9PFS..)
>
> People don't tell us anything, but somehow expect things to keep working.

I think even a "educated guess" config file is better than what we have now.

The *two* requirements (and they're really the same theme) I
personally think we should have for this are

 -  I think every single "select" for these things should come with a
comment about what it is about and why the distro needs it (to show
there was some thought involved and not just a blind "took it from the
distro config")

 - It should be about *minimal* settings. I'd rather have too few
things and the occasional complaint about "oh, it didn't work because
it missed XYZ" than have it grow to contain all the options just
because somebody decided to just add random things until things
worked.

Other than that, even if it only gets you *closer* to a kernel that
works with that distro, I think it doesn't have to be all that
perfect. Because the alternative is what we have now.

           Linus

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[Linus Torvalds]

On Fri, Jul 13, 2012 at 2:17 PM, Casey Schaufler <[hidden email]> wrote:
>
> Oh dear. I would expect Fedora to say that they require SELinux,
> thereby making it unusable by anyone doing LSM development.

Oh, *absolutely*.

These options would *not* be meant for people doing odd things and
experienting with configs.

If you do that, then you might *start* by saying "I want this distro"
to get the initial guesstimate of the config file you want, but then
edit the .config by hand later (and remove the "I want all the Fedora
requirements" option, of course).

This is explicitly and exclusively for normal users. The whole point
of "expert configurator for special cases" should not be given any
thought at all - those kinds of people should simply answer "No" to
the "Do you want the distro basic kconfig requirements" question.

                Linus

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[Geert Uytterhoeven]

On Fri, Jul 13, 2012 at 11:02 PM, Dave Jones <[hidden email]> wrote:
> I wish defconfig was actually something useful like this, instead of..
> what the hell is it exactly ? No-one even seems to agree, other than
> "random selection of options, many of which were removed n years ago"

It's just to difficult to update them in a sane way.

I mean, I have my own set of defconfigs for all supported m68k-platforms,
but getting them in sync and ready for submitting an update seems to be a
multi-year project, and there are always more important (and more fun) things
to do. So that's why I haven't gotten to updating them since the defconfig
reduction.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [hidden email]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[richard -rw- weinberger]

On Fri, Jul 13, 2012 at 10:54 PM, Myklebust, Trond
<[hidden email]> wrote:
> We could at least make selection of a minimal set of drivers for the
> more common virtualised platforms a lot easier.
> Right now, you need to hunt through 30+ different menus in order to find
> what you need to run in a basic KVM virtual machine...

Yes, every time I build a kernel to be used on KVM I forget something. :-\

We could introduce a section in Kconfig which contains selections for
common use cases.
E.g. as Linus requested for minimal distro requirements but also
selections for various common
guest configurations.

--
Thanks,
//richard

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[Paul Bolle]

On Fri, 2012-07-13 at 17:02 -0400, Dave Jones wrote:
> I wish defconfig was actually something useful like this, instead of..
> what the hell is it exactly ? No-one even seems to agree, other than
> "random selection of options, many of which were removed n years ago"

As for the "many of which were removed n years ago" part: in
https://lkml.org/lkml/2011/11/18/211 I suggested to delete
almost 2000 lines from over 400 defconfig files. That would have deleted
all certainly unused macros from all defconfig files. Nothing happened
after that. My fault, I'm afraid.

But just removing all the certainly unused macros probably wouldn't have
made a noticeable difference to anyone using those defconfig files
anyway.


Paul Bolle


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[Dave Jones]

On Fri, Jul 13, 2012 at 11:50:25PM +0200, Paul Bolle wrote:

 > But just removing all the certainly unused macros probably wouldn't have
 > made a noticeable difference to anyone using those defconfig files
 > anyway.

My point is that I don't think there's many people actually using them.
(maybe more on the niche platforms, but x86[64] ? I'm sceptical they're used at all)

        Dave
 

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[Hans de Bruin]

On 07/13/2012 10:37 PM, 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
 >
 > and then depending on the DISTRO config, we'd include one of the
 > distro-specific ones with lists of supported distro versions and then
 > the random config settings for that version:
 >
 >   - distro/Kconfig.suse:
 >
 >      config OPENSUSE_121
 >          select OPENSUSE_11
 >          select IP_NF_RAW  # ..
 >
 >   - distro/Kconfig.Fedora:
 >
 >      config FEDORA_16
 >          select FEDORA_15
 >          select DEVTMPFS               # F16 initrd needs this
 >          select DEVTMPFS_MOUNT  # .. and expects the kernel to mount
 > DEVTMPFS automatically
 >          ...
 >
 >      config FEDORA_17
 >          select FEDORA_16
 >          select CGROUP_xyzzy
 >          ...

Could this be made more dynamic? I would like to download a minimal
config file from my distro's website and perhaps add my own minimal
config for the hardware I own and put both downloads somewhere in my
local tree, or have makemenuconfig ask me for a location of my minimal
config files?

--
Hans

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[Tony Luck]

I always thought that the x86 defconfig file was the one that Linus
used for his primary machine.

-Tony

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[David Lang]

On Fri, 13 Jul 2012, Linus Torvalds wrote:

> On Fri, Jul 13, 2012 at 2:17 PM, Casey Schaufler <[hidden email]> wrote:
>>
>> Oh dear. I would expect Fedora to say that they require SELinux,
>> thereby making it unusable by anyone doing LSM development.
>
> Oh, *absolutely*.
>
> These options would *not* be meant for people doing odd things and
> experienting with configs.
>
> If you do that, then you might *start* by saying "I want this distro"
> to get the initial guesstimate of the config file you want, but then
> edit the .config by hand later (and remove the "I want all the Fedora
> requirements" option, of course).
>
> This is explicitly and exclusively for normal users. The whole point
> of "expert configurator for special cases" should not be given any
> thought at all - those kinds of people should simply answer "No" to
> the "Do you want the distro basic kconfig requirements" question.

hopefully this can be made a little easier.

more of a 'enable anything set in this file, then give me control again so
I can turn things off' rather than having to manually edit the .config
file.

If this is done as a hard set of dependancy settings, it will be very
annoying for people who for any reason want to disable something that the
distro considers 'essential'.

I also _really_ like the idea of being able to have a vmware option that
enables the minimum devices that are needed to run.

Having these be hard dependancies also seems like it would make
interactions between these sorts of things much more likely to cause
problems.

If however they are one-shot "go through this file and enable anything
that it says to turn on" things that then let you turn anything off, it
seems much less likely to cause problems.

and if we can then get some of the big hardware vendors to create such
files to enable all the drivers needed for their hardware.... (the big
things are easy, it's when you get into the internal monitoring busses and
so on that things get messy)

David Lang

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[Paul Bolle]

On Fri, 2012-07-13 at 17:55 -0400, Dave Jones wrote:
> My point is that I don't think there's many people actually using them.
> (maybe more on the niche platforms, but x86[64] ? I'm sceptical they're used at all)

I guess you're right. Personally, I tend to start my journeys in self
compiled kernel land by using something I know that works as a starting
point. Ie, I use some distribution's kernel, notice that things seem to
mostly work, and use the .config of that kernel to start exploring
whatever it is I'm interested in. I can't remember ever feeling the urge
to use some defconfig to start these journeys.


Paul Bolle


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[Josh Boyer-2]

On Fri, Jul 13, 2012 at 02:17:30PM -0700, Linus Torvalds wrote:

> On Fri, Jul 13, 2012 at 2:02 PM, Dave Jones <[hidden email]> wrote:
> >
> > As long as you don't mind these being added after the fact, I suppose
> > it would be workable.  The reason I say that is sometimes, it even catches *us*
> > by surprise.  We recently found out our virtualisation guys started
> > using sch_htb for example, and we inadvertantly broke it when we moved
> > its module to a 'not always installed' kernel subpackage. (and before that, 9PFS..)
> >
> > People don't tell us anything, but somehow expect things to keep working.
>
> I think even a "educated guess" config file is better than what we have now.
>
> The *two* requirements (and they're really the same theme) I
> personally think we should have for this are
>
>  -  I think every single "select" for these things should come with a
> comment about what it is about and why the distro needs it (to show
> there was some thought involved and not just a blind "took it from the
> distro config")
>
>  - It should be about *minimal* settings. I'd rather have too few
> things and the occasional complaint about "oh, it didn't work because
> it missed XYZ" than have it grow to contain all the options just
> because somebody decided to just add random things until things
> worked.

I'd agree that should be the goal.  It seems like something worth at
least trying to get to.  Even if we don't wind up merging them into the
kernel, it will at least lead to a better documented distro config for
every one that tries it.

josh

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[Jesper Juhl]

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 <[hidden email]>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[David Lang]

On Sat, 14 Jul 2012, Jesper Juhl wrote:

> 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?

this needs to be more like 'make install' where the build system doesn't
have specifics for every distro, but instead refrences a separate file
that's provided in the same place by every distro, ideally separate from
the kernel itself.

David Lang

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[Frank Rowand]

On 07/13/12 14:55, Dave Jones wrote:
> On Fri, Jul 13, 2012 at 11:50:25PM +0200, Paul Bolle wrote:
>
>  > But just removing all the certainly unused macros probably wouldn't have
>  > made a noticeable difference to anyone using those defconfig files
>  > anyway.
>
> My point is that I don't think there's many people actually using them.
> (maybe more on the niche platforms, but x86[64] ? I'm sceptical they're used at all)

I'm one of those people who use default configs.  I build a given kernel version for
many different embedded boards and expect the default config to work for them.  It
makes life much easier.

I also share Linus' pain when building for my host x86 system and try to
remove the cruft from my distro config.

-Frank


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

[Ben Hutchings-3]

On Fri, 2012-07-13 at 13:37 -0700, 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.
[...]
> 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

I like this idea in principle.

[...]

>  - 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
>
> and then depending on the DISTRO config, we'd include one of the
> distro-specific ones with lists of supported distro versions and then
> the random config settings for that version:

You might also want to *un*select some options like
CONFIG_SYSFS_DEPRECATED and CONFIG_SYSFS_DEPRECATED_V2 that need to be
set one way or the other depending on the version of udev.  (I think
it's possible to kluge this with the addition of a hidden negative
config option.)

How about stuff like NET and INET, that every distro will need and yet
is configurable even without EXPERT?

[...]
> Sure, you can copy the config file that came with the distro, but it
> has tons of stuff that really isn't required. Not just in hardware,
> but all the debug choices etc that are really a user choice. And it's
> really hard to figure out - even for somebody like me - what a minimal
> usable kernel is.
[...]

And it's still hard for me as kernel packager: just because an option
was requested and enabled to support some bit of userland, doesn't mean
I know what's using or depending on it now.  (I think Dave Jones made
this point already.)  I'm not usually concerned with *minimal* config.

Ben.

--
Ben Hutchings
The generation of random numbers is too important to be left to chance.
                                                            - Robert Coveyou

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team