On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov <bp@amd64.org> wrote:
>
> Seriously, this helps only in the cases where the stuff the distro
> actually needs is in modules. So, there probably are obscure situations
> where you need to enable stuff which is bool and not M.

Sadly, not obscure at all.

Most of the *drivers* are modules, but most of the "distro config"
options are indeed booleans (or, if tristate, =y).

Even driver-wise, there are some things that are often =y, even though
you generally don't want them. PCMCIA? Not even *laptops* have that
shit any more, but having built-in cardbus support almost certainly
helps in a distro kernel for booting of certain odder cases.

Xen support? Odd partition tables? All the different AGP versions?
Many of us couldn't care less, but again, it makes sense in the actual
distro kernel, even if it does *not* necessarily make sense in a
personalized one.

So doing "make allmodconfig" is certainly a workable thing (modulo the
modules that you need for stuff you hadn't happened to use), but it's
not wonderful.

I also hate having to enable support for modules. A non-modular build
is quicker to build and avoids some security issues. Some drivers
don't work well built-in (they load firmware etc too early), but imho
it's worth doing if you can, and it's something we should make easy
for people to do because of the security side (of course, per-build
randomly generated keys and signed modules with the keys deleted after
the build would be reasonably equivalent from a security standpoint,
but we're not there yet).

Linus

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On Thu, Jul 19, 2012 at 01:02:46PM -0400, Steven Rostedt wrote:
> This is why I created the make-min-config in ktest. It keeps on
> disabling configs to see what the machine needs to boot (and optionally
> run some test), and what configs it can disable. It does not touch the
> multi options though.
>
> It creates two configs. One that has the configs that it can't turn off
> (still enabled with a make allnoconfig, or selected by something that it
> must have), and a config that just has the configs that 'if I disable
> this, the box doesn't boot'.
>
> Here's an example:
>
> For my min-config files with the configs that couldn't be turned off:
>
> $ wc -l config-min*
> 117 config-min
> 139 config-min-net
>
> The config-min will get the box to boot (no network). The -net, adds
> enough to ssh to the box.
>
> $ wc -l config-skip*
> 11 config-skip
> 14 config-skip-net
>
> The above are the configs that ktest found if it disabled, would not
> boot (or ssh).
>
> $ cat config-skip-net
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SATA_AHCI=y
> CONFIG_E1000=y
> CONFIG_QUOTA=y
> CONFIG_ATA=y
> CONFIG_UNIX=y
> CONFIG_INET=y
> CONFIG_DEVTMPFS=y
> CONFIG_EXT4_FS=y
> CONFIG_DEVTMPFS_MOUNT=y
> CONFIG_SERIAL_8250=y
> CONFIG_BLK_DEV_SD=y
> CONFIG_NET=y
> CONFIG_NETDEVICES=y
>
> I can pass the above to a allnoconfig, and the box will boot and allow
> ssh. Note, the reason for the serial config, is that this ktest run uses
> a serial port to see if the box booted. If the serial isn't there, then
> it thinks it failed.

I agree with all this and you've explained this to me live already so
you're preaching to the choir.

But it would be a lot faster/easier if users can select, let's call'em
"profiles" which are not mutually exclusive and can speed up the
configuration process. They can either be distro-specific or generic,
selecting certain features you need.

So configuring your kernel would be like shopping without paying too
much attention to details. Let's look into the head of a person doing a
config like that and read some of her thoughts :

"Hm, ok, this new configurator is cool, a lot faster I gotta say... So,
what do I need, ah, yes, it is an AMD laptop so from vendors I select
AMD, then I probably need ext4, then I'd like to do packet filtering
so I should enable iptables.. Oh, I'd like to do tracing too so let's
enable tracing and trust Steven with the options he's added by default,
then I need ahci, I'd also like to do encrypted partitions so I'll
enable device mapper with crypto... "

So all those things could be selectable from that profiles menu without
having to go through the gazillion of little suboptions and having to
read help (which is sometimes completely helpless) and figure out do I
need it or not.

And this would simplify configuration a lot. IMHO, anyway.

--
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120719173415.GE23393@aftab.osrc.amd.com">http://lists.debian.org/20120719173415.GE23393@aftab.osrc.amd.com

On Thu, Jul 19, 2012 at 01:02:46PM -0400, Steven Rostedt wrote:
> This is why I created the make-min-config in ktest. It keeps on
> disabling configs to see what the machine needs to boot (and optionally
> run some test), and what configs it can disable. It does not touch the
> multi options though.
>
> It creates two configs. One that has the configs that it can't turn off
> (still enabled with a make allnoconfig, or selected by something that it
> must have), and a config that just has the configs that 'if I disable
> this, the box doesn't boot'.
>
> Here's an example:
>
> For my min-config files with the configs that couldn't be turned off:
>
> $ wc -l config-min*
> 117 config-min
> 139 config-min-net
>
> The config-min will get the box to boot (no network). The -net, adds
> enough to ssh to the box.
>
> $ wc -l config-skip*
> 11 config-skip
> 14 config-skip-net
>
> The above are the configs that ktest found if it disabled, would not
> boot (or ssh).
>
> $ cat config-skip-net
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SATA_AHCI=y
> CONFIG_E1000=y
> CONFIG_QUOTA=y
> CONFIG_ATA=y
> CONFIG_UNIX=y
> CONFIG_INET=y
> CONFIG_DEVTMPFS=y
> CONFIG_EXT4_FS=y
> CONFIG_DEVTMPFS_MOUNT=y
> CONFIG_SERIAL_8250=y
> CONFIG_BLK_DEV_SD=y
> CONFIG_NET=y
> CONFIG_NETDEVICES=y
>
> I can pass the above to a allnoconfig, and the box will boot and allow
> ssh. Note, the reason for the serial config, is that this ktest run uses
> a serial port to see if the box booted. If the serial isn't there, then
> it thinks it failed.

I agree with all this and you've explained this to me live already so
you're preaching to the choir.

But it would be a lot faster/easier if users can select, let's call'em
"profiles" which are not mutually exclusive and can speed up the
configuration process. They can either be distro-specific or generic,
selecting certain features you need.

So configuring your kernel would be like shopping without paying too
much attention to details. Let's look into the head of a person doing a
config like that and read some of her thoughts :

"Hm, ok, this new configurator is cool, a lot faster I gotta say... So,
what do I need, ah, yes, it is an AMD laptop so from vendors I select
AMD, then I probably need ext4, then I'd like to do packet filtering
so I should enable iptables.. Oh, I'd like to do tracing too so let's
enable tracing and trust Steven with the options he's added by default,
then I need ahci, I'd also like to do encrypted partitions so I'll
enable device mapper with crypto... "

So all those things could be selectable from that profiles menu without
having to go through the gazillion of little suboptions and having to
read help (which is sometimes completely helpless) and figure out do I
need it or not.

And this would simplify configuration a lot. IMHO, anyway.

--
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On Thu, Jul 19, 2012 at 10:06:44AM -0700, Linus Torvalds wrote:
> On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov <bp@amd64.org> wrote:
> >
> > Seriously, this helps only in the cases where the stuff the distro
> > actually needs is in modules. So, there probably are obscure situations
> > where you need to enable stuff which is bool and not M.
>
> Sadly, not obscure at all.
>
> Most of the *drivers* are modules, but most of the "distro config"
> options are indeed booleans (or, if tristate, =y).
>
> Even driver-wise, there are some things that are often =y, even though
> you generally don't want them.

Tell me about it. I'm always pissed off when someone thinks his stuff is
very important and sets his sacred option to be =y/=m by default so the
wider audience can at least compile-test it while the majority of the
machines don't actually need it.

A more coarse-grained config where most of the stuff is off by default
could take care of that probably.

> PCMCIA? Not even *laptops* have that shit any more, but having
> built-in cardbus support almost certainly helps in a distro kernel for
> booting of certain odder cases.

Yeah, distros need the one-size-fits-all thing so they have to enable
*everything*.

> Xen support? Odd partition tables? All the different AGP versions?
> Many of us couldn't care less, but again, it makes sense in the actual
> distro kernel, even if it does *not* necessarily make sense in a
> personalized one.

Yep.

> So doing "make allmodconfig" is certainly a workable thing (modulo the
> modules that you need for stuff you hadn't happened to use), but it's
> not wonderful.

Oh and I always aim to build distro kernels on a big machine -
allmodconfig build is no fun on a tiny laptop. So would it be better
to have better profiled kernels, obviating the need for an almost full
build? Hell yeah!

> I also hate having to enable support for modules. A non-modular build
> is quicker to build and avoids some security issues. Some drivers
> don't work well built-in (they load firmware etc too early), but imho
> it's worth doing if you can, and it's something we should make easy
> for people to do because of the security side (of course, per-build
> randomly generated keys and signed modules with the keys deleted after
> the build would be reasonably equivalent from a security standpoint,
> but we're not there yet).

Agreed.

So there are some not-so-obscure situations, judging by your examples
above. Ho-humm.

--
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120719175310.GF23393@aftab.osrc.amd.com">http://lists.debian.org/20120719175310.GF23393@aftab.osrc.amd.com

On Thu, Jul 19, 2012 at 10:06:44AM -0700, Linus Torvalds wrote:
> On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov <bp@amd64.org> wrote:
> >
> > Seriously, this helps only in the cases where the stuff the distro
> > actually needs is in modules. So, there probably are obscure situations
> > where you need to enable stuff which is bool and not M.
>
> Sadly, not obscure at all.
>
> Most of the *drivers* are modules, but most of the "distro config"
> options are indeed booleans (or, if tristate, =y).
>
> Even driver-wise, there are some things that are often =y, even though
> you generally don't want them.

Tell me about it. I'm always pissed off when someone thinks his stuff is
very important and sets his sacred option to be =y/=m by default so the
wider audience can at least compile-test it while the majority of the
machines don't actually need it.

A more coarse-grained config where most of the stuff is off by default
could take care of that probably.

> PCMCIA? Not even *laptops* have that shit any more, but having
> built-in cardbus support almost certainly helps in a distro kernel for
> booting of certain odder cases.

Yeah, distros need the one-size-fits-all thing so they have to enable
*everything*.

> Xen support? Odd partition tables? All the different AGP versions?
> Many of us couldn't care less, but again, it makes sense in the actual
> distro kernel, even if it does *not* necessarily make sense in a
> personalized one.

Yep.

> So doing "make allmodconfig" is certainly a workable thing (modulo the
> modules that you need for stuff you hadn't happened to use), but it's
> not wonderful.

Oh and I always aim to build distro kernels on a big machine -
allmodconfig build is no fun on a tiny laptop. So would it be better
to have better profiled kernels, obviating the need for an almost full
build? Hell yeah!

> I also hate having to enable support for modules. A non-modular build
> is quicker to build and avoids some security issues. Some drivers
> don't work well built-in (they load firmware etc too early), but imho
> it's worth doing if you can, and it's something we should make easy
> for people to do because of the security side (of course, per-build
> randomly generated keys and signed modules with the keys deleted after
> the build would be reasonably equivalent from a security standpoint,
> but we're not there yet).

Agreed.

So there are some not-so-obscure situations, judging by your examples
above. Ho-humm.

--
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On Thu, 2012-07-19 at 19:34 +0200, Borislav Petkov wrote:

> > I can pass the above to a allnoconfig, and the box will boot and allow
> > ssh. Note, the reason for the serial config, is that this ktest run uses
> > a serial port to see if the box booted. If the serial isn't there, then
> > it thinks it failed.
>
> I agree with all this and you've explained this to me live already so
> you're preaching to the choir.

Yes, I know you know this already, as we discussed it in a pub over a
beer (choir practice). But this is a public forum on LKML (the church),
where I now have an audience of heathens. Convert! Convert! You are all
sinners!

>
> But it would be a lot faster/easier if users can select, let's call'em
> "profiles" which are not mutually exclusive and can speed up the
> configuration process. They can either be distro-specific or generic,
> selecting certain features you need.
>
> So configuring your kernel would be like shopping without paying too
> much attention to details. Let's look into the head of a person doing a
> config like that and read some of her thoughts :
>
> "Hm, ok, this new configurator is cool, a lot faster I gotta say... So,
> what do I need, ah, yes, it is an AMD laptop so from vendors I select
> AMD, then I probably need ext4, then I'd like to do packet filtering
> so I should enable iptables.. Oh, I'd like to do tracing too so let's
> enable tracing and trust Steven with the options he's added by default,
> then I need ahci, I'd also like to do encrypted partitions so I'll
> enable device mapper with crypto... "
>
> So all those things could be selectable from that profiles menu without
> having to go through the gazillion of little suboptions and having to
> read help (which is sometimes completely helpless) and figure out do I
> need it or not.
>
> And this would simplify configuration a lot. IMHO, anyway.
>

I totally agree with this. It would be nice to have a profile list where
you can pick and chose what you have installed:

network
nfs
ext3
serial
xen
kvm
etc etc

Where you can pick and choose what general features you want and it
selects all the core infrastructure to get those features usable. It
wouldn't select the device modules needed, you will still need to select
what hardware you have. But it gets most of the work done for you.

But this still doesn't solve Linus's initial request. That would be a
single option that makes your distro boot, and work well. Again, that
option wont have the drivers needed, but it will enable all the core
infrastructure that you need.

Going with my /usr/share/Linux/Kconfig, this could use the profile
options as well. And just select those that are required. But then
again, Linus did want a minimum selection of stuff.

Side note (again), IIRC, "select" has a bug. If you have Config X
selecting config Y but Y depends on Z, if you enable X, it will enable Y
without enabling Z. I think there were some patches to address this, but
I don't remember.

-- Steve



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1342720646.12353.67.camel@gandalf.stny.rr.com">htt p://lists.debian.org/1342720646.12353.67.camel@gandalf.stny.rr.com

On Thu, Jul 19, 2012 at 01:57:26PM -0400, Steven Rostedt wrote:
> Yes, I know you know this already, as we discussed it in a pub over a
> beer (choir practice). But this is a public forum on LKML (the church),
> where I now have an audience of heathens. Convert! Convert! You are all
> sinners!

Ah, gotcha.

[ … ]

> But this still doesn't solve Linus's initial request. That would be a
> single option that makes your distro boot, and work well. Again, that
> option wont have the drivers needed, but it will enable all the core
> infrastructure that you need.

Oh I'm being additive here. You'll have feature profiles for the stuff
we talk above and distro profiles which solve Linus' issue. Basically
one coarse-grained config option will either select a feature which has
a lot of small subfeatures of which some are sane and want to be enabled
by default when selecting the topfeature.

Or a distro-specific feature which could itself select other
topfeatures.

I haven't tried this in reality to actually be able to say that a
tree-like configure approach would actually make sense and work. It
sounds like a nice idea though, especially having the hierarchical
structure.

--
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120719180914.GG23393@aftab.osrc.amd.com">http://lists.debian.org/20120719180914.GG23393@aftab.osrc.amd.com

On Thu, Jul 19, 2012 at 01:57:26PM -0400, Steven Rostedt wrote:
> Yes, I know you know this already, as we discussed it in a pub over a
> beer (choir practice). But this is a public forum on LKML (the church),
> where I now have an audience of heathens. Convert! Convert! You are all
> sinners!

Ah, gotcha.

[ … ]

> But this still doesn't solve Linus's initial request. That would be a
> single option that makes your distro boot, and work well. Again, that
> option wont have the drivers needed, but it will enable all the core
> infrastructure that you need.

Oh I'm being additive here. You'll have feature profiles for the stuff
we talk above and distro profiles which solve Linus' issue. Basically
one coarse-grained config option will either select a feature which has
a lot of small subfeatures of which some are sane and want to be enabled
by default when selecting the topfeature.

Or a distro-specific feature which could itself select other
topfeatures.

I haven't tried this in reality to actually be able to say that a
tree-like configure approach would actually make sense and work. It
sounds like a nice idea though, especially having the hierarchical
structure.

--
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On Thu, Jul 19, 2012 at 07:53:10PM +0200, Borislav Petkov wrote:
> On Thu, Jul 19, 2012 at 10:06:44AM -0700, Linus Torvalds wrote:
> > On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov <bp@amd64.org> wrote:
> > >
> > > Seriously, this helps only in the cases where the stuff the distro
> > > actually needs is in modules. So, there probably are obscure situations
> > > where you need to enable stuff which is bool and not M.
> >
> > Sadly, not obscure at all.
> >
> > Most of the *drivers* are modules, but most of the "distro config"
> > options are indeed booleans (or, if tristate, =y).
> >
> > Even driver-wise, there are some things that are often =y, even though
> > you generally don't want them.
>
> Tell me about it. I'm always pissed off when someone thinks his stuff is
> very important and sets his sacred option to be =y/=m by default so the
> wider audience can at least compile-test it while the majority of the
> machines don't actually need it.
>
> A more coarse-grained config where most of the stuff is off by default
> could take care of that probably.
>
> > PCMCIA? Not even *laptops* have that shit any more, but having
> > built-in cardbus support almost certainly helps in a distro kernel for
> > booting of certain odder cases.
>
> Yeah, distros need the one-size-fits-all thing so they have to enable
> *everything*.
>
> > Xen support? Odd partition tables? All the different AGP versions?
> > Many of us couldn't care less, but again, it makes sense in the actual
> > distro kernel, even if it does *not* necessarily make sense in a
> > personalized one.
>
> Yep.

I proposed something that would solve some of this - but not during
compile time but rather during boot-time
[http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/000099.html]
(interestingly enough hpa was first to propose it 10 years ago :-)

The goal is turn built-in components in well, unloadable components.
That way you won't have at least that much stuff laying around not being
used. Not the full silver bullet, but at least it gets some of this
stuff out of the way and you don't have to worry about the extra
stuff that was built-in.


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120719184249.GA6696@phenom.dumpdata.com">http://lists.debian.org/20120719184249.GA6696@phenom.dumpdata.com

On Thu, Jul 19, 2012 at 07:53:10PM +0200, Borislav Petkov wrote:
> On Thu, Jul 19, 2012 at 10:06:44AM -0700, Linus Torvalds wrote:
> > On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov <bp@amd64.org> wrote:
> > >
> > > Seriously, this helps only in the cases where the stuff the distro
> > > actually needs is in modules. So, there probably are obscure situations
> > > where you need to enable stuff which is bool and not M.
> >
> > Sadly, not obscure at all.
> >
> > Most of the *drivers* are modules, but most of the "distro config"
> > options are indeed booleans (or, if tristate, =y).
> >
> > Even driver-wise, there are some things that are often =y, even though
> > you generally don't want them.
>
> Tell me about it. I'm always pissed off when someone thinks his stuff is
> very important and sets his sacred option to be =y/=m by default so the
> wider audience can at least compile-test it while the majority of the
> machines don't actually need it.
>
> A more coarse-grained config where most of the stuff is off by default
> could take care of that probably.
>
> > PCMCIA? Not even *laptops* have that shit any more, but having
> > built-in cardbus support almost certainly helps in a distro kernel for
> > booting of certain odder cases.
>
> Yeah, distros need the one-size-fits-all thing so they have to enable
> *everything*.
>
> > Xen support? Odd partition tables? All the different AGP versions?
> > Many of us couldn't care less, but again, it makes sense in the actual
> > distro kernel, even if it does *not* necessarily make sense in a
> > personalized one.
>
> Yep.

I proposed something that would solve some of this - but not during
compile time but rather during boot-time
[http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/000099.html]
(interestingly enough hpa was first to propose it 10 years ago :-)

The goal is turn built-in components in well, unloadable components.
That way you won't have at least that much stuff laying around not being
used. Not the full silver bullet, but at least it gets some of this
stuff out of the way and you don't have to worry about the extra
stuff that was built-in.

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team