Re: [9fans] 9front sam in plan9port.
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
> 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
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 Martinwrote: > 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()
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
unfortunately, sam has hardcoded B into the command channel. see /sys/src/cmd/samterm/plan9.c:/^plumbformat - erik
Re: [9fans] bug in authdial()
> 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
> 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()
> On May 21, 2016, at 10:04 AM, erik quanstromwrote: > > 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()
>> >> 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()
> 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()
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()
> < 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()
> i believe this is missing a free. > > - erik good catch; thanks.
Re: [9fans] problem with acme on 9front
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 Simonwrote: > > 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()
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()
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()
> 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.
#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
#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
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
On Thu, May 19, 2016 at 11:18 PM, Lee Fallatwrote: > 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.
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.
>> > 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.
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.
> 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
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 Maierwrote: > 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.
> 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.
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
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
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
> 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.
On Sat, May 21, 2016 at 9:33 AMwrote: > 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()
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()
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()
> 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.
> 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.
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 AMwrote: > Hello everyone, > any experience with this? > > https://bitbucket.org/iru/sam9f-unix > > trebol. > > >
[9fans] 9front sam in plan9port.
Hello everyone, any experience with this? https://bitbucket.org/iru/sam9f-unix trebol.
Re: [9fans] Namespace inheritance between processes
Anthony Martinonce 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
Casey Rodarmoronce 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
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 Rodarmorwrote: >> 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
On Sat, May 21, 2016 at 12:26 AM, Casey Rodarmorwrote: > 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
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()
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?