Dan Nicholson wrote:
The udevsettle program is run so that the bootscript will wait until
all the uevents regenerated by udevtrigger will be processed.
Unfortunately, udevsettle can't really tell when the rule processing
has finished for each uevent. I can't remember the exact reasons why.
The problem is with new uevents that result from processing of "this" uevent. E.g., the Realtek 8139 PCI device has been found, the udev rule executed the "modprobe" command, which generated a second uevent (now for the network interface, not simply a PCI device)

The "udevsettle" program makes the following wrong assumption: such "child" uevents appear in the kernel while udev is still processing the "parent" uevent". For USB and FireWire, this is not the case.

In this case, the kernel discovered a FireWire host controller, and loaded the module for it. Then the module, while loading, sent a "who is there?" question on the wire, and immediately said that it loaded successfully (without waiting for answers!). Since modprobe returned, udev marked the uevent as fully processed. Then it processed other uevents, and reported hat its queue is empty. Udevsettle returned. Then somebody said "I'm here!" on the wire, thus generating a new uevent which triggred the bug-catching logic in the old udev initscript (the idea was that the udevsettle command should have waited for this uevent).

However, there is really no way to wait for child uevents in such cases when the bus driver finishes loading early and waits for its devices to announce themselves in the background.
Upstream doesn't care about this because apparently there's no way to
check this. So, it Alexander decided that the /dev/bugreport stuff was
useless after he reported it upstream a bunch of times.
Right, although I still have to check the logic in SUSE scripts, even though that would add to the "35 patches and counting" thread.

--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to