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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20643 invoked from network); 7 Jul 2021 05:20:59 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 7 Jul 2021 05:20:59 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 943C09CA75; Wed, 7 Jul 2021 15:20:56 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id AD0889CA36; Wed, 7 Jul 2021 15:20:05 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="kdKZpvzH"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 4E1289C87C; Wed, 7 Jul 2021 15:19:44 +1000 (AEST) Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) by minnie.tuhs.org (Postfix) with ESMTPS id 31B669C86D; Wed, 7 Jul 2021 15:19:40 +1000 (AEST) Received: by mail-lf1-f50.google.com with SMTP id y42so1910983lfa.3; Tue, 06 Jul 2021 22:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XnRkvxhERyTRy/qgNcor/rrPO9loBmP7yGk3sjJIRio=; b=kdKZpvzHQH2MS2LdlpelG4BBzXT+GvE35zVMXqWPRLn68jCH2x8epkac04HPF4PE4S slLFVQ6RL0GaH4yXRetHkKaqEZ9xZ0PPzDeCO24TohcYFT+Rbi/wDA003SzLKbQkbQyl wt/dyO36ao2+AHVcHgN4m0nMRFMT+xa7T1A/+ivV4rPSir3s66Do2ALjVRJMhpbDg9x+ WKXk/5zhkiLF7HQhhJz+DvJ1e3H7DQcMngv9xtMY2YV0CQo0QqnNf7N35VF/DMRoqsHf 81RbP7CZstufNBrLscUGclYaR9hel5oyPzdOQgK/RZLcn8HozPsb+HOJ1XDGY/HTUOoa PeVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XnRkvxhERyTRy/qgNcor/rrPO9loBmP7yGk3sjJIRio=; b=BPQyY46HG7sXBwOCa80ZLX7Nol2VB+CiWjmyEUbj4OBiD/9Fguf/eStqzbMnoHzzdF GicAppgmmL/Yh2a5VB6Hf0ENX10iEeFy8NuQdmWvCk9BNQWnhul2d2R+WoiGKo27DIav Rimyh8r+ANt05ElsBSagY5dOMah5YV6lfsWRNvnkp9XUUMcf5I9kA5wZ2FTXYtChr7He Uks6kZ/rnvy0bE7uIEERL8MiliLt+UILhku+h55Xjeh97hIIPkAk3yeImuZ7VqFTkk+E Wbu7Gr0wrgqQRBtody5f+zX8jV1AbO4FucH3LTxlYPiz1Kcc16USJ3luHjCAiaes7FXZ YdjQ== X-Gm-Message-State: AOAM532QyXc/bA1TfNsD3Cd1eiIl0BFNTSIse1iUkjl6JQmm6+XmFTMc jex7hHlOWIMtdBCUZ/PfxCwjux4fuxyulA8+RN0C7Dr7 X-Google-Smtp-Source: ABdhPJwTcOPsK7xkOnXODCbyYid6ilCU0RwjQdM4hVRoJOuKHQu2KIzj2Qi0E0x6oyfsxNgoektuns6F8fb7CjQbq1Y= X-Received: by 2002:a05:6512:114a:: with SMTP id m10mr16818822lfg.402.1625635177729; Tue, 06 Jul 2021 22:19:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:b8c3:0:0:0:0:0 with HTTP; Tue, 6 Jul 2021 22:19:37 -0700 (PDT) In-Reply-To: <20210707025244.GO10781@mcvoy.com> References: <06737C14-1122-4832-BCAA-A37B242F69E4@me.com> <20210707025244.GO10781@mcvoy.com> From: Andrew Warkentin Date: Tue, 6 Jul 2021 23:19:37 -0600 Message-ID: To: The Unix Heritage Society mailing list Content-Type: text/plain; charset="UTF-8" Subject: Re: [TUHS] [tuhs] The Unix shell: a 50-year view 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: coff Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 06/07/2021, Larry McVoy wrote: > > http://lkml.iu.edu/hypermail/linux/kernel/0106.2/0405.html > > I wasn't completely right 20 years ago but I was close. I'm tired, > if you want to know where I'm wrong, ask and I'll tell you how I > tried to get Linus to fix it. > > In general, Rob was on point. He usually is. > I've never been a fan of clone(). It always strikes me as something that seems like an elegant simplification at first, but the practical realization (on Linux that is) requires several rather ugly library-level hacks to make it work right for typical use cases. UX/RT will use the "processes are containers for threads" model rather than rfork()/clone() since that's the model the seL4 kernel basically uses (in a very generalized form with address spaces , capability spaces, and threads being separate objects and each thread being associated with a capability space and address space), and it would also be slightly easier to create the helper threads that will be required in certain parts of the IPC transport layer. The base process creation primitive (efork(), for "empty/eviscerated fork") will create a completely blank non-runnable child process with no memory mappings or file descriptors, and return a context FD that the parent can use to manipulate the state of the child with normal APIs, including copying FDs and memory mappings. To actually start the child the parent will perform an exec*() within the child context (either a regular exec*() to make the child run a different program, or a new eexec() function that takes an entry point rather than a command line to run the process with whatever memory mappings were set up), after which point the parent will no longer be able to manipulate the child's state. This will eliminate the overhead of fork() for spawning processes running other programs, but will still allow for a library-level fork() implementation that has comparable overhead to traditional implementations. Also, it will do what Plan 9 never did and make the process/memory APIs file-oriented (I still don't get why Plan 9 went with a rather limited anonymous memory API rather than using memory-mapped files for everything). Also, we're straying a bit from historical Unix here and should have probably moved to COFF several messages ago.