The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Bakul Shah <bakul@iitbombay.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Systematic approach to command-line interfaces
Date: Sun, 1 Aug 2021 19:32:54 -0700	[thread overview]
Message-ID: <B22C6B6E-BBF0-48F7-801A-CA22475B67F3@iitbombay.org> (raw)
In-Reply-To: <YQdEv2nOznGExbK8@mit.edu>

On Aug 1, 2021, at 6:05 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> 
> On Sun, Aug 01, 2021 at 06:13:18PM -0600, Andrew Warkentin wrote:
>> There's a third kind of primitive that is superior to either spawn()
>> or fork() IMO, specifically one that creates a completely empty child
>> process and returns a context that lets the parent set up the child's
>> state using normal APIs.
> 
> I've seen this argument a number of times, but what's never been clear
> to me is what *would* the "normal APIs" be which would allow a parent
> to set up the child's state?  How would that be accomplished?  Lots of
> new system calls?  Magic files in /proc/<pid>/XXX which get
> manipulated somehow?  (How, exactly, does one affect the child's
> memory map via magic read/write calls to /proc/<pid>/XXX....  How
> about environment variables, etc.)
> 
> And what are the access rights by which a process gets to reach out
> and touch another process's environment?  Is it only allowed only for
> child processes?  And is it only allowed before the child starts
> running?  What if the child process is going to be running a setuid or
> setgid executable?

From the "KeyKOS Nanokernel Architecture" (1992) paper:
----
KeyKOS processes are created by building a segment that will
become the program address space, obtaining a fresh domain,
and inserting the segment key in the domain's address slot.
The domain is created in the waiting state, which means that
it is waiting for a message. A threads paradigm can be
supported by having two or more domains share a common
address space segment.

Because domain initialization is such a common operation,
KeyKOS provides a mechanism to generate "prepackaged"
domains. A factory is an entity that constructs other
domains. Every factory creates a particular type of domain.
For example, the queue factory creates domains that provide
queuing services.  An important aspect of factories is the
ability of the client to determine their trustworthiness. It
is possible for a client to determine whether an object
created by a factory is secure.
----
This paper also talks about their attempt to emulate Unix on
top.

