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