21 Nov
2017
21 Nov
'17
1:56 a.m.
On Mon, Nov 20, 2017 at 02:44:03PM -0500, Paul Winalski wrote:
System/360/370 had a radically different I/O model.
I/O devices and
their control units were connected to specialized coprocessors called
I/O channels. Devices were addressed via a number with three hex
digits, the first of which was the channel number. The CPU had an
instruction called start I/O (SIO) that took as parameters a device
address and the address of a series of channel command words (CCWs)
that indicated to the channel the I/O operation to perform and its
parameters (such as the address of the I/O buffer in main memory).
The CPU was notified of I/O termination by three interrupts:
channel-end (the I/O channel reached the end of its channel program),
control-unit-end (the I/O control unit completed a command), and
device-end (the I/O device completed a command).
Yep, familiar with this model. I wrote a device driver for the Unix
side of an I/O channel (talking to an Ibis disk if I recall correctly).
I didn't find it hard, the I/O channel processor did all the real work,
talking to it was sort of like doing networking.
Truth be told, it was a polling driver, this was early on in the ETA-10
days and interrupts on the I/O channel didn't work. So that simplified
the driver to the point that it was almost trivial.
I get that PDP-11 and VAX used memory mapped I/O but was that somehow
exposed above the device driver layer? If so, I missed that, because
I had no conceptual or technical problem with talking to an I/O channel,
it was pretty easy. And I suck at writing drivers.