Hallo Stefan, Le Monday 06 May 2013 à 16:21 +0200, Stefan Seyfried a écrit :

Am 06.05.2013 16:05, schrieb Jean Delvare:

...

This is a rather long list, 41 drivers. While I am certain that there are false positives, either common hardware which I just happen to not have on any of my machines (most of pci and acpi), or drivers we may need very early (pci/serial?), or pseudo-drivers which are in fact part of their subsystem core (i2c/dummy, pci_express/aer, pcie_pme), it still seems to me that many of these should be modularized, to make our kernel smaller in size and faster to boot.

IIRC Greg once built them in in order to boot faster. Module loading is (was?) dog slow compared to initializing built-in drivers.

Yes, I remember that, and have no problem with it. But this only applies to devices present on a significant portion of all user systems.

...

More than half of the drivers are HID drivers.

HID drivers (and USB) are good to have in case mkinitrd screws up, so that you can actually access the console you got with init = /bin/bash :-)

Most of the HID drivers I listed are for joysticks, game controllers and remote controls. I doubt you'll be able to debug your initrd with these... And even if this was remotely possible, I'd rather ask the user to connect a regular keyboard in the rare event the initrd goes wrong, rather than include 25 arbitrary drivers in every kernel for a total of 363 kB (x86-64.) -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Hi Stefan, Le Monday 06 May 2013 à 21:17 +0200, Stefan Seyfried a écrit :

Am 06.05.2013 16:34, schrieb Jean Delvare:

...

And even if this was remotely possible, I'd rather ask the user to connect a regular keyboard in the rare event the initrd goes wrong,

None of the machines I'm concerned about has even the possibility of connecting a regular keyboard. Think blade-servers - they often only have an usb keyboard (but maybe if the usb hostcontroller drivers would also be missing, the BIOS emulation would work).

Regular USB keyboards are OK, they don't need any of the fancy drivers I listed.

Long story short: I vote for keeping uhci, ohci and usbhid in the kernel, not only in -desktop flavour :-)

Of course! I never meant to remove these standard drivers.

...

rather than include 25 arbitrary drivers in every kernel for a total of 363 kB (x86-64.)

Oh - and we could include pciehp, since autoloading obviously does not work, I always have to remember to load it, most of the time after wondering for quite some time what today's problem with my USB3 ExpressCard is... :-)

Interesting point, although this is a different issue from the ones I am tracking right now. But pciehp should be no different from all other PCI hotplug drivers, is it? There are 7 of these, for a total of about 250 kB on x86-64. I agree that you shouldn't have to manually load a kernel driver, but I don't know if the proper fix is to build that driver into the kernel, or to load it unconditionally at boot time, or conditionally depending on the machine you're on... Some investigation is needed, for which I have no time left at the moment, I'm afraid. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Hi Jiri, Le Wednesday 15 May 2013 à 12:09 +0200, Jiri Kosina a écrit :

On Mon, 6 May 2013, Jean Delvare wrote:

...

Most of the HID drivers I listed are for joysticks, game controllers and remote controls. I doubt you'll be able to debug your initrd with these... And even if this was remotely possible, I'd rather ask the user to connect a regular keyboard in the rare event the initrd goes wrong, rather than include 25 arbitrary drivers in every kernel for a total of 363 kB (x86-64.)

Yeah, as a maintainer of that code, I fully agree, those drivers you listed have no business being built in.

OK, I modularized all HID device drivers which could be. Some couldn't due to a weird dependency on !EXPERT. I'll bring this up upstream. As things are right now, we would need to switch CONFIG_HID back from y to m if we want to be able to modularize the remaining 12 HID drivers. I think this makes sense, but what do you think? After all, not all systems need the hid core driver - my workstation doesn't. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Am 30.05.2013 05:57, schrieb Andrey Borzenkov:

Does mkinitrd support probing for and adding correct HID drivers to initrd? If not, you may be left without keyboard during early boot.

The way to go is probably to add the keyboard HID drivers unconditionally to initrd, unless they are blacklisted. => for the normal installation, nothing changes, and the experts who really do not need them and want to save the wasted memory can blacklist them. -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Hi Jeff, Stefan, Andrey, Jiri and Michal, Le Thursday 30 May 2013 à 00:22 -0400, Jeff Mahoney a écrit :

