1 |
> From: Alan McKinnon [mailto:alan.mckinnon@×××××.com] |
2 |
|
3 |
> OK, semantics. Let me re-phrase: |
4 |
> |
5 |
> Why is a third party script, running in the context of the udev universe, |
6 |
> indiscriminately allowed to launch daemons at early boot time? |
7 |
> |
8 |
> I don't think I agree with Neil in that this is a udev design flaw (as any |
9 |
"fix" will |
10 |
> be worse than the "flaw"). Instead it looks to me like a classic case of |
11 |
> |
12 |
> "You are free to do anything you want but if you break it you keep the |
13 |
> pieces. If you do something stupid, it's not my problem and you're on your |
14 |
> own." |
15 |
|
16 |
This is, unfortunately, the biggest drawback to having a commercial entity |
17 |
in charge of doing the software development: this kind of attitude stops |
18 |
applying. Gentoo's developers, for example, would really like for people to |
19 |
use Gentoo, and work hard to make Gentoo useable, but if you start with the |
20 |
threats of "I'm gonna stop using your OS unless you fix this RIGHT NOW!" |
21 |
they'll probably just roll their eyes and ignore you. RedHat has a |
22 |
*commercial* interest in people using RedHat, even the non-commercial |
23 |
versions, and if their *customers* start filing bugs like "I cannot make my |
24 |
Bluetooth keyboard work with my nfs mounted /usr that plays a ring tone |
25 |
through alsa when I mount it", they are much more motivated to fix it. |
26 |
|
27 |
> I see nothing wrong with udev applying some reasonable constraints such as |
28 |
> clearly documenting at what point in the boot process udev is in a |
29 |
position to |
30 |
> arbitrarily run anything. Earlier than that point, "anything" does not |
31 |
actually |
32 |
> apply. |
33 |
|
34 |
I don't think it's a design flaw, as much as it's a possible point of |
35 |
improvement for udev. It would be useful if udev could somehow distinguish |
36 |
between "early" and "late" devices. This doesn't eliminate the problem |
37 |
entirely: nothing is stopping you from, say, telling udev that mounting /usr |
38 |
requires /usr/mountme. But if you did something that silly, it would |
39 |
obviously be your fault. |
40 |
|
41 |
I think there are some options for how udev could be better here, it's just |
42 |
that they all seem to be a lot of risk; as much risk or more as just saying |
43 |
"don't do that or use an initramfs." Off the top of my head: |
44 |
|
45 |
* udev could enforce that point you mention, and allow device scripts to |
46 |
explicitly say "defer trying to configure me until after $KEYPOINT has been |
47 |
reached." |
48 |
* udev could keep track of dependencies between devices or device scripts |
49 |
and allow one to say "don't run me until $DEVICE is also present" |
50 |
* udev could keep track of prerequisite triggers for device scripts, and |
51 |
allow one to say "don't run me until /usr/bin/alsaconf exists, but run me as |
52 |
soon as that appears." |
53 |
* udev could keep track of failed devices, and include a command-line switch |
54 |
like --reprocess; the init process could launch udev, allow whatever fails |
55 |
to fail, mount /usr, then tell udev to try again. |
56 |
|
57 |
As I understand it, the architecture of udev (and the kernel) makes many of |
58 |
these difficult; udev events are processed individually, isolated from each |
59 |
other. It has no concept of things like "when I'm done configuring devices" |
60 |
or "devices that are waiting to be configured after this one". Though |
61 |
keeping track of failed devices seems like it would not be terribly |
62 |
difficult, as long as you could distinguish btween devices that are fatal |
63 |
failures vs. transient ones. |
64 |
|
65 |
Again, I'm not faulting the udev team for not doing those things. They |
66 |
either do a lot of work to update the behavior of udev to support a |
67 |
configuration they think is invalid and broken, or they simply tell people |
68 |
to stop using the invalid or broken configuration. If there were a clear |
69 |
consensus that the configuration was not, in fact, broken, then I could |
70 |
possibly see where they might be expected (from a /community/ perspective, |
71 |
clearly they have no /formal/ obligations to any of us) to put in that |
72 |
effort. But the consensus seems largely weighted towards agreeing with them, |
73 |
or at least not caring either way. |
74 |
|
75 |
--Mike |