Asynchronous Device/Driver Probing For The Linux Kernel

[DeepDayze]

Async device/driver probing sounds like what should be in Linux and I am sure Windows does async probing by now too. There should be a multithreaded way to get a system from cold power-up to login screen to desktop in the least amount of time possible so with async device probing this might save a bit more time. Of course with async probing, devices/drivers will not not available till devices have been probed and appropriate driver modules loaded so slow devices won't be ready till system is fully up. Also can some Linux services be delayed start?

[pal666]

Also can some Linux services be delayed start?

everything can be started when ready by systemd

[Adarion]

Does that mean my kernel will boot faster once I have multiple USB things attached? If yes: please, here, I'm first!
Kernel even on an old device fires up in 1.5 - 2.5 seconds. Have USB card readers, sticks and stuff attached it will take up to 7 seconds on the same machine.

[gens]

Does that mean my kernel will boot faster once I have multiple USB things attached? If yes: please, here, I'm first!
Kernel even on an old device fires up in 1.5 - 2.5 seconds. Have USB card readers, sticks and stuff attached it will take up to 7 seconds on the same machine.

weird
afaik usb devices are not probed until the usb controller's driver is loaded
that happens on init when udev is started

to be honest, i don't know the context in what kind of machine it is

[DeepDayze]

weird
afaik usb devices are not probed until the usb controller's driver is loaded
that happens on init when udev is started
...

This has to be how it works for attached USB devices as first the USB controller driver gets loaded by udev, then once that occurs then udev can query and enumerate any devices that are on the USB bus. Most likely its the motherboard's hardware that gets enumerated first by udev then any PCI/PCIe cards plugged into the mobo are next, followed by USB devices that are plugged in (once USB controller driver loads). Any devices that are slow to respond could be enumerated later under the async probe method so as not to delay the boot unnecessarily.

[nanonyme]

This has to be how it works for attached USB devices as first the USB controller driver gets loaded by udev, then once that occurs then udev can query and enumerate any devices that are on the USB bus. Most likely its the motherboard's hardware that gets enumerated first by udev then any PCI/PCIe cards plugged into the mobo are next, followed by USB devices that are plugged in (once USB controller driver loads). Any devices that are slow to respond could be enumerated later under the async probe method so as not to delay the boot unnecessarily.

You mean like out-of-order results with probing? That sounds sensible

[BradN]

Ive always wondered why the Kernel did so many things in a single threaded fashion during boot.
I guess supporting so many platforms, its just kind of hard to do in a queue fashion?

You end up avoiding a lot of accidental race conditions. Initialization only happens once so it's not a very sexy thing to optimize performance wise, and if by doing so you expose some instabilities, it becomes more work than you expected. A lot of older drivers no longer have the original writer looking at the code - there is a bitrot risk to making unnecessary changes.

[gens]

This has to be how it works for attached USB devices as first the USB controller driver gets loaded by udev, then once that occurs then udev can query and enumerate any devices that are on the USB bus. Most likely its the motherboard's hardware that gets enumerated first by udev then any PCI/PCIe cards plugged into the mobo are next, followed by USB devices that are plugged in (once USB controller driver loads). Any devices that are slow to respond could be enumerated later under the async probe method so as not to delay the boot unnecessarily.

the kernel enumerates things

udev reads sysfs then tells the kernel to load the module for the usb controller
the kernel then finds usb devices and tells udev it found them
as it gets those msgs, udev tells the kernel to load their modules

[liam]

the kernel enumerates things

udev reads sysfs then tells the kernel to load the module for the usb controller
the kernel then finds usb devices and tells udev it found them
as it gets those msgs, udev tells the kernel to load their modules

That's certainly the way it was when udev was in userspace, but are you sure that's still the case? Do you recall all the moaning around having udev merged with systemd and, subsequently, integrated into the kernel? I don't recall the particulars but, at this point, I'd expect udev to handle both enumeration and module loading.

[gens]

That's certainly the way it was when udev was in userspace, but are you sure that's still the case? Do you recall all the moaning around having udev merged with systemd and, subsequently, integrated into the kernel? I don't recall the particulars but, at this point, I'd expect udev to handle both enumeration and module loading.

run the C program from this link

https://www.kernel.org/doc/pending/hotplug.txt

then, idk, unplug-plug something

those are the events udev receives from the kernel

it even gets the modalias of the module for the device, for example

ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:12.0/usb5/5-3/5-3:1.0
DEVTYPE=usb_interface
INTERFACE=3/1/2
MODALIAS=usb:v093Ap2521d0100dc00dsc00dp00ic03isc01ip02in00
PRODUCT=93a/2521/100
SEQNUM=2538
SUBSYSTEM=usb
TYPE=0/0/0
UDEV_LOG=3
USEC_INITIALIZED=49969834494

it also gets the major and minor node numbers needed to create a node in /dev

even more then that the systemd udev does not anymore change network interface names to be persistent after reboot
but for some reason they decided to give them dumb names (it's still a good thing; thank dell for that)

the change you are thinking of is going over to dbus instead of netlink
it makes no real difference
netlink interface to the kernel will, ofc, still work fine