9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Casey Rodarmor <casey@rodarmor.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Namespace inheritance between processes
Date: Sat, 21 May 2016 20:01:55 -0700	[thread overview]
Message-ID: <CANLPe+OOXvDQ88Nm1iUb31y6iEU2g5pjxRu48r8m9My_Dz9_Rg@mail.gmail.com> (raw)
In-Reply-To: <20160521120606.GA20452@dinah>

Thanks Skip and Anthony for the scripts!

Okay, that makes sense. What is the reason for performing namespace
inheritance by copy as opposed to namespace inheritance by reference?
Is it just to simplify the implementation?

It seems like it might be useful. For example, if you had a daemon
that automatically reacted to devices, like USB drives and CDs being
attached and mounted them in the namespace, then you might want
processes to inherit from it so they would see new mounts.

Also, a totally random question: It seems like poor ergonomics that
one must create empty directories in order to serve as mount points.
Why not just allow mounting to names that don't exist yet?

On Sat, May 21, 2016 at 5:06 AM, Anthony Martin <ality@pbrane.org> wrote:
> Anthony Martin <ality@pbrane.org> once said:
>> Casey Rodarmor <casey@rodarmor.com> once said:
>> > Also, whatever the answer is, how can I test this for myself? I was
>> > struggling to come up with a combination of commands, short of writing
>> > some C programs, which would let me have two interactive rc shells
>> > that inherit from one another, since rc doesn't have job control and
>> > new rio windows are in a new process group.
>>
>> In one rio window, do the following:
>>
>>   % mkdir -p /tmp/wsys
>>   % mount $wsys /tmp/wsys 'new -r 0 0 512 512 -pid '$pid
>>   % { rc -i <>/tmp/wsys/cons >[1=0] >[2=0] } &
>>
>> Any further changes to the namespace will be reflected in both windows.
>
> I was playing around with this a bit more and I came
> up with something a bit cleaner. The following command
> will create an interactive shell in a new window that
> shares the namespace of it's parent and acts like a
> normal rio window (as much as possible).
>
> Cheers,
>   Anthony
>
> #!/bin/rc
>
> rfork e
>
> mkdir -p /tmp/wsys
> mount $wsys /tmp/wsys 'new -r 0 0 640 480 -pid -1'
> {
>         rc -i </tmp/wsys/cons >/tmp/wsys/cons >[2=1] &
>         rcpid = $apid
>         echo set -pid $rcpid >/tmp/wsys/wctl
>         echo -n rc $rcpid >/tmp/wsys/label
>         wait $rcpid
>         echo delete >/tmp/wsys/wctl
> } &
>



  reply	other threads:[~2016-05-22  3:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-21  7:26 Casey Rodarmor
2016-05-21  7:37 ` Casey Rodarmor
2016-05-21  8:49   ` Skip Tavakkolian
2016-05-21 10:01   ` Anthony Martin
2016-05-21 12:06     ` Anthony Martin
2016-05-22  3:01       ` Casey Rodarmor [this message]
2016-05-22  5:28         ` Skip Tavakkolian
2016-05-22  6:14           ` erik quanstrom

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=CANLPe+OOXvDQ88Nm1iUb31y6iEU2g5pjxRu48r8m9My_Dz9_Rg@mail.gmail.com \
    --to=casey@rodarmor.com \
    --cc=9fans@9fans.net \
    /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).