Messages in this thread | | | Date | Fri, 18 Jun 1999 20:25:33 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: UUIDs (and devfs and major/minor numbers) |
| |
Date: Fri, 18 Jun 1999 18:17:16 -0400 From: "Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net>
We're all pretty much agreed that device major and minor numbers are something of a problem, especially when it comes to hot-pluggable devices. So what alternatives might there be?
Actually, I'm not convinced that major/minor numbers are the problem. Right now we have our choice between statically allocated major/minor numbers, which admittedly can be a problem because you have to deal with a central registry (although I don't that problem is *that* bad yet!), or purely dynamic major numbers which have the problem that it's hard to create the devices with the correct major number. (Althoguh this problem can be solved; I dealt with it in the Comtrol Rocketport driver's rc.d script, before I got a statically allocated major number.)
Having a range of major numbers which are assigned dynamically isn't really a problem if you have a user-mode daemon which can deal with creating the devices if necessary. (And I think almost everyone participating in this discussion recognizes that having a user-mode daemon is a good and useful strategy.) The kernel and the user-mode daemon can also (without not much difficulty) connive to make sure that when a device disappears from a system and plugged back in later, that the same major number is reused.
I do agree with you having having a unique string-based, self-descriptive device ID is a good thing, but instead of using that ID *instead* of the major/minor devices, why not have the kernel export a mapping table between the string ID and the major/minor devices to the user mode daemon, and then letting the user mode deamon crate the appropriate device files if necessary? This solves the NFS backwards compatibility problem, for example.
It also deal with the problem that symlinks into /devices doesn't solve: the permissions problem. By using real, traditional block/character mode device files in /dev, we can solve the ownership/group/permissions problem extremely easily.
As far as trying to find all of the CD-ROM's present in the system, or all of the some particular type of device, if applications really badly need this sort of thing, it's a really bad idea to tell them that they can do this by scanning /dev in some fashion. That would lock us into that way of doing things forever. Instead, we should specify and publish a general API for doing this! That way, if we later decide that we want to change how to obtain that information, we can change a shared library without having to force all of the application programs to recode their programs.
If we use this approach, it also means that we can also solve the problem for existing systems by having that API (let's call it the device-lookup API) consult a static file (or set of files) to find the information which cdparanoia or some other application wants. It would also be trivial to make the PCMCIA manager edit that file when a PCMCIA CD-ROM drive was inserted or removed into the system. This would allow applications to have the benefits of such an API right away, without having to wait for 2.4, or some more complicated scheme (whether it be devfs or -- I hope --- something cleaner) to be deployed into the mainstream kernel.
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |