Bug#386006: [Pkg-sysvinit-devel] Bug#386006: Cannot mount -o auto USB filesystems from /etc/fstab

[Henrique de Moraes Holschuh]

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