[TUHS] UNIX on S/370
ron at ronnatalie.com
Tue Nov 21 09:49:05 AEST 2017
In fact, on the HEP, we didn't have a traditional interrupt service routine.
When the I/O completed a new kernel thread was spawned to run the
"interrupt" and start the next I/O.
Later on, I wrote a UNIX port that ran on a MultibusII that used a Message
Passing bus paradigm. IO starts and incoming completions were more along
the line of message packets than the PDP-11 CSRs and interrupt vectors.
UNIX is pretty gosh-darn resilient about hardware paradigms.
From: Larry McVoy [mailto:lm at mcvoy.com]
Sent: Monday, November 20, 2017 6:45 PM
To: Ron Natalie
Cc: 'Larry McVoy'; 'Paul Winalski'; 'The Eunuchs Hysterical Society'
Subject: Re: [TUHS] UNIX on S/370
On Mon, Nov 20, 2017 at 06:43:28PM -0500, Ron Natalie wrote:
> > 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.
> There's nothing that restricts a device driver to memory mapped I/O.
> do what ever you have to do to initiate the I/O. Even the x86's
> used special instructions to start the I/O (in/out). The DENELCOR HEP
> supercomputer (we did this port around 1983) we had to bounce I/O
> requests off a separate I/O processor different from where the kernel was
> Similar constucts were used on other machines.
Yeah, that's what I thought. But other people were saying that I/O
processors and Unix didn't mix. I don't get that, seems like whatever the
model is is hidden under the driver, that's the whole point of the driver
design is it not?
More information about the TUHS