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