Messages in this thread |  | | | Subject | Re: udev is too slow creating devices | | From | Gianni Tedesco <> | | Date | Wed, 15 Sep 2004 00:34:40 +0100 |
| |
On Wed, 2004-09-15 at 01:20 +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. > > > Sitting and waiting is a band-aid, I agree. That's why we created the > > /etc/dev.d/ notifier system to fix this issue (that is there for systems > > that don't even use udev.) > > if the fsck can run from there ok, if for some reason it's not feasible > to run it from there (like if it would create a bus congestion by > running all the fsck in parallel if you attach multiple devices at the > same time), and/or you need some other seriaization, then probably > having a way to run things serially without a > spin-and-sleep-and-risk-to-hang could be needed. I guess in the worst > case one could serialize things by using file locking in /var/run > and by creating an API between the dev.d and the init.d scripts, is that > how the long term is supposed to work? > > So it's more a question if the current interface is complete for all > usages, and if the fsck spin-and-sleep is just a temporary band-aid, or > if the spin-and-sleep is supposed to last longer than a few month > release cycle.
Surely fsck can be done on top of /etc/dev.d/ by just writing to a FIFO? That'll serialize up the fsck caller...
-- // Gianni Tedesco (gianni at scaramanga dot co dot uk) lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import 8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |