> 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