On 5/30/13 12:18 AM, Stefan Seyfried wrote:

...

Am 30.05.2013 05:57, schrieb Andrey Borzenkov:

...

Does mkinitrd support probing for and adding correct HID drivers to initrd? If not, you may be left without keyboard during early boot.

The only reference to HID I could find in mkinitrd is in /lib/mkinitrd/script/boot-usb.sh, and the only device-specific driver listed is hid-logitech-dj. But everything is commented out so I don't know if it really has any effect in practice (sorry I don't know much about mkinitrd.) Also note that all remaining built-in drivers aren't for keyboards. HID_A4TECH is for a mice, HID_CHICONY is for a keyboard extension (aimed at gamers as I understand it), HID_CYPRESS is for a mouse / barcode reader device, and HID_KENSINGTON is for a trackball. Most Logitech drivers aren't for keyboards either. On the other hand, some of the drivers I modularized yesterday are for keyboards (HID_ORTEK, HID_SAMSUNG.) I can make them built-in again if anyone thinks modularizing them was a bad idea. One thing I don't know is how these non HID-compliant devices are handled if only the generic HID driver is present. Do they work with limited capabilities, or don't they work at all? Jiri? If they don't work at all then I think the best solution would be to teach mkinitrd about these drivers so that they can be added conditionally. If it's only a matter of adding them to /lib/mkinitrd/script/boot-usb.sh it's easy enough. Michal?

...

The way to go is probably to add the keyboard HID drivers unconditionally to initrd, unless they are blacklisted.

=> for the normal installation, nothing changes, and the experts who really do not need them and want to save the wasted memory can blacklist them.

Anything that should be unconditionally added to the initrd should be unconditionally added to the kernel. I don't think the advantage to experts is worth the complication. If a driver loaded automatically has a bug in it - it's severe. If an expert can't afford the driver being loaded, their requirements are strict enough that they should build their own kernels.

I completely agree. My goal is to make the kernel boot faster. If that also makes the kernel smaller, this is great, but that's only a side effect. There is no point in modularizing anything that we would forcibly load on all systems by default anyway. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Hi Michal, Sorry for the late reply. Le Thursday 30 May 2013 à 12:12 +0200, Michal Marek a écrit :

On 30.5.2013 11:58, Jean Delvare wrote:

...

Hi Jeff, Stefan, Andrey, Jiri and Michal,

The only reference to HID I could find in mkinitrd is in /lib/mkinitrd/script/boot-usb.sh, and the only device-specific driver listed is hid-logitech-dj. But everything is commented out so I don't know if it really has any effect in practice (sorry I don't know much about mkinitrd.)

This is a special comment that tells mkinitrd which modules to add to the initrd. If you are modularizing more keyboard drivers, please let me know which ones, so that I can add them to the list. I you know how to programmatically tell if a given hid driver drives keyboards, that would be even better.

Unfortunately I couldn't come up with any programmatic method to obtain the list. Jiri?

...

(...) If it's only a matter of adding them to /lib/mkinitrd/script/boot-usb.sh it's easy enough. Michal?

Yes, just send me the list.

The following list is the result of manual inspection: hid-holtek-kbd hid-lenovo-tpkbd hid-logitech-dj hid-ortek hid-roccat-arvo hid-roccat-isku hid-samsung As a side question: will mkinitrd break or complain if the list contains some modules which end being included in the kernel directly? If not, you could add the following too, in anticipation of them being modularized in the future: hid-apple hid-belkin hid-cherry hid-ezkey hid-microsoft Thanks, -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Le Wednesday 05 June 2013 à 21:32 +0200, Michal Marek a écrit :

Dne 5.6.2013 20:45, Jean Delvare napsal(a):

...

The following list is the result of manual inspection:

hid-holtek-kbd hid-lenovo-tpkbd hid-logitech-dj hid-ortek hid-roccat-arvo hid-roccat-isku hid-samsung

As a side question: will mkinitrd break or complain if the list contains some modules which end being included in the kernel directly?

No.

...

hid-apple hid-belkin hid-cherry hid-ezkey hid-microsoft

I added them all.

