Errno Mapping

There seems to be an encouraging amount of commonality between the error numbers returned by different platforms. To date, we have only found one mismatch, namely the errno returned when an attempt is made to write to a non-write-enabled tape. As time goes on, I'm sure more will surface.

The objectives behind the design of the errno mapping scheme were:
1)To not do the mapping in the driver, because the consequences of errors in the driver are so severe
2)To localize the mapping, so it would be easy to update
3)To make it easily extensible to a multiplicity of new platforms
4)To not do any mapping between like systems, so that things will always work transparently when the local and remote systems are both of the same type.

In an effort to make changes to errno mapping as painless as possible, all errno mapping has been localized to routing 'tcerrno.c'. This routine is passed the actual errno returned by the real tape drive, and the platform types of the local and remote systems. If the two platform types are the same, of if either is 'UNKNOWN', no mapping is done. If the two types are different, the appropriate new errno is determined by table lookup. The format of the table is described in the comments of tcerrno.c.

Ioctl mapping

The ioctl mapping is done rather differently than the errno mapping. The scheme for ioctl mapping is that the ioctl calls are always mapped to a canonical (aix, in this case) form by the sender, and reverse mapped by the recipient. This is carried out by tclientd (routine top_translate() in udev_aux.c), and in the decosf driver code itself. The mapping is determined by #ifdefs, and so adding new platforms may be a little messy. Since the mapping/unmapping is going on even when two decosf systems communicate, mapping problems are possible even for like systems. One thing to note is that all our physical drives are attached to aix systems, so we have only tested aix to aix and virtual-decosf to physical-aix mapping.

Hardware differences

My knowledge here is pretty spotty - all our actual hardware is aix based. One peculiarity of aix tape devices is the blocksize of the tape drive. This can be set to 0 (by an ioctl or smit), in which case each read() or write() call encompasses exactly one physical tape block, or to some other value. If a non zero value, that is used for the actual blocksize when writing, and becomes the apparent blocksize when reading. Some applications want to be able to manipulate this blocksize. Unfortunately, DEC OSF systems don't include the ioctl #defines needed. The device driver and tclient/d will correctly process the requests, but you have to bring over the right ioctl codes. See the tscan source for an example. And, of course, there may be other yet undiscovered peculiarities.