1 |
On Thursday, September 15, 2011 10:57:27 AM Canek Peláez Valdés wrote: |
2 |
|
3 |
<snipped to keep only the email from Canek> |
4 |
|
5 |
> Let me throw my own guess of how they came out with the corrent |
6 |
> proposed solution. I repeat: is my own guess: I am not the one calling |
7 |
> the shots, so maybe I'm completely wrong. |
8 |
|
9 |
Ok and I do actually think you are correct with your guess as to why the |
10 |
developer came up with his solution. |
11 |
|
12 |
> As many of you guys said, there are ways of solving the problem |
13 |
> without requiring an initramfs. Note that if you decide to use an |
14 |
> initramfs, every use case works: You can have a practically empty /, |
15 |
> throw everything in /usr, and have /usr in another partition, maybe |
16 |
> even an encrypted remote NFS share. With an initramfs you can have a |
17 |
> separate /var, you can even have a separated /etc, mounted even by NFS |
18 |
> too. You can do pretty much whatever you want, because you have a full |
19 |
> userspace *the moment you boot*. Bluetooth, network, LVM, |
20 |
> crypto-filesystems: Everything is available from the instant zero. |
21 |
|
22 |
For these specific custom environments, yes, I agree. An initramfs is |
23 |
mandatory. |
24 |
|
25 |
> From that perspective, the problem then is trying to support the |
26 |
> initramfs-less setups. Putting myself in the shoes of the developers, |
27 |
> the smart solution is to simply force an initramfs. KISS is to force |
28 |
> an initramfs, because it solves everything. The Gentoo devs are |
29 |
> working in a minimal initramfs that works for most "normal" usecases. |
30 |
> Everything else will be handled by dracut or genkernel. |
31 |
|
32 |
Initramfs is already supported. so is initramfs-less. |
33 |
|
34 |
> An initramfs is not an initrd. And is not a binary blob coming who |
35 |
> knows from where; with dracut, your initramfs is simply a subset of |
36 |
> your normal installation, and can be as simple (just mount /usr) or as |
37 |
> complicated (LVM+crypto+network+NFS+whatever) as you want. |
38 |
|
39 |
I haven't looked at dracut yet, but as far as I understand, it does create an |
40 |
initramfs with the script(s), libraries and binaries needed to start whatever |
41 |
is needed to get to the stage where udev is happy. |
42 |
|
43 |
> Of course you can solve it differently, for example splitting udev as |
44 |
> Joost proposes. But then is more code to maintain, and the number of |
45 |
> possible setups is suddenly the double it was before. It. Is. Not. |
46 |
> KISS. |
47 |
|
48 |
Depends on your definition of Simple. |
49 |
|
50 |
> It's a lot like the CUPS/lprng situation we discussed before. CUPS can |
51 |
> do anything that lprng does, so it makes no sense to keep support for |
52 |
> lprng. It's the same: with an initramfs you will be able to do |
53 |
> anything, so it will make no sense to keep supporting initramfs-less |
54 |
> systems. |
55 |
|
56 |
The situation with Cups and lprng is different. |
57 |
If either of these fail, the system will still boot and then you can spend the |
58 |
time to fix the problem. |
59 |
|
60 |
If this change continues, an initramfs failure, will mean the system will not |
61 |
boot correctly. And when all the tools needed to fix the system are moved to |
62 |
/usr, what options are there to actually analyse and solve the problem? |
63 |
|
64 |
In my opinion, the simplest solution will be to make the tool(s) do what |
65 |
they're supposed to do. |
66 |
udev should, in my opinion, create the devices in userspace. |
67 |
That it also allows for programs/scripts to be executed when a device is |
68 |
created is a nice thing to have. |
69 |
Unfortunately, this leads to chicken-and-egg style problems when the scripts |
70 |
are on a filesystem that hasn't been mounted yet. |
71 |
|
72 |
There are 3 solutions for this: |
73 |
1) The easy way out: the whole user-space must be available before udev |
74 |
2) udev actually includes correct error-handling for this and retries |
75 |
3) udev splits this into 2 seperate tools |
76 |
|
77 |
Option 1 is what is currenty proposed and what you appear to be in favour off. |
78 |
Except, what is the point of having "udev" when the entire user-space already |
79 |
exists before it starts? |
80 |
You yourself said it's nice to have everything already available from the |
81 |
beginning. But isn't the problem that udev can't start bluetoothd because |
82 |
/usr/bin/bluetoothd can't be found when /usr doesn't exist yet? |
83 |
|
84 |
How would udev handle a situation where I have /usr on my mobile phone which |
85 |
shares the filesystem over bluetooth? |
86 |
|
87 |
Option 2 has been suggested and rejected. And I happen to agree with this as |
88 |
it would make udev, a vital part of the system, bigger and will increase the |
89 |
chances of problems/bugs. |
90 |
|
91 |
Option 3, which I have proposed, would actually make the first part smaller |
92 |
and simpler. |
93 |
The action-handling can then be run at a later stage, when /usr is available |
94 |
and could then easier implement a retry-queue. With this being a seperate |
95 |
tool, not needed for the /dev-tree creation, failure on this should not lead |
96 |
to an unusable system. |
97 |
|
98 |
-- |
99 |
Joost |