The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
@ 2019-08-30 20:21 Norman Wilson
  2019-08-30 20:28 ` Larry McVoy
  2019-08-30 20:39 ` Clem Cole
  0 siblings, 2 replies; 49+ messages in thread
From: Norman Wilson @ 2019-08-30 20:21 UTC (permalink / raw)
  To: tuhs

John Reiser did do his own paging system for UNIX 32/V.
I heard about it from friends at Bell Labs ca. 1982-83,
when I was still running systems for physicists at Caltech.
It sounded very interesting, and I would love to have had
my hands on it--page cache unified with buffer cache,
copy-on-write from the start.

The trouble is that Reiser worked in a different group
from the original UNIX crowd, and his management didn't
think his time well spent on that work, so it never got
released.

I remember asking, either during my interview at the Labs
or after I started work there, why the 4.1 kernel had been
chosen instead of Reiser's.  It had to do with maintainability:
there were already people who could come in and hack on the
Berkeley system, as well as more using it and maintaining it,
whereas Reiser's system had become a unicorn.  Nobody in
1127 wanted to maintain a VM system or anything much close
to the VAX hardware.  So the decision was to stick with a
kernel for which someone else would do those things.

Once I'd been there for a year or so and settled in, I found
that I was actually looking after all that stuff, because I
was really interested in it.  (Which seemed to delight a lot
of people.)  Would we have ended up using Reiser's kernel had
I been there a couple of years earlier?  I don't know.

It is in any case a shame that jfr's code never saw the light
of day.  I really hope someone can find it on an old tape
somewhere and we can get it into the archive, if only because
I'd love to look at it.

Norman Wilson
Toronto ON

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-30 20:21 [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] Norman Wilson
@ 2019-08-30 20:28 ` Larry McVoy
  2019-08-30 20:39 ` Clem Cole
  1 sibling, 0 replies; 49+ messages in thread
From: Larry McVoy @ 2019-08-30 20:28 UTC (permalink / raw)
  To: Norman Wilson; +Cc: tuhs

On Fri, Aug 30, 2019 at 04:21:47PM -0400, Norman Wilson wrote:
> John Reiser did do his own paging system for UNIX 32/V.
> I heard about it from friends at Bell Labs ca. 1982-83,
> when I was still running systems for physicists at Caltech.
> It sounded very interesting, and I would love to have had
> my hands on it--page cache unified with buffer cache,
> copy-on-write from the start.

Huh, Moran published his SunOS VM system paper in 1988, my guess is he
was working on the code for a year or two before that.  So Reiser's work
predates that.  Super interesting.  I too would love for someone to find
a copy of that code.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-30 20:21 [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] Norman Wilson
  2019-08-30 20:28 ` Larry McVoy
@ 2019-08-30 20:39 ` Clem Cole
  2019-08-30 21:52   ` Larry McVoy
  1 sibling, 1 reply; 49+ messages in thread
From: Clem Cole @ 2019-08-30 20:39 UTC (permalink / raw)
  To: Norman Wilson; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]

On Fri, Aug 30, 2019 at 4:22 PM Norman Wilson <norman@oclsc.org> wrote:

> It had to do with maintainability:
> there were already people who could come in and hack on the
> Berkeley system, as well as more using it and maintaining it,
> whereas Reiser's system had become a unicorn.  Nobody in
> 1127 wanted to maintain a VM system or anything much close
> to the VAX hardware.  So the decision was to stick with a
> kernel for which someone else would do those things.


Norman, I suspect the folks in 1127 was really not different the CS-Dept at
UCB in fact.  The whole reason CSRG wound down (and that was before wnj
left BTW) is the project stopped being research and started to have a
maintainence flavor which a lot of people found distasteful.

Funny, one of the things that I think made BSD the most useful, and *really
where wnj made his contribution IMO,* was the all the 'completors' between
things like the #ifdef FAST_VAX work and autoconfiguration, all the new
device support, *etc*.  That was a huge amount of work not very sexy work
that made 4.1BSD in particular, 'just work'   I had had the out-of-box
experience with all of V5 in RK05s, V6 and V7 on 9-track tape, earlier.
 4.1BSD was a dream, really not much to do but role the tape and answer
questions.

I can see why people liked that.    I remember a lot of people complaining
about the BSD VM system, but it worked 'good enough.'  I can tell you when
we did the Masscomp system (and the first thing I worked on was the VM
system with tjt), even thought we had started with a System III kernel
(that was our license), we pulled Joy's code in for the VM pretty early.
The first thing Tom and I did is made it 'MP-safe' (big lock scheme to be
honest) but we were interested in debugging the locking code, not the VM
system.  It's true when we did Stellar and had V.3, we used the AT&T VM
base by that point and started over, used a fine grain locking model
etc...., but by we knew how to make a MP UNIX box by then (remember the
MC-500/DP was the first MP Unix >>product<< -- predates our friends in on
the West coast by 2 years).

[-- Attachment #2: Type: text/html, Size: 3555 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-30 20:39 ` Clem Cole
@ 2019-08-30 21:52   ` Larry McVoy
  2019-08-31  0:58     ` Clem Cole
  0 siblings, 1 reply; 49+ messages in thread
From: Larry McVoy @ 2019-08-30 21:52 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

On Fri, Aug 30, 2019 at 04:39:09PM -0400, Clem Cole wrote:
> MC-500/DP was the first MP Unix >>product<< -- predates our friends in on
> the West coast by 2 years).

And as I recall you had to do 2 68000's in lockstep to get the VM system
to do page fault restarts.  That was neat, was that a Masscomp invention
or was it a commonly known trick?

--lm

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-30 21:52   ` Larry McVoy
@ 2019-08-31  0:58     ` Clem Cole
  2019-08-31  1:13       ` Bakul Shah
  0 siblings, 1 reply; 49+ messages in thread
From: Clem Cole @ 2019-08-31  0:58 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

Actually not in lock step.  They were independent.  One was called the
executor and the other the fixer.  When a fault was detected the executor
was sent wait stated while the fixer handled the fault and refilled the
TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
when the 68010 was released the pals on the board were changed to allow the
executor to actually take the fault and do something else while the fixer
replaced the TLB entry

The idea was proposed by Forest Baskett at an early Asilomar conference but
never built by him - I want to say 1980 or 81.    I have lost that paper
and would love to find a copy again BTW.    To be fair both Apollo and
Masscomp’s hw teams reduced the idea to practice independently but I know
of no other folks that tried it.

On Fri, Aug 30, 2019 at 5:52 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Fri, Aug 30, 2019 at 04:39:09PM -0400, Clem Cole wrote:
> > MC-500/DP was the first MP Unix >>product<< -- predates our friends in on
> > the West coast by 2 years).
>
> And as I recall you had to do 2 68000's in lockstep to get the VM system
> to do page fault restarts.  That was neat, was that a Masscomp invention
> or was it a commonly known trick?
>
> --lm
>
-- 
Sent from a handheld expect more typos than usual

[-- Attachment #2: Type: text/html, Size: 1752 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-31  0:58     ` Clem Cole
@ 2019-08-31  1:13       ` Bakul Shah
  2019-08-31  2:46         ` Clem cole
  0 siblings, 1 reply; 49+ messages in thread
From: Bakul Shah @ 2019-08-31  1:13 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc@ccc.com> wrote:
>
> Actually not in lock step.  They were independent.  One was called the
> executor and the other the fixer.  When a fault was detected the executor
> was sent wait stated while the fixer handled the fault and refilled the
> TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
> when the 68010 was released the pals on the board were changed to allow the
> executor to actually take the fault and do something else while the fixer
> replaced the TLB entry

As I remember, the issue with 68000 was that instructions were
not restartable so in case of accessing memory that didn't
exist, you couldn't take a segfault and do anything useful.
This is why you needed a second processor to deal with an
external MMU. There would have been no TLB unless you actually
added an external TLB -- but an external CAM would've been
very expensive. May be a direct map?

What we did at Fortune was to utilize a 4 entry external map:
text, data, extra and stack.  When a new function was invoked
it would do a 'probe'. If the probe caused a segfault, stack
was extended in the handler. The probe didn't have to be
restartable. So we didn't need a second 68k. This logic may
have been in the V7 port we started from.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-31  1:13       ` Bakul Shah
@ 2019-08-31  2:46         ` Clem cole
  2019-08-31  2:57           ` Clem cole
  2019-08-31  3:19           ` Bakul Shah
  0 siblings, 2 replies; 49+ messages in thread
From: Clem cole @ 2019-08-31  2:46 UTC (permalink / raw)
  To: Bakul Shah; +Cc: The Eunuchs Hysterical Society

There was most definitely a TLB or as Dave called it ‘The TB’ ***
Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec.  He was a bus and memory specialist 


