[opensuse-kernel] Built-in kernel drivers
Hi all, I recently noticed that driver ucb1400_gpio was built into all openSUSE kernels while most systems did not need it. Now that I fixed this specific issue, I decided to check if there were other drivers like that. I used the following script to test my running systems: #!/bin/sh find /sys/bus -path "*/drivers/*/uevent" | sed -e 's/\/sys\/bus\/\(.*\)\/uevent$/\1/' | sort > /tmp/drivers find /sys/bus -type l -path "*/drivers/*" | sed -e 's/\/sys\/bus\/\(.*\)\/[^/]*$/\1/' | sort -u > /tmp/drivers_with_devices diff -u /tmp/drivers_with_devices /tmp/drivers | grep '^+[^+]' | cut -c 2- OK, this is a somewhat crude heuristic but it seems to work. I ran this script on 3 different machines running openSUSE 12.2 or 12.3, and took the common results. This led me to the following driver list: acpi/drivers/ec acpi/drivers/hardware_error_device acpi/drivers/hpet hid/drivers/a4tech hid/drivers/belkin hid/drivers/cherry hid/drivers/chicony hid/drivers/cypress hid/drivers/dragonrise hid/drivers/ezkey hid/drivers/greenasia hid/drivers/gyration hid/drivers/kensington hid/drivers/kye hid/drivers/logitech hid/drivers/microsoft hid/drivers/monterey hid/drivers/ortek hid/drivers/pantherlord hid/drivers/petalynx hid/drivers/samsung hid/drivers/smartjoyplus hid/drivers/sony hid/drivers/sunplus hid/drivers/thrustmaster hid/drivers/topseed hid/drivers/twinhan hid/drivers/zeroplus i2c/drivers/dummy mdio_bus/drivers/Generic PHY pci/drivers/agpgart-sis pci/drivers/agpgart-via pci/drivers/ioapic pci/drivers/ohci_hcd pci/drivers/pci-stub pci/drivers/serial pci/drivers/tsi721 pci_express/drivers/aer pci_express/drivers/pcie_pme platform/drivers/dsa platform/drivers/ucb1400_gpio 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. More than half of the drivers are HID drivers. They are only built-in in 4 kernel flavors: i386/desktop, x86_64/desktop, ppc/default and ppc/vanilla. Jeff, Jiri, is this on purpose? If not, can I change all these to modular? Then we have mdio_bus/Generic PHY (what a driver name is that? <sigh>), pci/tsi721 and platform/dsa left. mdio_bus/Generic PHY is part of PHYLIB, I think we could build that as a module? It was accidentally made a bool in kernel v3.2-rc1 but was reverted to tristate in v3.2-rc5. Jeff, you made it build-in in commit 455827126, no objection to me making it a module again? pci/tsi721 is part of RapidIO. None of RapidIO support being built as modules. Which is a shame really, because I suspect most users don't need that and it isn't small - 165 kB on x86-64. This needs to be discussed with upstream. And finally platform/dsa is already dealt with in Factory. By me, even :) -- 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 Jean, 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.
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 :-)
They are only built-in in 4 kernel flavors: i386/desktop, x86_64/desktop, ppc/default and ppc/vanilla. Jeff, Jiri, is this on purpose? If not, can I change all these to modular? -- 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
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 Jean, Am 06.05.2013 16:34, schrieb Jean Delvare:
Le Monday 06 May 2013 à 16:21 +0200, Stefan Seyfried a écrit :
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.
Is smolt still alive? maybe we can gather which hardware is present on a significant portion of all user system :-)
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...
Ok, that's a fair argument.
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). Long story short: I vote for keeping uhci, ohci and usbhid in the kernel, not only in -desktop flavour :-)
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... :-) -- 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 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
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. Thanks for bringing this up, -- Jiri Kosina SUSE Labs -- 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
В Wed, 29 May 2013 20:54:53 +0200 Jean Delvare <jdelvare@suse.de> пишет:
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.
Does mkinitrd support probing for and adding correct HID drivers to initrd? If not, you may be left without keyboard during early boot. -- 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
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 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. -Jeff -- Jeff Mahoney SUSE Labs
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
On 30.5.2013 11:58, Jean Delvare wrote:
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.)
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.
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.
They must be always there, not all machines have a keyboard permanently attached.
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. Michal -- 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
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. Michal -- 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
On Wednesday 29 May 2013 20:54:53 Jean Delvare wrote:
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.
IMHO we should go for the very common case, not the theoretical optimum. Regards Oliver -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
El 06/05/13 10:05, Jean Delvare escribió:
This is a rather long list, 41 drivers.
Funny that this list does not include modules that are always unconditionally modprobed such as autofs and af_packet...
pci/tsi721 is part of RapidIO. None of RapidIO support being built as modules. Which is a shame really, because I suspect most users don't need that and it isn't small - 165 kB on x86-64. This needs to be discussed with upstream.
Better question is are there at least x86 desktop systems with rapidIO ? you could just disable it entirely at least on kernel-desktop. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Monday 06 of May 2013 15:25EN, Cristian Rodríguez wrote:
Funny that this list does not include modules that are always unconditionally modprobed such as autofs and af_packet...
On the machine I'm sending this from (with 12.3): alaris:~ # lsmod | egrep 'autofs|af_packet' af_packet 39587 0 No autofs and af_packet is loaded but not used and can be unloaded. Michal Kubeček -- 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 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. Michal Kubeček -- 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
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". Michal Kubeček -- 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: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
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. Regards Oliver -- 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
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.
"Always load" in this case is a userspace policy decision that can change without much input from or notification to the kernel teams. And that's _fine_. We don't need to be informed of things like that in order to build a kernel that will work well in the majority of situations. 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. Anything that doesn't improve boot speed or isn't required for interacting with the initrd should be a module. As far as things that can't be modules, I agree with Jean that we should figure out how common those devices are and just compile the the miswritten driver out. -Jeff -- Jeff Mahoney SUSE Labs
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
On Tue, 07 May 2013 09:42:03 -0400 Jeff Mahoney <jeffm@suse.com> 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. Unless you want to add back the kdump kernel flavour, that is. Petr T.
At Wed, 15 May 2013 13:39:48 +0200, Petr Tesarik wrote:
[1 <text/plain; US-ASCII (quoted-printable)>] On Tue, 07 May 2013 09:42:03 -0400 Jeff Mahoney <jeffm@suse.com> 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 Wed, 15 May 2013 14:17:39 +0200 Takashi Iwai <tiwai@suse.de> wrote:
At Wed, 15 May 2013 13:39:48 +0200, Petr Tesarik wrote:
[1 <text/plain; US-ASCII (quoted-printable)>] On Tue, 07 May 2013 09:42:03 -0400 Jeff Mahoney <jeffm@suse.com> 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. Petr T. -- 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 <tiwai@suse.de> wrote:
At Wed, 15 May 2013 13:39:48 +0200, Petr Tesarik wrote:
[1 <text/plain; US-ASCII (quoted-printable)>] On Tue, 07 May 2013 09:42:03 -0400 Jeff Mahoney <jeffm@suse.com> 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
On 05/07/2013 09:08 AM, Michal Kubeček wrote:
Perhaps. But my original response was to a mail claiming that these two modules are "always unconditionally modprobed".
There are unconditionally modprobed modules, autofs4 is one of them, as systemd _requires_ autofs for .automount units. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
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
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. The initrd is already tailored for every system. For the kernel itself, the decision of built-in vs. modular is made based on imperatives and subsystem popularity, with the goal of minimizing the boot time on average. We have made some progress in this area over the past few years, even though more is needed, as underlined by the post of mine which started this discussion. For other decisions, we go for different kernel flavors when we really have to (but even this we try to avoid.) If users want more, we already provide everything they need to build their own kernel. And I think we even have a tutorial on how to do so. It's not that hard, really, I do it daily ;-) I think anyone who really want to squeeze every drop out of their machine, can go through this, they shouldn't need any additional tool. -- Jean Delvare Suse L3 -- 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
Hi Cristian, Le Monday 06 May 2013 à 15:25 -0400, Cristian Rodríguez a écrit :
El 06/05/13 10:05, Jean Delvare escribió:
This is a rather long list, 41 drivers.
Funny that this list does not include modules that are always unconditionally modprobed such as autofs and af_packet...
My list is a driver list, not a module list. autofs and af_packet aren't device driver modules, that's why they don't show up. One thing at a time... There may be more cleanups possible, but I'd rather start with a subset of reasonable size and complexity, otherwise I will never do anything.
pci/tsi721 is part of RapidIO. None of RapidIO support being built as modules. Which is a shame really, because I suspect most users don't need that and it isn't small - 165 kB on x86-64. This needs to be discussed with upstream.
Better question is are there at least x86 desktop systems with rapidIO ? you could just disable it entirely at least on kernel-desktop.
This is an excellent question, which I will include in my request to upstream. 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
On 5/6/13 10:05 AM, Jean Delvare wrote:
Hi all,
I recently noticed that driver ucb1400_gpio was built into all openSUSE kernels while most systems did not need it. Now that I fixed this specific issue, I decided to check if there were other drivers like that. I used the following script to test my running systems:
#!/bin/sh
find /sys/bus -path "*/drivers/*/uevent" | sed -e 's/\/sys\/bus\/\(.*\)\/uevent$/\1/' | sort > /tmp/drivers find /sys/bus -type l -path "*/drivers/*" | sed -e 's/\/sys\/bus\/\(.*\)\/[^/]*$/\1/' | sort -u > /tmp/drivers_with_devices diff -u /tmp/drivers_with_devices /tmp/drivers | grep '^+[^+]' | cut -c 2-
OK, this is a somewhat crude heuristic but it seems to work. I ran this script on 3 different machines running openSUSE 12.2 or 12.3, and took the common results. This led me to the following driver list:
acpi/drivers/ec acpi/drivers/hardware_error_device acpi/drivers/hpet
A ton of systems have this one.
hid/drivers/a4tech hid/drivers/belkin hid/drivers/cherry hid/drivers/chicony hid/drivers/cypress hid/drivers/dragonrise hid/drivers/ezkey hid/drivers/greenasia hid/drivers/gyration hid/drivers/kensington hid/drivers/kye hid/drivers/logitech hid/drivers/microsoft hid/drivers/monterey hid/drivers/ortek hid/drivers/pantherlord hid/drivers/petalynx hid/drivers/samsung hid/drivers/smartjoyplus hid/drivers/sony hid/drivers/sunplus hid/drivers/thrustmaster hid/drivers/topseed hid/drivers/twinhan hid/drivers/zeroplus i2c/drivers/dummy mdio_bus/drivers/Generic PHY pci/drivers/agpgart-sis pci/drivers/agpgart-via pci/drivers/ioapic
I think this is used all over the place.
pci/drivers/ohci_hcd
Likewise.
pci/drivers/pci-stub pci/drivers/serial
Not sure about this one. I think most built-in serial will use the serial8250 driver.
pci/drivers/tsi721 pci_express/drivers/aer pci_express/drivers/pcie_pme platform/drivers/dsa platform/drivers/ucb1400_gpio
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.
More than half of the drivers are HID drivers. They are only built-in in 4 kernel flavors: i386/desktop, x86_64/desktop, ppc/default and ppc/vanilla. Jeff, Jiri, is this on purpose? If not, can I change all these to modular?
No. Feel free to change non-keyboard drivers to modules, but keyboard drivers should be builtins.
Then we have mdio_bus/Generic PHY (what a driver name is that? <sigh>), pci/tsi721 and platform/dsa left.
mdio_bus/Generic PHY is part of PHYLIB, I think we could build that as a module? It was accidentally made a bool in kernel v3.2-rc1 but was reverted to tristate in v3.2-rc5. Jeff, you made it build-in in commit 455827126, no objection to me making it a module again?
No objection. I suspect something changed in the Kconfig there.
pci/tsi721 is part of RapidIO. None of RapidIO support being built as modules. Which is a shame really, because I suspect most users don't need that and it isn't small - 165 kB on x86-64. This needs to be discussed with upstream.
And finally platform/dsa is already dealt with in Factory. By me, even :)
Thanks for looking into this. Some of the builtins aren't on purpose, but are relics of old Kconfigs that only offered bools. Others were probably added as part of the boot speedup attempt years ago. -Jeff -- Jeff Mahoney SUSE Labs
On 07.05.13 at 15:52, Jeff Mahoney <jeffm@suse.com> wrote: On 5/6/13 10:05 AM, Jean Delvare wrote: pci/drivers/ioapic
I think this is used all over the place.
No, it isn't. This is only about hot pluggable I/O-APICs, which is a pointless business on x86 (as the rest of the infrastructure to support this is missing). At most IA64 ever had a use for this, which is why some time ago I actually submitted the patch to allow this to be a module on x86 (so one could keep building it, but wouldn't have it around all the time). Furthermore, I guess even on IA64 it was dead code (maybe just following some never implemented spec), because up until that very patch the driver didn't even have its ID table right, i.e. would never have got bound to a matching device by the PCI core. Jan -- 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 <jbohac@suse.cz> SUSE Labs, SUSE CZ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (14)
-
Andrey Borzenkov -
Cristian Rodríguez -
Jan Beulich -
Jean Delvare -
Jeff Mahoney -
Jiri Bohac -
Jiri Kosina -
Linda Walsh -
Michal Kubeček -
Michal Marek -
Oliver Neukum -
Petr Tesarik -
Stefan Seyfried -
Takashi Iwai