Re: [9fans] 9front sam in plan9port.

[Iruatã Souza]

This is just a port of the 9front version of sam to p9p. As you can see, it
hasn't been updated in a while. But I can do that if anybody wants it.
Em 21/05/2016 4:50 PM,  escreveu:

#define chording 0  /* code here for reference but it causes deadlocks
*/

I suppose the bug is still messing around.
I'll give it a try to the 9front version.

Thanks for the info!

Re: [9fans] Namespace inheritance between processes

[Skip Tavakkolian]

> What is the reason for performing namespace
> inheritance by copy as opposed to namespace inheritance by reference?
> Is it just to simplify the implementation?

i assume by reference you mean shared between parent and child.  most
of the time you don't want the child process to change the namespace
of the parent.

> 
> 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.
> 

for unrelated processes the way to import a namespace from a server is
for the server to post the client end of the 9P to /srv; any process needing the
service can mount the connection into its namespace.  that way access
permissions are also enforced.  see srv(3)

> 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?

mntgen(4)

Re: [9fans] Namespace inheritance between processes

[Casey Rodarmor]

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  wrote:
> Anthony Martin  once said:
>> Casey Rodarmor  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 >[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
> } &
>

Re: [9fans] bug in authdial()

[erik quanstrom]

On Sat May 21 16:05:58 PDT 2016, 9...@9netics.com wrote:
> >> >> Waitmsg *exitsts = nil;
> 
> i see; it's set but not used before it is assigned to again.
> 
> i would expect the compiler to get the hint that it's initialization
> -- especially given that the value is 0 and the assignment is right
> with the declaration.

like i mentioned, gcc ignores variables that are set and not used, for
the most part.  i think behavior is odd.  there's nothing special about
assigning a simple type in a declaration.  

for example

char *s = nil;
and
char *s;

s = nil;

are equivalent.  gcc ignores both cases if they are not actually used.
one could add an automatic implicit USED in kenc by modifying
the doinit() in dcl.c, but i think that would be a mistake.  i find extra
assignments make it harder to read the code, as one has to consider
the assignment might be used when evaluating how a variable is used.

there are some exceptions to the general rule, for non simple types,
where the assignment may change the size.  and i'm gnoring some dark
corners of c99 like const int, which are not implemented in plan 9.

- erik

Re: [9fans] problem with acme on 9front

[erik quanstrom]

unfortunately, sam has hardcoded B into the command channel.
see /sys/src/cmd/samterm/plan9.c:/^plumbformat

- erik

Re: [9fans] bug in authdial()

[erik quanstrom]

> Yes, exactly.  And doesn't/didn't ndb have a tag that was used to indicate 
> whether a system or network used il?  (proto=il? I don't have access to a 
> 9labs machine to check at the moment.)
> 
> Determining ip6 connectivity shouldn't be that hard.  If you have a route, 
> you connect.  If you don't, the network stack does a fast ENOROUTE return and 
> the case falls through to the next address family.
> 
> IL is a bit trickier, since you can't know in advance if the destination 
> supports it, thus the ndb tags I'm vaguely remembering.  And if my memory is 
> correct, the fix for that would be to default 'supports IL' to no, if that's 
> not already the case.

cs uses hard-coded rules.  one could argue that it's up to dns to filter out
ip6, which would be straightforward one would only return ip6 when the
path from . to the zone in question is all ip6 accessible.  i realize this is
wrong, as the path to the dns server is not the same as the path of the
packets, but, you know, should be a better hurestic than we've got today.

- erik

Re: [9fans] problem with acme on 9front

[Lyndon Nerenberg]

> I've never seen it happen, and I don't really expect to.  I do maintain
> that calling acme an editor is akin to calling New York a shopping
> center.
> 
> khm

That deserves an entry in the fortunes file.

Re: [9fans] bug in authdial()

[Lyndon Nerenberg]

