The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] PCS Munix kernel source
@ 2022-08-11  6:04 Paul Ruizendaal via TUHS
  2022-08-11  9:01 ` [TUHS] " Holger Veit
  2022-08-11 13:32 ` Nelson H. F. Beebe
  0 siblings, 2 replies; 6+ messages in thread
From: Paul Ruizendaal via TUHS @ 2022-08-11  6:04 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society


> Message: 4
> Date: Wed, 10 Aug 2022 12:29:24 +0200
> From: Holger Veit <hveit01@web.de>
> Subject: [TUHS] PCS Munix kernel source
> 
> Hi all,
> 
> I have uploaded the kernel source of 32 bit PCS MUNIX 1.2 to
> https://github.com/hveit01/pcs-munix.

Thank you for sharing this work, most impressive!

> MUNIX was an AT&T SVR3.x implementation ...

Are you sure? Could it perhaps be SVR2? (I don’t see any STREAMS stuff that one would expect for R3).

> The interesting feature of this kernel is the integration of the
> Newcastle Connection network

One of my interests is Unix (packet) networking 1975-1985 and that includes Newcastle Connection. I’ve so far not dived deep into this, but your work may be the trigger for some further investigation.

My understanding so far (from reading the paper a few years ago) is that Newcastle Connection works at the level of libc, substituting  system calls like open() and exec() with library routines that scan the path, and if it is a network path invokes user mode routines that use remote procedure calls to give the illusion of a networked kernel. I’ve briefly looked at the Git repo, but I do not see that structure in the code. Could you elaborate a bit more on how Newcastle Connection operates in this kernel? Happy to communicate off-list if it goes in too much detail.

I note that the repo Readme says that the kernel only does some basic IP networking as a carrier, but I also see some files in the tree that seem to implement a form of tcp (and that seem unrelated to the early Unix tcp/ip’s that I have seen so far). Or am I reading too much into these files?

===

Re-reading the Newcastle Connection paper also brought up some citations from Bell Labs work that seems to have been lost. There is a reference to “RIDE” which appears to be a system similar to Newcastle Connection. The RIDE paper is from 1979 and it mentions that RIDE is a Datakit re-implementation of earlier an earlier system that ran on Spider. Any recollections about these things among the TUHS readership?

The other citation is for J. C. Kaufeld and D. L. Russell, "Distributed UNIX System", in Workshop on Fundamental Issues in Distributed Computing, ACM SIGOPS and SIGPLAN (15-17 Dec. 1980). It seems contemporaneous with the Luderer/Marshall/Chu work on S/F-Unix. I could not find this paper so far. Here, too, any recollections about this distributed Unix among the TUHS readership?





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

* [TUHS] Re: PCS Munix kernel source
  2022-08-11  6:04 [TUHS] PCS Munix kernel source Paul Ruizendaal via TUHS
