I.e., udev combines major+minor+name information from the kernel with the permissions policy (i.e., the thing that should not be in the kernel) expressed in its rules. In yet other words, the kernel doesn’t have enough information to create a device node in sysfs.

- what apps really really *want* are stable device names,
like /dev/disk/by-label/David-Zeuthens-iPod. They want
to e.g. save this name in their config files etc. Or you
want stable names in /etc/fstab or whatever.

- stable names are somewhat expensive to compute (probing
an fs for the fstype and fslabel; sending commands to a
serial device to figure out what kind of modem it is etc.)
and rely on both per-os, per-site and and per-machine policy.
Also, user space driver frameworks wants to participate here,
for example if I’m libgphoto2 or libmtp I want to somehow
create /dev/mtp/Sansa_e200 -> /dev/bus/usb/002/003

Hence why it’s good to put it in user space like we do now.

- Permissions. Figuring out the permission of a device node
may require pretty sophisticated user space components (like
PolicyKit) and you really want to ensure the permissions are
set before the device is announced to user space.

- The raw device file name (e.g. /dev/sda) are simply not
interesting; in fact it’s a bug that so many people store
it in config files etc. And that’s all you’d get from having device
nodes in sysfs.

While devfs-ish schemes can be cute and all, there’s just no
reason to do it in kernel space. And, FWIW, remember the last
time someone tried this in Linux? It was pretty much FAIL FAIL
FAIL all over the map.

[my personal opinion is that a minimal devfs would probably
work and even make things a bit simpler. But you'd need
stable names even in the initramfs anyway.]

- also, sysfs expresses the physical by-connection hierarchy,
it’s most often don’t what you want

- note that some devices don’t have file files; apps poke
them via sysfs files already so at least parts of what
you’re proposing is working like this (e.g. PCI devices,
I think libpciaccess mmaps files from sysfs)

- also, for some devices you may need to send commands / firmware
to them (for initialization) before you announce the device to
the rest of the OS. Some usb devices (I think ezusb but maybe
I got the name wrong) actually requires this; initially such
devices pop up as a vendor-specific usb devices; then you load
firmware onto them and then the device reboots (e.g. the usb
device disappears from the host’s POV) and then come back as a
different usb device. So e.g. you need some way of expressing
this and with udev it works just fine.

I hope this clarifies why udev is very useful as it does all this
today; I’m not exactly sure what part of the current udev you’re
unhappy with and how you propose to solve all the problems above
by switching to a pure devfs (as you are suggesting) solution?

2. Creating and maintaining /dev files - As long as this is suitably buried beneath the hardware abstraction library, it’s fairly irrelevant to desktop application developers how it works. Anything that works is great.