On Sat, 18 Apr 2009 21:22:34 -0500
"Mumia W." <paduille.4061.mumia.w+nospam@earthlink.net> wrote:
> Yes, that's the braindamage that I and millions of other Linux users
> would prefer to have nothing to do with.
I don't understand what is brain-damaged about that. We now have
extremely robust filesystem mounting; you can move disks around in any
configuration, or boot from something else entirely, and
your /etc/fstab can still find the filesystem because it uses a unique
ID to find it.
This is better than the whole disk-ID that Windows uses for a couple of
reasons:
1. It's more granular.
2. It uses UUIDs instead of very small and easily clashable
identifiers.
Also, it is more robust; you can move a partition from one drive to
another and the system will still know _exactly_ what you mean when you
want to mount that filesystem.
> What I'm saying is that it is not /impossible/ for the kernel
> developers to assign devices in a rational, consistent order since
> they've actually done it. What scares me is that the solution is
> "deprecated," and one day we'll all be forced into udev. If I were to
> "upgrade" to SATA, I would be forced today.
Older hardware environments (in the x86 world) provided more assurances
and were easier to enumerate in a deterministic fashion. New buses are
_not_ easy to do that with.
WRT to software in general, consistency is always better than the
alternative. I have the feeling that this is probably the general idea
here, too. Consistency is better than special cases. udev is a 100k
binary, so I don't see the big fuss; that is no trouble size-wise for
today's embedded devices, let alone a desktop workstation or a server.
On my system it uses less than 1 MiB of RAM (I am not counting shared
memory that belongs to libraries, since they're already loaded for
other processes), which also is affordable.
For an environment that is so resource-constrained that it *can't*
afford 700k of cost, and mostly sleeping (mine has used 00:00:00 of CPU
time in 39 days of uptime). On my server, it's taking up approx. the
same RAM, and no measurable CPU time in six months of uptime.
> And I don't think that the PCI spec. is to blame. Just because
> devices don't start up in order does not mean that those devices
> don't have numbers. Those numbers would be used to order the devices,
> and if that slows down the boot by a few seconds--so what.
No, we can blame the overall architecture of x86 systems and new buses;
ACPI and all these new things that "solve" old "problems". Things may
be different on other platforms, I don't know. I don't have anything
other than the PS3 and my ADP1 that runs Linux; I can't look at the PS3
at the moment, but the ADP1 has no udevd; it doesn't need it though, it
has one mmcblk dev, a fixed number of mtd devices, and a fixed number
of loopback devices. Everything else about the platform is fixed, too,
so udevd is unnecessary on it. (It is running Linux 2.6.25.)
Some of it, I get. It used to be that devices were extremely limited
and expansion was hardly possible.
However, today we have things like USB, 1394, and other new buses which
don't provide any guarantees. You can have the same devices in the
same ports and they'll wind up being initialized in a different order
every time. Hell, Windows (last I checked) _still_ didn't get USB
device enumeration right. If Windows thinks it's moved at all, it has
to install a new device driver because it's changed location.
That said, there would be other things to take udev's place, whether
those be scripts or other things. Also, udev won't show nodes for
things that don't exist, making life easier (at least, IMHO). I never
really liked having to add device nodes and remove them myself anyway.
--- Mike
--
The start of a journey should never be mistaken for success.
FAQ
Search
Profile
Private Messages
Log in
Linux