| 1 |
On Thursday, September 15, 2011 09:47:34 AM Michael Mol wrote: |
| 2 |
> > The main purpose of udev is to populate the /dev-tree. |
| 3 |
> > The running of scripts based on /dev-tree events should be in a seperate |
| 4 |
> > tool that starts later in the boot-process. |
| 5 |
> |
| 6 |
> I'm not entirely convinced this is the case, because it feels like |
| 7 |
> some situations like network devices (nbd, iSCSI) or loopback would |
| 8 |
> require userland tools to bring up once networking is up. |
| 9 |
|
| 10 |
Yes, but the kernel-events referencing those devices won't appear untill after |
| 11 |
the networking is brought up. |
| 12 |
The scripts that "udev" starts are run *after* a device-event is created. If |
| 13 |
the device itself has not been spotted by the kernel (for instance, the |
| 14 |
networking doesn't exist yet), the event won't be triggered yet. |
| 15 |
|
| 16 |
This situation does not require udev to start all these tools when network- |
| 17 |
devices appear. |
| 18 |
|
| 19 |
I hope the following would make my thoughts a bit clearer: |
| 20 |
|
| 21 |
1) kernel boots |
| 22 |
|
| 23 |
2) kernel detects network device and places "network-device-event" in the |
| 24 |
queue |
| 25 |
|
| 26 |
3) further things happen and kernel places relevant events in the queue (some |
| 27 |
other events may also already be in the queue before step 2) |
| 28 |
|
| 29 |
4) udev starts and starts processing the queue |
| 30 |
|
| 31 |
5) For each event, udev creates the corresponding device-entry and places |
| 32 |
action-entries in a queue |
| 33 |
|
| 34 |
6) system-init-scripts mount all local filesystems |
| 35 |
|
| 36 |
7) udev-actions starts (I made up this name) |
| 37 |
|
| 38 |
8) udev-actions processes all the entries in the action-queue |
| 39 |
|
| 40 |
From step 4, udev will keep processing further events it gets, which means |
| 41 |
that if any action taken by "udev-actions" causes further devices to become |
| 42 |
available, "udev" will create the device-entries and place the action in the |
| 43 |
action-queue. |
| 44 |
|
| 45 |
If anyone has a setup where /usr can not be mounted easily, it won't work |
| 46 |
currently either and a init* would be necessary anyway. |
| 47 |
(Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers,.... hosting /usr |
| 48 |
or other required filesystems) |
| 49 |
|
| 50 |
But anyone with a currently working environment should be able to expect a |
| 51 |
currently working environment. If it fails to boot with only updating |
| 52 |
versions, it's a regression. And one of the worst kinds of all. |
| 53 |
|
| 54 |
-- |
| 55 |
Joost |
Archives