@ 2022-08-11  9:01 ` Holger Veit
  2022-08-13 20:40   ` Paul Ruizendaal
  2022-08-11 13:32 ` Nelson H. F. Beebe
  1 sibling, 1 reply; 6+ messages in thread
From: Holger Veit @ 2022-08-11  9:01 UTC (permalink / raw)
  To: Paul Ruizendaal, The Eunuchs Hysterical Society


Am 11.08.2022 um 08:04 schrieb Paul Ruizendaal:
> MUNIX was an AT&T SVR3.x implementation ...
> Are you sure? Could it perhaps be SVR2? (I don’t see any STREAMS stuff that one would expect for R3).
It is a hybrid system. I found files and similarities in R1, R2 as well
as R3 - the C compiler (in my queue) for instance is likely derived (and
heavily modified) from a R1 origin, but in this version itself linked
with a C library where parts are newer, namely from a later released
version (in the update 3-3.1 in tape IS0463P) which I'll add in the
future. I am sure that the kernel libs will then reveal the missing
streams stuff.

I think it was a rolling release which also still contains parts of the
older 16 bit MUNIX for a 68010 with Motorolas FFP lib - the kernel still
contains an obsolete module named m68341 which emulates an incompatible
floating point lib. The 32 bit system here demands a 68020/68881
combination. There are also several QBUS I/O drivers which seem to stem
from the 16 bit systems which likely do no longer access real existing
hardware because the newer systems used a communication controller board
named ICC with an own 68010 processor and a highly stripped down
tailored UNIX (?) on it. This is also on my to-do list.

@readers of TUHS: can anyone say something about m68341? There are
Motorola FFP libs elsewhere on the net, but this appears to be a
complete copro emulation which intercepts the line-F interrupt which I
could not locate so far. Internally, it is pretty much optimized - I
doubt it was cooked at PCS itself, so it is likely a Motorola product.
And no, it has absolutely nothing to do with the embedded controller
MC68341.

Currently I am dissecting the also rather unique a68 assembler which is
a modified Trix/Mical assembler; after that, I'll look into the IS0463P
update.
>> The interesting feature of this kernel is the integration of the
>> Newcastle Connection network
> One of my interests is Unix (packet) networking 1975-1985 and that includes Newcastle Connection. I’ve so far not dived deep into this, but your work may be the trigger for some further investigation.
>
> My understanding so far (from reading the paper a few years ago) is that Newcastle Connection works at the level of libc, substituting  system calls like open() and exec() with library routines that scan the path, and if it is a network path invokes user mode routines that use remote procedure calls to give the illusion of a networked kernel. I’ve briefly looked at the Git repo, but I do not see that structure in the code. Could you elaborate a bit more on how Newcastle Connection operates in this kernel? Happy to communicate off-list if it goes in too much detail.
Maybe the original NC did so, but here there are numerous additions to
the kernel, including a new syscall uipacket() which is the gateway into
the MUNET/NC implementation. Stuff is in /usr/sys/munet, the low level
networking is in uipacket.c and uiswtch.c which will process RPC
open/close/read/write/exec etc. calls, as well support master and
diskless nodes). The OS code is full of "if (master) {...} else {...}'
code which then redirects detected access to remote paths to the network
handler.

>
> I note that the repo Readme says that the kernel only does some basic IP networking as a carrier, but I also see some files in the tree that seem to implement a form of tcp (and that seem unrelated to the early Unix tcp/ip’s that I have seen so far). Or am I reading too much into these files?
>
> ===
>
> Re-reading the Newcastle Connection paper also brought up some citations from Bell Labs work that seems to have been lost. There is a reference to “RIDE” which appears to be a system similar to Newcastle Connection. The RIDE paper is from 1979 and it mentions that RIDE is a Datakit re-implementation of earlier an earlier system that ran on Spider. Any recollections about these things among the TUHS readership?
>
> The other citation is for J. C. Kaufeld and D. L. Russell, "Distributed UNIX System", in Workshop on Fundamental Issues in Distributed Computing, ACM SIGOPS and SIGPLAN (15-17 Dec. 1980). It seems contemporaneous with the Luderer/Marshall/Chu work on S/F-Unix. I could not find this paper so far. Here, too, any recollections about this distributed Unix among the TUHS readership?
Good to mention this. I am interested in such stuff as well.

Regards
Holger

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

* [TUHS] Re: PCS Munix kernel source
  2022-08-11  6:04 [TUHS] PCS Munix kernel source Paul Ruizendaal via TUHS
  2022-08-11  9:01 ` [TUHS] " Holger Veit
@ 2022-08-11 13:32 ` Nelson H. F. Beebe
  1 sibling, 0 replies; 6+ messages in thread
From: Nelson H. F. Beebe @ 2022-08-11 13:32 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society; +Cc: Paul Ruizendaal

Paul Ruizendaal <pnr@planet.nl> writes on the TUHS list today:

>> ...
>> ... the Luderer/Marshall/Chu work on S/F-Unix. I could not find this
>> paper so far. Here, too, any recollections about this distributed Unix
>> among the TUHS readership?
>> ...

Is this the sought paper?:

@String{j-OPER-SYS-REV          = "Operating Systems Review"}

@Article{Luderer:1981:DUS,
  author =       "G. W. R. Luderer and H. Che and J. P. Haggerty and P.
                 A. Kirslis and W. T. Marshall",
  title =        "A distributed {UNIX} system based on a virtual circuit
                 switch",
  journal =      j-OPER-SYS-REV,
  volume =       "15",
  number =       "5",
  pages =        "160--168",
  month =        dec,
  year =         "1981",
  CODEN =        "OSRED8",
  ISSN =         "0163-5980 (print), 1943-586X (electronic)",
  ISSN-L =       "0163-5980",
  bibdate =      "Sat Aug 26 08:55:53 MDT 2006",
  bibsource =    "http://portal.acm.org/;
                 http://www.math.utah.edu/pub/tex/bib/unix.bib",
  acknowledgement = ack-nhfb,
  fjournal =     "ACM SIGOPS Operating Systems Review",
  journal-URL =  "http://portal.acm.org/browse_dl.cfm?idx=J597",
}

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                                                          -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

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

* [TUHS] Re: PCS Munix kernel source
  2022-08-11  9:01 ` [TUHS] " Holger Veit
