Computer Old Farts Forum
 help / color / mirror / Atom feed
From: Andrew Warkentin <andreww591@gmail.com>
To: The Unix Heritage Society mailing list <tuhs@minnie.tuhs.org>
Cc: coff <coff@minnie.tuhs.org>
Subject: Re: [COFF] [TUHS] [tuhs] The Unix shell: a 50-year view
Date: Tue, 6 Jul 2021 23:19:37 -0600	[thread overview]
Message-ID: <CAD-qYGpHiPuEv3=Ow7NoRCkj6gk3zJ525AZooD4Nd_=dEL5HkA@mail.gmail.com> (raw)
In-Reply-To: <20210707025244.GO10781@mcvoy.com>

On 06/07/2021, Larry McVoy <lm@mcvoy.com> 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.
_______________________________________________
COFF mailing list
COFF@minnie.tuhs.org
https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff

           reply	other threads:[~2021-07-07  5:20 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20210707025244.GO10781@mcvoy.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAD-qYGpHiPuEv3=Ow7NoRCkj6gk3zJ525AZooD4Nd_=dEL5HkA@mail.gmail.com' \
    --to=andreww591@gmail.com \
    --cc=coff@minnie.tuhs.org \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).