Re: debian and UDEV
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.
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.)
> 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.
> > 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.
> Even with devfs.
No. The confusion comes from the fact that when devfs was still
maintained, the kernel still used the old device discovery scheme.
If devfs had not been obsoloted it would have _exactly_ the same
problems as udev because it used/uses the same internal in-kernel event
notification mechanisms and data structures as udev.
devfs may be somewhat faster than udev and therefore the time window
between insmod returning and the device node appearing might be a bit
smaller, but it would still be there and with a fast enough processor
you'd hit it just as well you hit it with udev.
> For all cases where you load a module to activate a certain device
> (disk for initrd, mouse for X, ...) this is a serious step back.
No, it's just the visible effect for the kernel slowly becoming fully
hotplug-ready. It's just userspace that's severely lagging behind.
Also, the kernel people know that these changes cause problems for
userspace. It's just the benefits of the changes outweight the problems
by far as far as the kernel is concerned.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
Reply to: