will be gladly ignored.
-First off, some background. For a description of udev, and what it's
+First off, some background. For a description of udev, and what its
original design goals were, please see the OLS 2003 paper on udev,
available at:
<http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf>
In that OLS paper, I described the current situation of a static /dev
and the current problems that a number of people have with it. I also
detailed how devfs tries to solve a number of these problems. In
-hindsight, I should have never mentioned the word, devfs, when talking
+hindsight, I should have never mentioned the word "devfs" when talking
about udev. I did so only because it seemed like a good place to start
with. Most people understood what devfs is, and what it does. To
compare udev against it, showing how udev was more powerful, and a more
to name devices in a persistent manner. More on that below.
4) udev emits D-BUS messages so that any other userspace program
(like HAL) can listen to see what devices are created or removed.
- It also allows userspace programs to query it's database to see
+ It also allows userspace programs to query its database to see
what devices are present and what they are currently named as
(providing a pointer into the sysfs tree for that specific device
node.)
want to deviate away from this standard (for example when naming
some devices in a persistent manner), it is easily possible to do
so.
- 3) udev is small (49Kb binary) and is entirely in userspace, which
+ 3) udev is small and is entirely in userspace, which
is swapable, and doesn't have to be running at all times.
Nice, 7 out of 7 for udev. Makes you think the problems and constraints
were picked by a udev developer, right? No, the problems and
constraints are ones I've seen over the years and so udev, along with
the kernel driver model and sysfs, were created to solve these real
-problems.
+problems. I also have had the luxury to see the problems that the
+current devfs implementation has, and have taken the time to work out
+something that does not have those same problems.
So by just looking at the above descriptions, everyone should instantly
realize that udev is far better than devfs and start helping out udev
Yes, that's right, 6Kb. So, you are asking, why are you still working
on udev if it did everything devfs did back in May 2003? That's because
just managing static device nodes based on what the kernel calls the
-devices is _not_ the primary goal of udev. It's just a tiny side affect
-of it's primary goal, the ability to never worry about major/minor
+devices is _not_ the primary goal of udev. It's just a tiny side effect
+of its primary goal, the ability to never worry about major/minor
number assignments and provide the ability to achieve persistent device
names if wanted.
and read the previous paragraph. Yes, all Gentoo users who keep filling
up my inbox with smoking emails, I mean you.
-So, how well does udev solve it's goals:
+So, how well does udev solve its goals:
Prevent users from ever worrying about major/minor numbers
And here you were, not knowing you ever needed to worry about
major/minor numbers in the first place, right? Ah, I see you
As the above scenarios show, both desktop users and big iron users
both need to not worry about which device is assigned to what
major/minor device.
-
+
udev doesn't care what major/minor number is assigned to a device.
It merely takes the numbers that the kernel says it assigned to the
device and creates a device node based on it, which the user can
For more information on how to create udev rules to name devices,
please see the udev man page, and look at the example udev rules
that ship with the tarball.
-
+
So, convinced already why you should use udev instead of devfs? No.
Ok, fine, I'm not forcing you to abandon your bloated, stifling policy,
~ianmdlvl / elogind.git / blobdiff