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 8859 invoked from network); 4 Aug 2021 15:05:37 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 4 Aug 2021 15:05:37 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 72A049CADF; Thu, 5 Aug 2021 01:05:33 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 96C079CAA5; Thu, 5 Aug 2021 01:04:57 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="ZzdWTemm"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id AD9A59CAA5; Thu, 5 Aug 2021 01:04:53 +1000 (AEST) Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) by minnie.tuhs.org (Postfix) with ESMTPS id DEDBF9CAA4 for ; Thu, 5 Aug 2021 01:04:52 +1000 (AEST) Received: by mail-vk1-f174.google.com with SMTP id g16so501524vkk.12 for ; Wed, 04 Aug 2021 08:04:52 -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=pR/LjgtfQ/6hiZw1IIu7T73D700NcEBwiywLpQZScpI=; b=ZzdWTemmGmHC8i/618rVgyQuLg/9ohYvcuFQ36lLiDNtMlz4JQh9h/cbdIvs3K/Bcx 2/sV31JC5IC1Xi0AY1k/SI/t9s0psV3kjOIdKSWsJzldM8ZOHmmWPFBA4kiLa8A8hQMQ VQkrTj0t60xdJRRGMz35SwEpUDh2fMMjFR6iIzMTNPLzia9ZAhjydP98eT9fD0IOwu6k UiY6tgNnVIu9/HWApMqQM+XROwSnMSfGgnQgp4wUOU+jz7U4BKuqIUqHpHQr296QNKVj Ga/U65nysBvD+rBepNKLfXAX1g2G7iuhlKwLcRuUyaLmoYPzA2c/K8YpZzc7ytzsmiKq x2Ig== 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=pR/LjgtfQ/6hiZw1IIu7T73D700NcEBwiywLpQZScpI=; b=TDbFw0Jr5TuTp6WsZBR7vnW8/tijzuKG09azwWaVyuJhy8dvPdDfPmrwULIXA95vAo KH605IyFvZR8xbRldYk10Hd2ALz+TYISQYGr385FI5CRPbV+HqaonYXJ7/gzCURlW/bS BFvSd/u2umqvHrwlHyPgcWugj5iDjazNjmn1rrqFTtjugAgKbr9O6TQ8ryQf13jtRDbA V0q3QkYoaizDac30K7MzdDsVbMkykm/aMSY6y1m2Z0GxXu1byAlv53yu5rKWWCjGGSTq wWDJirVRbAMxt6C7JMTlipo6t3msRR6pxN8yRglH/9BkIpEyDGAmfFZNkNFx+JnTlSHV y8TA== X-Gm-Message-State: AOAM532ayMlH3Y7JTrd4TC2GuCPqXPYAfo19++WwjrS2Uw5pmRJRBJV1 QclTtFfWcjTAJo2JbitImtTrzT7YX6mBielwhJI= X-Google-Smtp-Source: ABdhPJzaqYEdiuFaOFJPpcRzIGJ83mROdUrq398x1CYwMxlZrumHrArAOo7QHBJxFj6oC2kO+tdK3mMYixenyq4UXac= X-Received: by 2002:a1f:d943:: with SMTP id q64mr20714vkg.23.1628089491520; Wed, 04 Aug 2021 08:04:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:739a:0:0:0:0:0 with HTTP; Wed, 4 Aug 2021 08:04:50 -0700 (PDT) In-Reply-To: References: <202108030719.1737JJRc019869@freefriends.org> From: Paul Winalski Date: Wed, 4 Aug 2021 11:04:50 -0400 Message-ID: To: Andrew Warkentin Content-Type: text/plain; charset="UTF-8" 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@tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 8/3/21, Andrew Warkentin wrote: > > Up until now I was just planning on following the traditional > threading model of associating most state with processes with only > execution state being per-thread in the OS I'm working on, but now I'm > thinking I should reduce the state associated with a process to just > the PID, PPID, PGID, containing cgroup, command line, and list of > threads. All other state would be contained in various types of > context objects that are not tied to a particular process or thread > (other than being destroyed when no more threads are associated with > them). For what it's worth, this is the process model that Windows NT has. This thread has discussed two very different ways to do command line processing: the TOPS-20 model, where the program image for the command is activated immediately and then calls back to the OS to process the command line elements, and the UNIX model, where the first element of the command line is a path (full or partial) to the program image for the command, and it's entirely up to that image to process the command line elements as it sees fit. VMS takes a third approach. The VAX had four, hierarchical execution modes: user, supervisor, exec, and kernel, in increasing order of privilege. The VAX had "change mode" instructions (CHMU, CHMS, CHME, CHMK) that ran the current process's change-mode interrupt handler to process the request. Applications and programs to process commands ran in user mode. The DCL command interpreter (VMS's equivalent of the UNIX shell) ran in supervisor mode. Exec mode was reserved for record management services (RMS), VMS's equivalent of the file system code in UNIX. Kernel mode (the only mode where privileged instructions can be executed) was, of course, for the kernel. One oddity of VMS is that each process had the supervisor, exec, and kernel code and data mapped to its address space. Commands in VMS are described using a meta-language that is compiled into a set of data tables that the command line interpreter (CLI, running in supervisor mode) uses to determine which program image needs to be activated to execute the command. The CLI also does a full parse of the command line. It then calls the kernel's image activator to map the appropriate program image and switches to user mode to start it running. There is a runtime library of routines to retrieve the various options and parameters from the command line (the routines in this library do CHMS calls to achieve this). So on VMS we have a situation where the command interpreter (shell) is part of every process. Processes are created by the "create process" OS library routine, sys$creprc, which is a wrapper around the appropriate CHMK instruction. Unlike fork() on UNIX, the new process inherits very little state from its parent. Most significantly it inherits neither address space nor open file context. VMS process creation is also notoriously expensive compared to fork() on UNIX. -Paul W.