1 |
On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld <joost@××××××××.org> wrote: |
2 |
>> I'm not entirely convinced this is the case, because it feels like |
3 |
>> some situations like network devices (nbd, iSCSI) or loopback would |
4 |
>> require userland tools to bring up once networking is up. |
5 |
> |
6 |
> Yes, but the kernel-events referencing those devices won't appear untill after |
7 |
> the networking is brought up. |
8 |
> The scripts that "udev" starts are run *after* a device-event is created. If |
9 |
> the device itself has not been spotted by the kernel (for instance, the |
10 |
> networking doesn't exist yet), the event won't be triggered yet. |
11 |
> |
12 |
> This situation does not require udev to start all these tools when network- |
13 |
> devices appear. |
14 |
> |
15 |
> I hope the following would make my thoughts a bit clearer: |
16 |
> |
17 |
> 1) kernel boots |
18 |
> |
19 |
> 2) kernel detects network device and places "network-device-event" in the |
20 |
> queue |
21 |
> |
22 |
> 3) further things happen and kernel places relevant events in the queue (some |
23 |
> other events may also already be in the queue before step 2) |
24 |
> |
25 |
> 4) udev starts and starts processing the queue |
26 |
> |
27 |
> 5) For each event, udev creates the corresponding device-entry and places |
28 |
> action-entries in a queue |
29 |
> |
30 |
> 6) system-init-scripts mount all local filesystems |
31 |
> |
32 |
> 7) udev-actions starts (I made up this name) |
33 |
> |
34 |
> 8) udev-actions processes all the entries in the action-queue |
35 |
> |
36 |
> From step 4, udev will keep processing further events it gets, which means |
37 |
> that if any action taken by "udev-actions" causes further devices to become |
38 |
> available, "udev" will create the device-entries and place the action in the |
39 |
> action-queue. |
40 |
|
41 |
So, if I read this correctly, there are two classes of processing |
42 |
events. kernel events and scripted actions. Here's rough pseudocode |
43 |
describing what I think you're saying. (Or perhaps what I'm hoping |
44 |
you're saying) |
45 |
|
46 |
while(wait_for_event()) |
47 |
{ |
48 |
kevent* pkEvent = NULL; |
49 |
if(get_waiting_kernel_event(pkEvent)) // returns true if an event was waiting |
50 |
{ |
51 |
process_kernel_event(pkEvent); |
52 |
} |
53 |
else |
54 |
{ |
55 |
aevent* pAction = NULL; |
56 |
if(get_waiting_action(pAction)) // Returns true if there's an |
57 |
action waiting. |
58 |
{ |
59 |
process_action(pAction); |
60 |
} |
61 |
} |
62 |
} |
63 |
|
64 |
So, udev processes one event at a time, and always processes kernel |
65 |
events with a higher priority than resulting scripts. This makes a |
66 |
certain amount of sense; an action could launch, e.g. nbdclient, which |
67 |
would cause a new kernel event to get queued. |
68 |
|
69 |
> If anyone has a setup where /usr can not be mounted easily, it won't work |
70 |
> currently either and a init* would be necessary anyway. |
71 |
> (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers,.... hosting /usr |
72 |
> or other required filesystems) |
73 |
|
74 |
I don't see how this is relevant to actually fixing udev. (See below) |
75 |
|
76 |
> But anyone with a currently working environment should be able to expect a |
77 |
> currently working environment. If it fails to boot with only updating |
78 |
> versions, it's a regression. And one of the worst kinds of all. |
79 |
|
80 |
I agree that the direction udev is going is a regression. There aren't |
81 |
very many people active in this thread who would disagree with that |
82 |
point. So let's just drop it and focus on what a good, general |
83 |
solution would look like. (And anyone who says something amounting to |
84 |
'status quo' for udev needs another explanation of why the udev |
85 |
developer sees the current scenario as broken. And he's right; the |
86 |
current scenario is architecturally unsound. I just think he's wrong |
87 |
about the solution.) |
88 |
|
89 |
-- |
90 |
:wq |