David Zeuthen (david@xxxxxxxx) said: > 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 [1] accessible through a unified interface [2]. Once you have > that, it's not really hard to replace existing or write new policy > agents. 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 naming [1]. 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. > > 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 > > http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0769.html > > 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 on startup. 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. [2] Under udev, either: a) it works. This means that the driver has been loaded and udev has already run, hopefully. This means that some other process: - has loaded all the device modules. Ergo, every user has floppy, loop, nvram, etc loaded in nonswappable kernel memory. - has made random device nodes for them and trusted that kmod works. So, what exactly was the point of a dynamic /dev then? 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 are deficient. Bill [1] Yes, I've seen the examples in udev or the stuff proposed by OSDL. Next joke. [2] Yeah, I know the device name can change with udev. Doesn't solve this aspect without patching your apps either.....
