Post by David Zeuthen
Which is planned to be added upstream in hal - in a nutshell, what is
needed for auto configuration of hardware is some mechanism to store
configuration data about physical and logical devices in a persistent
manner  accessible through a unified interface . Once you have
that, it's not really hard to replace existing or write new policy
A good chunk of this is per-system, not per device. The main
purpose of most of the aliases these days is to enforce some sort
of reasonable ordering, which is needed in lieu of persistent device
Realistically, all the aliases written by kudzu these days are for is:
a) enforcing ordering among scsi devices
b) enforcing ordering among sound devices
c) allowing network devices to be brought up if the driver isn't already
loaded (which usually means it's been manually removed)
d) parport_serial (its own weirdness)
e) allowing video devices to be loaded on demand
c) and e) could conceivably go away right now.
If you're looking per-device, you can add this sort of ordering/indexing
there, but I'm not sure that's the most efficent.
Post by David Zeuthen Post by Bill Nottingham
Of course, foisting complication on userspace from the kernel seems
to be the way to go these days, judging by udev. :)
Heh, actually one thing I like about udev is the fact that it made
a lot of *existing* bugs and hacks like inserting "sleep 2" visible.
Oh wait, Greg KH already explained this here
and in surrounding messages :-)
Oh my goodness.
OK, first. 'sleep 2'? Part of the udev stack still is userspace busy
waiting on the kernel. It's not making the hack more visible, it's
just moving it somewhere else.
That's the majority of what udev does... it just merely moves
all the races and oddness to userspace. It's a case of the kernel saying
'here, I don't want to deal with these problems, I'm going to
break your access model based on the deficiences of some buses, have
fun reorienting to fix it.'
And then leaves userspace to clean up the mess.
For example, because of the wonders of udev:
- Take the example of a sound card. You want to restore the volume
Under previous configurations, you needed to know the name of the
command to restore sound. You then added it to modules.conf.
Under udev you need to create a dev.d script to run, which means:
- your script needs to know the sysfs layout of the device,
which of course never changes (to avoid running extraneously)
- because you never get a 'this driver is done creating devices'
signal, you need to either
a) sleep a random amount of time
b) run the restore command multiple times
Repeat this scenario for other devices.
How is this progress?
- Say an app wants to use some sort of random device, not
really tied to a piece of hardware.
Under previous configurations, they opened the device, and
either got ENODEV, or continued successfully. 
Under udev, either:
a) it works. This means that the driver has been loaded
and udev has already run, hopefully. This means that some
- has loaded all the device modules. Ergo, every user
has floppy, loop, nvram, etc loaded in nonswappable
- has made random device nodes for them and trusted
that kmod works. So, what exactly was the point of a dynamic
b) it fails with -ENOENT
Hopefully, that means there's no device. But if
someone decided to remove a module like nvram earlier...?
Then the *app* needs to know what driver to load, and
create its own dev.d script to notify itself that the
device is ready.
I'm sure there can be more examples.
It's true that there are many classes of devices that require
an asynchronous framework to work correctly. I'm not convinced
that adding the same handicaps to all the device types, Harrison
Bergeron-style, is a well thought out design. It's akin to
making apps that use dlopen() or apps that link library dependencies
parse text files for every link libraries because some platforms' linkers
 Yes, I've seen the examples in udev or the stuff proposed by
OSDL. Next joke.
 Yeah, I know the device name can change with udev. Doesn't
solve this aspect without patching your apps either.....