Re: udev is too slow creating devices

[Marc Ballarin]

On Sat, 18 Sep 2004 21:44:03 +0200
Ihar 'Philips' Filipau <filia@xxxxxxxxxxxx> wrote:

> 
>    That's wrong attitude. I'm working on workstation where 95% of 
> hardware plugged 100% of time. That's not exception. Not eerything is 
> hot-pluggable USB/FireWire/whatever.

Even PCI devices are "attached" to the kernel at bootup. From an
abstracted POV they are plugged in.

> 
>    Event-based hot-plug scripts are great thing. As an implementation. 
> But user cares about one thing: 'modprobe usb-storage; mount /whatever' 
> working reliably.

That's actually something the user doesn't want to be bothered with.
modprobe is done automatically when the device is plugged in. Mounting is
done automatically when udev signals the script in dev.d (or your desktop
environment via D-BUS). This is what users care about.
Even uber-geeks don't enjoy unnecessary work.

> 
>    /etc/dev.d probably great thing - but I'm not going to implement FSM 
> into every shell script which does modprobe for sake being Ok with 
> dynamic /dev/.

Why not switch completely. Of course, there still is Kernel 2.4, but there
is little reason not to use udev on 2.6. We all know that open source is
about choice, but his may well mean that more work is needed (ie. two
versions of an init script)

> 
>    You need to change your attitude for first. For second - come up with
>    
> a way for user space to block until device is here, and if it is not 
> here/error detected - fail.

Already done. All userspace nees to do is wait in /etc/dev.d. The only
issue is error handling, but after some consideration I have to admit,
that this is not different than before.
In a situation where modprobe failed before, it will still do so. In a
situation where modprobe succeeded, but later phases failed (like
partition detection), the situation isn't any worse with udev.
Instead of a non-working device node and an error in dmesg you now get no
device node and an error in dmesg. Checking for such a condition is
equally hard in both cases.

> 
>    As it was said before - /all/ we need, is to be able to tell 
> discovery phase from idle state of driver. "/All/" is quite much here - 
> but it must be a goal.

Why? You couln't do so from userspace before, and there is little reason
to do so. Or am I missing something?

> 
>    I'm absolutely sure, that for PCI devices it is implementable quite 
> easy - probing is already done outside of modules. And we know precisely
> are we Ok, or are we not. And we know when we are done.

Not really. modprobe may return sucessfully, but the hardware still might
fail to work - either silently or with error messages in kernel log. All
you really can rely on is that the module has been loaded. Nothin changes
with udev.

Regards
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/