[ I normally just lurk and read the archives, but...here's where I get into
trouble! ]
It seems to me that there are several issues that have come up in this thread,
but here are my thoughts on some of them:
* Identifying hardware:
Since we don't want to use topology as the primary method of
identifying a device, perhaps it could be the secondary method. If a device
id consisted of several parts, userspace could make an educated guess about
which devices correspond to which names, across reboots. Consider an ID
consisting of:
* vendor
* model
* serial number
* content-cookie
* topology-cookie
The two cookie values are opaque, but reproducable. The content cookie might
be an MD5 of the partition table of a disk, or its serial number, or
something to that effect. The topology cookie would some topology
parameters (such as mem address, irq, io ports, slot #, etc) which could be
used to identify the device later. These are only used for identification,
not for discovering topology.
If all 5 fields match, then we know what it is. If only topology-cookie is
different, then it just moved. If content-cookie is different then it might
be a different device (There's a trickyness to partitioning, I suppose).
I suppose these ID fields could also be used by a userspace tool to
load/unload drivers as necessary.
The id could also determine the device is only inaccessable (not removed)
when it disappears. So, if disk5 disappeared on reboot, the next disk
added would be given an ID at the end of the list, while disk5 would remain
unused. Only on a 'cleanup' would disk5 become reassignable. This fixes
issues like a device being unpowered on boot and a new one being powered up.
* User-space device naming
I think the diskN naming is nice. "randomly assigned" major ids won't be a
problem, except on NFS mounted /dev directories. If the kernel maintained
a filesystem (like devfs or proc) which always managed the "currently
available" devices the only problem to solve would be dealing with software
which opens the /dev node to get a driver loaded.
<pipe_dream>
It would be very cool if the dev filesystem could be exported to other linux
boxes, so you could transparently have access to block devices (like nbd does
now) and character devices (like the sound card)
mount -t dev -o other_machine /dev/other_machine
cat foo.au > /dev/other_machine/audio &
</pipe_dream>
* IOCTL
Since ioctl() is commonly regarded as a kluge, is there any reason why it
couldn't be replaced by the /dev/fb0/frame0 thing that was described earlier?
The libc implementation of ioctl could convert the binary data back into
text calls. Gross, but possible...though it would probably be better to just
depreciate the ioctl mechanism. It could also package it for remote
usage (see my pipe_dream above).
If device info/controls are tied to subdirectory entries, it would be nice
to be able to get a device's capabilities via existance checking...
I.E. '-e /dev/disk0/eject' could check of the device is ejectable.
Brian Wheeler
bdwheele@indiana.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 23 2001 - 21:00:24 EST