1 |
On Jan 5, 2012 7:10 PM, "Alan McKinnon" <alan.mckinnon@×××××.com> wrote: |
2 |
> |
3 |
> On Thu, 05 Jan 2012 09:17:23 +0100 |
4 |
> pk <peterk2@××××××××.se> wrote: |
5 |
> |
6 |
> > On 2012-01-05 08:43, Alan McKinnon wrote: |
7 |
> > |
8 |
> > > I fiddle around a lot with the hardware on those and udev deals with |
9 |
> > > that nicely considering udev is designed to deal with that nicely. |
10 |
> > |
11 |
> > I confess to being quite ignorant when it comes to what magic udev |
12 |
> > does behind the scenes but what makes it different to any other device |
13 |
> > manager (well, I don't know any other than mdev but...)? I.e. what |
14 |
> > technical problem(s) does udev solve that no other device manager |
15 |
> > can't? What is the technical need for something else than a device |
16 |
> > file under /dev that can be used to communicate with the kernel? |
17 |
> > |
18 |
> > What I mean is: If you say "... considering udev is designed to deal |
19 |
> > with that..." you seem to indicate that you know what it does and why |
20 |
> > it does what it does... and henceforth the technical reason why the |
21 |
> > rearrangements of the file system hierarchy is necessary... |
22 |
> |
23 |
> I don't claim any special deep knowledge of these things, but a |
24 |
> superficial glance over the packages tells you a lot. udev is designed |
25 |
> to deal with any realistic device needs on modern systems - it's the |
26 |
> kitchen sink. |
27 |
> |
28 |
> mdev has a much narrower scope where things are considerably more |
29 |
> static. |
30 |
> |
31 |
> As for re-arranging the fs layout, I think it was Canek in the last |
32 |
> thread that gave an excellent example of why this is needed. When |
33 |
> devices hotplug, or need to become active early on in the boot process, |
34 |
> they need to run code that can be located almost anywhere. It wouldn't |
35 |
> be fun trying to get a wireless keyboard going when it's start-up |
36 |
> script needs to get into /usr/lib/firmware and /usr isn't mounted yet. |
37 |
> |
38 |
> The example was something along the lines of a machine that has no |
39 |
> physical keyboard or a port for one, it uses a bluetooth keyboard. But |
40 |
> the main file systems are encrypted using a key that's on a smartcard. |
41 |
> To decrypt and mount the filesystems, the drivers for keyboard, |
42 |
> bluetooth and smart card, plus all firmware, needs to be loaded first. |
43 |
> This is actually not all that far-fetched, and it's a classic bootstrap |
44 |
> problem first solved in the 60s. It much more complex now than it was |
45 |
> then but the principles behind the solution are much the same. |
46 |
> |
47 |
> I do agree with collapsing the executable code in /usr into /, or |
48 |
> having /usr on the root partition. A separate /usr/{,s}bin is pretty |
49 |
> pointless and was never done for safety or maintenance reasons. It was |
50 |
> done way way way back when disks were small and a convenient hack was |
51 |
> to keep the OS on the boot device and user apps somewhere else on |
52 |
> bigger but slower storage (which often was remote). |
53 |
> |
54 |
> If /usr is local, what really is the point of having it separate |
55 |
> from /? Have you ever found a Linux system in any condition that could |
56 |
> not start just because the stuff in /usr was available? I haven't. |
57 |
> |
58 |
> Even the split between bin and sbin is arbitrary. It's only there so |
59 |
> that users can take sbin out of PATH and not have the screen cluttered |
60 |
> with endless junk when they tab-tab. It makes much more sense to me to |
61 |
> just have one single bin and lib location and shove everything into it. |
62 |
> |
63 |
> What I do object to is any possible idea that an initramfs will be |
64 |
> *required* regardless. I know this isn't on the table just yet, but |
65 |
> it's a very small amount of creep before it is. |
66 |
> |
67 |
> > |
68 |
> > > Becoming rather lazy in my old age is getting to be a factor too |
69 |
> > |
70 |
> > Ho hum... so "you lazy old fart" is true then? ;-) |
71 |
> |
72 |
> Dunno about lazy old fart, but splog (snarky pedantic lazy old git) |
73 |
> definitely is. I think we decided that Neil is the lazy old fart :-) |
74 |
> |
75 |
|
76 |
After some soul-searching (yes, I still have one despite learning from |
77 |
BOFH), I think I'll agree with Alan... with some caveats. |
78 |
|
79 |
I have less resistance to requiring /usr to be part of /. The way I see it, |
80 |
I can still do some bind mount black magic to provide a minimal /usr for |
81 |
booting yet isolating the 'real' /usr to prevent it messing up the rootfs. |
82 |
|
83 |
As to udev, I still think it's an overkill for a static server environment. |
84 |
With virtualization, I can *guarantee* that the (virtual) hardware |
85 |
environment will never change. For these environments, I much prefer mdev |
86 |
to udev. |
87 |
|
88 |
Finally, regarding initramfs, I wholly agree. Don't force me to use one. A |
89 |
server is already a complex system, and adding complexity won't end up |
90 |
pretty. |
91 |
|
92 |
Rgds, |