1 |
On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld <joost@××××××××.org> wrote: |
2 |
> On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote: |
3 |
>> On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld <joost@××××××××.org> |
4 |
> wrote: |
5 |
>> >> I'm not entirely convinced this is the case, because it feels like |
6 |
>> >> some situations like network devices (nbd, iSCSI) or loopback would |
7 |
>> >> require userland tools to bring up once networking is up. |
8 |
>> > |
9 |
>> > Yes, but the kernel-events referencing those devices won't appear untill |
10 |
>> > after the networking is brought up. |
11 |
>> > The scripts that "udev" starts are run *after* a device-event is |
12 |
>> > created. If the device itself has not been spotted by the kernel (for |
13 |
>> > instance, the networking doesn't exist yet), the event won't be |
14 |
>> > triggered yet. |
15 |
>> > |
16 |
>> > This situation does not require udev to start all these tools when |
17 |
>> > network- 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 |
24 |
>> > the |
25 |
>> > queue |
26 |
>> > |
27 |
>> > 3) further things happen and kernel places relevant events in the queue |
28 |
>> > (some other events may also already be in the queue before step 2) |
29 |
>> > |
30 |
>> > 4) udev starts and starts processing the queue |
31 |
>> > |
32 |
>> > 5) For each event, udev creates the corresponding device-entry and |
33 |
>> > places |
34 |
>> > action-entries in a queue |
35 |
>> > |
36 |
>> > 6) system-init-scripts mount all local filesystems |
37 |
>> > |
38 |
>> > 7) udev-actions starts (I made up this name) |
39 |
>> > |
40 |
>> > 8) udev-actions processes all the entries in the action-queue |
41 |
>> > |
42 |
>> > From step 4, udev will keep processing further events it gets, which |
43 |
>> > means that if any action taken by "udev-actions" causes further devices |
44 |
>> > to become available, "udev" will create the device-entries and place |
45 |
>> > the action in the action-queue. |
46 |
>> |
47 |
>> So, if I read this correctly, there are two classes of processing |
48 |
>> events. kernel events and scripted actions. Here's rough pseudocode |
49 |
>> describing what I think you're saying. (Or perhaps what I'm hoping |
50 |
>> you're saying) |
51 |
>> |
52 |
>> while(wait_for_event()) |
53 |
>> { |
54 |
>> kevent* pkEvent = NULL; |
55 |
>> if(get_waiting_kernel_event(pkEvent)) // returns true if an event was |
56 |
>> waiting { |
57 |
>> process_kernel_event(pkEvent); |
58 |
>> } |
59 |
>> else |
60 |
>> { |
61 |
>> aevent* pAction = NULL; |
62 |
>> if(get_waiting_action(pAction)) // Returns true if there's an |
63 |
>> action waiting. |
64 |
>> { |
65 |
>> process_action(pAction); |
66 |
>> } |
67 |
>> } |
68 |
>> } |
69 |
> |
70 |
> This is, sort-of, what I feel should happen. But currently, in pseudo-code, |
71 |
> the following seems to happen: |
72 |
> while(wait_for_event()) |
73 |
> { |
74 |
> kevent* pkEvent = NULL; |
75 |
> if(get_waiting_kernel_event(pkEvent)) // returns true if an event was |
76 |
> waiting { |
77 |
> process_kernel_event(pkEvent); |
78 |
> } |
79 |
> } |
80 |
> |
81 |
> I would prefer to see 2 seperate processes: |
82 |
> |
83 |
> --- process 1 --- |
84 |
> while(wait_for_event()) |
85 |
> { |
86 |
> kevent* pkEvent = NULL; |
87 |
> if(get_waiting_kernel_event(pkEvent)) // returns true if an event was |
88 |
> waiting |
89 |
> { |
90 |
> action_event = process_kernel_event(pkEvent); |
91 |
> if (action_event != NULL) |
92 |
> { |
93 |
> put_action_event(pkEvent); |
94 |
> } |
95 |
> } |
96 |
> } |
97 |
> |
98 |
> ------ |
99 |
> |
100 |
> --- process 2 --- |
101 |
> while(wait_for_event()) |
102 |
> { |
103 |
> aevent* paEvent = NULL; |
104 |
> if(get_waiting_action_event(paEvent)) // returns true if an event was |
105 |
> waiting |
106 |
> { |
107 |
> process_action_event(paEvent); |
108 |
> } |
109 |
> } |
110 |
> ------- |
111 |
> |
112 |
>> So, udev processes one event at a time, and always processes kernel |
113 |
>> events with a higher priority than resulting scripts. This makes a |
114 |
>> certain amount of sense; an action could launch, e.g. nbdclient, which |
115 |
>> would cause a new kernel event to get queued. |
116 |
> |
117 |
> Yes, except that udev ONLY handles kernel-events and doesn't process any |
118 |
> "actions" itself. |
119 |
> These are placed on a seperate queue for a seperate process. |
120 |
|
121 |
The problem with this is that you now need to manage synchronization |
122 |
between the kernel event processor and the action processor, which is |
123 |
actually more complicated than keeping them together in a |
124 |
single-threaded, single-process scenario. |
125 |
|
126 |
|
127 |
-- |
128 |
:wq |