The IBM 360 introduced channels that could sustain sequences of I/O operations on one I/O device without attention from the CPU. (See comments about 709 in this concerning a precursor to the 360 channels.) A CPU instruction called SIO would select a particular device and direct the channel to a channel program in core. The channel program comprised sequential channel commands which contained orders for the device, and core addresses and counts from which or to which to transfer data. The device orders were sent to the device and specified such things as read and write. The channel decoded the orders enough to know the direction of any data transfer.

A one bit signal from the device was interpreted by the channel to cause conditional skipping of the following channel command. Thus a degree of conditional programs were possible. There was an unconditional branch in the channel program repertoire.

Keykos followed the practice of IBM’s conventional operating systems and VM 370 in translating channel programs from user supplied channel programs, with virtual addresses, into channel programs with corresponding real addresses. The channel then obeyed the translated program. The integrity of real core was thus protected. The channel architecture is describe more fully here along with a bug that is likely to creep into programs that translate channel programs and their conceptual counterparts. There was no device specific code in the kernel except a small amount to drive the disks for purposes of swapping.

On the largest 370s, the channels were real pieces of hardware that worked really as they did conceptually. On the smaller systems much of the channel was the figment of the imagination of the micro-code. On these smaller systems the micro-code would become involved every 128 bytes, or so, to deal with the transfer. Such events were called “breakins” by the hardware designers and were invisible to the privileged code and most of the micro code. More substantial micro-code involvement happened between the execution of channel commands. Yet the illusion of real channels was rather perfectly maintained even to the privileged code.

Early and large IO devices are connected by bus and tag cables with published specifications. Later there were systems with some I/O devices integrated into the system without bus and tag cables. The difference was invisible to the privileged code.

Systems commonly had several channels, most with bus and tag interfaces. They were logically independent. A device would be attached to just one channel until the advent of the two channel switch whereupon a device could attach to two channels at once for better thru-put and availability. Furthermore an I/O operation could begin on one channel even while previous channel programs proceeded. The real facilities of the channel and cables, were timeshared.

Micro-code allowed IBM to make systems whose capacity ranged over three orders of magnitude appear remarkable alike to even the privileged code.

SCSI

SCSI closely mimicked the IBM channels. There was no attempt, however, to specify what SCSI hardware looked like to the program. There is a standard, however, called CAM (Command Access Method) which specifies how a C program which is to drive a SCSI device, communicates with its device by calling standard entry points in the CAM software. The CAM software is presumably written by the vendor of the host interface which is the hardware that attaches the SCSI cable to the system.

There are standards that bring some uniformity to the later world of SCSI 3.0 and this may reduce the amount of privileged code and perhaps eliminate the need for kernel code that is device savvy. Among these are standards that say what a SCSI disk should respond to in the way of SCSI commands. Other standards are for SCSI tape. I do not know which commercial SCSI I/O devices conform to these standards.

FireWire & USB

FireWire and USB go further with standards. For each there is an OHCI (Open Host Controller Interface) standard which specifies how the hardware that connects the cable to the system, looks to the privileged code. There are different standards for FireWire and USB but they seem similar in gross detail. Here are the FireWire and the USB versions. The standard assumes that the hardware is a PCI card. From my brief look it seems that fixed kernel code is able to entirely mediate between user mode driver code and an arbitrary conforming hardware adapter. This promises to bring us back to the sanity of the IBM I/O architecture. Better: upon attaching a new kind of device, we need neither power down the system nor add new kernel drivers!

We shall see.

Intel’s UHCI led to OHIC for USB. Intel has pushed or is pushing version 2.0 of USB which is much faster than version 1, to compete with FireWire. EHCI is sort of like OHIC except for including features for USB 2.0. EHIC requires a license from Intel to build conforming hardware.
All of this does nothing to ameliorate the problem of graphics cards. VNC may save the day. You must run the client in a trusted platform, which sort of ruins things for some purposes. On the other hand hardware to do a VNC client is real cheap whether it is a dedicated PC or special hardware.