@ 2022-08-13 20:40   ` Paul Ruizendaal
  0 siblings, 0 replies; 6+ messages in thread
From: Paul Ruizendaal @ 2022-08-13 20:40 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society



> On Aug 11, 2022, at 11:01 AM, Holger Veit <hveit01@web.de> wrote:
>> 
>> 
>> My understanding so far (from reading the paper a few years ago) is that Newcastle Connection works at the level of libc, substituting  system calls like open() and exec() with library routines that scan the path, and if it is a network path invokes user mode routines that use remote procedure calls to give the illusion of a networked kernel. I’ve briefly looked at the Git repo, but I do not see that structure in the code. Could you elaborate a bit more on how Newcastle Connection operates in this kernel? Happy to communicate off-list if it goes in too much detail.
> Maybe the original NC did so, but here there are numerous additions to
> the kernel, including a new syscall uipacket() which is the gateway into
> the MUNET/NC implementation. Stuff is in /usr/sys/munet, the low level
> networking is in uipacket.c and uiswtch.c which will process RPC
> open/close/read/write/exec etc. calls, as well support master and
> diskless nodes). The OS code is full of "if (master) {...} else {...}'
> code which then redirects detected access to remote paths to the network
> handler.

I came across a later paper for Unix United / Newcastle Connection. It seems to consider moving parts of the code into the kernel, to combat executable bloat (the relevant libc code would be copied into every executable, prior to shared libraries):

https://www.researchgate.net/publication/2997714_The_architecture_of_UNIX_united


>> Re-reading the Newcastle Connection paper also brought up some citations from Bell Labs work that seems to have been lost. There is a reference to “RIDE” which appears to be a system similar to Newcastle Connection. The RIDE paper is from 1979 and it mentions that RIDE is a Datakit re-implementation of earlier an earlier system that ran on Spider. Any recollections about these things among the TUHS readership?
>> 
>> The other citation is for J. C. Kaufeld and D. L. Russell, "Distributed UNIX System", in Workshop on Fundamental Issues in Distributed Computing, ACM SIGOPS and SIGPLAN (15-17 Dec. 1980). It seems contemporaneous with the Luderer/Marshall/Chu work on S/F-Unix. I could not find this paper so far. Here, too, any recollections about this distributed Unix among the TUHS readership?

> Good to mention this. I am interested in such stuff as well.

I found a summary of that ACM SIGOPS workshop. There is a half page summary about David Russels presentation on “Distributed Unix”:

====

2.4 David Russell: Distributed UNIX

Distributed UNIX is an experimental system consisting of a collection of machines running a modified version of UNIX.

Communication among processors is performed by a packet switching network built on Datakit hardware. The network has
a capacity of roughly 7.5 megabits, shared among several channels. Addressing is done by channel, not by target
processor. Messages are received in the order sent. To the user, communication takes the form of a virtual circuit,
a logical full-duplex connection between processors.

A virtual circuit can be modeled as a box with four ends: DIN and DOUT control data transmission, and CIN and COUT
control transmission of control information. Circuits can be spliced together, or attached to devices. Circuits can
also be joined into groups. A virtual circuit is set up in the following way: a socket is created with a globally
unique name, and processes then request connections to the named socket. Routing information is implicit. Virtual
circuits support location transparency, since sockets can move, but not replication transparency. If a circuit breaks,
it is set up again, although it is up to the user to handle recovery of state information. Machine failure will destroy
a virtual circuit.

A transparent distributed file system was set up. When a remote file is accessed, a socket name is generated, which is
used to establish a connection with a daemon at the file server processor. The daemon carries out the file access on
behalf of the remote user. In conclusion, offloading of tasks was found to work well. The path manager maintains very
little state. The splice interface between virtual circuits was found to be very efficient, although UNIX scheduling
was not appropriate for fast setup of circuits.

====

The modeling of virtual circuits sounds like a mid-point between Chesson’s multiplexed files and Ritchie’s streams.

The file system actually sounds like it could be the RIDE system. Maybe this Distributed Unix and RIDE are one and the same thing.
(although the original Newcastle Connection paper suggests they are not:   https://inis.iaea.org/collection/NCLCollectionStore/_Public/16/081/16081910.pdf?r=1&r=1).

Paul


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

* [TUHS] Re: PCS Munix kernel source
  2022-08-10 10:29 [TUHS] " Holger Veit
  2022-08-10 16:12 ` [TUHS] " Warner Losh
