3 ms·
We know from papers published by Bell labs that there were two other UNIX kernel implementations that ran on top of foreign kernels: One ran on top of Sperry/U
by chasil 2y ago
We know from papers published by Bell labs that there were two other UNIX kernel implementations that ran on top of foreign kernels:
One ran on top of Sperry/Univac OS2200 EXEC-8 (and this was the first SMP UNIX AFAIK):
https://www.bell-labs.com/usr/dmr/www/otherports/newp.pdf https://www.bell-labs.com/usr/dmr/www/otherports/newp.pdf
"The UNIX system for the UNIVAC 1100 series was built as an integrated development environment
for transactions that run directly on EXEC. Unlike most other implementations, therefore, it runs not
directly on the hardware but as a collection of user-level activities under control of EXEC. These obtain
services that would normally be provided by device drivers, and some process creation and management
services from EXEC. Any configuration supplied by Sperry, including multiprocessor ones, can run the
UNIX system."
A Bell Labs port to an IBM mainframe ran on top of TSS/370:
https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf
"Of the available systems, TSS/370 came the closest to meeting our needs and was thus chosen as the
base for our UNIX system implementation. The choice of TSS/370 was a controversial one; it is a little
known and inadequately documented system. Still, it came the closest to providing the structure and function needed to support UNIX system processes, and it appeared that it could be enhanced to provide any
missing functions with reasonable effort. In 1979 we proposed to IBM that they make the necessary modifications to the TSS supervisor to support UNIX system processes, according to our design. IBM agreed to
do so under a program license agreement, and the first version of the enhanced TSS was delivered in 1980."
- skissane 2y agoI knew about the TSS/370-based port but had forgotten its relevance I can think of another: the University of Wollongong’s port of Unix V6 to the Interdata 7/32 started out running under Interdata’s OS/32, until the port advanced to the point that they could get rid of OS/32 and run it directly on bare metal. I suppose this differs from these other ports in that it was only ever intended as a temporary stopgap while the port could be completed, not as a final destination: http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/32bit/unix/univWollongong_v6/miller.pdf http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/... The Princeton port that evolved into Amdahl UTS maybe also counts, since early versions could only run under VM, not bare metal. That meant they could use VM’s simplified paravirtual device API (hypercalls via DIAG instruction), that hid some of the complexity of mainframe IO-running on bare metal required dealing with those complexities directly
- chasil 2y agoI knew there were multiple ports to the Interdata hardware, one specifically from Bell. I actually went over the Univac and TSS ports in my parallel xargs article: https://www.linuxjournal.com/content/parallel-shells-xargs-utilize-all-your-cpu-cores-unix-and-windows https://www.linuxjournal.com/content/parallel-shells-xargs-u... In my workplace, we still have fully-supported OS2200 running the DMS hierarchical database. We are also running VAX VMS on the Charon emulator, but there are plans to replace the VAX's functions with Rockwell's "Factory Talk Production Center."
- gregw2 2y agoI hadn't heard about that UNIX "Princeton port" before. Thanks! Also TIL: Eric Schmidt worked on that port apparently ( https://en.wikipedia.org/wiki/Amdahl_UTS https://en.wikipedia.org/wiki/Amdahl_UTS ), in addition to or around the same time as his ?summer? internship work at Bell Labs as co-author of Lex (https://en.wikipedia.org/wiki/Eric_Schmidt https://en.wikipedia.org/wiki/Eric_Schmidt). That would have been before he went to Berkeley and then joined Sun as its first software manager. Tom Lyons's 3-part blog post on the port (which he worked on) adds nice context and some fun to read technical tidbits and commentary: https://akapugs.blog/2018/05/12/370unixpart1/ https://akapugs.blog/2018/05/12/370unixpart1/ Aparently Eric didn't just work on the port, he recognized the technical pieces were in place enabling a port and organized the collaboration to carry it out. Although in a funny line in that same piece, Tom notes: "Eric, in a display of his future managerial potential, did not participate in the actual technical work, but deserves a lot of credit for working the system to make things possible."