The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: lm@mcvoy.com (Larry McVoy)
Subject: [TUHS] UNIX on S/370
Date: Mon, 20 Nov 2017 18:41:11 -0800	[thread overview]
Message-ID: <20171121024111.GO9146@mcvoy.com> (raw)
In-Reply-To: <CAC20D2N=aBhdON1YqHH57ZG-TmC62yWGF4_=HK5Gp2XwdbHkyQ@mail.gmail.com>

So tape I can see being more weird, but isn't raw disk just "don't put it
in buffer cache"?

From what I've been able to gather early tape in Unix was dicey, something
about the driver doing seek.  Was there more to it than that?

On Tue, Nov 21, 2017 at 02:33:55AM +0000, Clem Cole wrote:
> It???s not so much that they don???t mix, it???s not quite the same.    Some
> coprocessor ideas work really well into the Unix I/O model, others don't.
>  Raw disk and tape I/O ala a PDP11 or VAX for instance is not easy on an
> IBM channel controller or a CDC PPU.
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Nov 20, 2017 at 6:45 PM Larry McVoy <lm at mcvoy.com> wrote:
> 
> > 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?
> >
> -- 
> Sent from a handheld expect more typos than usual

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


  parent reply	other threads:[~2017-11-21  2:41 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-20  0:57 Nemo
2017-11-20  1:01 ` Ronald Natalie
2017-11-20  1:06 ` Dave Horsfall
2017-11-20  3:50 ` arnold
2017-11-20 15:23   ` Clem Cole
2017-11-20 16:03     ` ron minnich
2017-11-20 16:31       ` Clem Cole
2017-11-20 19:44         ` Paul Winalski
2017-11-20 19:56           ` Larry McVoy
2017-11-20 23:43             ` Ron Natalie
2017-11-20 23:45               ` Larry McVoy
2017-11-20 23:49                 ` Ron Natalie
     [not found]                 ` <CAC20D2N=aBhdON1YqHH57ZG-TmC62yWGF4_=HK5Gp2XwdbHkyQ@mail.gmail.com>
2017-11-21  2:41                   ` Larry McVoy [this message]
2017-11-29 22:42                     ` Dave Horsfall
2017-11-29 22:55                       ` ron minnich
2017-11-21  1:15     ` Ron Natalie
2017-11-21  3:29       ` Grant Taylor
2017-11-21  3:40         ` Ron Natalie
2017-11-21  3:46           ` Grant Taylor
2017-11-21  8:09             ` arnold
2017-11-21 16:49             ` Paul Winalski
2017-11-21  4:34           ` Clem cole
2017-11-21  5:42             ` Grant Taylor
2017-11-21 12:00               ` Ron Natalie
2017-11-21 13:51                 ` Clem Cole
2017-11-21 14:59                   ` Larry McVoy
2017-11-21 17:06                     ` Clem Cole
2017-11-21 17:23                       ` Clem Cole
2017-11-21 18:29                         ` Larry McVoy
2017-11-21 19:10                           ` Clem Cole
2017-11-21 15:40                   ` Ron Natalie
2017-11-21 15:45                     ` Larry McVoy
2017-11-21 13:24               ` Clem Cole
2017-11-22  1:33 ` Kevin Bowling
2017-11-22  6:35   ` Wesley Parish
2017-11-22  9:38     ` Kevin Bowling
2017-11-22 13:40       ` Clem Cole
2017-11-22 14:09         ` Ron Natalie
2017-11-22 13:51     ` Clem Cole
2017-11-22 14:04       ` Ron Natalie
2017-11-20 16:05 Noel Chiappa
2017-11-20 16:37 ` Clem Cole
2017-11-20 16:47   ` Charles H Sauer
2017-11-20 17:44     ` Toby Thain
2017-11-20 19:07 ` Paul Winalski
2017-11-20 19:10   ` Larry McVoy
2017-11-20 19:36     ` Warner Losh
2017-11-20 19:36       ` Larry McVoy
2017-11-20 19:39         ` Larry McVoy
2017-11-20 19:56     ` Arthur Krewat
2017-11-20 19:59       ` Larry McVoy
2017-11-20 19:27   ` arnold
2017-11-20 19:29     ` Larry McVoy
2017-11-20 22:56       ` Michael Parson
2017-11-20 23:23         ` Larry McVoy
2017-11-21  2:56 Noel Chiappa
2017-11-21  3:15 ` Ron Natalie
2017-11-21  3:51   ` Larry McVoy
2017-11-21  5:14     ` Warner Losh
2017-11-21  5:20       ` Larry McVoy
2017-11-22 15:38 Noel Chiappa
2017-11-28  0:13 ` Kevin Bowling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171121024111.GO9146@mcvoy.com \
    --to=lm@mcvoy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).