Re: debian and UDEV
Gabor Gombas <gombasg@sztaki.hu> writes:
> On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote:
>
>> What timeout? With feedback you would know exactly when it is done and
>> wouldn't have to poll.
>
> Quoting Linus:
>
> : It really is very hard to accept the "blocking" behaviour.
> :
> : Some things can take a _loong_ time to be ready, including even
> : requiring user intervention. And even when scanning takes "only" a few
> : seconds, if there are multiple modules, you really want to scan things
> : in parallel.
> :
> : Not finding a disk is often a matter of timing out - not all buses
> : even have any real "enumeration" capability, and enumeration literally
> : ends up being "try these addresses, and if nothing answers in 500
> : msec, assume it's empty".
> :
> : Now, 500 msec may not sound very bad, but it all adds up. I get
> : unhappy if my bootup is a minute. I'd prefer booting up in a couple of
> : seconds.
> :
> : Also, how ready do you want things to be? Do you want to know the
> : device is there ("disk at physical location X exists"), or do you want
> : to have read the UUID off the disk and partitioned it? The latter is
> : what is needed for a mount, but it's often a _lot_ more expensive than
> : just knowing the disk is there, and it's not even necessarily needed
> : in many circumstances.
>
> So you can _not_ prevent polling.
>
> With some SCSI setups it literally takes minutes till all devices power
> up and answer to the inquiry command. If you happen to have several SCSI
> buses those latencies do add up pretty quickly.
Yes it does. But then it works all the time.
Now the system randomly doesn't boot and instead of a 10 minute boot
time you have a 3 hour drive to reset the system and analyse that is
was just udev screwing you over.
> And not just SCSI:
>
> Linus:
>
> : For example, any USB host driver will always discover its devices
> : asynchronously, and has no dependency on CONFIG_HOTPLUG. It can take
> : several seconds for all the hubs to have powered up and discovered
> : what is behind them.
>
> Greg K-H:
>
> : And as others have pointed out, for a lot of busses, we just don't
> : know how long the device is going to take to be found. For one of my
> : boxes with a flaky USB controller, it takes _minutes_ for devices to
> : be detected (yes, it is broken hardware, but the rest of the system
^^^^^^^^^^^^^^^^^^^^^^^^^^
> : works just fine while it is off and trying to be detected.)
USB seems to be pretty broken by design. But most hardware is
not. Even scsi, while taking some time to scan the bus, will finish in
a reasonable time.
>> Scan the USB bus, find all devices on it, run all udev scripts for
>> them, return.
>
> Greg K-H:
>
> : Another point is that some busses just don't know when all the devices
> : on it are found, as there is no such state. USB is one such bus, and
> : I imagine firewire is another one. So there is no real way for us to
> : delay at insmod time for all devices to be found.
>
>> Just like the kernel always did prior to udev.
>
> You're missing a very important thing. This is _NOT_ a "udev vs.
> pre-udev" question. This is a "new kernel hotplug behavior vs. old
> kernel hotplug behavior" question. The fact is that the kernel behavior
> changed fundamentally in the early 2.6.x series compared to 2.4.x, and
> userspace did not follow that change ever since. udev simply exposes how
> the kernel really works. Not using udev solves NOTHING since it's not
> udev that is broken: it is the general userspace assumption about how
> the kernel works what is broken.
Yes, it is a problem with the kernels hotplug implementation. Hotplug
and udev are just linked together. I'm not blaming the userspace part
(udev) but the kernel part (hotplug).
>> > I think it is pointless to bitch about udev without a clean proposal how
>> > should Debian handle hotplug events (including cases like when the
>> > device containing the root file system is literally plugged in _after_
>> > the kernel/initrd has been loaded).
>>
>> That is a different matter. That never ever worked by itself and udev
>> doesn't change anything there.
>
> Not different at _all_. As far as the kernel is concerned this is how it
> actually works right now. If you look at the initrd generators, they add
> delays and retries when mounting the root file system because the kernel
> does _not_ make any difference between delaying the discovery of an
> already-plugged-in device and physically plugging in the device later.
>
> In fact, if you have hotplug capable hardware, you could just connect
> the root device when you see the "waiting for the root file system to
> appear" (or similar) message and it would quite likely Just Work.
>
>> But for already plugged in devices the
>> device node was always ready when the insmod was done.
>
> And that has changed. And udev has _nothing_ to do with it apart from
> making that change more visible.
And that is what I consider broken. I know it is not going to change
but I pain for all the users (and myself) that will (and already have
been) get hit by problems caused by it.
MfG
Goswin
Reply to: