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/