Perfect, thanks Michal! -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Am 07.05.2013 08:46, schrieb Michal Kubeček:

No autofs and af_packet is loaded but not used and can be unloaded.

I think you need af_packet e.g. for dhcp. -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On 5/7/13 5:59 AM, Michal Kubeček wrote:

On Tuesday 07 of May 2013 11:51EN, Stefan Seyfried wrote:

...

Am 07.05.2013 08:46, schrieb Michal Kubeček:

...

No autofs and af_packet is loaded but not used and can be unloaded.

I think you need af_packet e.g. for dhcp.

Well, not every system needs DHCP. Most of mine don't, for example.

Most everyone else's do. -Jeff -- Jeff Mahoney SUSE Labs

At Tue, 07 May 2013 15:08:28 +0200, Michal Kubeček wrote:

On Tuesday 07 of May 2013 09:04EN, Jeff Mahoney wrote:

...

On 5/7/13 5:59 AM, Michal Kubeček wrote:

...

On Tuesday 07 of May 2013 11:51EN, Stefan Seyfried wrote:

...

Am 07.05.2013 08:46, schrieb Michal Kubeček:

...

No autofs and af_packet is loaded but not used and can be unloaded.

I think you need af_packet e.g. for dhcp.

Well, not every system needs DHCP. Most of mine don't, for example.

Most everyone else's do.

Perhaps. But my original response was to a mail claiming that these two modules are "always unconditionally modprobed".

I guess you are one of few no-systemd-on-12.3 users? :) But this is getting OT... The original question was about the built-in drivers. These are impossible to avoid to load unless you rebuild the kernel by yourself. Meanwhile, the modules that always loaded are the problem of the user-space stuff. So, we shouldn't mix them up. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

At Tue, 07 May 2013 15:34:55 +0200, Oliver Neukum wrote:

On Tuesday 07 May 2013 15:28:03 Takashi Iwai wrote:

...

The original question was about the built-in drivers. These are impossible to avoid to load unless you rebuild the kernel by yourself. Meanwhile, the modules that always loaded are the problem of the user-space stuff. So, we shouldn't mix them up.

But if we always load them we waste about half a page per module on average, which we could conserve if we compile them in.

You can still avoid to load such modules, too. "Always load" is a matter of systemd or whatever setup. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Le Tuesday 07 May 2013 à 09:42 -0400, Jeff Mahoney a écrit :

Anything that doesn't improve boot speed or isn't required for interacting with the initrd should be a module.

That was my goal exactly, good to see we're on the same track :) I'll go on with the clean-ups thanks for the feedback provided by many. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

At Wed, 15 May 2013 13:39:48 +0200, Petr Tesarik wrote:

[1 ] On Tue, 07 May 2013 09:42:03 -0400 Jeff Mahoney wrote:

...

On 5/7/13 9:34 AM, Oliver Neukum wrote:

...

On Tuesday 07 May 2013 15:28:03 Takashi Iwai wrote:

...

The original question was about the built-in drivers. These are impossible to avoid to load unless you rebuild the kernel by yourself. Meanwhile, the modules that always loaded are the problem of the user-space stuff. So, we shouldn't mix them up.

But if we always load them we waste about half a page per module on average, which we could conserve if we compile them in.

[...] The concern over wasting sub-page sized chunks of module memory is overblown. In the days where 4 MB RAM was the norm, sure, there's an argument to be made. Now, when people buy systems off the shelves where 4 GB is a "small" system, it's much less of a concern. Now that several tens of kB is caching for like 10 more inodes or something.

Hi Jeff,

there's one use case of the kernel that you haven't considered - using it a secondary kernel for kdump. Now, I still think that a few extra pages is not an issue compared to dozens of megabytes that you need at a minimum for the crash kernel (and hundreds of megabytes you need on some machines), but keeping the kernel small is still an important target.

It's other way round. For kdump, you'll likely save more memory by moving things out of built-in kernel, as kdump initrd doesn't have to load all modules. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On 5/15/13 9:53 AM, Petr Tesarik wrote:

On Wed, 15 May 2013 14:17:39 +0200 Takashi Iwai wrote:

...

At Wed, 15 May 2013 13:39:48 +0200, Petr Tesarik wrote:

...

