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