1 |
On Thu, Sep 15, 2011 at 10:32 AM, Michael Mol <mikemol@×××××.com> wrote: |
2 |
> On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld <joost@××××××××.org> wrote: |
3 |
>>> I'm not entirely convinced this is the case, because it feels like |
4 |
>>> some situations like network devices (nbd, iSCSI) or loopback would |
5 |
>>> require userland tools to bring up once networking is up. |
6 |
>> |
7 |
>> Yes, but the kernel-events referencing those devices won't appear untill after |
8 |
>> the networking is brought up. |
9 |
>> The scripts that "udev" starts are run *after* a device-event is created. If |
10 |
>> the device itself has not been spotted by the kernel (for instance, the |
11 |
>> networking doesn't exist yet), the event won't be triggered yet. |
12 |
>> |
13 |
>> This situation does not require udev to start all these tools when network- |
14 |
>> devices appear. |
15 |
>> |
16 |
>> I hope the following would make my thoughts a bit clearer: |
17 |
>> |
18 |
>> 1) kernel boots |
19 |
>> |
20 |
>> 2) kernel detects network device and places "network-device-event" in the |
21 |
>> queue |
22 |
>> |
23 |
>> 3) further things happen and kernel places relevant events in the queue (some |
24 |
>> other events may also already be in the queue before step 2) |
25 |
>> |
26 |
>> 4) udev starts and starts processing the queue |
27 |
>> |
28 |
>> 5) For each event, udev creates the corresponding device-entry and places |
29 |
>> action-entries in a queue |
30 |
>> |
31 |
>> 6) system-init-scripts mount all local filesystems |
32 |
>> |
33 |
>> 7) udev-actions starts (I made up this name) |
34 |
>> |
35 |
>> 8) udev-actions processes all the entries in the action-queue |
36 |
>> |
37 |
>> From step 4, udev will keep processing further events it gets, which means |
38 |
>> that if any action taken by "udev-actions" causes further devices to become |
39 |
>> available, "udev" will create the device-entries and place the action in the |
40 |
>> action-queue. |
41 |
> |
42 |
> So, if I read this correctly, there are two classes of processing |
43 |
> events. kernel events and scripted actions. Here's rough pseudocode |
44 |
> describing what I think you're saying. (Or perhaps what I'm hoping |
45 |
> you're saying) |
46 |
> |
47 |
> while(wait_for_event()) |
48 |
> { |
49 |
> kevent* pkEvent = NULL; |
50 |
> if(get_waiting_kernel_event(pkEvent)) // returns true if an event was waiting |
51 |
> { |
52 |
> process_kernel_event(pkEvent); |
53 |
> } |
54 |
> else |
55 |
> { |
56 |
> aevent* pAction = NULL; |
57 |
> if(get_waiting_action(pAction)) // Returns true if there's an |
58 |
> action waiting. |
59 |
> { |
60 |
> process_action(pAction); |
61 |
> } |
62 |
> } |
63 |
> } |
64 |
> |
65 |
> So, udev processes one event at a time, and always processes kernel |
66 |
> events with a higher priority than resulting scripts. This makes a |
67 |
> certain amount of sense; an action could launch, e.g. nbdclient, which |
68 |
> would cause a new kernel event to get queued. |
69 |
> |
70 |
>> If anyone has a setup where /usr can not be mounted easily, it won't work |
71 |
>> currently either and a init* would be necessary anyway. |
72 |
>> (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers,.... hosting /usr |
73 |
>> or other required filesystems) |
74 |
> |
75 |
> I don't see how this is relevant to actually fixing udev. (See below) |
76 |
> |
77 |
>> But anyone with a currently working environment should be able to expect a |
78 |
>> currently working environment. If it fails to boot with only updating |
79 |
>> versions, it's a regression. And one of the worst kinds of all. |
80 |
> |
81 |
> I agree that the direction udev is going is a regression. There aren't |
82 |
> very many people active in this thread who would disagree with that |
83 |
> point. So let's just drop it and focus on what a good, general |
84 |
> solution would look like. (And anyone who says something amounting to |
85 |
> 'status quo' for udev needs another explanation of why the udev |
86 |
> developer sees the current scenario as broken. And he's right; the |
87 |
> current scenario is architecturally unsound. I just think he's wrong |
88 |
> about the solution.) |
89 |
|
90 |
Let me throw my own guess of how they came out with the corrent |
91 |
proposed solution. I repeat: is my own guess: I am not the one calling |
92 |
the shots, so maybe I'm completely wrong. |
93 |
|
94 |
As many of you guys said, there are ways of solving the problem |
95 |
without requiring an initramfs. Note that if you decide to use an |
96 |
initramfs, every use case works: You can have a practically empty /, |
97 |
throw everything in /usr, and have /usr in another partition, maybe |
98 |
even an encrypted remote NFS share. With an initramfs you can have a |
99 |
separate /var, you can even have a separated /etc, mounted even by NFS |
100 |
too. You can do pretty much whatever you want, because you have a full |
101 |
userspace *the moment you boot*. Bluetooth, network, LVM, |
102 |
crypto-filesystems: Everything is available from the instant zero. |
103 |
|
104 |
From that perspective, the problem then is trying to support the |
105 |
initramfs-less setups. Putting myself in the shoes of the developers, |
106 |
the smart solution is to simply force an initramfs. KISS is to force |
107 |
an initramfs, because it solves everything. The Gentoo devs are |
108 |
working in a minimal initramfs that works for most "normal" usecases. |
109 |
Everything else will be handled by dracut or genkernel. |
110 |
|
111 |
An initramfs is not an initrd. And is not a binary blob coming who |
112 |
knows from where; with dracut, your initramfs is simply a subset of |
113 |
your normal installation, and can be as simple (just mount /usr) or as |
114 |
complicated (LVM+crypto+network+NFS+whatever) as you want. |
115 |
|
116 |
Of course you can solve it differently, for example splitting udev as |
117 |
Joost proposes. But then is more code to maintain, and the number of |
118 |
possible setups is suddenly the double it was before. It. Is. Not. |
119 |
KISS. |
120 |
|
121 |
It's a lot like the CUPS/lprng situation we discussed before. CUPS can |
122 |
do anything that lprng does, so it makes no sense to keep support for |
123 |
lprng. It's the same: with an initramfs you will be able to do |
124 |
anything, so it will make no sense to keep supporting initramfs-less |
125 |
systems. |
126 |
|
127 |
That's how I see it. |
128 |
|
129 |
Regards. |
130 |
-- |
131 |
Canek Peláez Valdés |
132 |
Posgrado en Ciencia e Ingeniería de la Computación |
133 |
Universidad Nacional Autónoma de México |