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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7056 invoked from network); 1 Aug 2021 23:59:51 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 1 Aug 2021 23:59:51 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 5F77A9CA7B; Mon, 2 Aug 2021 09:59:50 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 5A82C9CA63; Mon, 2 Aug 2021 09:59:29 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="jQfuVXAn"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 506979CA63; Mon, 2 Aug 2021 09:59:28 +1000 (AEST) Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) by minnie.tuhs.org (Postfix) with ESMTPS id BE3469CA60 for ; Mon, 2 Aug 2021 09:59:27 +1000 (AEST) Received: by mail-oi1-f171.google.com with SMTP id n16so15499125oij.2 for ; Sun, 01 Aug 2021 16:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kKiKryutAmIGPCWM0e+HpU7iwx8dbg//iez+rFFHUGE=; b=jQfuVXAnO7pGReFYRIPBKNKJ1GkZ9N2LeNmQ8nlIzfIKMUDHsUzwUjZEA6C1LAm0Qn pqZJsr/JCwx7N4ZQ3Pi4sHa3832NLRhjZGRUDXqCXiKkpSHSVT6X5kaxwr2pKlmLtXc3 fRbYN6hNMt2AIY4c2VbPFxeMUWAakzDshBy/YtPuGvXZysYDvIZMaXNdI8LzKkgUppV4 J+R3t8mNhSbzcWKJMiubMDZ6itziAjxFqdWdC6VEt2Rhp44BgD4lOk55/rbSf0FQpkUG GNckOTNgOUKvjiaQ6ryya3UJzjodhqY0L9xraXoc3wODaVrRK9ROBl77YLmYR/QKwavs DkMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kKiKryutAmIGPCWM0e+HpU7iwx8dbg//iez+rFFHUGE=; b=nuBJPJspmDneUk49lXwhAwihrcvUX6f7I+aI2mn2pEL1s+MqaZZ2hwF6khAzp9lzy9 J0kC3FYy0SlCamz3FrRbEmwNO5QGWPYRpTOtDVZtt6gMzWAMnyR67QtO63R4vpCMgxRs jtw5BTFuxuRiemyFlRAiYPRFMD8WKGEw2KaqLDbt6Ox3lHUG28LXTkpeMa6qFtjQ1MMC g/Cy+318GMey1d2V/gesQ4RjZ3Ljc07D+BQOYad+5SL9GPWnJ1hE1/fHu39G+Ws9m8Gl En0xiGIKMokuOtTFc6fxMTcxkrKZIRpU6bnV+e8LN8YAToaF1Whw8b/Fkip4npanjry5 6nfQ== X-Gm-Message-State: AOAM533NI5KUhwwIpz/JCuffFVSJ7Gz1nOJulji/kqqOydBNxCzmN8RJ Mg8AwsdmUsJJoGimnYbUQmpPz9h5So+gL00whps= X-Google-Smtp-Source: ABdhPJxQVG6R9Y3gL7tnyZvkgq5IalImYW4egfnXNUlwKSzSqhk9lKeC3h35vyBzgquHYsDhZMyMXy+xekfQ7JnEiE4= X-Received: by 2002:aca:4c49:: with SMTP id z70mr8502825oia.174.1627862366894; Sun, 01 Aug 2021 16:59:26 -0700 (PDT) MIME-Version: 1.0 References: <20210731142533.69caf929@moon> <40763c2d-52ad-eb01-8bf8-85acf6fee700@case.edu> In-Reply-To: From: Dan Cross Date: Sun, 1 Aug 2021 19:58:50 -0400 Message-ID: To: John Cowan Content-Type: multipart/alternative; boundary="0000000000001f401b05c8883e32" Subject: Re: [TUHS] Systematic approach to command-line interfaces X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000001f401b05c8883e32 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 1, 2021 at 7:37 PM John Cowan wrote: > On Sun, Aug 1, 2021 at 5:55 PM Dan Cross wrote: > >> Looking at other systems that were available roughly around the time of >> Unix (TENEX, Multics), it strikes me that the Unix was a bit of an odd-duck >> with the way it handled exec in terms of destructively overlaying the >> memory of the user portion of a process with a new image; am I wrong here? >> > > See dmr's paper at for > details, but in short exec and its equivalents elsewhere have always > overlaid the running program with another program. > That's a great paper and I've really enjoyed revisiting it over the years, but while it does a great job of explaining how the Unix mechanism worked, and touches on the "why", it doesn't contrast with other schemes. I suppose my question could be rephrased as, if the early Unix implementers had had more resources to work with, would they have chosen a model more along the lines used by Multics and Twenex, or would they have elected to do basically what they did? That's probably impossible to answer, but gets at what they thought about how other systems operated. Early versions of PDP-7 Linux used the same process model as Tenex: one > process per terminal which alternated between running the shell and a user > program. So exec() loaded the user program on top of the shell. Indeed, > this wasn't even a syscall; the shell itself wrote a tiny program loader > into the top of memory that read the new program, which was open for > reading, and jumped to it. Likewise, exit() was a specialized exec() that > reloaded the shell. The Tenex and Multics shells had more memory to play > with and didn't have to use these self-overlaying tricks[*]: they loaded > your program into available memory and called it as a subroutine, which > accounts for the name "shell". > Presumably the virtual memory hardware could also be used to protect the shell from a malicious or errant program trashing the image of the shell in memory. [snip] > Nowadays it's a question whether fork() makes sense any more. "A fork() > in the road" [Baumann et al. 2019] < > https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf> > is an interesting argument against fork(): > > * It doesn't compose. > * It is insecure by default. > * It is slow (there are about 25 properties a process has in addition to > its memory and hardware state, and each of these needs to be copied or not) > even using COW (which is itself a Good Thing and can and should be provided > separately) > * It is incompatible with a single-address-space design. > > In short, spawn() beats fork() like a drum, and fork() should be > deprecated. To be sure, the paper comes out of Microsoft Research, but I > find it pretty compelling anyway. > Spawn vs fork/exec is a false dichotomy, though. We talked about the fork paper when it came out, and here's what I wrote about it at the time: https://minnie.tuhs.org/pipermail/tuhs/2019-April/017700.html [*] My very favorite self-overlaying program was the PDP-8 bootstrap for > the DF32 disk drive. You toggled in two instructions at locations 30 and > 31 meaning "load disk registers and go" and "jump to self" respectively, > hit the Clear key on the front panel, which cleared all registers, and > started up at 30. > > The first instruction told the disk to start reading sector 0 of the disk > into location 0 in memory (because all the registers were 0, including the > disk instruction register where 0 = READ) and the second instruction kept > the CPU busy waiting. As the sector loaded, the two instructions were > overwritten by "skip if disk ready" and "jump to previous address", which > would wait until the whole sector was loaded. Then the OS could be loaded > using the primitive disk driver in block 0. > Very nice; that's highly reminiscent of a Sergeant-style forth: https://pygmy.utoh.org/3ins4th.html One wonders if the PDP-8 was one of Sergeant's inspirations? - Dan C. --0000000000001f401b05c8883e32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Aug 1, 2021 at 7:37 PM John Cowan <= ;cowan@ccil.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
On Sun, Aug 1, 2021 at 5:55 PM Dan Cross <crossd@gmail.com> wrote:=C2=A0
Looking at=C2= =A0other systems that were available roughly around the time of Unix (TENEX= , Multics), it strikes me that the Unix was a bit of an odd-duck with the w= ay it handled exec in terms of destructively overlaying the memory of the u= ser portion of a process with a new image; am I wrong here?

