Actually, I find "scheme" very relevant for some non-PCMCIA
devices; specifically, network interfaces. I've had linux systems
(desktops, not just laptops) being moved between 3 or 4 locations each
day. For each system, each location implies a new IP address, a new
gateway, etc... stuff that DHCP might be useful for, except it isn't
deployed. I use user-level scripts to alter the files in /etc prior
to loading device drivers. As root, I manually select the current
configuration, although I think that in most cases I really ought to
be able to dynamically probe for gateways and automatically select the
appropriate /etc files.
I've also had SCSI peripherals that I've moved between systems
(including laptops, thanks, David!), especially SCSI hard drives. I
manually run a script to adjust the mount points to the hard drive
I've plugged in. I've considered putting an easily-read volume label
file in each of my partitions ("VOLUME.SYS"? ".volume"?) to automate
mount point selection.
We should create user-level resource management programs to
keep track of our disks, tapes, network interfaces, etc. according to
rules that are specified by the system administrator. These programs
will update files in "/etc" and "/dev", with appropriate file
protections. These programs will need information about SCSI channel,
ID, and LUN, but there may be better ways to get it than via the minor
device number.
Instead of creating sophisticated partitions of the minor
device ID field, consider simple sequential assignment of minor
numbers as devices are found, while creatina a "/proc" table entry
that provides detailed information about the the device. For example,
picking numbers at random:
directory /dev:
/dev/sda 8,0
/dev/sda1 8,1
/dev/sda2 8,2
file /proc/dev:
8,0 Host: scsi0 Channel: 00 Id: 05 Lun: 00
8,1 Host: scsi0 Channel: 00 Id: 05 Lun: 00 Partition: 1
8,2 Host: scsi0 Channel: 00 Id: 05 Lun: 00 Partition: 2
with similar information for IDE disks, CDROMS, tape drives, etc. We
could probably stay with 16-bit device numbers, although 32-bit ones
would really be better.
As for the problem of identifying the system bootstrap
filesystem, that could be done by having a "/proc" block-device inode,
read-only by root, which could be used during system startup. Another
option would be a special major device number (or major/minor pair)
which is remapped internally to the bootstrap filesystem.
Craig Milo Rogers