Re: udev is too slow creating devices

[Marc Ballarin]

On Sun, 19 Sep 2004 22:00:52 +0600
"Alexander E. Patrakov" <patrakov@xxxxxxxxxx> wrote:

> 
> OK. The fact is that, when mounting the root filesystem, the kernel can 
> (?) definitely say "there is no such device, and it's useless to wait 
> for it--so I panic". Is it possible to duplicate this logic in the case 
> with udev and modprobe? If so, it should be built into a common place 
> (either the kernel or into modprobe), but not into all apps.

Well, once  the system is running, the device might appear any time, so
waiting is hardly useless then.

In the past you did modprobe and afterwards tried to access the device. If
this succeeded, the device was created successfully, if not, something
went wrong, and your script returned an error code.
This approach has some problems.
The device is plugged in later on: "su" to root, re-run script. Not nice.
The script doesn't check properly for later errors: something breaks.

Now, the device is either autodetected or - when this is not possible
("legacy" devices) you have to modprobe manually.
If this succeeds, you are informed in dev.d. If it fails you are
"informed" by not being called in dev.d.

If I understand correctly, you wish do modprobe for a legacy device and
then know if this succeeded completely.
Simply choose a state-file in /var and write something like "not detected"
inside. Then do modprobe.
The other part of your script will wait in dev.d for the event. If it
arrives, the script will change the state file to "found" and do its work.
So, as long as the state is "not detected" you treat the device as not
present - just as if your old, synchronous script had returned an error
code. The advantage is, that if the device appears later on everything
will work automatically.

> 
> Then the "char-major" aliases were always broken, do I understand 
> correctly? Once we realize that, isn't it the time to mark the 
> "Automatic kernel module loading" in the kernel configuration as BROKEN 
> or OBSOLETE?

IIRC this feature is intended primarily for loadable kernel features and
pseudo devices, not "real" device drivers.

> 
> Yes. Now we have a lot of short scriptlets under /etc/dev.d. But I don't
> yet see how these scriptlets interact with each other.

You could use some state file if hotplug messages aren't enough, as
described above.

mfg
-
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/