http://css.csail.mit.edu/6.858/2009/readings/keykos.pdf

  parent reply	other threads:[~2021-08-02  2:33 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-31 12:25 Michael Siegel
2021-07-31 13:05 ` Dan Halbert
2021-07-31 14:21 ` Adam Thornton
2021-07-31 14:25   ` Adam Thornton
2021-07-31 15:45 ` Richard Salz
2021-07-31 16:03   ` Clem Cole
2021-07-31 16:06     ` Richard Salz
2021-07-31 16:21       ` Clem Cole
2021-07-31 16:17     ` Clem Cole
2021-07-31 16:30       ` Dan Cross
2021-07-31 15:56 ` Paul Winalski
2021-07-31 16:19   ` Dan Cross
2021-08-01 17:44     ` Chet Ramey
2021-08-01 21:53       ` Dan Cross
2021-08-01 23:21         ` Chet Ramey
2021-08-01 23:36         ` John Cowan
2021-08-01 23:49           ` Larry McVoy
2021-08-02  0:28             ` Larry McVoy
2021-08-01 23:58           ` Dan Cross
2021-08-02  0:29             ` Steve Nickolas
2021-08-02  0:13           ` Andrew Warkentin
2021-08-02  0:18             ` John Cowan
2021-08-02  0:54               ` Andrew Warkentin
2021-08-02  1:04               ` Dan Cross
2021-08-02  1:05             ` Theodore Ts'o
2021-08-02  2:10               ` Andrew Warkentin
2021-08-02  2:32               ` Bakul Shah [this message]
2021-08-02 17:33             ` Lars Brinkhoff
2021-09-28 17:46             ` Greg A. Woods
2021-09-28 18:10               ` Larry McVoy
2021-09-29 16:40                 ` Greg A. Woods
2021-09-29 16:57                   ` Larry McVoy
2021-09-30 17:31                     ` Greg A. Woods
2021-09-29 23:10               ` Phil Budne
2021-08-02 17:37           ` Lars Brinkhoff
2021-08-02 18:52             ` Clem Cole
2021-08-02 20:59               ` John Cowan
2021-08-02 21:06                 ` Al Kossow
2021-08-02 21:14                 ` Clem Cole
2021-08-02 21:13               ` Clem Cole
2021-08-01 16:51   ` Michael Siegel
2021-08-01 17:31     ` Jon Steinhart
2021-07-31 16:41 ` Clem Cole
2021-07-31 17:41   ` John Cowan
2021-07-31 17:30 ` Anthony Martin
2021-07-31 17:46   ` John Cowan
2021-07-31 18:56   ` Michael Siegel
2021-07-31 19:41     ` Clem Cole
2021-07-31 21:30       ` Michael Siegel
2021-08-01 17:48     ` Chet Ramey
2021-08-01 19:23       ` Richard Salz
2021-08-01 23:26         ` Chet Ramey
2021-07-31 19:20 ` [TUHS] Systematic approach to command-line interfaces [ meta issues ] Jon Steinhart
2021-07-31 21:06   ` Richard Salz
2021-07-31 21:32     ` Jon Steinhart
2021-07-31 21:37       ` Richard Salz
2021-07-31 21:55         ` Jon Steinhart
2021-07-31 22:10       ` Warner Losh
2021-07-31 22:19         ` Larry McVoy
2021-07-31 22:20         ` Jon Steinhart
2021-07-31 23:26           ` Warner Losh
2021-07-31 23:41             ` Jon Steinhart
2021-07-31 22:04   ` Bakul Shah
2021-07-31 22:13     ` Larry McVoy
2021-07-31 22:14       ` Bakul Shah
2021-07-31 22:17         ` Bakul Shah
2021-07-31 22:16     ` Jon Steinhart
2021-07-31 22:20       ` Bakul Shah
2021-07-31 16:27 [TUHS] Systematic approach to command-line interfaces Nelson H. F. Beebe
2021-07-31 16:47 Ron Young
2021-08-02  2:34 ` Jim Carpenter
2021-08-02  2:38   ` Ron Young
2021-08-02  2:42 Douglas McIlroy
2021-08-02 14:58 ` Theodore Ts'o
2021-08-02 18:15   ` Adam Thornton
2021-08-02 18:24     ` Warner Losh
2021-08-02 20:55     ` John Cowan
2021-08-02 21:06       ` Jon Steinhart
2021-08-02 21:25         ` Dan Cross
2021-08-02 21:59           ` Jon Steinhart
2021-08-02 22:33             ` John Cowan
2021-08-03  0:21     ` Bakul Shah
2021-08-03  1:49       ` Jon Steinhart
2021-08-03  3:21         ` Adam Thornton
2021-08-03  3:27         ` Bakul Shah
2021-08-03  3:51           ` Jon Steinhart
2021-08-03  7:19   ` arnold
2021-08-03 23:12     ` Andrew Warkentin
2021-08-04 15:04       ` Paul Winalski
2021-08-03 15:01 Douglas McIlroy
2021-08-03 17:13 ` Tom Lyon via TUHS
2021-08-11 18:11   ` Tom Ivar Helbekkmo via TUHS
2021-08-11 21:24     ` Tom Lyon via TUHS
2021-08-03 19:12 Douglas McIlroy
2021-09-28 18:15 Noel Chiappa
2021-09-29 18:07 Noel Chiappa
2021-09-29 19:04 ` Dan Cross
2021-09-29 19:12 ` Larry McVoy
2021-09-30 11:41 Douglas McIlroy
2021-10-01 12:11 Paul Ruizendaal

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=B22C6B6E-BBF0-48F7-801A-CA22475B67F3@iitbombay.org \
    --to=bakul@iitbombay.org \
    --cc=tuhs@minnie.tuhs.org \
    --cc=tytso@mit.edu \
    /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).