Gentoo Archives: gentoo-user

From: Mike Edenfield <kutulu@××××××.org>
To: gentoo-user@l.g.o
Subject: RE: [gentoo-user] Re: InitRAMFS - boot expert sought
Date: Thu, 29 Mar 2012 22:13:07
Message-Id: 00b601cd0df8$cb448bd0$61cda370$
In Reply to: Re: [gentoo-user] Re: InitRAMFS - boot expert sought by Alan McKinnon
1 > From: Alan McKinnon [mailto:alan.mckinnon@×××××.com]
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."
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.
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.
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.
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:
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.
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.
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.
75 --Mike