*** west coast VS east coast training - calling it a TB vs a TLB.  

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul@bitblocks.com> wrote:
> 
>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc@ccc.com> wrote:
>> 
>> Actually not in lock step.  They were independent.  One was called the
>> executor and the other the fixer.  When a fault was detected the executor
>> was sent wait stated while the fixer handled the fault and refilled the
>> TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
>> when the 68010 was released the pals on the board were changed to allow the
>> executor to actually take the fault and do something else while the fixer
>> replaced the TLB entry
> 
> As I remember, the issue with 68000 was that instructions were
> not restartable so in case of accessing memory that didn't
> exist, you couldn't take a segfault and do anything useful.
> This is why you needed a second processor to deal with an
> external MMU. There would have been no TLB unless you actually
> added an external TLB -- but an external CAM would've been
> very expensive. May be a direct map?
> 
> What we did at Fortune was to utilize a 4 entry external map:
> text, data, extra and stack.  When a new function was invoked
> it would do a 'probe'. If the probe caused a segfault, stack
> was extended in the handler. The probe didn't have to be
> restartable. So we didn't need a second 68k. This logic may
> have been in the V7 port we started from.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-31  2:46         ` Clem cole
@ 2019-08-31  2:57           ` Clem cole
  2019-08-31  3:14             ` Gregg Levine
                               ` (2 more replies)
  2019-08-31  3:19           ` Bakul Shah
  1 sibling, 3 replies; 49+ messages in thread
From: Clem cole @ 2019-08-31  2:57 UTC (permalink / raw)
  To: Bakul Shah; +Cc: The Eunuchs Hysterical Society

Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save enough information during some of the faults.  Les Crudele once told me, that it turns out he had tried to fix it but there were a series of errors and some short cuts they used to fit it in the store.  They gave up trying to fix it as the part was purely skunkworks and they could not respin it at the time.  After it succeeded and were a real project, the difference between the original and the 10 was Nick redid the microcode but they had made a larger microstore - otherwise basically the same Si.    

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Aug 30, 2019, at 10:46 PM, Clem cole <clemc@ccc.com> wrote:
> 
> There was most definitely a TLB or as Dave called it ‘The TB’ ***
> Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec.  He was a bus and memory specialist 
> 
> 
> *** west coast VS east coast training - calling it a TB vs a TLB.  
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>>> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul@bitblocks.com> wrote:
>>> 
>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc@ccc.com> wrote:
>>> 
>>> Actually not in lock step.  They were independent.  One was called the
>>> executor and the other the fixer.  When a fault was detected the executor
>>> was sent wait stated while the fixer handled the fault and refilled the
>>> TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
>>> when the 68010 was released the pals on the board were changed to allow the
>>> executor to actually take the fault and do something else while the fixer
>>> replaced the TLB entry
>> 
>> As I remember, the issue with 68000 was that instructions were
>> not restartable so in case of accessing memory that didn't
>> exist, you couldn't take a segfault and do anything useful.
>> This is why you needed a second processor to deal with an
>> external MMU. There would have been no TLB unless you actually
>> added an external TLB -- but an external CAM would've been
>> very expensive. May be a direct map?
>> 
>> What we did at Fortune was to utilize a 4 entry external map:
>> text, data, extra and stack.  When a new function was invoked
>> it would do a 'probe'. If the probe caused a segfault, stack
>> was extended in the handler. The probe didn't have to be
>> restartable. So we didn't need a second 68k. This logic may
>> have been in the V7 port we started from.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-31  2:57           ` Clem cole
@ 2019-08-31  3:14             ` Gregg Levine
  2019-08-31  3:47               ` Clem cole
  2019-08-31  3:38             ` Bakul Shah
  2019-08-31  5:37             ` Dave Horsfall
  2 siblings, 1 reply; 49+ messages in thread
From: Gregg Levine @ 2019-08-31  3:14 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Hello!
That definitely groks with a decidedly thirty year old memory. I
remember going to BUSCON, and getting into an interesting discussion
with the folks behind the M68K just how difficult it could be to run
more modern code (or operating systems). Let's just say it was
peculiar. They wanted to stick with a proprietary OS, and one odd man
there wanted to expand CPM-68K. And still another was looking into
bringing up UNIX on it.

It was fun.
-----
Gregg C Levine gregg.drwho8@gmail.com
"This signature fought the Time Wars, time and again."

On Fri, Aug 30, 2019 at 10:58 PM Clem cole <clemc@ccc.com> wrote:
>
> Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save enough information during some of the faults.  Les Crudele once told me, that it turns out he had tried to fix it but there were a series of errors and some short cuts they used to fit it in the store.  They gave up trying to fix it as the part was purely skunkworks and they could not respin it at the time.  After it succeeded and were a real project, the difference between the original and the 10 was Nick redid the microcode but they had made a larger microstore - otherwise basically the same Si.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
> > On Aug 30, 2019, at 10:46 PM, Clem cole <clemc@ccc.com> wrote:
> >
> > There was most definitely a TLB or as Dave called it ‘The TB’ ***
> > Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec.  He was a bus and memory specialist
> >
> >
> > *** west coast VS east coast training - calling it a TB vs a TLB.
> >
> > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
> >
> >>> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul@bitblocks.com> wrote:
> >>>
> >>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc@ccc.com> wrote:
> >>>
> >>> Actually not in lock step.  They were independent.  One was called the
> >>> executor and the other the fixer.  When a fault was detected the executor
> >>> was sent wait stated while the fixer handled the fault and refilled the
> >>> TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
> >>> when the 68010 was released the pals on the board were changed to allow the
> >>> executor to actually take the fault and do something else while the fixer
> >>> replaced the TLB entry
> >>
> >> As I remember, the issue with 68000 was that instructions were
> >> not restartable so in case of accessing memory that didn't
> >> exist, you couldn't take a segfault and do anything useful.
> >> This is why you needed a second processor to deal with an
> >> external MMU. There would have been no TLB unless you actually
> >> added an external TLB -- but an external CAM would've been
> >> very expensive. May be a direct map?
> >>
> >> What we did at Fortune was to utilize a 4 entry external map:
> >> text, data, extra and stack.  When a new function was invoked
> >> it would do a 'probe'. If the probe caused a segfault, stack
> >> was extended in the handler. The probe didn't have to be
> >> restartable. So we didn't need a second 68k. This logic may
> >> have been in the V7 port we started from.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-31  2:46         ` Clem cole
  2019-08-31  2:57           ` Clem cole
