[jonathaneunice]

Channelized I/O, intent-based security policies (e.g. from RACF), multi-layered error handling and recovery. It's a rich garden. However, it's not as simple as "implementing a feature," since the interesting things are all systems of activity with interlocking assumptions and expectations with all the other systems. You can't "just" pluck pieces out of context any more than you can grab a cool phrase from Mandarin or Urdu, or admire a lobster's claw and decide to graft it onto your own arm.

But for anyone interested in evolving systems/OSs, definitely study S/3x0 and Z successors, or the proprietary mainframes and minicomputers in general. In many cases we are now stumbling into reinventing techniques that mainframes or minicomputer teams built many years earlier. Best case in point probably virtual machines (VMs), in which VMware et al started in ~2003 rebuilding a technology capability that had been developed in Z systems in 1967/68.

[AnimalMuppet]

ELI5: What is "channelized" I/O? How does it differ from, say, handing off I/O to a DMA controller?

[Teknoman117]

It's essentially having a small CPU as a DMA controller. For a prototypical DMA controller, you just give a list of source and destination addresses + transfer size and it runs off an performs those transfers and tells you when it's done. Maybe they can even be chained together (one DMA channel writes to control registers of another then starts that channel).

For "channelized" IO, you had CPU instructions which would effectively hand off small programs to another processor that was extremely limited in capability compared to your CPU. The channel processor would handle the direct interrupts/events from physical IO devices, do basic processing, then kick off (a) DMA transfer(s) to and from main memory, or as a data stream straight to the CPU.

For some mainframe architectures, you could implement things like text-editors and filesystem drivers that would run on the channel processors so that basic tasks didn't take up core CPU time. The main CPU could allocate memory for a process to be placed in, then send off a channel program to the tape drive and go and do something else for awhile while the tape drive found and loaded the executable completely independent of the CPU.

Probably a more realistic example would be to take something like a database and have a separate CPU processing the on-disk format, or a separate CPU to process your network protocol's wire format and only having the actual data it contains seen by the main CPU.

These days processing power is so ridiculously cheap compared to those days that flexibility rules the day. Might as well have a bunch of dumb IO devices because even a basic CPU core can move and process gigabytes of data per second.

[trasz]

It's something between that and RISC-V minion cores.

[zozbot234]

Your hard drive probably has a RISC-V core in it anyway. It seems like a distinction without a difference.

[monocasa]

The channel I/O format has conditional jumps in the command stream and lets you as the application programmer offload large parts of the filesystem or database directly onto the hard drive controller without main CPU intervention. It's closer to GPU command submissions than what you see out of NVMe/SCSI/ATA. So, for one example, telling the controller to "walk an index tree in this format and retrieve the block that matches this key" is something you can code yourself in the channel I/O command stream as it's own sort of ISA.

[Teknoman117]

From the "roads not taken" perspective, Intel actually made something like a channel IO engine for the 8086/8088 family called the 8089 (https://en.wikipedia.org/wiki/Intel_8089) which supported the 20-bit address space of those systems and proper 8 and 16-bit operations. You could write little programs for it which would communicate with IO devices and respond to interrupts on either a shared or private bus, do some processing, and then move the results to main memory.

IBM in a cost saving move grafted the DMA engine from the 8080 family (the 8237) and made it mostly work by adding a page register to cover the remaining bits and setting one up in an odd way for the 286 to get it to do IO <-> memory transfers for 16-bit devices (but unable to do memory-to-memory transfers).

[trasz]

See eg https://netfpga.org for pretty much exactly this for network. I believe it's more of a research platform than something that's used in production. It's not exactly new either.

[rbanffy]

Not quite, because this is reconfiguring the hardware itself, but similar in intent.

[rbanffy]

As a note, Commodore’s 1541 and 1571 drives ran the filesystem in the drive themselves. The computer only sent file commands to the drive.

[monocasa]

And even a faster 6502 than the CPU! Yeah the true very programmable I/O offload you see in the C64 is very similar conceptually, and would be even closer if it could DMA into main RAM to communicate with the main CPU rather than bitbanging serial.