From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [IPv6:2600:3c01:e000:146::1]) by inbox.vuxu.org (Postfix) with ESMTP id 604ED26B70 for ; Mon, 13 May 2024 05:29:27 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 58B5143681; Mon, 13 May 2024 13:29:23 +1000 (AEST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by minnie.tuhs.org (Postfix) with ESMTPS id 4767543680 for ; Mon, 13 May 2024 13:29:17 +1000 (AEST) Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-51f12ccff5eso5243269e87.1 for ; Sun, 12 May 2024 20:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715570954; x=1716175754; darn=tuhs.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Qxy1PtMVi1qOQDQ/rvsilB2JPrOmmyvHLIMwK0VkTx0=; b=XoH9d1GRtWKZKd6MlMvciJSqgpSu1mHTk87diWQpD9HFNar5nVLs33Gbz2K6Yqs8Ki 5M3NmK2Og5xW9WJk7jeO7LTdymWLYuRlm7eqlvq7+sRzoopliPT1S/FSutT1GgiLp8Ow +S9Ng9BBivHzb5GZsJhZwGSQLCygY74m1Dt1YFPx/nGkr7Dmwjf3iVFEsw+qVMwJfw0H ieym4EmKpkaaXGJJGQjT66YcMEcI36eaZ1yzRbQtMkqWUEtzt/5dT+5v4TVw5EQKUln4 9E+YHgvseCKBFJNHBoSxu8M6YTiDe8/t04vilZx3/8IyvHw4AoJARj5zSJup0+BFpRLQ ie4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715570954; x=1716175754; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Qxy1PtMVi1qOQDQ/rvsilB2JPrOmmyvHLIMwK0VkTx0=; b=Is1/3VgnjMOLz29DH+N7prlLAV1s9Va2sDR4mbxinzJswuesFpYWEUo2nwlGOltelH MWO+/VFYhEW/6xV5vGRg5SfTmlYZ2VWOLTWGGXH5NCodUTjYm7i7YYoL5hVgqwSlhFog RTrAOHXWfBNTdNaoJoi89znw62QtoGuFre/EJa2NLDdIvgCAhd+84GHXqQ9iQUclCXBf TsHGyelvcZJN+XSwUBS7T4xiiA/oRUd8RGcqg8h+4/YHpk+wt5dRST9tcHFP8F6OfEVh jUbHO8pp7rWELSInAzj0NBRu8MteBbMLxhYJ2fAoJxPT1jQ30S/wwAmw6XyTMf1CvI6+ FpXg== X-Gm-Message-State: AOJu0YxAwT8IjzVyyluxE4LCJBHxjsYt0KnEqLinb1+IR8TExOPSyttr PT2//3VheC64JBXLsS35uiOsCkHrW7pXmPjuQXYXyrs4bVNd5rjCTYlMNN83H8Z2zpyRcIOq4o9 c9IgF/P7GaERSnn7MKXMQoRx9W2ZJkKga X-Google-Smtp-Source: AGHT+IEqbB5/DxaIOhO4CPNPt/iE0jWgPFd3vD4Q6HIVYXNPcP1oKE+omDFFuB5UaktDoDvyPV0yOrTBJBlQ1AdyMDM= X-Received: by 2002:a05:6512:230a:b0:51c:c2c1:6f58 with SMTP id 2adb3069b0e04-522105792e0mr6204096e87.55.1715570954086; Sun, 12 May 2024 20:29:14 -0700 (PDT) MIME-Version: 1.0 References: <20240512194707.GL9216@mcvoy.com> <20240512201349.0DB6A8A9D055@ary.qy> In-Reply-To: From: Andrew Warkentin Date: Sun, 12 May 2024 21:29:01 -0600 Message-ID: To: The Eunuchs Historic Society Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: BIHLXS7KMHXYJ3QI5PLNYX3VKZRNQESE X-Message-ID-Hash: BIHLXS7KMHXYJ3QI5PLNYX3VKZRNQESE X-MailFrom: andreww591@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; 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: forking, Re: [COFF] Re: On Bloat and the Idea of Small Specialized Tools List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Sun, May 12, 2024 at 4:57=E2=80=AFPM Dan Cross wrote: >l. > > Perhaps, but as I've written here before, `fork`/`exec` vs `spawn` is > a false dichotomy. Another alternative is a `proccreate`/`procrun` > pair, the former of which creates an unrunnable process, the latter of > which marks it runnable. Coupled with a set of primitives to > manipulate the state of an extant, but unrunnable, process and you > have the advantages of fork/exec without the downsides (which are > well-known; https://www.microsoft.com/en-us/research/uploads/prod/2019/04= /fork-hotos19.pdf). > Similarly, this gives you the functionality of spawn, without the > downside of a singularly complicated interface. Could you have > implemented that in something as small as the PDP-7? Perhaps not, but > it does not follow that `fork` now remains a good primitive. > IMO something like that is the best model (although it probably would have been a bit complicated for a PDP-7/PDP-11). That's basically what I'm doing in the OS that I'm writing . Processes will basically just be containers for hierarchical groups of threads, and will have pretty much no other state besides the command line. All of the context normally associated with a process (file descriptor space, permissions/UID/GID, filesystem namespace, virtual address space) will instead be in separate objects that are explicitly bound to threads. Separate APIs for creating an empty process, creating threads within it, manipulating context objects and binding threads to them, and starting the process will be provided (all of these APIs will use a file-based transport underneath; this will be the first OS I know of where literally everything is a file). The base process APIs will be general enough to allow an efficient copy-on-write fork() to be implemented on top of them for backwards compatibility and the remaining use cases where forking still makes sense (since even all process memory will be implemented with files, this will be implemented with a special in-memory "shadow filesystem" that creates alternate mappings of other memory filesystems). Really I'd say there are actually several design decisions in conventional Unix that made sense on a PDP-7 or PDP-11, but no longer make sense in the modern world. For instance, the rather inflexible security model with its fixed set of root-only system calls rather than some form of role-based access control, or the use of on-disk device nodes bound by numbers rather than something like separate special filesystems for each driver that get union mounted together, or the lack of integrated support for userspace filesystem servers (yes, there's FUSE, but it's kind of a poorly integrated hack that is rarely used for anything important).