@ 2022-08-10 17:15 ` emanuel stiebler
  1 sibling, 0 replies; 6+ messages in thread
From: emanuel stiebler @ 2022-08-10 17:15 UTC (permalink / raw)
  To: Holger Veit, tuhs

On 2022-08-10 06:29, Holger Veit wrote:
> Hi all,
> 
> I have uploaded the kernel source of 32 bit PCS MUNIX 1.2 to
> https://github.com/hveit01/pcs-munix.
> 
> MUNIX was an AT&T SVR3.x implementation for the German PCS Cadmus
> workstations in the 80's. They were
> based on Motorola 68020 CPUs on a DEC QBUS.

Great little machines, and nice graphics options. I loved working on them.

Thanks for sharing!

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

* [TUHS] Re: PCS Munix kernel source
  2022-08-10 10:29 [TUHS] " Holger Veit
@ 2022-08-10 16:12 ` Warner Losh
  2022-08-10 17:15 ` emanuel stiebler
  1 sibling, 0 replies; 6+ messages in thread
From: Warner Losh @ 2022-08-10 16:12 UTC (permalink / raw)
  To: Holger Veit; +Cc: The Eunuchs Hysterical Society

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

On Wed, Aug 10, 2022 at 4:29 AM Holger Veit <hveit01@web.de> wrote:

> Hi all,
>
> I have uploaded the kernel source of 32 bit PCS MUNIX 1.2 to
> https://github.com/hveit01/pcs-munix.
>

This is really cool!


> MUNIX was an AT&T SVR3.x implementation for the German PCS Cadmus
> workstations in the 80's. They were
> based on Motorola 68020 CPUs on a DEC QBUS.
>

Fun times that combination...


> The interesting feature of this kernel is the integration of the
> Newcastle Connection network
> (https://en.wikipedia.org/wiki/Newcastle_Connection) which I found,
> beyond a tech report https://assets.cs.ncl.ac.uk/TRs/175.pdf, no further
> references for.
>
> The kernel source was reverse engineered and verified (see readme in the
> distribution who this was done) from the binary tape at
> ftp.informatik.uni-stuttgart.de/pub/cm/pcs/sw/IS0371P.tap (Computer
> museum of the University of Stuttgart), and to my knowledge reveals the
> Newcastle connection code for the first time in a commercial Unix.
>
> The Github package includes the kernel sources, i/O drivers, several
> standard libraries, the disassembled boot ROM and for reference, two of
> my tools, a partial syscall emulator pcsrun which allowed me to run the
> C compiler and other native binaries outside the PCS hardware/Unix
> environment, and a disassembler pcsdis for the specific COFF dialect
> (note that IDA will produce garbage without a specific patch).
>

I love it. This is quite similar, though further along, than my on-again
off-again efforts to do the same with Venix 86/R for my Rainbow...

Warner

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

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

end of thread, other threads:[~2022-08-13 20:41 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-11  6:04 [TUHS] PCS Munix kernel source Paul Ruizendaal via TUHS
2022-08-11  9:01 ` [TUHS] " Holger Veit
2022-08-13 20:40   ` Paul Ruizendaal
2022-08-11 13:32 ` Nelson H. F. Beebe
  -- strict thread matches above, loose matches on Subject: below --
2022-08-10 10:29 [TUHS] " Holger Veit
2022-08-10 16:12 ` [TUHS] " Warner Losh
2022-08-10 17:15 ` emanuel stiebler

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