[1 ] On Tue, 07 May 2013 09:42:03 -0400 Jeff Mahoney wrote:

...

On 5/7/13 9:34 AM, Oliver Neukum wrote:

...

On Tuesday 07 May 2013 15:28:03 Takashi Iwai wrote:

...

The original question was about the built-in drivers. These are impossible to avoid to load unless you rebuild the kernel by yourself. Meanwhile, the modules that always loaded are the problem of the user-space stuff. So, we shouldn't mix them up.

But if we always load them we waste about half a page per module on average, which we could conserve if we compile them in.

[...] The concern over wasting sub-page sized chunks of module memory is overblown. In the days where 4 MB RAM was the norm, sure, there's an argument to be made. Now, when people buy systems off the shelves where 4 GB is a "small" system, it's much less of a concern. Now that several tens of kB is caching for like 10 more inodes or something.

Hi Jeff,

there's one use case of the kernel that you haven't considered - using it a secondary kernel for kdump. Now, I still think that a few extra pages is not an issue compared to dozens of megabytes that you need at a minimum for the crash kernel (and hundreds of megabytes you need on some machines), but keeping the kernel small is still an important target.

It's other way round. For kdump, you'll likely save more memory by moving things out of built-in kernel, as kdump initrd doesn't have to load all modules.

I know. And that's why I appreciate Jean's effort. But Jeff's mail sounded like he thinks that gigabytes of RAM are always available to the kernel on any modern hardware. They aren't.

I can see how you'd take that away from my comment. I also mentioned I was only talking about a few tens of kB. It's not worth trying to save that while wasting hundreds building in modules that aren't required everywhere. -Jeff -- Jeff Mahoney SUSE Labs

Michal Kubeček wrote:

On Tuesday 07 of May 2013 11:51EN, Stefan Seyfried wrote:

...

Am 07.05.2013 08:46, schrieb Michal Kube�ek:

...

No autofs and af_packet is loaded but not used and can be unloaded. I think you need af_packet e.g. for dhcp.

Well, not every system needs DHCP. Most of mine don't, for example.

How about unix-sockets? I think AF_packet supplies the AF_UNIX address family which is the basis of all local sockets (any networking that doesn't go out on the wire but through a file-system socket), so Samba, nscd, DNS, acpid, autofs, device-manger (raid/LVM et al) logging, rpc (nfs et al), dbus... virtually any every local service. It shouldn't be a loadable module, it should be built-in, your system won't function without it, vs. these: cherry, dragonrise, gyration, smartjoyplus, thrustmaster... Are you sure those are for game controllers? Some sound like sex toys.. ;-/ Why doesn't suse support the equivalent of "dracut" but one for building a minimal kernel for your HW? Those users that would go through the bother of creating a cut-down initrd, would likely be at least as interested in a similarly customized kernel... -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

El 13/05/13 07:07, Jean Delvare escribió:

Hi Linda,

Le Wednesday 08 May 2013 à 22:13 -0700, Linda Walsh a écrit :

...

cherry, dragonrise, gyration, smartjoyplus, thrustmaster...

Are you sure those are for game controllers? Some sound like sex toys.. ;-/

Oh well, people are allowed to use their hardware the way they like ;-) but that's none of my business. I only care about their drivers being built-in when I think they should not be.

...

Why doesn't suse support the equivalent of "dracut" but one for building a minimal kernel for your HW? Those users that would go through the bother of creating a cut-down initrd, would likely be at least as interested in a similarly customized kernel...

Presumably because this would require more time from us than is worth. The kernel is evolving very fast and any tool aiming at making configuration easier for a wider audience would require continuous updates.

Dracut is supported and coolo wants to drop suse mkinitrd as soon as possible. thing that I agree with, btw. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Tue, May 07, 2013 at 09:52:58AM -0400, Jeff Mahoney wrote:

On 5/6/13 10:05 AM, Jean Delvare wrote:

...

acpi/drivers/hpet

A ton of systems have this one.

Yes, but this driver (drivers/char/hpet) is for the character device that allows userspace to access the HPET hardware. Nothing to do with any timekeeping, rarely used. _Except_ for IA64, where this driver also implements the HPET clocksource. -- Jiri Bohac SUSE Labs, SUSE CZ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org