[TUHS] UNIX on S/370

Ron Natalie 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.

-----Original Message-----
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.
You
> 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?



More information about the TUHS mailing list