From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14820 invoked from network); 13 Aug 2022 20:41:19 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 13 Aug 2022 20:41:19 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id BBBAC40260; Sun, 14 Aug 2022 06:40:43 +1000 (AEST) Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.168]) by minnie.tuhs.org (Postfix) with ESMTPS id C50ED40246 for ; Sun, 14 Aug 2022 06:40:37 +1000 (AEST) X-KPN-MessageId: 28136d36-1b48-11ed-be70-005056aba152 Received: from smtp.kpnmail.nl (unknown [10.31.155.38]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id 28136d36-1b48-11ed-be70-005056aba152; Sat, 13 Aug 2022 22:40:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=to:message-id:date:from:subject:mime-version:content-type; bh=LC+s9DFwLx/fklmhzscnFK7q/O8LlQBEvwzAfWYQmgU=; b=o3is5he0l8kfBIGFvXYPFgYDDGugZGlmQ8mDAxyv2FAuiZh1w5QayN+Iu/RxhKRawn+wePcpmvyP5 eKmoCieV4MZfkaQ84qlnAgmolCb7x0L1lf7ImGY7YO0F5Z5Iun8/OZ4wOJoFkBKEzkva/6PSLlfAWw bgq7RCWVftbp6tnE= X-KPN-MID: 33|irB7nwQfMaxFkpER0TMCmmV7CtYTdhkMp/sqfiDi7oXUIvdGVRnUMUxjJdmPrmg DVxAa0utdHpKNzsjZLwOz/Ygg5r/NMGY/iJf4FEc/uQ0= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|lqEUaK3RT0bxuXJD4kLymjxLl5LYxhoLiZAkqxtlC9VZJFnfCjBXFisocXPcbn8 9bPR5/SMSNiUjtkHMRIl5nQ== X-Originating-IP: 77.172.38.96 Received: from mba1.fritz.box (77-172-38-96.fixed.kpn.net [77.172.38.96]) by smtp.kpnmail.nl (Halon) with ESMTPSA id 2996c571-1b48-11ed-b5e7-005056abf0db; Sat, 13 Aug 2022 22:40:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Paul Ruizendaal In-Reply-To: Date: Sat, 13 Aug 2022 22:40:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4418AB9D-1174-480C-9BC3-7F39F0593D11@planet.nl> References: To: The Eunuchs Hysterical Society X-Mailer: Apple Mail (2.3445.9.7) Message-ID-Hash: FIWYGDN5Y22Y5DK3USPA6QUFJ3EV2COG X-Message-ID-Hash: FIWYGDN5Y22Y5DK3USPA6QUFJ3EV2COG X-MailFrom: pnr@planet.nl X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: PCS Munix kernel source List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: > On Aug 11, 2022, at 11:01 AM, Holger Veit wrote: >>=20 >>=20 >> 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=E2=80=99ve 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 =E2=80=9CRIDE=E2=80=9D 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? >>=20 >> 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 =E2=80=9CDistributed = Unix=E2=80=9D: =3D=3D=3D=3D 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. =3D=3D=3D=3D The modeling of virtual circuits sounds like a mid-point between = Chesson=E2=80=99s multiplexed files and Ritchie=E2=80=99s 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/1608191= 0.pdf?r=3D1&r=3D1). Paul