> On May 21, 2016, at 10:04 AM, erik quanstrom  wrote:
> 
> this problem is a little easier to fix.  cs needs to do a little more work to 
> filter out
> impossible connection types.  for example, if one's internet connection is 
> not ip6
> capable, then cs should be instructed to not return ip6 addresses.

Yes, exactly.  And doesn't/didn't ndb have a tag that was used to indicate 
whether a system or network used il?  (proto=il? I don't have access to a 9labs 
machine to check at the moment.)

Determining ip6 connectivity shouldn't be that hard.  If you have a route, you 
connect.  If you don't, the network stack does a fast ENOROUTE return and the 
case falls through to the next address family.

IL is a bit trickier, since you can't know in advance if the destination 
supports it, thus the ndb tags I'm vaguely remembering.  And if my memory is 
correct, the fix for that would be to default 'supports IL' to no, if that's 
not already the case.

Re: [9fans] bug in authdial()

[Skip Tavakkolian]

>> >>   Waitmsg *exitsts = nil;

i see; it's set but not used before it is assigned to again.

i would expect the compiler to get the hint that it's initialization
-- especially given that the value is 0 and the assignment is right
with the declaration.

Re: [9fans] bug in authdial()

[David du Colombier]

> also,
> 
> 209c203
> < char exitsts[2*ERRMAX];
> ---
> > Waitmsg *exitsts = nil;  
> 
> is likely to generate used-and-not-set on amd64.

Wouldn't it be "set and not used" instead?

-- 
David du Colombier

Re: [9fans] bug in authdial()

[erik quanstrom]

On Sat May 21 15:19:06 PDT 2016, 9...@9netics.com wrote:
> > <   char exitsts[2*ERRMAX];
> > ---
> >>Waitmsg *exitsts = nil;
> > 
> > is likely to generate used-and-not-set on amd64.
> > 
> > - erik
> 
> i'm not sure i understand how. can you explain?

since the only code path that uses exitsts sets it unconditionally,
setting a declaration time is going to be optimized out.  when the
optimizer elides setting of a variable it emits the set and not used
diagnostic.

gcc doesn't do this with the usual flags, which is why it may be unexpected.
i've included a test program that makes this a little easier to read.
the test program emits the diagnostic "warning: warn.c:9 set and not used: s"

- erik

---
#include 
#include 

void
main(void)
{
char *s;

s = nil;
s = "xyz";
print("s=%s\n", s);
exits("");
}

Re: [9fans] bug in authdial()

[Skip Tavakkolian]

> < char exitsts[2*ERRMAX];
> ---
>>  Waitmsg *exitsts = nil;
> 
> is likely to generate used-and-not-set on amd64.
> 
> - erik

i'm not sure i understand how. can you explain?

Re: [9fans] bug in authdial()

[Skip Tavakkolian]

> i believe this is missing a free.
> 
> - erik

good catch; thanks.

Re: [9fans] problem with acme on 9front

[Mark Lee Smith]

Thanks for the interesting comments.

I've been making an effort to use Sam, in the interest of my own
understanding. One of the biggest barriers I've hit is that there doesn't
appear to be a good way to save complex edit commands for later. The man
page suggests that it's possible to send commands to Sam from shell scripts.

External communication
  Sam listens to the edit plumb port.  If plumbing is not
  active, on invocation sam creates a named pipe /srv/sam.user
  which acts as an additional source of commands.  Characters
  written to the named pipe are treated as if they had been
  typed in the command window.

  B is a shell-level command that causes an instance of sam
  running on the same terminal to load the named files. B uses
  either plumbing or the named pipe, whichever service is
  available.  If plumbing is not enabled, the option allows a
  line number to be specified for the initial position to dis-
  play in the last named file (plumbing provides a more gen-
  eral mechanism for this ability).

  E is a shell-level command that can be used as $EDITOR in a
  Unix environment.  It runs B on file and then does not exit
  until file is changed, which is taken as a signal that file
  is done being edited.

