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