@ 2019-08-31  3:19           ` Bakul Shah
  1 sibling, 0 replies; 49+ messages in thread
From: Bakul Shah @ 2019-08-31  3:19 UTC (permalink / raw)
  To: Clem cole; +Cc: The Eunuchs Hysterical Society

It would be interesting to see its MMU details.

> On Aug 30, 2019, at 7:46 PM, Clem cole <clemc@ccc.com> wrote:
> 
> There was most definitely a TLB or as Dave called it ‘The TB’ ***
> Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec.  He was a bus and memory specialist 
> 
> 
> *** west coast VS east coast training - calling it a TB vs a TLB.  
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul@bitblocks.com> wrote:
>> 
>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc@ccc.com> wrote:
>>> 
>>> Actually not in lock step.  They were independent.  One was called the
>>> executor and the other the fixer.  When a fault was detected the executor
>>> was sent wait stated while the fixer handled the fault and refilled the
>>> TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
>>> when the 68010 was released the pals on the board were changed to allow the
>>> executor to actually take the fault and do something else while the fixer
>>> replaced the TLB entry
>> 
>> As I remember, the issue with 68000 was that instructions were
>> not restartable so in case of accessing memory that didn't
>> exist, you couldn't take a segfault and do anything useful.
>> This is why you needed a second processor to deal with an
>> external MMU. There would have been no TLB unless you actually
>> added an external TLB -- but an external CAM would've been
>> very expensive. May be a direct map?
>> 
>> What we did at Fortune was to utilize a 4 entry external map:
>> text, data, extra and stack.  When a new function was invoked
>> it would do a 'probe'. If the probe caused a segfault, stack
>> was extended in the handler. The probe didn't have to be
>> restartable. So we didn't need a second 68k. This logic may
>> have been in the V7 port we started from.


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-31  2:57           ` Clem cole
  2019-08-31  3:14             ` Gregg Levine
@ 2019-08-31  3:38             ` Bakul Shah
  2019-08-31  5:37             ` Dave Horsfall
  2 siblings, 0 replies; 49+ messages in thread
From: Bakul Shah @ 2019-08-31  3:38 UTC (permalink / raw)
  To: Clem cole; +Cc: The Eunuchs Hysterical Society

One thing I can think of is something like this:
IIRC 68k had 24 address bits. So with a 4K page size, you can have one level
pagetable. If the pagetable is in fast SRAM, may be 1 or 2 clock cyles would
be added. If you allow 2^N processes, you need 2^(12+N) entry page table. The
width of the table would depend on the number of 4K pages in the physical
memory. Context switch would be to simply set the 2^N bit process "base"
register. Going beyond 2^N you'd have to swap out a process. Each process can
then grow up to 16MB. I don't think a real translation lookaside buffer would
help much.

It would be interesting to see the actual details.

> On Aug 30, 2019, at 7:57 PM, Clem cole <clemc@ccc.com> wrote:
> 
> Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save enough information during some of the faults.  Les Crudele once told me, that it turns out he had tried to fix it but there were a series of errors and some short cuts they used to fit it in the store.  They gave up trying to fix it as the part was purely skunkworks and they could not respin it at the time.  After it succeeded and were a real project, the difference between the original and the 10 was Nick redid the microcode but they had made a larger microstore - otherwise basically the same Si.    
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>> On Aug 30, 2019, at 10:46 PM, Clem cole <clemc@ccc.com> wrote:
>> 
>> There was most definitely a TLB or as Dave called it ‘The TB’ ***
>> Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec.  He was a bus and memory specialist 
>> 
>> 
>> *** west coast VS east coast training - calling it a TB vs a TLB.  
>> 
>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
>> 
>>>> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul@bitblocks.com> wrote:
>>>> 
>>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc@ccc.com> wrote:
>>>> 
>>>> Actually not in lock step.  They were independent.  One was called the
>>>> executor and the other the fixer.  When a fault was detected the executor
>>>> was sent wait stated while the fixer handled the fault and refilled the
>>>> TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
>>>> when the 68010 was released the pals on the board were changed to allow the
>>>> executor to actually take the fault and do something else while the fixer
>>>> replaced the TLB entry
>>> 
>>> As I remember, the issue with 68000 was that instructions were
>>> not restartable so in case of accessing memory that didn't
>>> exist, you couldn't take a segfault and do anything useful.
>>> This is why you needed a second processor to deal with an
>>> external MMU. There would have been no TLB unless you actually
>>> added an external TLB -- but an external CAM would've been
>>> very expensive. May be a direct map?
>>> 
>>> What we did at Fortune was to utilize a 4 entry external map:
>>> text, data, extra and stack.  When a new function was invoked
>>> it would do a 'probe'. If the probe caused a segfault, stack
>>> was extended in the handler. The probe didn't have to be
>>> restartable. So we didn't need a second 68k. This logic may
>>> have been in the V7 port we started from.


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-31  3:14             ` Gregg Levine
@ 2019-08-31  3:47               ` Clem cole
  0 siblings, 0 replies; 49+ messages in thread
From: Clem cole @ 2019-08-31  3:47 UTC (permalink / raw)
  To: Gregg Levine; +Cc: The Eunuchs Hysterical Society

Fwiw. the 68k design team used a 11/70 running an ISC based Unix and with Rand Editor running in Perkin Elmer Fox terminals with special microcode in the 6800 in the terminals roms.  Basically Les, Nick and Tom were all Unix folks.  


Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Aug 30, 2019, at 11:14 PM, Gregg Levine <gregg.drwho8@gmail.com> wrote:
> 
> Hello!
> That definitely groks with a decidedly thirty year old memory. I
> remember going to BUSCON, and getting into an interesting discussion
> with the folks behind the M68K just how difficult it could be to run
> more modern code (or operating systems). Let's just say it was
> peculiar. They wanted to stick with a proprietary OS, and one odd man
> there wanted to expand CPM-68K. And still another was looking into
> bringing up UNIX on it.
> 
> It was fun.
> -----
> Gregg C Levine gregg.drwho8@gmail.com
> "This signature fought the Time Wars, time and again."
> 
>> On Fri, Aug 30, 2019 at 10:58 PM Clem cole <clemc@ccc.com> wrote:
>> 
>> Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save enough information during some of the faults.  Les Crudele once told me, that it turns out he had tried to fix it but there were a series of errors and some short cuts they used to fit it in the store.  They gave up trying to fix it as the part was purely skunkworks and they could not respin it at the time.  After it succeeded and were a real project, the difference between the original and the 10 was Nick redid the microcode but they had made a larger microstore - otherwise basically the same Si.
>> 
>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>> 
>>> On Aug 30, 2019, at 10:46 PM, Clem cole <clemc@ccc.com> wrote:
>>> 
>>> There was most definitely a TLB or as Dave called it ‘The TB’ ***
>>> Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec.  He was a bus and memory specialist
>>> 
>>> 
>>> *** west coast VS east coast training - calling it a TB vs a TLB.
>>> 
>>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>>> 
>>>>> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul@bitblocks.com> wrote:
>>>>> 
>>>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc@ccc.com> wrote:
>>>>> 
>>>>> Actually not in lock step.  They were independent.  One was called the
>>>>> executor and the other the fixer.  When a fault was detected the executor
>>>>> was sent wait stated while the fixer handled the fault and refilled the
>>>>> TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
>>>>> when the 68010 was released the pals on the board were changed to allow the
>>>>> executor to actually take the fault and do something else while the fixer
>>>>> replaced the TLB entry
>>>> 
>>>> As I remember, the issue with 68000 was that instructions were
>>>> not restartable so in case of accessing memory that didn't
>>>> exist, you couldn't take a segfault and do anything useful.
>>>> This is why you needed a second processor to deal with an
>>>> external MMU. There would have been no TLB unless you actually
>>>> added an external TLB -- but an external CAM would've been
>>>> very expensive. May be a direct map?
>>>> 
>>>> What we did at Fortune was to utilize a 4 entry external map:
>>>> text, data, extra and stack.  When a new function was invoked
>>>> it would do a 'probe'. If the probe caused a segfault, stack
>>>> was extended in the handler. The probe didn't have to be
>>>> restartable. So we didn't need a second 68k. This logic may
>>>> have been in the V7 port we started from.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-31  2:57           ` Clem cole
  2019-08-31  3:14             ` Gregg Levine
  2019-08-31  3:38             ` Bakul Shah
@ 2019-08-31  5:37             ` Dave Horsfall
  2019-08-31 19:03               ` Clem Cole
  2019-09-02  8:28               ` Peter Jeremy
  2 siblings, 2 replies; 49+ messages in thread
From: Dave Horsfall @ 2019-08-31  5:37 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

On Fri, 30 Aug 2019, Clem cole wrote:

> Btw. The issue with the 68k was Nick Tredenick’s original Microcode did 
> not save enough information during some of the faults.  Les Crudele once 
> told me, that it turns out he had tried to fix it but there were a 
> series of errors and some short cuts they used to fit it in the store. 
> They gave up trying to fix it as the part was purely skunkworks and they 
> could not respin it at the time.  After it succeeded and were a real 
> project, the difference between the original and the 10 was Nick redid 
> the microcode but they had made a larger microstore - otherwise 
> basically the same Si.

Yep, that certainly rings a bell.  ISTR that Sun had a board with the two 
CPUs, one keeping an eye on the other.

Ah, those were the days :-)  Now, we just have to put up with Intel, 
although I believe the ARM is much better.

-- Dave

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-31  5:37             ` Dave Horsfall
@ 2019-08-31 19:03               ` Clem Cole
  2019-09-05  5:11                 ` Al Kossow
  2019-09-02  8:28               ` Peter Jeremy
  1 sibling, 1 reply; 49+ messages in thread
From: Clem Cole @ 2019-08-31 19:03 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2606 bytes --]

On Sat, Aug 31, 2019 at 1:38 AM Dave Horsfall <dave@horsfall.org> wrote:

> Yep, that certainly rings a bell.  ISTR that Sun had a board with the two
> CPUs, one keeping an eye on the other.

Interesting, I was under the belief that Sun never even tried the trick (at
least as a product).  The original Stanford University Network (SUN) CPU
was built for an Intel Multibus (electrically and mechanically) but using a
single 68000 instead of an Intel processor.  The 'SUN' was designed by one
of Forest's graduate students (Andy Bechtolsheim
<https://en.wikipedia.org/wiki/Andy_Bechtolsheim>); and the University licensed
the design extremely cheaply throughout the valley (VLSI Tech, *a.k.a.* Sun
Microsystems, was only one of the licensees.  But for instance the original
Cisco AGS and the Imagen Laser printers both used CPU's licensed from the
Unversity).

FWIW: I knew Andy at CMU previously, he had designed a similar board for
the CMU front-end as I was leaving for Tektronix - when I was there we used
LSI-11s and Andy replaced that with an 8085 (then 8086) based Multibus
[IIRC, Phil Karn may have mixed up in all that too - he was hacking on what
would become KA9Q TCP on his Z80 and then the 8085.   We had all taken the
graduate realtime course from Steely Dan as lab partners and our big
project was based on hacks to that hardware].

That said, it was Forest that proposed the executor/fixer trick (as I say
he gave a paper at an Asilomar Microprocessor Conference which I have sadly
misplaced).   It is certainly possible that Andy tried building it, but the
only two firms that I know of that built processors using the idea were
Apollo and Masscomp (neither who used or licensed the SUN CPU design from
Stanford) although all of them used a flavor of the Multibus as their first
bus.

I don't know what Apollo did. The multibus mechanically had two connectors,
but the Intel-defined I/O bus was on the lower (larger connector).   At,
Masscomp the MC-500 a private (synchronous) memory bus, that was very
similar to the BI in its protocol (because Dave designed both of course).
It was built on the unused/undefined header and ran much faster than the
I/O bus since memory fetches occurred.  Also, the Masscomp >>card cage<<
was larger than Multibus (I think Apollo was also).   The shorter boards
fit into the backplane, the larger size allowed for more 'chips to fit.'
IIRC, with the original memory chips being used at the time, one reason why
the Masscomp was so much faster than the Sun-1 (and 2) was it had larger
memory capacity on its boards and the memory transaction were quicker.

[-- Attachment #2: Type: text/html, Size: 5010 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-31  5:37             ` Dave Horsfall
  2019-08-31 19:03               ` Clem Cole
@ 2019-09-02  8:28               ` Peter Jeremy
  2019-09-02 23:26                 ` Dave Horsfall
  1 sibling, 1 reply; 49+ messages in thread
From: Peter Jeremy @ 2019-09-02  8:28 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 436 bytes --]

On 2019-Aug-31 15:37:32 +1000, Dave Horsfall <dave@horsfall.org> wrote:
>Ah, those were the days :-)  Now, we just have to put up with Intel, 
>although I believe the ARM is much better.

Well, https://www.youtube.com/watch?v=_6sh097Dk5k paints a less rosy
picture of ARM.  Maybe RISC-V will succeed.

It's a bit dated and very off topic but http://www.cpushack.com/CPU/cpu.html
makes interesting reading.

-- 
Peter Jeremy

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-09-02  8:28               ` Peter Jeremy
@ 2019-09-02 23:26                 ` Dave Horsfall
  0 siblings, 0 replies; 49+ messages in thread
From: Dave Horsfall @ 2019-09-02 23:26 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Mon, 2 Sep 2019, Peter Jeremy wrote:

> Well, https://www.youtube.com/watch?v=_6sh097Dk5k paints a less rosy
> picture of ARM.  Maybe RISC-V will succeed.
>
> It's a bit dated and very off topic but http://www.cpushack.com/CPU/cpu.html
> makes interesting reading.

Most interesting; thanks.

-- Dave

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-31 19:03               ` Clem Cole
@ 2019-09-05  5:11                 ` Al Kossow
  0 siblings, 0 replies; 49+ messages in thread
From: Al Kossow @ 2019-09-05  5:11 UTC (permalink / raw)
  To: tuhs

On 8/31/19 12:03 PM, Clem Cole wrote:
>
>
> I was under the belief that Sun never even tried the trick

Correct.

The original pre-BSD Sun-1 used the Stanford CPU,
ran Unisoft and used the stack probe hack in the compiler.

SunOS 1 required a 68010 'brain transplant'





^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?
@ 2019-09-01  2:36 Rudi Blom
  0 siblings, 0 replies; 49+ messages in thread
From: Rudi Blom @ 2019-09-01  2:36 UTC (permalink / raw)
  To: tuhs

Just to be precise and because I dislike loose ends :-)

Found the XTI to TCP/IP diagram. It's even online!
  https://www.cs.auckland.ac.nz/references/unix/digital/APS2WDTE/TITLE.HTM

Network Programmer's Guide
© Digital Equipment Corporation 1994, 1995, 1996
All Rights Reserved.
Product Version:  Digital UNIX Version 4.0 or higher
March 1996

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
@ 2019-09-01  2:16 Rudi Blom
  0 siblings, 0 replies; 49+ messages in thread
From: Rudi Blom @ 2019-09-01  2:16 UTC (permalink / raw)
  To: Clem Cole; +Cc: tuhs

I don't remember from where I got the scheme, so it might be general,
DigitalUnix, or HP-UX related. Checking the "HP 9000 networking XTI
programmer's guide" from 1995 there's no diagram.

The application which was initially developed on a SystemV derived
UNIX the Computer division of Philips Electronics had bought, used
TLI. Taken over by DEC we moved to SCO UNIX still using TLI, moving to
XLI on Alpha/Digital Unix.

The nice thing of TLI/XLI is the poll(). A multi-client server can
check a list of file descriptors AND indicate a timeout value for the
poll(). Like in
   	ret_cd = poll(tep->CEPlist, tep->CEPnumb, timeout);

BTW putting in a bit of OSI, on SCO UNIX I use a DEC package which
offers a TLI interface to an OSI TP4/IP stack. Even worked using X.25
as WAN. OSI TP4 and NetBIOS originally bought from Retix.

>Date: Sat, 31 Aug 2019 11:41:40 -0400
>From: Clem Cole <clemc@ccc.com>
>To: Rudi Blom <rudi.j.blom@gmail.com>
>Cc: tuhs <tuhs@minnie.tuhs.org>
>Subject: Re: [TUHS] dmr streams & networking [was: Re: If not Linux,then what?]
>Message-ID:
>        <CAC20D2MJPFoU6r73U9GDaqG+Q7vpH3T7CiDNjgN3D2uyuAJgLQ@mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>It's the Mentant implementation that HP originally bought.  At LCC we had
>to hacked on it a bit when we put Transparent Network Computing (TNC) stuff
>in HP-UX  [we had full process migration working BTW -- A real shame that
>never shipped].

>On Sat, Aug 31, 2019 at 5:44 AM Rudi Blom <rudi.j.blom@gmail.com> wrote:

>> Whenever I hear UNIX, networking and streams I have to think about this
>> scheme.
>>
>> Still using this, even on HP-UX 11.31 on Itanium rx-servers
>>
>> Cheers,
>> uncle rubl

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-31  9:43 Rudi Blom
@ 2019-08-31 15:41 ` Clem Cole
  0 siblings, 0 replies; 49+ messages in thread
