Messages in this thread |  | | Subject | Re: SCSI device numbering (was: Re: Ideas for v2.1 | Date | Wed, 3 Jul 1996 15:01:55 +0100 (BST) | From | "mpoole" <> |
| |
As Leonard pointed out earlier.
> Now the mapping between device names and physical peripheral devices is really > a two stage process: > > name ==> dev_t ==> device/partition > > Most of the kernel services expect a device name and derive the dev_t and > device/partition from it. The dev_t values are revealed in the stat structure, > but I don't believe there is any system call which accepts a dev_t from the > user. >
An fact it is slightly blurred, the dev_t currently includes controller/bus/lun as well as id/partition.
In fact, we are trying to deal with two different problems. The one being addressed in Leonard's posting is that of identifying a particular partition for use in file system mounts. The other is that of how to deal with an address space for dev_t that is too small for current and future needs.
The problem of identifying a partition for mount purposes can be dealt with by arranging that some properties of the visible partitions are available in user land along with the cookie/dev_t or current version of the dynamic path so that the mount program can use these indetermining which partition is which.
The things that are cannot change are the size of the partition, the size of the while disk, and the index into the partition table. If we can add to this some form of signature based on the content of the partition (creation date/cookie, super-block locations, all fs-type dependant granted) then this information can be used to provide data that comprises the 'new' /etc/fstab.
A possible bonus with this scheme comes when using removable media like CD-ROMs. The 'real cute feature' would be that the mount point for a particular CD-ROM ("Penguins in Bondage" FZ) would always be mounted at a particular place "/mnt/peng_perv". Depending on how perverse we are feeling, program access to particular file-system on removable media could automatically block, and cause a user-mode daemon to prompt for the relevant disc to entered into a drive. Something like the Amiga used for floppies. (Ignore this paragraph if it offends thine eye).
The problem of dev_t's size is somewhat more contentious (witness the traffic). For user-land a dev_t is simply a cookie. The only use I can think of is in tar and cpio, where the cookie is magically moved from A to B (and not neccesarily usefully). What is probably needed is some form of dynamic filesystem where entries of the following type can occur.
/devfs/scsi/controller_0/bus_1/id_2/lun_3/partition_4
Tie this with the previous idea and you can have,
/devfs/partitions/5
which gives an entry which can be interrogated by mount to get the characteristics.
One additional point I would like to raise is that of minors numbers causing variant action. The most obvious example of this is tape drives where the minor number causes all sorts of things like density, speed, rewind etc to be selected.. I consider this a 'Bad Idea (tm)'. It would be nice if the file-system entry could be not only the device, but could contain further information in the form of a sequence of ioctls which perform the required actions to set the drive into the correct mode.
-- Martin Poole, Perot Systems Europe mpoole@heac001.gb.ec.ps.net
|  |