21 Nov
2017
21 Nov
'17
12:49 a.m.
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.
-----Original Message-----
From: Larry McVoy [mailto:lm@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:
You
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
originally
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
running.
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?