See dmr's paper at <https://www.b= ell-labs.com/usr/dmr/www/hist.html> for details, but in short exec a= nd its equivalents elsewhere have always overlaid the running program with = another program.

That'= ;s a great paper and I've really enjoyed revisiting it over the years, = but while it does a great job of explaining how the Unix mechanism worked, = and touches on the "why", it doesn't contrast with other sche= mes. I suppose my question could be rephrased as, if the early Unix impleme= nters had had more resources to work with, would they have chosen a model m= ore along the lines used by Multics and Twenex, or would they have elected = to do basically what they did? That's probably impossible to answer, bu= t gets at what they thought about how other systems operated.
<= div class=3D"gmail_quote">
Early versions of PDP-7 Linux used the same pr= ocess model as Tenex: one process per terminal which alternated between run= ning the shell and a user program.=C2=A0 So exec() loaded the user program = on top of the shell.=C2=A0 Indeed, this wasn't even a syscall; the shel= l itself wrote a tiny program loader into the top of memory that read the n= ew program, which was open for reading,=C2=A0and jumped to it. Likewise, ex= it() was a specialized exec() that reloaded the shell.=C2=A0 The Tenex and = Multics shells had more memory to play with and didn't have to use thes= e self-overlaying tricks[*]: they loaded your program into available memory= and called it as a subroutine, which accounts for the name "shell&quo= t;.

Presumably the virtua= l memory hardware could also be used to protect the shell from a malicious = or errant program trashing the image of the shell in memory.

=
[snip]
Nowadays it's a question wheth= er fork() makes sense any more.=C2=A0 =C2=A0"A fork() in the road"= ; [Baumann et al. 2019] <https://www.m= icrosoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf> i= s an interesting argument against fork():

* It doesn'= ;t compose.
* It is insecure by default.
* It is slow (there = are about 25 properties a process has in addition to its memory and hardwar= e state, and each of these needs to be copied or not) even using COW (which= is itself a Good Thing and can and should be provided separately)
*= It is incompatible with a single-address-space design.=C2=A0

In short, spawn() beats fork() like a drum,=C2=A0and fork() should be= deprecated. To be sure, the paper comes out of Microsoft Research, but I f= ind it pretty compelling anyway.

Spawn vs fork/exec is a false dichotomy, though. We talked about th= e fork paper when it came out, and here's what I wrote about it at the = time:=C2=A0https://minnie.tuhs.org/pipermail/tuhs/2019-April/017700.html=

[*] My very favorite self-overlay= ing program was the PDP-8 bootstrap for the DF32 disk drive.=C2=A0 You togg= led in two instructions at locations 30 and 31 meaning "load disk regi= sters and go" and "jump to self" respectively, hit the Clear= key on the front panel, which cleared all registers, and started up at 30.=

The first i= nstruction told the disk to start reading sector 0 of the disk into locatio= n 0 in memory (because all the registers were 0, including the disk instruc= tion register where 0 =3D READ) and the second instruction kept the CPU bus= y waiting.=C2=A0 As the sector loaded,=C2=A0 the two instructions were over= written by "skip if disk ready" and "jump to previous addres= s", which would wait until the whole sector was loaded.=C2=A0 Then the= OS could be loaded using the primitive disk driver in block 0.
=

Very nice; that's highly reminis= cent of a Sergeant-style forth:=C2=A0https://pygmy.utoh.org/3ins4th.html

One wonders= if the PDP-8 was one of Sergeant's inspirations?

<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.

--0000000000001f401b05c8883e32--