From: Clem Cole @ 2019-08-31 15:41 UTC (permalink / raw)
  To: Rudi Blom; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

It's the Mentant implementation that HP originally bought.  At LCC we had
to hacked on it a bit when we put Transparent Network Computing (TNC) stuff
in HP-UX  [we had full process migration working BTW -- A real shame that
never shipped].

On Sat, Aug 31, 2019 at 5:44 AM Rudi Blom <rudi.j.blom@gmail.com> wrote:

> Whenever I hear UNIX, networking and streams I have to think about this
> scheme.
>
> Still using this, even on HP-UX 11.31 on Itanium rx-servers
>
> Cheers,
> uncle rubl
>

[-- Attachment #2: Type: text/html, Size: 873 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
@ 2019-08-31  9:43 Rudi Blom
  2019-08-31 15:41 ` Clem Cole
  0 siblings, 1 reply; 49+ messages in thread
From: Rudi Blom @ 2019-08-31  9:43 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 161 bytes --]

Whenever I hear UNIX, networking and streams I have to think about this scheme.

Still using this, even on HP-UX 11.31 on Itanium rx-servers

Cheers,
uncle rubl

[-- Attachment #2: Transport Interface.gif --]
[-- Type: image/gif, Size: 8969 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-29 16:38           ` Ralph Corderoy
@ 2019-08-29 17:35             ` arnold
  0 siblings, 0 replies; 49+ messages in thread
From: arnold @ 2019-08-29 17:35 UTC (permalink / raw)
  To: ralph, arnold; +Cc: tuhs, doug

Ralph Corderoy <ralph@inputplus.co.uk> wrote:

> Hi Arnold,
>
> > VM was done by Somebody Babaglu (a greek? name - I know I'm not
> > remembering it correctly.)
>
> Özalp Babaoğlu, a Turkish name.
> https://en.wikipedia.org/wiki/%C3%96zalp_Babao%C4%9Flu
>
> -- 
> Cheers, Ralph.

Much thanks. I knew I didn't have it right. :-)

Arnold

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-29 16:25         ` arnold
@ 2019-08-29 16:38           ` Ralph Corderoy
  2019-08-29 17:35             ` arnold
  0 siblings, 1 reply; 49+ messages in thread
From: Ralph Corderoy @ 2019-08-29 16:38 UTC (permalink / raw)
  To: arnold; +Cc: tuhs, doug

Hi Arnold,

> VM was done by Somebody Babaglu (a greek? name - I know I'm not
> remembering it correctly.)

Özalp Babaoğlu, a Turkish name.
https://en.wikipedia.org/wiki/%C3%96zalp_Babao%C4%9Flu

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-29  7:39     ` Rob Pike
@ 2019-08-29 16:26       ` arnold
  0 siblings, 0 replies; 49+ messages in thread
From: arnold @ 2019-08-29 16:26 UTC (permalink / raw)
  To: robpike, arnold; +Cc: tuhs, doug

Ah, OK.  Expedience + other considerations.

I don't suppose the Reiser 32V+paging survived anywhere?

Much thanks,

Arnold

Rob Pike <robpike@gmail.com> wrote:

> It had paging already and there was affection by some towards Berkeley.
>
> -rob
>
>
> On Thu, Aug 29, 2019 at 4:45 PM <arnold@skeeve.com> wrote:
>
> > Rob Pike <robpike@gmail.com> wrote:
> >
> > > Reiser Unix got demand paging a little later, and it was spectacularly
> > > fast. I remember being gobsmacked when I saw a demo in early 1981.
> >
> > So, once again, *W*H*Y* did Research choose BSD instead of Reiser's
> > version on the vax?
> >
> > > Dead ends everywhere.
> >
> > Explain please?
> >
> > Thanks,
> >
> > Arnold
> >

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-29 14:58       ` Jason Stevens
@ 2019-08-29 16:25         ` arnold
  2019-08-29 16:38           ` Ralph Corderoy
  0 siblings, 1 reply; 49+ messages in thread
From: arnold @ 2019-08-29 16:25 UTC (permalink / raw)
  To: lm, jsteve, chet.ramey; +Cc: tuhs, doug

Let's get it straight. I think Kirk McKusick did the FFS. VM was done
by Somebody Babaglu (a greek? name - I know I'm not remembering it correctly.)
I guess Joy did sockets, but I don't know. I do know that he did the
csh and ex/vi.  I gather he was also in the kernel, but it wasn't all him.

BSD was not a one man show.

Arnold

Jason Stevens <jsteve@superglobalmegacorp.com> wrote:

> Yeah sockets, FFS, VM, autoconfiguration.  It almost seems a shame he
> went to SUN.  Although at the same time it’s no wonder why they grabbed
> him ASAP.  I guess it’s like Avie working for NeXT.
>
> From: Larry McVoy
> Sent: Thursday, August 29, 2019 3:06 AM
> To: Chet Ramey
> Cc: tuhs@tuhs.org; doug@cs.dartmouth.edu
> Subject: Re: [TUHS] dmr streams & networking [was: Re: If not Linux,then what?]
>
> On Wed, Aug 28, 2019 at 03:03:34PM -0400, Chet Ramey wrote:
> > On 8/28/19 2:49 PM, arnold@skeeve.com wrote:
> > 
> > >> Sorry, what I said about London/Reiser is true, but not the whole
> > >> story. L/R didn't have demand paging; BSD did.
> > > 
> > > But my question still stands. Why didn't Research keep going from L/R
> > > and add demand paging?  Wouldn't that have been "cleaner" than starting
> > > from BSD?
> > 
> > It's my impression that BSD had done other work that Research didn't want
> > to duplicate, like autoconfiguration, device support, and so on. Joy got
> > a lot out of the VAX hardware.
>
> He was a coding machine back then.  Quite the legacy.
>

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28 19:05     ` Larry McVoy
@ 2019-08-29 14:58       ` Jason Stevens
  2019-08-29 16:25         ` arnold
  0 siblings, 1 reply; 49+ messages in thread
From: Jason Stevens @ 2019-08-29 14:58 UTC (permalink / raw)
  To: Larry McVoy, Chet Ramey; +Cc: tuhs, doug

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

Yeah sockets, FFS, VM, autoconfiguration.  It almost seems a shame he went to SUN.  Although at the same time it’s no wonder why they grabbed him ASAP.  I guess it’s like Avie working for NeXT.

From: Larry McVoy
Sent: Thursday, August 29, 2019 3:06 AM
To: Chet Ramey
Cc: tuhs@tuhs.org; doug@cs.dartmouth.edu
Subject: Re: [TUHS] dmr streams & networking [was: Re: If not Linux,then what?]

On Wed, Aug 28, 2019 at 03:03:34PM -0400, Chet Ramey wrote:
> On 8/28/19 2:49 PM, arnold@skeeve.com wrote:
> 
> >> Sorry, what I said about London/Reiser is true, but not the whole
> >> story. L/R didn't have demand paging; BSD did.
> > 
> > But my question still stands. Why didn't Research keep going from L/R
> > and add demand paging?  Wouldn't that have been "cleaner" than starting
> > from BSD?
> 
> It's my impression that BSD had done other work that Research didn't want
> to duplicate, like autoconfiguration, device support, and so on. Joy got
> a lot out of the VAX hardware.

He was a coding machine back then.  Quite the legacy.


[-- Attachment #2: Type: text/html, Size: 3030 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-29  6:43   ` arnold
@ 2019-08-29  7:39     ` Rob Pike
  2019-08-29 16:26       ` arnold
  0 siblings, 1 reply; 49+ messages in thread
From: Rob Pike @ 2019-08-29  7:39 UTC (permalink / raw)
  To: arnold; +Cc: The Eunuchs Hysterical Society, Doug McIlroy

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

It had paging already and there was affection by some towards Berkeley.

-rob


On Thu, Aug 29, 2019 at 4:45 PM <arnold@skeeve.com> wrote:

> Rob Pike <robpike@gmail.com> wrote:
>
> > Reiser Unix got demand paging a little later, and it was spectacularly
> > fast. I remember being gobsmacked when I saw a demo in early 1981.
>
> So, once again, *W*H*Y* did Research choose BSD instead of Reiser's
> version on the vax?
>
> > Dead ends everywhere.
>
> Explain please?
>
> Thanks,
>
> Arnold
>

[-- Attachment #2: Type: text/html, Size: 931 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28 21:54 ` Rob Pike
@ 2019-08-29  6:43   ` arnold
  2019-08-29  7:39     ` Rob Pike
  0 siblings, 1 reply; 49+ messages in thread
From: arnold @ 2019-08-29  6:43 UTC (permalink / raw)
  To: robpike, doug; +Cc: tuhs

Rob Pike <robpike@gmail.com> wrote:

> Reiser Unix got demand paging a little later, and it was spectacularly
> fast. I remember being gobsmacked when I saw a demo in early 1981.

So, once again, *W*H*Y* did Research choose BSD instead of Reiser's
version on the vax?

> Dead ends everywhere.

Explain please?

Thanks,

Arnold

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-29  0:11       ` Clem cole
  2019-08-29  0:18         ` George Michaelson
@ 2019-08-29  6:27         ` Lars Brinkhoff
  1 sibling, 0 replies; 49+ messages in thread
From: Lars Brinkhoff @ 2019-08-29  6:27 UTC (permalink / raw)
  To: Clem cole; +Cc: TUHS

Clem cole wrote:
> William That’s right. 4.1a supported at least these plus the original
> Xerox 3m card and I think a card MIT made for chaos

I would love to see 4.1a with Chaosnet support.  I have 4.1 patched with
MIT's Chaosnet software.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-29  3:29 ` Lawrence Stewart
@ 2019-08-29  4:10   ` Larry McVoy
  0 siblings, 0 replies; 49+ messages in thread
From: Larry McVoy @ 2019-08-29  4:10 UTC (permalink / raw)
  To: Lawrence Stewart; +Cc: tuhs, Doug McIlroy

On Wed, Aug 28, 2019 at 11:29:02PM -0400, Lawrence Stewart wrote:
> > On 2019, Aug 28, at 1:57 PM, Doug McIlroy <doug@cs.dartmouth.edu> wrote:
> >> How long was research running on a PDP-11 and when did they move to a VAX?
> > 
> > London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
> > 
> > Doug
> 
> I???ve always been a little curious about how Reiser (John Reiser, not Hans!) came to port Unix.  I had heard of him from his PhD Dissertation which was something like 35 pages long for Knuth (!) on random number generators.  He finished at Stanford in 1977 and in 1978 he was porting Unix?  How did that happen?

I'm with Lawrence, I'd love to hear this.  This thread is the first I've
heard about John Reiser and London.  I don't remember anything about them
in the Bell Labs journals.

I can say it is not a stretch to go from school to porting, I did that.

School is amazing at making you feel like you can do anything.  I took
the grad compiler class, you could take one of them or two of them at
a time, my buddy Rob Netzer and I took two together and we wrote a 
big subset of the ADA language in a semester.

You slow down when you have to make a product that works in the face
of people doing silly (aka stupid) things.  Error checking is a thing,
compiler error messages that point to the exact problem are a much,
much bigger thing.  Gcc is very good at that, I've got a lot of respect
for gcc, I know how hard that is.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28 17:57 Doug McIlroy
                   ` (3 preceding siblings ...)
  2019-08-28 21:54 ` Rob Pike
@ 2019-08-29  3:29 ` Lawrence Stewart
  2019-08-29  4:10   ` Larry McVoy
  4 siblings, 1 reply; 49+ messages in thread
From: Lawrence Stewart @ 2019-08-29  3:29 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: tuhs



> On 2019, Aug 28, at 1:57 PM, Doug McIlroy <doug@cs.dartmouth.edu> wrote:
> 
> 
>> How long was research running on a PDP-11 and when did they move to a VAX?
> 
> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
> 
> Doug

I’ve always been a little curious about how Reiser (John Reiser, not Hans!) came to port Unix.  I had heard of him from his PhD Dissertation which was something like 35 pages long for Knuth (!) on random number generators.  He finished at Stanford in 1977 and in 1978 he was porting Unix?  How did that happen?

-L


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-29  0:11       ` Clem cole
@ 2019-08-29  0:18         ` George Michaelson
  2019-08-29  6:27         ` Lars Brinkhoff
  1 sibling, 0 replies; 49+ messages in thread
From: George Michaelson @ 2019-08-29  0:18 UTC (permalink / raw)
  To: Clem cole; +Cc: TUHS

I should add that in the UK the vaxes we run included "systime"
equipment: They got done for photocopying DEC boards and reselling
without licence fee, and for selling kit to the USSR.  They'd started
as a Vt100 seller. nice terminals.

Shame about the bad business practices. The headquarters was a
modernist building used for the BBC tv series "edge of darkness" and
did have the CEO's helicopter parked outside: he flew it when they
could afford the avgas.

-G

On Thu, Aug 29, 2019 at 10:12 AM Clem cole <clemc@ccc.com> wrote:
>
> William That’s right. 4.1a supported at least these plus the original Xerox 3m card and I think a card MIT made for chaos and the protean card. iirc.  We had one of each of the production 10M Ethernet cards in the cad lab at UCB at some point.  The machine dec gave us had a dec card and that was the only dec card on campus so Sam would come over to my lab to test new OSses on that system.  UCB originally bought 3com cards (eventually in the cad group I got some early interlan cards from their ceo to test and I remember we liked them better for some reason I don’t remember). Before we had the 3COM based 10M link, we had couple of 3M Xerox cards on the original link back to Evans hall.
>
> The Xerox cards were used with the BBN tcp before 4.1a.  Eric cooper brought all that up with Sam and Bob Kriddle Iirc.
>
> That was all switched to the 3com cards pretty early to get 10M and Early after 4.1a and I do remember sam and I had used all that to debug Routed as we had the CAD Ethernet in Cory Hall, the back link to Evans and another Ethernet in the Evans machine room.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
> > On Aug 28, 2019, at 6:36 PM, William Pechter <pechter@gmail.com> wrote:
> >
> > I could've sworn 4.x BSD supported Micom Internan NI1010 or some other early
> > ethernet like 3com as well as the DEC boards.
> >
> > Anyone have the 4.1 or 4.2 BSD docs handy.  Mine are boxed away for safe keeping.
> >
> >> On 8/28/2019 6:29 PM, George Michaelson wrote:
> >> This is an object lesson in not making assumptions about things. I had
> >> always assumed the V in UNIX 32V stood for something which went to
> >> demand paging, from 'Virtual Addressing'. Turns out: I was wrong.
> >>
> >> One other note about sockets: The original 4.2 port had to be used by
> >> a lot of people without the ethernet, because we didn't have the DEC
> >> ethernet card it was written to. This made unix domain sockets very
> >> interesting because you could test in them. Except: the very first
> >> test program somebody wrote at Leeds university to create and write to
> >> a unix domain socket in /tmp crashed the vax. ... (this was around
> >> 1982/3) -We were warned off using sockets until the first patch tape
> >> came in the post.
> >>
> >>
> >

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28 22:36     ` William Pechter
  2019-08-28 23:02       ` Arthur Krewat
@ 2019-08-29  0:11       ` Clem cole
  2019-08-29  0:18         ` George Michaelson
  2019-08-29  6:27         ` Lars Brinkhoff
  1 sibling, 2 replies; 49+ messages in thread
From: Clem cole @ 2019-08-29  0:11 UTC (permalink / raw)
  To: William Pechter; +Cc: TUHS

William That’s right. 4.1a supported at least these plus the original Xerox 3m card and I think a card MIT made for chaos and the protean card. iirc.  We had one of each of the production 10M Ethernet cards in the cad lab at UCB at some point.  The machine dec gave us had a dec card and that was the only dec card on campus so Sam would come over to my lab to test new OSses on that system.  UCB originally bought 3com cards (eventually in the cad group I got some early interlan cards from their ceo to test and I remember we liked them better for some reason I don’t remember). Before we had the 3COM based 10M link, we had couple of 3M Xerox cards on the original link back to Evans hall. 

The Xerox cards were used with the BBN tcp before 4.1a.  Eric cooper brought all that up with Sam and Bob Kriddle Iirc.  

That was all switched to the 3com cards pretty early to get 10M and Early after 4.1a and I do remember sam and I had used all that to debug Routed as we had the CAD Ethernet in Cory Hall, the back link to Evans and another Ethernet in the Evans machine room.  

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Aug 28, 2019, at 6:36 PM, William Pechter <pechter@gmail.com> wrote:
> 
> I could've sworn 4.x BSD supported Micom Internan NI1010 or some other early
> ethernet like 3com as well as the DEC boards.
> 
> Anyone have the 4.1 or 4.2 BSD docs handy.  Mine are boxed away for safe keeping.
> 
>> On 8/28/2019 6:29 PM, George Michaelson wrote:
>> This is an object lesson in not making assumptions about things. I had
>> always assumed the V in UNIX 32V stood for something which went to
>> demand paging, from 'Virtual Addressing'. Turns out: I was wrong.
>> 
>> One other note about sockets: The original 4.2 port had to be used by
>> a lot of people without the ethernet, because we didn't have the DEC
>> ethernet card it was written to. This made unix domain sockets very
>> interesting because you could test in them. Except: the very first
>> test program somebody wrote at Leeds university to create and write to
>> a unix domain socket in /tmp crashed the vax. ... (this was around
>> 1982/3) -We were warned off using sockets until the first patch tape
>> came in the post.
>> 
>> 
> 

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28 22:36     ` William Pechter
@ 2019-08-28 23:02       ` Arthur Krewat
  2019-08-29  0:11       ` Clem cole
  1 sibling, 0 replies; 49+ messages in thread
From: Arthur Krewat @ 2019-08-28 23:02 UTC (permalink / raw)
  To: tuhs

On 8/28/2019 6:36 PM, William Pechter wrote:
> I could've sworn 4.x BSD supported Micom Internan NI1010 or some other 
> early
> ethernet like 3com as well as the DEC boards. 
I know some VAX-11/750's running BSD 4.2 were running NI1010's - I don't 
know if that was because someone had made/found a driver and installed 
it, or it was native. Maybe backported from 4.3.

I think I might actually have one of those 1010's and I'm pretty sure I 
have the driver development guide for it (tech specs).

Looking at the 4.3 sources I got from the place that had these VAXs, 
there's this.

./src/nfsdist/32_43.FCS/sys/vaxif/if_il.c
/* @(#)if_il.c  1.4 87/07/22 3.2/4.3NFSSRC */
/*
  * Copyright (c) 1982, 1986 Regents of the University of California.
  * All rights reserved.  The Berkeley software License Agreement
  * specifies the terms and conditions for redistribution.
  *
  *      @(#)if_il.c     7.1 (Berkeley) 6/5/86
  */

#include "il.h"
#if NIL > 0

/*
  * Interlan Ethernet Communications Controller interface
  */

<SNIP>


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28 22:29   ` George Michaelson
@ 2019-08-28 22:36     ` William Pechter
  2019-08-28 23:02       ` Arthur Krewat
  2019-08-29  0:11       ` Clem cole
  0 siblings, 2 replies; 49+ messages in thread
From: William Pechter @ 2019-08-28 22:36 UTC (permalink / raw)
  Cc: TUHS

I could've sworn 4.x BSD supported Micom Internan NI1010 or some other early
ethernet like 3com as well as the DEC boards.

Anyone have the 4.1 or 4.2 BSD docs handy.  Mine are boxed away for safe 
keeping.

On 8/28/2019 6:29 PM, George Michaelson wrote:
> This is an object lesson in not making assumptions about things. I had
> always assumed the V in UNIX 32V stood for something which went to
> demand paging, from 'Virtual Addressing'. Turns out: I was wrong.
>
> One other note about sockets: The original 4.2 port had to be used by
> a lot of people without the ethernet, because we didn't have the DEC
> ethernet card it was written to. This made unix domain sockets very
> interesting because you could test in them. Except: the very first
> test program somebody wrote at Leeds university to create and write to
> a unix domain socket in /tmp crashed the vax. ... (this was around
> 1982/3) -We were warned off using sockets until the first patch tape
> came in the post.
>
>


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28 21:55 ` Rob Pike
@ 2019-08-28 22:29   ` George Michaelson
  2019-08-28 22:36     ` William Pechter
  0 siblings, 1 reply; 49+ messages in thread
From: George Michaelson @ 2019-08-28 22:29 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

This is an object lesson in not making assumptions about things. I had
always assumed the V in UNIX 32V stood for something which went to
demand paging, from 'Virtual Addressing'. Turns out: I was wrong.

One other note about sockets: The original 4.2 port had to be used by
a lot of people without the ethernet, because we didn't have the DEC
ethernet card it was written to. This made unix domain sockets very
interesting because you could test in them. Except: the very first
test program somebody wrote at Leeds university to create and write to
a unix domain socket in /tmp crashed the vax. ... (this was around
1982/3) -We were warned off using sockets until the first patch tape
came in the post.

The Berkeley lawyers were amazing. I like to think 'shakespear
witches' or 'evil gnomes' -We had changed staff in some functional
role, and when we came to do licence renewal for the upgrade from 4.1
They insisted we find the mouldering body of the ex appointee and get
them to countersign (press the dead flesh in a pot of ink and put on
the paper?) before they'd re-issue. I'd never seen documents (a)
printed on this bizarre page size called 'legal and (b) actually
*embossed* by the university seal.. This was some serious magic going
down. In my nightmares, somebody in mid-western nondescript university
of somewhereville is screaming "I CANT GET THE ORIGINAL SIGNATURE" and
the Berkeley lawyers just shrug and walk away from the deal.

This was also the release which brought T/Roff drivers for xerographic
process printers. They emitted wet, shiny, even slimy pages in some
process I don't want to understand, all of which bore cut marks on the
side (roll feed, before A4 printers existed) marking this US legal
thing. Cut at the mark? Won't fit a ring-binder we own in the entire
University...  Mike Lesk told me the code had 'witticisms' such as an
extra emitted char on \r to ensure the specific printer it was written
for didn't stuff up TBL output.

-G

On Thu, Aug 29, 2019 at 7:55 AM Rob Pike <robpike@gmail.com> wrote:
>
> Reiser added paging and it was working well by early 1981.
>
> -rob
>
>
> On Thu, Aug 29, 2019 at 4:41 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:
>>
>> > Doug McIlroy <doug@cs.dartmouth.edu> wrote:
>> >
>> >>
>> >>> How long was research running on a PDP-11 and when did they move to a VAX?
>> >>
>> >> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
>> >>
>> >> Doug
>> >
>> > So, what's the story on why the London/Reiser port didn't get adapted
>> > back by Research, and they ended up starting from 4.1 BSD?
>> >
>> > Thanks,
>> >
>> > Arnold
>>
>>
>> Sorry, what I said about London/Reiser is true, but not the whole story. L/R didn't have demand paging; BSD did.
>>
>> Doug
>>

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28 18:41 Doug McIlroy
  2019-08-28 18:49 ` arnold
@ 2019-08-28 21:55 ` Rob Pike
  2019-08-28 22:29   ` George Michaelson
  1 sibling, 1 reply; 49+ messages in thread
From: Rob Pike @ 2019-08-28 21:55 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

Reiser added paging and it was working well by early 1981.

-rob


On Thu, Aug 29, 2019 at 4:41 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

> > Doug McIlroy <doug@cs.dartmouth.edu> wrote:
> >
> >>
> >>> How long was research running on a PDP-11 and when did they move to a
> VAX?
> >>
> >> London and Reiser had ported Unix to the VAX, replete with virtual
> memory, in 1978. By the time v7 was released (1979), Vaxen had become the
> workhorse machines in Research.
> >>
> >> Doug
> >
> > So, what's the story on why the London/Reiser port didn't get adapted
> > back by Research, and they ended up starting from 4.1 BSD?
> >
> > Thanks,
> >
> > Arnold
>
>
> Sorry, what I said about London/Reiser is true, but not the whole story.
> L/R didn't have demand paging; BSD did.
>
> Doug
>
>

[-- Attachment #2: Type: text/html, Size: 1316 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28 17:57 Doug McIlroy
                   ` (2 preceding siblings ...)
  2019-08-28 18:27 ` Warner Losh
@ 2019-08-28 21:54 ` Rob Pike
  2019-08-29  6:43   ` arnold
  2019-08-29  3:29 ` Lawrence Stewart
  4 siblings, 1 reply; 49+ messages in thread
From: Rob Pike @ 2019-08-28 21:54 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

I think it was slightly later. I joined mid-1980 and VAXes to replace the
11/70 were being discussed but had not arrived. We needed to convert a lab
into a VAX machine room and decide between BSD and Reiser, all of which
happened in the second half of 1980.

Reiser Unix got demand paging a little later, and it was spectacularly
fast. I remember being gobsmacked when I saw a demo in early 1981.

Dead ends everywhere.

-rob


On Thu, Aug 29, 2019 at 3:57 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

>
> > How long was research running on a PDP-11 and when did they move to a
> VAX?
>
> London and Reiser had ported Unix to the VAX, replete with virtual memory,
> in 1978. By the time v7 was released (1979), Vaxen had become the workhorse
> machines in Research.
>
> Doug
>

[-- Attachment #2: Type: text/html, Size: 1156 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28 19:03   ` Chet Ramey
@ 2019-08-28 19:05     ` Larry McVoy
  2019-08-29 14:58       ` Jason Stevens
  0 siblings, 1 reply; 49+ messages in thread
From: Larry McVoy @ 2019-08-28 19:05 UTC (permalink / raw)
  To: Chet Ramey; +Cc: tuhs, doug

On Wed, Aug 28, 2019 at 03:03:34PM -0400, Chet Ramey wrote:
> On 8/28/19 2:49 PM, arnold@skeeve.com wrote:
> 
> >> Sorry, what I said about London/Reiser is true, but not the whole
> >> story. L/R didn't have demand paging; BSD did.
> > 
> > But my question still stands. Why didn't Research keep going from L/R
> > and add demand paging?  Wouldn't that have been "cleaner" than starting
> > from BSD?
> 
> It's my impression that BSD had done other work that Research didn't want
> to duplicate, like autoconfiguration, device support, and so on. Joy got
> a lot out of the VAX hardware.

He was a coding machine back then.  Quite the legacy.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28 18:49 ` arnold
@ 2019-08-28 19:03   ` Chet Ramey
  2019-08-28 19:05     ` Larry McVoy
  0 siblings, 1 reply; 49+ messages in thread
From: Chet Ramey @ 2019-08-28 19:03 UTC (permalink / raw)
  To: arnold, tuhs, doug

On 8/28/19 2:49 PM, arnold@skeeve.com wrote:

>> Sorry, what I said about London/Reiser is true, but not the whole
>> story. L/R didn't have demand paging; BSD did.
> 
> But my question still stands. Why didn't Research keep going from L/R
> and add demand paging?  Wouldn't that have been "cleaner" than starting
> from BSD?

It's my impression that BSD had done other work that Research didn't want
to duplicate, like autoconfiguration, device support, and so on. Joy got
a lot out of the VAX hardware.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28 18:41 Doug McIlroy
@ 2019-08-28 18:49 ` arnold
  2019-08-28 19:03   ` Chet Ramey
  2019-08-28 21:55 ` Rob Pike
  1 sibling, 1 reply; 49+ messages in thread
From: arnold @ 2019-08-28 18:49 UTC (permalink / raw)
  To: tuhs, doug

Doug McIlroy <doug@cs.dartmouth.edu> wrote:

> > Doug McIlroy <doug@cs.dartmouth.edu> wrote:
> > 
> >>
> >>> How long was research running on a PDP-11 and when did they move to a VAX?
> >>
> >> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
> >> 
> >> Doug
> > 
> > So, what's the story on why the London/Reiser port didn't get adapted
> > back by Research, and they ended up starting from 4.1 BSD?
> > 
> > Thanks,
> > 
> > Arnold
>
> Sorry, what I said about London/Reiser is true, but not the whole
> story. L/R didn't have demand paging; BSD did.

But my question still stands. Why didn't Research keep going from L/R
and add demand paging?  Wouldn't that have been "cleaner" than starting
from BSD?

Thanks,

Arnold

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
@ 2019-08-28 18:41 Doug McIlroy
  2019-08-28 18:49 ` arnold
  2019-08-28 21:55 ` Rob Pike
  0 siblings, 2 replies; 49+ messages in thread
From: Doug McIlroy @ 2019-08-28 18:41 UTC (permalink / raw)
  To: tuhs

> Doug McIlroy <doug@cs.dartmouth.edu> wrote:
> 
>>
>>> How long was research running on a PDP-11 and when did they move to a VAX?
>>
>> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
>> 
>> Doug
> 
> So, what's the story on why the London/Reiser port didn't get adapted
> back by Research, and they ended up starting from 4.1 BSD?
> 
> Thanks,
> 
> Arnold


Sorry, what I said about London/Reiser is true, but not the whole story. L/R didn't have demand paging; BSD did.

Doug


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28 18:27 ` Warner Losh
@ 2019-08-28 18:34   ` Warner Losh
  0 siblings, 0 replies; 49+ messages in thread
From: Warner Losh @ 2019-08-28 18:34 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

On Wed, Aug 28, 2019, 12:27 PM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Wed, Aug 28, 2019, 11:57 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:
>
>>
>> > How long was research running on a PDP-11 and when did they move to a
>> VAX?
>>
>> London and Reiser had ported Unix to the VAX, replete with virtual
>> memory, in 1978. By the time v7 was released (1979), Vaxen had become the
>> workhorse machines in Research.
>>
>
>
> Is there a paper on this work?
>

Found the 32V paper, but this was still a swapping implementation if I'm
reading correctly. I thought that the virtual memory was added by BSD /
Bill Joy. That would explain why V8 was BSD 4.1 based, since it was the
first usable Vax port with VM.

Warner

>

[-- Attachment #2: Type: text/html, Size: 1809 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28 17:57 Doug McIlroy
  2019-08-28 18:05 ` Adam Thornton
  2019-08-28 18:08 ` arnold
@ 2019-08-28 18:27 ` Warner Losh
  2019-08-28 18:34   ` Warner Losh
  2019-08-28 21:54 ` Rob Pike
  2019-08-29  3:29 ` Lawrence Stewart
  4 siblings, 1 reply; 49+ messages in thread
From: Warner Losh @ 2019-08-28 18:27 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

On Wed, Aug 28, 2019, 11:57 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

>
> > How long was research running on a PDP-11 and when did they move to a
> VAX?
>
> London and Reiser had ported Unix to the VAX, replete with virtual memory,
> in 1978. By the time v7 was released (1979), Vaxen had become the workhorse
> machines in Research.
>


Is there a paper on this work?

Warner

>

[-- Attachment #2: Type: text/html, Size: 959 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28 17:57 Doug McIlroy
  2019-08-28 18:05 ` Adam Thornton
@ 2019-08-28 18:08 ` arnold
  2019-08-28 18:27 ` Warner Losh
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 49+ messages in thread
From: arnold @ 2019-08-28 18:08 UTC (permalink / raw)
  To: tuhs, doug

Doug McIlroy <doug@cs.dartmouth.edu> wrote:

>
> > How long was research running on a PDP-11 and when did they move to a VAX?
>
> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
>
> Doug

So, what's the story on why the London/Reiser port didn't get adapted
back by Research, and they ended up starting from 4.1 BSD?

Thanks,

Arnold

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28 17:57 Doug McIlroy
@ 2019-08-28 18:05 ` Adam Thornton
  2019-08-28 18:08 ` arnold
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 49+ messages in thread
From: Adam Thornton @ 2019-08-28 18:05 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

Interesting.  In my head, v7 is kind of the pinnacle of what you should run
on a PDP-11 (yes, I know 2.11BSD is still maintained), but that once you
add a networking stack, the 16-bit address limitations really start to
hurt, no matter how clever you are with your overlays.  But when I think of
v7, in my mind it's running on an 11/70.

I also find the multilayer switching described in the streams networking
implementation a lot like "inetd, all the way down."  That's kinda nifty.

Adam

On Wed, Aug 28, 2019 at 10:57 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

>
> > How long was research running on a PDP-11 and when did they move to a
> VAX?
>
> London and Reiser had ported Unix to the VAX, replete with virtual memory,
> in 1978. By the time v7 was released (1979), Vaxen had become the workhorse
> machines in Research.
>
> Doug
>

[-- Attachment #2: Type: text/html, Size: 1234 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
@ 2019-08-28 17:57 Doug McIlroy
  2019-08-28 18:05 ` Adam Thornton
                   ` (4 more replies)
  0 siblings, 5 replies; 49+ messages in thread
From: Doug McIlroy @ 2019-08-28 17:57 UTC (permalink / raw)
  To: tuhs


> How long was research running on a PDP-11 and when did they move to a VAX?

London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.

Doug

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
  2019-08-28  9:17 Paul Ruizendaal
@ 2019-08-28 10:44 ` Angelo Papenhoff
  0 siblings, 0 replies; 49+ messages in thread
From: Angelo Papenhoff @ 2019-08-28 10:44 UTC (permalink / raw)
  To: TUHS main list

On 28/08/19, Paul Ruizendaal wrote:
> 
> There is some contemporary material that gives a bit of context. The quotes are a bit contradictory and perhaps reflect evolving views.
> 
> [1]
> 
> The original dmr paper (1984) on streams (http://cm.bell-labs.co/who/dmr/st.html) seems to support the no networking view, focussing on terminal handling in its discussion. Also, near the end it says: "Streams are linear connections; by themselves, they support no notion of multiplexing, fan-in or fan-out. [...] It seems likely that a general multiplexing mechanism could help in both cases, but again, I do not yet know how to design it.” This seems to exclude usage for networking, which is typically multiplexed.
> 
> [2]
> 
> However, now that the V8 sources are available it is clear that the streams mechanism was used (by dmr?) to implement TCP/IP networking. He explains how that tallies with the above quote on multiplexing in a 1985 usenet post: https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3Astreams/net.unix-wizards/b7W_j_0qASU
> The config files in the surviving TUHS V8 source tree actually match with the setup that dmr described in the penultimate paragraph.
> 

Something else I found interesting is in v8's blit/Road.map:

"Next, operating systems.  We run under Berkeley 4.1bsd or Dennis Ritchie's
stacked line-discipline system."

That sounds to me like an early v8. If not, what was it? I'm really
interested in the timeline here. How long was research running on a
PDP-11 and when did they move to a VAX?


aap

^ permalink raw reply	[flat|nested] 49+ messages in thread

* [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
@ 2019-08-28  9:17 Paul Ruizendaal
  2019-08-28 10:44 ` Angelo Papenhoff
  0 siblings, 1 reply; 49+ messages in thread
From: Paul Ruizendaal @ 2019-08-28  9:17 UTC (permalink / raw)
  To: TUHS main list


> I find it hard to believe what you remember Dennis saying. The point of
> dmr's streams was to support networking research in the lab and avoid the
> myriad bugs of the mpx interface by stepping around them completely.
> 
> Perhaps it's out of context.
> 
> -rob

> I could be wrong but that's my memory.  What he told me was streams was
> for line disciplines for tty drivers.  That's what I know but you were
> there, I was not.  I'm pretty confused because what Dennis said to me
> was that he did not think streams would work for networking, he thought
> they made sense for a stream but not for a networking connection because
> that had multiple connections coming up through a stream.


There is some contemporary material that gives a bit of context. The quotes are a bit contradictory and perhaps reflect evolving views.

[1]

The original dmr paper (1984) on streams (http://cm.bell-labs.co/who/dmr/st.html) seems to support the no networking view, focussing on terminal handling in its discussion. Also, near the end it says: "Streams are linear connections; by themselves, they support no notion of multiplexing, fan-in or fan-out. [...] It seems likely that a general multiplexing mechanism could help in both cases, but again, I do not yet know how to design it.” This seems to exclude usage for networking, which is typically multiplexed.

[2]

However, now that the V8 sources are available it is clear that the streams mechanism was used (by dmr?) to implement TCP/IP networking. He explains how that tallies with the above quote on multiplexing in a 1985 usenet post: https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3Astreams/net.unix-wizards/b7W_j_0qASU
The config files in the surviving TUHS V8 source tree actually match with the setup that dmr described in the penultimate paragraph.

If the post by dmr does not immediately appear, click on the 8-10-85 post by 'd...@dutoit.uucp’ to make it fold out. For ease of reference, I’m including the message text below.

<quote>

Steven J. Langdon claimed that without multiplexing one couldn't
do a proper kernel-resident version of TCP/IP in the V8 stream context.
Here's how it's done.
It is still true in our system that stream multiplexing does not occur,
in the sense that every stream connection has (from the point of view
of the formal data structures) exactly two ends, one at a user process,
and the other at a device or another process.  However, this has, in
practice, not turned out to be a problem.  Say you have a hardware
device that hands you packets with a channel (or socket) number buried
inside in some complicated format.  The general scheme to handle the
situation uses both a line discipline (stream filter module) and
associated code that, to the system, looks like a stream device driver
with several minor devices; these have entries in /dev.

A watchdog process opens the underlying real device, and pushes
the stream module.   Arriving packets from the real device
are passed to this module, where they are analyzed,
and then given to the appropriate associated pseudo-device.
Likewise, messages written on the pseudo-device are shunted over to
the line discipline, where they are encoded appropriately and sent
to the real device.  This is where the multiplexing-demultiplexing
occurs; formally, it is outside of the stream structure, because
the data-passing doesn't follow the forward and backward links
of the stream modules.  However, the interfaces of the combined
larger module obey stream rules.

For example, IP works this way:  The IP line discipline looks at the
type field of data arriving from the device, and determines whether the
packet is TCP or UDP or ARP or whatever, and shunts it off to the
stream associated with /dev/ip6 or /dev/ip17 or whatever the numbers
are.

TCP, of course, is multiplexed as well.  So there is a TCP line
discipline, and a bunch of TCP devices; a watchdog process opens
/dev/ip6, and pushes the TCP line discipline; then the TCP packets it
gets are parcelled out to the appropriate /dev/tcpXX device.  Each TCP
device looks like the end of a stream, and may, of course, have other
modules (e.g.  tty processor) inserted in this stream.

UDP sits on top of IP in the same way.

This example is complicated, because (TCP,UDP)/IP is.  However, it
works well.  In particular, the underlying real device can be either an
ethernet or our own Datakit network; the software doesn't care.  For
example, from my machine, I can type "rlogin purdy" and connect to a
Sequent machine running 4.2; the TCP connection goes over Datakit to
machine "research" where it is gatewayed to a local ethernet that purdy
is connected to.

A further generalization (that we haven't made) is in principle easy:
there can be protocol suites other than IP on an Ethernet cable.  So
there could be another layer to separate IP from XNS from Chaosnet, etc.

        Dennis Ritchie

</quote>

Maybe the subtle notion expressed as "formally, it is outside of the stream structure, because the data-passing doesn't follow the forward and backward links of the stream modules.  However, the interfaces of the combined larger module obey stream rules” explains how dmr could talk about streams as being just suitable for line disciplines without meaning to say that they did not have good use in networking.

Paul
 


^ permalink raw reply	[flat|nested] 49+ messages in thread

end of thread, other threads:[~2019-09-05  5:18 UTC | newest]

Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-30 20:21 [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] Norman Wilson
2019-08-30 20:28 ` Larry McVoy
2019-08-30 20:39 ` Clem Cole
2019-08-30 21:52   ` Larry McVoy
2019-08-31  0:58     ` Clem Cole
2019-08-31  1:13       ` Bakul Shah
2019-08-31  2:46         ` Clem cole
2019-08-31  2:57           ` Clem cole
2019-08-31  3:14             ` Gregg Levine
2019-08-31  3:47               ` Clem cole
2019-08-31  3:38             ` Bakul Shah
2019-08-31  5:37             ` Dave Horsfall
2019-08-31 19:03               ` Clem Cole
2019-09-05  5:11                 ` Al Kossow
2019-09-02  8:28               ` Peter Jeremy
2019-09-02 23:26                 ` Dave Horsfall
2019-08-31  3:19           ` Bakul Shah
  -- strict thread matches above, loose matches on Subject: below --
2019-09-01  2:36 [TUHS] dmr streams & networking [was: Re: If not Linux, then what? Rudi Blom
2019-09-01  2:16 [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] Rudi Blom
2019-08-31  9:43 Rudi Blom
2019-08-31 15:41 ` Clem Cole
2019-08-28 18:41 Doug McIlroy
2019-08-28 18:49 ` arnold
2019-08-28 19:03   ` Chet Ramey
2019-08-28 19:05     ` Larry McVoy
2019-08-29 14:58       ` Jason Stevens
2019-08-29 16:25         ` arnold
2019-08-29 16:38           ` Ralph Corderoy
2019-08-29 17:35             ` arnold
2019-08-28 21:55 ` Rob Pike
2019-08-28 22:29   ` George Michaelson
2019-08-28 22:36     ` William Pechter
2019-08-28 23:02       ` Arthur Krewat
2019-08-29  0:11       ` Clem cole
2019-08-29  0:18         ` George Michaelson
2019-08-29  6:27         ` Lars Brinkhoff
2019-08-28 17:57 Doug McIlroy
2019-08-28 18:05 ` Adam Thornton
2019-08-28 18:08 ` arnold
2019-08-28 18:27 ` Warner Losh
2019-08-28 18:34   ` Warner Losh
2019-08-28 21:54 ` Rob Pike
2019-08-29  6:43   ` arnold
2019-08-29  7:39     ` Rob Pike
2019-08-29 16:26       ` arnold
2019-08-29  3:29 ` Lawrence Stewart
2019-08-29  4:10   ` Larry McVoy
2019-08-28  9:17 Paul Ruizendaal
2019-08-28 10:44 ` Angelo Papenhoff

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).