I use Plan9Port on OpenBSD and typically use the plumber with Acme. I've
changed "editor" to sam, and read the B and E scripts. As I understand it
the plumbing approach doesn't allows sending arbitrary commands, so I've
stopped the plumber. I'm unable to find the named pipe and looking at the
sam source code it's not obvious to me how or whether such a pipe is
created. Is this capability still present in Sam? Perhaps the plumber has
completely subsumed this by now? Ultimately what I'd like to know is how
you go about reusing common commands? Do you snarf and paste them? I was
thinking that it would be useful to create scripts like "ap" which select
the current paragraph (name inspired by Vim.) What's the typical workflow
when using Sam? I don't deny that it's a great editor. Writing several
thousand words in Sam yesterday was a pleasure.

Maybe I'm completely off base here?

All the best,

Mark





On Fri, 20 May 2016 at 22:05 Steve Simon  wrote:

>
> I started with Sam a sit ran on all the different unixes I used an vi an
> emacs just felt clunky.
>
> I never got into help and when acme replaced that I just never made the
> transition.
>
> I love Sam, though it is because I know it so well.
>
> btw, anyone written scripts to allow the plan9 wiki to be edited from Sam?
> maybe the wiki is outmoded these days?
>
> -Steve
>
>
>
>

Re: [9fans] bug in authdial()

[erik quanstrom]

also,

209c203
<   char exitsts[2*ERRMAX];
---
>   Waitmsg *exitsts = nil;

is likely to generate used-and-not-set on amd64.

- erik

Re: [9fans] bug in authdial()

[erik quanstrom]

On Sat May 21 14:47:24 PDT 2016, 9...@9netics.com wrote:
> > a better solution is to just use waitmsg (see wait(2)).  the parsing rules 
> > and sizing are
> > already implemented there.
> 
> yes, i agree. i changed my patch.

i believe this is missing a free.

- erik

Re: [9fans] bug in authdial()

[Skip Tavakkolian]

> a better solution is to just use waitmsg (see wait(2)).  the parsing rules 
> and sizing are
> already implemented there.

yes, i agree. i changed my patch.

