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 14447 invoked from network); 2 Aug 2021 01:06:24 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 Aug 2021 01:06:24 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id A57B89CB3F; Mon, 2 Aug 2021 11:06:04 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 96BC49CAD7; Mon, 2 Aug 2021 11:05:38 +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="qmCQUtef"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id B02F09CA90; Mon, 2 Aug 2021 11:05:25 +1000 (AEST) Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) by minnie.tuhs.org (Postfix) with ESMTPS id 0A7169CA7C for ; Mon, 2 Aug 2021 11:05:23 +1000 (AEST) Received: by mail-oi1-f178.google.com with SMTP id w6so22231664oiv.11 for ; Sun, 01 Aug 2021 18:05:23 -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=uzvkyGTXmA3HP+H1X0tJA2OE2L3ncgKrcC6MOo0ean8=; b=qmCQUtefnuvsKGad1yuerPg3TH3IXdXmQ79oNdBFhSItMsrjyo2rZ6HusLdSil+BNK umjKnRrbD1z5Ld5qeAKqOS+MFgx0O1RgCzitSlgN6tfHV6igTeTzaXMVJgVBISJm63qk 4iRMJWL122LHP7Gc+TcMN6VgJc6WqLSIjAjiMa2jcPXehjQOf+r104wdoOqGbhYO6LPJ W0Nub4Zjz9kIjM9TXMMrMRbHYeUq8QHXe34C9M5j0T41cLFENRTcy9UL7tiXjwg0E0Xx 7zpA2SXoO1lDvkUiHwIRjxTmz1m2C31Ou59k5oJYeeh4lzBXdrNHniWXUX9Ue2j4oDPc nx9A== 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=uzvkyGTXmA3HP+H1X0tJA2OE2L3ncgKrcC6MOo0ean8=; b=Z28F1nOxJQgaF/nF3rqE0UZcqQacun3tjTL+MGBFjCXBeWFP5Qa0735plKv0yiA8Lc LQmmboRrEudpjKvEg549kJZ9QarH4+j/Mn7F4/xZnrfLfM6wpPhB7MtPIKZToeDUvaL1 zVhKfkqt7KJYF8/qogMRG/0hgdbUNbSqUvHUrZmneiwdZhBRI6erx431rqyyqyNVNDxX AV/mk3+OaTq+uh+eH9G/Y3JXtTVdlhWNmzrkefF6si/TRTN4/eNBzFx3xX93UYdvy+xw HP+SnSrOeU/ltsxpWiWN9qjmpdgDhyRk2pcIuwHBW2wqnK7DH7ABdXUPl+kTwkGnOjIW c7hA== X-Gm-Message-State: AOAM533ixqMD811kJVrUuMWzbTJVZ5iJ6JehLqJjDW7EYxIxZ3YBxjHo PsmVU8Cf3mqDwEBT6YXen4jr5Nux15DdiKO6Llw= X-Google-Smtp-Source: ABdhPJzDc3Y3yjL7KVzDy4b+l7O++qdz/FWKtgJQw9rw9rqC1OQArhop09SfhyoBWaFstpe3uwXAB3rGcXKADDCcGFU= X-Received: by 2002:a05:6808:216:: with SMTP id l22mr8869254oie.24.1627866322157; Sun, 01 Aug 2021 18:05:22 -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 21:04:46 -0400 Message-ID: To: John Cowan Content-Type: multipart/alternative; boundary="000000000000dfc54d05c8892921" 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" --000000000000dfc54d05c8892921 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 1, 2021 at 8:19 PM John Cowan wrote: > On Sun, Aug 1, 2021 at 8:13 PM Andrew Warkentin > wrote > >> To start the child the parent would either >> call exec() to start the child running a different program, or call a >> new function that starts the child with a parent-provided entry point >> and whatever memory mappings the parent set up. > > > >> This is what I plan to do on the OS I'm writing >> (manipulating the child's state won't require any additional >> primitives beyond regular file I/O since literally all process state >> will have a file-based interface). >> > > In that case you don't need *any* primitive except create_empty_process(): > you can do exec() by opening the file, writing to /proc//mem and > then to /pc-and-go. > Sadly, that's not _quite_ true. You still need some primordial way to get the system going. Once you have a proc_create and a make_proc_runnable system call, it seems like it opens the door to doing all kinds of cool things like moving binary parsers out of the kernel and into user space, but consider how `init` gets bootstrapped: often, there's a handful of instructions that basically invoke `execl("/bin/init", "init", 0);` that you compile into the kernel; on creation of process 1, the kernel copies those instructions into a page somewhere in user portion of the address space and "returns" to it; the process then invokes /bin/init which carries on with bringing up the rest of the system. Now you're confronted with two choices: you either put a much more elaborate bootstrap into the kernel (in this day and age, probably not that hard), or you have a minimal bootstrap that's smart enough to load a smarter bootstrap that in turn can load something like init. I suppose a third option is to compile `init` in some dead simple way that you can load in the kernel as a special case, and invoke that. This problem isn't insurmountable, but it's a wide design space, and it's not quite as straight-forward as it first appears. As I mentioned in the email I linked to earlier, Akaros implemented the proc_create/proc_run model. It really was superior to fork()/exec() and I would argue superior to spawn() as well. - Dan C. --000000000000dfc54d05c8892921 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Aug 1, 2021 at 8:19 PM John Cowan= <cowan@ccil.org> wrote:
On Sun, Aug 1, 2021 at 8:13 PM Andrew = Warkentin <andrew= w591@gmail.com> 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">To start the child the par= ent would either
call exec() to start the child running a different program, or call a
new function that starts the child with a parent-provided entry point
and whatever memory mappings the parent set up.
=C2=A0
This is what I plan to= do on the OS I'm writing
(manipulating the child's state won't require any additional
primitives beyond regular file I/O since literally all process state
will have a file-based interface).

In that= case you don't need *any* primitive except create_empty_process(): you= can do exec() by opening the file, writing to /proc/<child>/mem=C2= =A0and then to <proc/<child>/pc-and-go.

Sadly, that's not _quite_ true. You still need = some primordial way to get the system going.

Once = you have a proc_create and a make_proc_runnable system call, it seems like = it opens the door to doing all kinds of cool things like moving binary pars= ers out of the kernel and into user space, but consider how `init` gets boo= tstrapped: often, there's a handful of instructions that basically invo= ke `execl("/bin/init", "init", 0);` that you compile in= to the kernel; on creation of process 1, the kernel copies those instructio= ns into a page somewhere in user portion of the address space and "ret= urns" to it; the process then invokes /bin/init which carries on with = bringing up the rest of the system.

Now you're= confronted with two choices: you either put a much more elaborate bootstra= p into the kernel (in this day and age, probably not that hard), or you hav= e a minimal bootstrap that's smart enough to load a smarter bootstrap t= hat in turn can load something like init. I suppose a third option is to co= mpile `init` in some dead simple way that you can load in the kernel as a s= pecial case, and invoke that. This problem isn't insurmountable, but it= 's a wide design space, and it's not quite as straight-forward as i= t first appears.

As I mentioned in the email I lin= ked to earlier, Akaros implemented the proc_create/proc_run model. It reall= y was superior to fork()/exec() and I would argue superior to spawn() as we= ll.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.

--000000000000dfc54d05c8892921--