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?
Announcement
Collapse
No announcement yet.
Asynchronous Device/Driver Probing For The Linux Kernel
Collapse
X
-
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.Stop TCPA, stupid software patents and corrupt politicians!
Comment
-
Originally posted by Adarion View PostDoes 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.
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
Comment
-
Originally posted by gens View Postweird
afaik usb devices are not probed until the usb controller's driver is loaded
that happens on init when udev is started
...
Comment
-
Originally posted by DeepDayze View PostThis 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.
Comment
-
Originally posted by MrEcho View PostIve 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?
Comment
-
Originally posted by DeepDayze View PostThis 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.
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
Comment
-
Originally posted by gens View Postthe 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
Comment
-
Originally posted by liam View PostThat'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.
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
Code: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
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
Comment
Comment