diff /n/dump/2016/0519/sys/src/libc/9sys/dial.c /sys/src/libc/9sys/dial.c
167c167
< notedeath(Dest *dp, char *exitsts)
---
> notedeath(Dest *dp, Waitmsg *exitsts)
169,170c169
<   int i, n, pid;
<   char *fields[5];/* pid + 3 times + error */
---
>   int n;
173,176c172
<   for (i = 0; i < nelem(fields); i++)
<   fields[i] = "";
<   n = tokenize(exitsts, fields, nelem(fields));
<   if (n < 4)
---
>   if (exitsts->pid <= 0)
178,180d173
<   pid = atoi(fields[0]);
<   if (pid <= 0)
<   return;
182c175
<   if (conn->pid == pid && !conn->dead) {  /* it's one we know? */
---
>   if (conn->pid == exitsts->pid && !conn->dead) {  /* it's one we 
> know? */
187,188c180,182
<   strncpy(conn->err, fields[4], sizeof conn->err - 1);
<   conn->err[sizeof conn->err - 1] = '\0';
---
>   n = strlen(exitsts->msg);
>   assert(n < ERRMAX);
>   strncpy(conn->err, exitsts->msg, n);
209c203
<   char exitsts[2*ERRMAX];
---
>   Waitmsg *exitsts = nil;
211c205
<   if (outstandingprocs(dp) && await(exitsts, sizeof exitsts) >= 0) {
---
>   if (outstandingprocs(dp) && (exitsts = wait()) != nil) {

Re: [9fans] 9front sam in plan9port.

[trebol55555]

#define chording 0  /* code here for reference but it causes deadlocks */

I suppose the bug is still messing around.
I'll give it a try to the 9front version.

Thanks for the info!

Re: [9fans] problem with acme on 9front

[trebol55555]

#define chording 0  /* code here for reference but it causes deadlocks */

I suppose the bug is still messing around.
I'll give it a try to the 9front version.

Thanks for the info!

Re: [9fans] problem with acme on 9front

[Kurt H Maier]

On Sat, May 21, 2016 at 11:28:09AM -0700, Rob Pike wrote:
> If that was meant as a dis, you obviously haven't been to New York lately.
> 

Merely an observation that editing text is a minor subset of acme's
functionality.  When I dis things, you will not be confused about my
intent.

khm

Re: [9fans] problem with acme on 9front

[Mark van Atten]

On Thu, May 19, 2016 at 11:18 PM, Lee Fallat  wrote:
> You can copy code from Acme and "backport" it. I've done it before and
> it was trivial (and it's long gone too).

That's most interesting.

The following had made me think it would not be easy:

http://thread.gmane.org/gmane.os.plan9.general/8889/focus=8920

Mark.

Re: [9fans] 9front sam in plan9port.

[Mark van Atten]

On Sat, May 21, 2016 at 8:30 PM,   wrote:
>> The plan9port version also has chording if in its samterm/main.c you
>> change #define chording 0 to #define chording 1.
>
> It was also marked as being buggy, which is why it remains disabled by 
> default.

I noticed the comment in the source, but also that on my systems
(FreeBSD, Debian) I have never run into trouble with it. This may be
different in other setups. Any experiences?

Mark.

Re: [9fans] 9front sam in plan9port.

[sl]

>> > The plan9port version also has chording if in its samterm/main.c you
>> > change #define chording 0 to #define chording 1.
>> 
>> It was also marked as being buggy, which is why it remains disabled by 
>> default.
> 
> i believe rsc found the reason for this later.  the bug was that it caused 
> protocol lock.
> i don't recall what the details of the bug or the fix were.

Ah, I wasn't aware of that.

The chording in 9front sam is a different implementation.

There haven't been many changes; as far as I can remember, only the addition
of chording and Ctrl-b to switch focus to the command window. And some minor
bugfixes.

sl

Re: [9fans] 9front sam in plan9port.

[erik quanstrom]

On Sat May 21 11:32:04 PDT 2016, s...@9front.org wrote:
> > The plan9port version also has chording if in its samterm/main.c you
> > change #define chording 0 to #define chording 1.
> 
> It was also marked as being buggy, which is why it remains disabled by 
> default.

i believe rsc found the reason for this later.  the bug was that it caused 
protocol lock.
i don't recall what the details of the bug or the fix were.

- erik

Re: [9fans] 9front sam in plan9port.

[sl]

> The plan9port version also has chording if in its samterm/main.c you
> change #define chording 0 to #define chording 1.

It was also marked as being buggy, which is why it remains disabled by default.

sl

Re: [9fans] problem with acme on 9front

[Rob Pike]

If that was meant as a dis, you obviously haven't been to New York lately.

-rob


On Sat, May 21, 2016 at 11:16 AM, Kurt H Maier  wrote:

> On Sat, May 21, 2016 at 10:36:44AM -0700, erik quanstrom wrote:
> > > This is tantamount to saying acme is superior because you are better at
> > > acme.  [...]
> >
> > c'mon man.  you follow this with several paragraphs of opinion which
> appear
> > to say that acme is not better because you don't like it.
>
> Yes, having explicitly set the dimensions of the field, I proceeded to
> stay in bounds.
>
> > but then again, editors don't tend to lead to logical arguments.  :-)
>
> I've never seen it happen, and I don't really expect to.  I do maintain
> that calling acme an editor is akin to calling New York a shopping
> center.
>
> khm
>
>

Re: [9fans] 9front sam in plan9port.

[sl]

> Ok, the wording on that site is a bit odd to me.  The name plan9port is a
> project Russ Cox wrote, so the wording
> 
> A port of 9front's version of sam(1) to unix (plan9port)
> 
> seemed to imply porting 9front's sam(1) to plan9port. That didn't make
> sense to me since Russ's plan9port sam goes back many many years earlier
> than the 2014 timestamp in that repo you pointed at.

Yes, and 9front's sam has some additional features (like chording) that are
not found in p9p's sam.

If I understand correctly, the author wanted to use those features, which is
why he set out to replace the same that was already in p9p with this newer
modification.

sl

Re: [9fans] 9front sam in plan9port.

[Mark van Atten]

On Sat, May 21, 2016 at 6:31 PM,   wrote:
>> If you mean Russ's project, as referred to on that link, yes.
>
> Hello James.
>
> No, it appears to be the 9front version (2014, with mouse chords in 
> samterm/main.c ), ported to plan9port.

The plan9port version also has chording if in its samterm/main.c you
change #define chording 0 to #define chording 1.

Mark.

Re: [9fans] problem with acme on 9front

[Kurt H Maier]

On Sat, May 21, 2016 at 10:36:44AM -0700, erik quanstrom wrote:
> > This is tantamount to saying acme is superior because you are better at
> > acme.  [...]
> 
> c'mon man.  you follow this with several paragraphs of opinion which appear
> to say that acme is not better because you don't like it.

Yes, having explicitly set the dimensions of the field, I proceeded to
stay in bounds.

> but then again, editors don't tend to lead to logical arguments.  :-)

I've never seen it happen, and I don't really expect to.  I do maintain
that calling acme an editor is akin to calling New York a shopping
center.

khm

Re: [9fans] Marvell Yukon 88E8055 NIC

[erik quanstrom]

On Wed May  4 23:51:49 PDT 2016, kokam...@hera.eonet.ne.jp wrote:
> I think this is written by eric, however, it may concern to others,
> and I'm now a 9front user.
> 
> I use Panasonic CF-R7 C2D notebook(maybe around 2009) which has 
> Yukon 88E8055 ether chip.  The etheryuk.c has no this entry.   
> Please add the entry of
>   0x11ab, 0x4363 1514 "88e8055"
> to vtab[].
> This chip works file!
> 
> Thank you eric!

great!  i never got much milage on this chipset.  it was a christmas project, 
and
was never in a product.

- erik

Re: [9fans] problem with acme on 9front

[erik quanstrom]

> This is tantamount to saying acme is superior because you are better at
> acme.  [...]

c'mon man.  you follow this with several paragraphs of opinion which appear
to say that acme is not better because you don't like it.

but then again, editors don't tend to lead to logical arguments.  :-)

- erik

Re: [9fans] 9front sam in plan9port.

[James A. Robinson]

On Sat, May 21, 2016 at 9:33 AM  wrote:

> No, it appears to be the 9front version (2014, with mouse chords in
> samterm/main.c ), ported to plan9port.
>

Ok, the wording on that site is a bit odd to me.  The name plan9port is a
project Russ Cox wrote, so the wording

A port of 9front's version of sam(1) to unix (plan9port)

seemed to imply porting 9front's sam(1) to plan9port. That didn't make
sense to me since Russ's plan9port sam goes back many many years earlier
than the 2014 timestamp in that repo you pointed at.

Jim

Re: [9fans] bug in authdial()

[erik quanstrom]

On Fri May 20 15:27:56 PDT 2016, charles.fors...@gmail.com wrote:

> On 20 May 2016 at 23:04, Skip Tavakkolian <9...@9netics.com> wrote:
> 
> > i'm a little confused by the discussion of il + tcp on authdial
> > causing the delay.  if ndb/cs returns multiple dial strings, dialmulti
> > function (/sys/src/libc/9sys/dial.c) dials them all in parallel
> > (rfork) and the first one that returns, wins.
> >
> 
> 9front uses the original sequential one

so does 9atom.

- erik

Re: [9fans] bug in authdial()

[erik quanstrom]

On Fri May 20 21:48:40 PDT 2016, aris...@ar.aichi-u.ac.jp wrote:
> parallel dialing would be fine.
> I guess both cinap and erik have examined labs code.
> any problem with it?

i don't use this code.

i think the problem with parallel dial is that like the tricks we used to play 
in
nsec()—it assumes things about the calling environment.  for starters, it's 
going
to break anything that's already forking as it may eat wait messages.

it's been a while since i looked at this, but i think parallel dialing requires 
a
bit more of a rethink of the dialing code than just hacking in a fork.  without
restructuring the system, i think one would be forced into a dial device so that
any forking/threading could escape the current running environment.

the original problem this code was trying to solve was the fact that many 
connections
can't do ip6, and dialing ip6 slows down the connection quite a bit.

this problem is a little easier to fix.  cs needs to do a little more work to 
filter out
impossible connection types.  for example, if one's internet connection is not 
ip6
capable, then cs should be instructed to not return ip6 addresses.

- erik

Re: [9fans] bug in authdial()

[erik quanstrom]

> static int
> reap(Dest *dp)
> {
>   char exitsts[2*ERRMAX];
> + int n;
> - if (outstandingprocs(dp) && await(exitsts, sizeof exitsts) >= 0) {
> + if (outstandingprocs(dp) && (n = await(exitsts, sizeof exitsts-1)) >= 
> 0) {
> + exitsts[n] = 0;
>   notedeath(dp, exitsts);
>   return 0;
>   }
>   return -1;
> }
>
> probably 2*ERRMAX is enough for await().
> 
> I wonder why await() returns non-terminated string?
> 

a better solution is to just use waitmsg (see wait(2)).  the parsing rules and 
sizing are
already implemented there.

- erik

Re: [9fans] 9front sam in plan9port.

[trebol55555]

> If you mean Russ's project, as referred to on that link, yes.

Hello James.

No, it appears to be the 9front version (2014, with mouse chords in 
samterm/main.c ), ported to plan9port.

Re: [9fans] 9front sam in plan9port.

[James A. Robinson]

If you mean Russ's project, as referred to on that link, yes.

https://swtch.com/plan9port/

I am using it under Mac OS X now, mainly for acme and sam.  I've tried it
under Linux years ago and it seemed just as solid (I am guessing Russ
initially developed it under Linux).

Jim

On Sat, May 21, 2016 at 8:37 AM  wrote:

> Hello everyone,
> any experience with this?
>
> https://bitbucket.org/iru/sam9f-unix
>
> trebol.
>
>
>

[9fans] 9front sam in plan9port.

[trebol55555]

Hello everyone,
any experience with this?

https://bitbucket.org/iru/sam9f-unix

trebol.

Re: [9fans] Namespace inheritance between processes

[Anthony Martin]

Anthony Martin  once said:
> Casey Rodarmor  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 >[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
} &

Re: [9fans] Namespace inheritance between processes

[Anthony Martin]

Casey Rodarmor  once said:
> > Let's say I have a process A which forks a child process B with the
> > RFNAMEG so it receives a copy of A's namespace.
> >
> > If process A then makes a change to its namespace, will process B see
> > that change? Or does B receive a distinct copy that A then can't
> > change?

The latter. B won't observe any namespace changes made by A.

> 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.

Cheers,
  Anthony

Re: [9fans] Namespace inheritance between processes

[Skip Tavakkolian]

lets create a couple of shell scripts like this:

1) ns_shared:
#! /bin/rc

cat /n/tmp/foo
ramfs -m /n/tmp # start another ramfs in the child's namespace
echo something > /n/tmp/foo
cat /n/tmp/foo
exit

2) ns_RFNAMEG
#! /bin/rc

rfork n
cat /n/tmp/foo
ramfs -m /n/tmp # start another ramfs in the child's namespace
echo anotherthing > /n/tmp/foo
cat /n/tmp/foo
exit

then in an interactive rc:

% ramfs -m /n/tmp
% echo 123 > /n/tmp/foo
% touch /n/tmp/bar
% ls -l /n/tmp
--rw-rw-r-- M 14458 fst fst 0 May 21 01:46 /n/tmp/bar
--rw-rw-r-- M 14458 fst fst 4 May 21 01:45 /n/tmp/foo
% ns_RFNAMEG
123
anotherthing
% ls -l /n/tmp
--rw-rw-r-- M 14458 fst fst 0 May 21 01:46 /n/tmp/bar
--rw-rw-r-- M 14458 fst fst 4 May 21 01:45 /n/tmp/foo
% cat /n/tmp/foo
123
% ns_shared
123
something
% ls -l /n/tmp
--rw-rw-r-- M 14462 fst fst 10 May 21 01:46 /n/tmp/foo
% cat /n/tmp/foo
something
% 

> On Sat, May 21, 2016 at 12:26 AM, Casey Rodarmor  wrote:
>> Hi 9 fans,
>>
>> I'm trying to figure out how namespace inheritance between process groups 
>> works.
>>
>> Let's say I have a process A which forks a child process B with the
>> RFNAMEG so it receives a copy of A's namespace.
>>
>> If process A then makes a change to its namespace, will process B see
>> that change? Or does B receive a distinct copy that A then can't
>> change?
>>
>> Thanks!
>>
>> Best,
>> Casey
> 
> 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.

Re: [9fans] Namespace inheritance between processes

[Casey Rodarmor]

On Sat, May 21, 2016 at 12:26 AM, Casey Rodarmor  wrote:
> Hi 9 fans,
>
> I'm trying to figure out how namespace inheritance between process groups 
> works.
>
> Let's say I have a process A which forks a child process B with the
> RFNAMEG so it receives a copy of A's namespace.
>
> If process A then makes a change to its namespace, will process B see
> that change? Or does B receive a distinct copy that A then can't
> change?
>
> Thanks!
>
> Best,
> Casey

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.

[9fans] Namespace inheritance between processes

[Casey Rodarmor]

Hi 9 fans,

I'm trying to figure out how namespace inheritance between process groups works.

Let's say I have a process A which forks a child process B with the
RFNAMEG so it receives a copy of A's namespace.

If process A then makes a change to its namespace, will process B see
that change? Or does B receive a distinct copy that A then can't
change?

Thanks!

Best,
Casey

Re: [9fans] bug in authdial()

[arisawa]

Hello,

> 2016/05/21 11:25、Skip Tavakkolian <9...@9netics.com> のメール：
> 
> i think this fix is correct; i'm not sure why tokenize didn't have a
> problem walking a buffer it expects to be null terminated.

I agree with skip.

the man wait(2) says:
The underlying system call is await, which fills in the n-
byte buffer s with a textual representation of the pid,
times, and exit string.  There is no terminal NUL.  The
return value is the length, in bytes, of the data.

thus the typical usage of await is:
Waitmsg*
wait(void)
{
int n, l;
char buf[512], *fld[5];
Waitmsg *w;

n = await(buf, sizeof buf-1);
if(n < 0)
return nil;
buf[n] = '\0';
if(tokenize(buf, fld, nelem(fld)) != nelem(fld)){
werrstr("couldn't parse wait message");
return nil;
}


/sys/src/libc/9sys/dial.c may be fixed as follows:

static int
reap(Dest *dp)
{
char exitsts[2*ERRMAX];
+   int n;
-   if (outstandingprocs(dp) && await(exitsts, sizeof exitsts) >= 0) {
+   if (outstandingprocs(dp) && (n = await(exitsts, sizeof exitsts-1)) >= 
0) {
+   exitsts[n] = 0;
notedeath(dp, exitsts);
return 0;
}
return -1;
}

probably 2*ERRMAX is enough for await().

I wonder why await() returns non-terminated string?