1 |
On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote: |
2 |
> On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld <joost@××××××××.org> |
3 |
wrote: |
4 |
> >> I'm not entirely convinced this is the case, because it feels like |
5 |
> >> some situations like network devices (nbd, iSCSI) or loopback would |
6 |
> >> require userland tools to bring up once networking is up. |
7 |
> > |
8 |
> > Yes, but the kernel-events referencing those devices won't appear untill |
9 |
> > after the networking is brought up. |
10 |
> > The scripts that "udev" starts are run *after* a device-event is |
11 |
> > created. If the device itself has not been spotted by the kernel (for |
12 |
> > instance, the networking doesn't exist yet), the event won't be |
13 |
> > triggered yet. |
14 |
> > |
15 |
> > This situation does not require udev to start all these tools when |
16 |
> > network- devices appear. |
17 |
> > |
18 |
> > I hope the following would make my thoughts a bit clearer: |
19 |
> > |
20 |
> > 1) kernel boots |
21 |
> > |
22 |
> > 2) kernel detects network device and places "network-device-event" in |
23 |
> > the |
24 |
> > queue |
25 |
> > |
26 |
> > 3) further things happen and kernel places relevant events in the queue |
27 |
> > (some 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 |
32 |
> > places |
33 |
> > action-entries in a queue |
34 |
> > |
35 |
> > 6) system-init-scripts mount all local filesystems |
36 |
> > |
37 |
> > 7) udev-actions starts (I made up this name) |
38 |
> > |
39 |
> > 8) udev-actions processes all the entries in the action-queue |
40 |
> > |
41 |
> > From step 4, udev will keep processing further events it gets, which |
42 |
> > means that if any action taken by "udev-actions" causes further devices |
43 |
> > to become available, "udev" will create the device-entries and place |
44 |
> > the action in the action-queue. |
45 |
> |
46 |
> So, if I read this correctly, there are two classes of processing |
47 |
> events. kernel events and scripted actions. Here's rough pseudocode |
48 |
> describing what I think you're saying. (Or perhaps what I'm hoping |
49 |
> you're saying) |
50 |
> |
51 |
> while(wait_for_event()) |
52 |
> { |
53 |
> kevent* pkEvent = NULL; |
54 |
> if(get_waiting_kernel_event(pkEvent)) // returns true if an event was |
55 |
> waiting { |
56 |
> process_kernel_event(pkEvent); |
57 |
> } |
58 |
> else |
59 |
> { |
60 |
> aevent* pAction = NULL; |
61 |
> if(get_waiting_action(pAction)) // Returns true if there's an |
62 |
> action waiting. |
63 |
> { |
64 |
> process_action(pAction); |
65 |
> } |
66 |
> } |
67 |
> } |
68 |
|
69 |
This is, sort-of, what I feel should happen. But currently, in pseudo-code, |
70 |
the following seems to happen: |
71 |
while(wait_for_event()) |
72 |
{ |
73 |
kevent* pkEvent = NULL; |
74 |
if(get_waiting_kernel_event(pkEvent)) // returns true if an event was |
75 |
waiting { |
76 |
process_kernel_event(pkEvent); |
77 |
} |
78 |
} |
79 |
|
80 |
I would prefer to see 2 seperate processes: |
81 |
|
82 |
--- process 1 --- |
83 |
while(wait_for_event()) |
84 |
{ |
85 |
kevent* pkEvent = NULL; |
86 |
if(get_waiting_kernel_event(pkEvent)) // returns true if an event was |
87 |
waiting |
88 |
{ |
89 |
action_event = process_kernel_event(pkEvent); |
90 |
if (action_event != NULL) |
91 |
{ |
92 |
put_action_event(pkEvent); |
93 |
} |
94 |
} |
95 |
} |
96 |
|
97 |
------ |
98 |
|
99 |
--- process 2 --- |
100 |
while(wait_for_event()) |
101 |
{ |
102 |
aevent* paEvent = NULL; |
103 |
if(get_waiting_action_event(paEvent)) // returns true if an event was |
104 |
waiting |
105 |
{ |
106 |
process_action_event(paEvent); |
107 |
} |
108 |
} |
109 |
------- |
110 |
|
111 |
> So, udev processes one event at a time, and always processes kernel |
112 |
> events with a higher priority than resulting scripts. This makes a |
113 |
> certain amount of sense; an action could launch, e.g. nbdclient, which |
114 |
> would cause a new kernel event to get queued. |
115 |
|
116 |
Yes, except that udev ONLY handles kernel-events and doesn't process any |
117 |
"actions" itself. |
118 |
These are placed on a seperate queue for a seperate process. |
119 |
|
120 |
> > If anyone has a setup where /usr can not be mounted easily, it won't |
121 |
> > work |
122 |
> > currently either and a init* would be necessary anyway. |
123 |
> > (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers,.... hosting |
124 |
> > /usr or other required filesystems) |
125 |
> |
126 |
> I don't see how this is relevant to actually fixing udev. (See below) |
127 |
> |
128 |
> > But anyone with a currently working environment should be able to expect |
129 |
> > a currently working environment. If it fails to boot with only updating |
130 |
> > versions, it's a regression. And one of the worst kinds of all. |
131 |
> |
132 |
> I agree that the direction udev is going is a regression. There aren't |
133 |
> very many people active in this thread who would disagree with that |
134 |
> point. So let's just drop it and focus on what a good, general |
135 |
> solution would look like. (And anyone who says something amounting to |
136 |
> 'status quo' for udev needs another explanation of why the udev |
137 |
> developer sees the current scenario as broken. And he's right; the |
138 |
> current scenario is architecturally unsound. I just think he's wrong |
139 |
> about the solution.) |
140 |
|
141 |
I agree he is wrong about the solution as well. |
142 |
|
143 |
I have actually just posted my idea to the gentoo-dev list to see how the |
144 |
developers actually feel about possible splitting udev into 2 parts. |
145 |
|
146 |
I'm not a good enough programmer to do this myself. But if anyone who can code |
147 |
and who also agrees with me that my idea for a solution is actually a good |
148 |
idea, please let me know and lets see how far we can get with implementing |
149 |
this solution. |
150 |
|
151 |
-- |
152 |
Joost |