Messages in this thread | | | Subject | Re: UUIDs (and devfs and major/minor numbers) | Date | Sat, 19 Jun 1999 10:38:22 -0400 | From | "Brandon S. Allbery KF8NH" <> |
| |
In message <199906190025.UAA07516@tsx-prime.MIT.EDU>, "Theodore Y. Ts'o" writes : +----- | 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. +--->8
Nit: I didn't say "the" problem, I said "something of a problem". It's not a major issue now, but clearly it will be: not only because of e.g. SCSI device spaces which keep straining the limits, but also because of hot-swappable devices which need to grab device IDs on the fly.
The device number space works when you have a relatively fixed device "address space". PCMCIA could be accomodated because there's generally only two PCMCIA slots in a machine; USB, FireWire, etc. (and ADB on LinuxPPC!) make the problem potentially much larger.
That's also why I said it was probably a Linux 3.0 issue. Although if USB and/or FireWire catch on, we might need it sooner....
| or purely dynamic major numbers which have the problem that it's hard to | create the devices with the correct major number. (Althoguh this +--->8
Major numbers are easy to cope with via /proc/devices; certainly easier than the fun I had trying to script creation of Arla's /dev/xfs0 on FreeBSD 3.1 (2.x passes the major number to a device creation script, it's 3.x's ELF kernel modules that are a pain, as the major number is apparently only available by parsing the syslog... [granted, it might be hidden somewhere that neither the Arla folks nor I noticed]).
Minor device numbers are easy to deal with for specific hardware such as the RocketPort. But what about (theoretical?) FireWire CDROM jukeboxes?
| appropriate device files if necessary? This solves the NFS backwards | compatibility problem, for example. +--->8
Actually, it occurred to me afterward that backward compatibility is a non-issue because in both cases, the devices are never used to access resources operated by the new kernel: NFS devices are implemented by the client, and booting to an old kernel just uses the old devices. And in the new kernel, the old devices are merely "lumps" in the filesystem (which presumably return ENXIO on all accesses in the new system).
Actually, the biggest NFS-related problem with the proposal is that if an non-devnamespace NFS client accesses an NFS-exported devnamespace device, the device access gets handled by the NFS server; this can't happen with any NFS implementation currently, barring possible vendor extensions. OTOH that might be considered a feature in some quarters....
| 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 +--->8
Well, yes; but currently that's how we deal with all the information in /proc (and for the anti-/proc types: sysctl() isn't a solution). I didn't address that part because it's already a problem that needs to be dealt with in some fashion.
The GNOME project's libgtop library is such an alternative API, BTW, although its author chose to use GPL instead of LGPL so commercial programs can't use it (but *that* issue belongs in gnu.misc.discuss, not here!). So is Solaris's /usr/proc and earlier /usr/kvm stuff, although those are a bit weaker and (for /usr/proc on 2.5.1, at least) not especially well documented.
-- brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net system administrator [WAY too many hats] allbery@ece.cmu.edu carnegie mellon / electrical and computer engineering KF8NH We are Linux. Resistance is an indication that you missed the point.
- 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/
| |