In particular the Gnosis manual defines I/O authority but does not define the nature of the primitive devalloc key that creates I/O capabilities. I use “key” when referring to the manual, but think “capability”.

The 370 architecture presents a clear concept of an I/O device. It is specified by an 8 bit device address on some channel. (“Channel” is 1960 computer speak for a DMA.) The hardware tries and largely succeeds in keeping commands addressed to one device from interfering with operations on other devices. For better and worse the 370 channel architecture makes I/O devices look uniform to the privileged code and the kernel may be oblivious to the attached device types. Device dependence is left to user code even in classic OSes from IBM.

The I/O device capability allows the holder (device driver) to do any operation on that device as described here. In that description mysterious reference is made to the b number. The kernel associates a long integer with each I/O device that it knows. Each I/O capability includes a long integer that is compared with that of the designated device on each invocation. It must match else a distinctive code is returned and the device is left untouched.

In Keykos, the device savvy code (device driver?) runs in user mode with persistent state. Any interaction with the device is via a capability. Upon restart from checkpoint the next invocation of the capability will report a missing device. The code must cope. It may ask higher authorities for another device, or it may report to its client that it is quitting. On restart the hardware (micro code) resets the devices to known state documented in the spec for the device type. Media state is, of course, stale.

There is a closely held capability, devalloc, that creates a device capability and at the same time sets the number of the device to match. The holder of devalloc has persistent memory and always chooses a new number. It adds one to the most recent number for that device. Holders of device capabilities must typically contend with the possibility that the system is restarted and that access to the device has disappeared. The state of the I/O device is not preserved in the checkpoint and it is even possible that checkpoint has restarted on another computer with no such device.

Users with channel attached displays (3270) may log in once more upon restart and the display driver is trained to greet the user, on a newly allocated display device. No user state is otherwise lost.

Of course the kernel uses disks to store checkpoints and is exempt from this discipline.