On Monday, September 12, 2011 10:13:45 AM Neil Bothwick wrote: > On Mon, 12 Sep 2011 11:07:12 +0200, Joost Roeleveld wrote: > > > I'd like to know why these functions cannot be separated, run the > > > command to populate /dev early on, then start the udev daemon after > > > the filesystems have been mounted. > > > > > > Some sort of early boot rules file would need to be used to handle > > > things like setting up symlinks for block devices to avoid breaking > > > some users' fstabs. > > > > Yes, which means "udev" would need to be split into: > > * devd (which controls the /dev-tree) > > * plugd (which handles all the "hotplug-events" where special things > > happen) > > > > The communication between the 2 could be done using a > > simple /dev/udev_pipe device. "devd" throws events onto the pipe and > > plugd handles these events. > > I wonder if it could be done more simply. udevd loads but only parses > those rule files marked as suitable for early boot time. Later in the > boot it switches to "full" mode and loads all rule files. > > This is so simple it is either pure genius or completely naive and > unworkable. I know which option my money is on...
This would depend on wether or not udev (or whatever program handles the events) can pick specific events out of the queue. I think the events are placed on a queue waiting for some process to handle them and that process then does the following in an endless loop: 1) get event from queue 2) handle event In order to split the 2 options, there needs to be something that sorts them between "init-level" and "run-level" events where "init-level" is what is needed/possible during boot. As I currently understand it, the kernel does not support cherry-picking / multiple queues for hotplug-events and all devices cause a hotplug-event for the /dev-tree creation part of "udev". A second queue will need to be handled somehow. I also don't see why "udev" needs to get the additional code to handle delaying running external tools when this could be split off into seperate process. This way, if the program/script that is configured in the udev-rules causes a system-crash, avoiding the handler for these to start up, will actually provide a better fail-safe. The part that creates the dev-tree will still run and has become smaller and simpler. Would a udev-fork work for Gentoo? -- Joost
