On Mon, 11 Sep 2006, Petter Reinholdtsen wrote: > [Henrique de Moraes Holschuh] > > The only way we can support this nowadays is with the full async userspace > > model. > > Why? For the case of mounting a fixed USB disk, I would expect udev > to find it before its init.d scripts is done, as it will load the USB
How could it? Remeber, udev finds *NOTHING*. The kernel does, and will do so only after the entire chain from PCI to usb-storage has loaded, waited for whatever to settle, etc. It is async. I really mean it. You don't know when it will come, if it ever does. So the only thing that will work sanely is to react when (and if) it does come. And it also means we need proper concurrency-safe handling, because the chances are there that it will try to run at inconvenient times. > Am I mistaken? Isn't the long udev wait making sure all detected > devices are available in /dev/ before it continues? No. What udev can wait for reliably is, AFAIK, precious little. Small stuff like sysfs entries showing up, and other *direct* effects of an event. > I agree that would be a solution for the disks inserted after boot. > But is it really necessary for disks that are present when the machine > boot? With all Etch kernels and udev, all disks are inserted either *at* or *after* boot, i.e. you get coldplug events for the disks at bootup, as soon as udev tells the kernel it is up to handle the coldplug, and the kernel dumps the entire coldplug queue into udev. You get the same type of events later, if new disks are hotplugged. Or hot-removed, for that matter. In an udev-less system, all that happens is that coldplug and hotplug/hotremoves are never processed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
