Re: udev is too slow creating devices

[Greg KH <greg@kroah.com>]

On Wed, Sep 15, 2004 at 01:20:11AM +0200, Andrea Arcangeli wrote:
> On Tue, Sep 14, 2004 at 04:04:09PM -0700, Greg KH wrote:
> > On Wed, Sep 15, 2004 at 12:47:31AM +0200, Andrea Arcangeli wrote:
> > > On Tue, Sep 14, 2004 at 02:51:22PM -0700, Greg KH wrote:
> > > > True, so sit and spin and sleep until you see the device node.  That's
> > > > how a number of distros have fixed the fsck startup issue.
> > > 
> > > that's more a band-aid than a fix (I can imagine a userspace hang if the
> > > device isn't created for whatever reason), if there's no way to do
> > > better than this if you've to run fsck (or if it's not the best to run
> > > the fsck inside the dev.d scripts), then probably this needs better
> > > fixing. is such a big problem to execute a sys_wait4 to wait the udev
> > > userspace to return before returning from the insmod syscall?
> > 
> > But how do you know what to wait for?
> 
> the kernel sure can know about it, by passing a waitqueue into the
> registration routine and calling wake_up once the discovery is over.

But the low level driver (like a USB driver for example), has no way of
knowing when the "device discovery" process is over.  Actually the USB
core never knows this either, as devices come and go all the time.

That's why we had to move to the "probe" and "release" way of writing
drivers.  The bus cores notify the driver when they find something, as
the driver never knows when a device is found.

So the kernel can not know what or when to wait for something it doesn't
know is going to ever happen in the future.

Does that make more sense now?

Remember, this isn't your old "static device tree" unix-like kernel that
people grew up with, anymore. :)

thanks,

greg k-h