[9fans] p9p: 9pfuse

[arisawa]

Hello,

my 9pfuse on mac is something weird.
executing: 9pfuse hebe /n/hebe  # hebe is one of my plan9 server 
(9front)
I can see /n/hebe/usr/arisawa/tmp

-bash$ ls -l /n/hebe/usr/arisawa/tmp/x
ls: /n/hebe/usr/arisawa/tmp/x: No such file or directory# this is OK. I 
don’t have tmp/x
-bash$ echo abc >/tmp/a
-bash$ cp /tmp/a /n/hebe/usr/arisawa/tmp/x
cp: /n/hebe/usr/arisawa/tmp/x: fchmod failed: Result too large
-bash$ cat /tmp/a >/n/hebe/usr/arisawa/tmp/x
-bash$ ls -l /n/hebe/usr/arisawa/tmp/x
-rw-r-----  1 arisawa  staff  4  4 22 22:29 /n/hebe/usr/arisawa/tmp/x
-bash$ chmod 664 /n/hebe/usr/arisawa/tmp/x
chmod: Unable to change file mode on /n/hebe/usr/arisawa/tmp/x: Result too large
-bash$ 

Is this only to me?
or any one already have fixed this problem?

Kenji Arisawa

P.S. it seems that I need to send mail twice or more to be received by 9fans.

[9fans] p9p: 9pfuse

[arisawa]

Hello,

my 9pfuse on mac is something weird.
by executing: 9pfuse hebe /n/hebe   # hebe is one of my plan9 
server (9front)
I can see /n/hebe/usr/arisawa/tmp

-bash$ ls -l /n/hebe/usr/arisawa/tmp/x
ls: /n/hebe/usr/arisawa/tmp/x: No such file or directory# this is OK. I 
don’t have tmp/x
-bash$ echo abc >/tmp/a
-bash$ cp /tmp/a /n/hebe/usr/arisawa/tmp/x
cp: /n/hebe/usr/arisawa/tmp/x: fchmod failed: Result too large
-bash$ cat /tmp/a >/n/hebe/usr/arisawa/tmp/x
-bash$ ls -l /n/hebe/usr/arisawa/tmp/x
-rw-r-----  1 arisawa  staff  4  4 22 22:29 /n/hebe/usr/arisawa/tmp/x
-bash$ chmod 664 /n/hebe/usr/arisawa/tmp/x
chmod: Unable to change file mode on /n/hebe/usr/arisawa/tmp/x: Result too large
-bash$ 

Is this only to me?
or any one already have fixed this problem?

Kenji Arisawa

P.S. it seems that I need to send mail twice to be received by 9fans.

[9fans] p9p: 9pfuse

[arisawa]

Hello,

my 9pfuse on mac is something weird.
by executing: 9pfuse hebe /n/hebe   # hebe is one of my plan9 
server (9front)
I can see /n/hebe/usr/arisawa/tmp

-bash$ ls -l /n/hebe/usr/arisawa/tmp/x
ls: /n/hebe/usr/arisawa/tmp/x: No such file or directory# this is OK. I 
don’t have x
-bash$ echo abc >/tmp/a
-bash$ cp /tmp/a /n/hebe/usr/arisawa/tmp/x
cp: /n/hebe/usr/arisawa/tmp/x: fchmod failed: Result too large
-bash$ cat /tmp/a >/n/hebe/usr/arisawa/tmp/x
-bash$ ls -l /n/hebe/usr/arisawa/tmp/x
-rw-r-----  1 arisawa  staff  4  4 22 22:29 /n/hebe/usr/arisawa/tmp/x
-bash$ chmod 664 /n/hebe/usr/arisawa/tmp/x
chmod: Unable to change file mode on /n/hebe/usr/arisawa/tmp/x: Result too large
-bash$ 

Is this only to me?
or any one already have fixed this problem?

Kenji Arisawa

[9fans] p9p: symlink

[arisawa]

Hello,

Symlink is one of ugly things in unix.
For example, my mac shows:

-bash$ ls -l /usr/bin/vi
lrwxr-xr-x  1 root  wheel  3 11 18  2014 /usr/bin/vi -> vim
-bash$

This expression is something like a thorn.
Irregular fields makes things difficult.
The entity of /usr/bin/vi is /usr/bin/vim, which is

-bash$ ls -l /usr/bin/vim
-rwxr-xr-x  1 root  wheel  1530240  6 24  2016 /usr/bin/vim
-bash$

I guess Russ hated the irregularity.
In plan9port we have

-bash$ 9 ls -l /usr/bin/vi
-Lrwxr-xr-x M 0 root wheel 3 Jun 24  2016 /usr/bin/vi
-bash$ 

but I wander why this isn't

-bash$ 9 ls -l /usr/bin/vi
-Lrwxr-xr-x M 0 root wheel 1530240 Jun 24  2016 /usr/bin/vi
-bash$ 

This comes from $P9P/src/lib9/_p9dir.c

if(S_ISLNK(lst->st_mode)){  /* yes, lst not st */
d->mode |= DMSYMLINK;
d->length = lst->st_size;   <- why Russ 
put this code?
}

Any merit?

Kenji Arisawa

-

P.S. This mail is resent because the mail wasn't received by 9fans.

[9fans] p9p: symlink

[arisawa]

Hello,

Symlink is one of ugly things in unix.
For example, my mac shows:

-bash$ ls -l /usr/bin/vi
lrwxr-xr-x  1 root  wheel  3 11 18  2014 /usr/bin/vi -> vim
-bash$

This expression is something like a thorn.
Irregular fields makes things difficult.
The entity of /usr/bin/vi is /usr/bin/vim, which is

-bash$ ls -l /usr/bin/vim
-rwxr-xr-x  1 root  wheel  1530240  6 24  2016 /usr/bin/vim
-bash$

I guess Russ hated the irregularity.
In plan9port we have

-bash$ 9 ls -l /usr/bin/vi
-Lrwxr-xr-x M 0 root wheel 3 Jun 24  2016 /usr/bin/vi
-bash$ 

but I wander why this isn't

-bash$ 9 ls -l /usr/bin/vi
-Lrwxr-xr-x M 0 root wheel 1530240 Jun 24  2016 /usr/bin/vi
-bash$ 

This comes from $P9P/src/lib9/_p9dir.c

if(S_ISLNK(lst->st_mode)){  /* yes, lst not st */
d->mode |= DMSYMLINK;
d->length = lst->st_size;   <- why Russ 
put this code?
}

Any merit?

Kenji Arisawa

Re: [9fans] p9p: 9 ls /dev

[arisawa]

Hello David, thanks for the response.

>  it may not be worth it

I agree.
I think it is wise to give up to simulate dirread() rigorously. plan9 is not 
unix.

> Ori's suggestion to use Getdirentries64 on OSX might be  better
I cannot find getdirentries64() on my OSX.



I examined david code and found the code have still some problems.

(1) some directory entries are lost.
(2) uid and gid is wrong.

the test program is attached here.


test_dirread.c
Description: Binary data


the result is shown below.

#
#   ls   (official ls in osx)
#
-bash$ ls /usr/bin|wc
110811089719
-bash$ ls /dev|wc
 352 3522428

#
#   david
#

-bash$ mk -f mkfile_david
9c -D__DARWIN_64_BIT_INO_T test_dirread.c
9c -D__DARWIN_64_BIT_INO_T dirread_david2.c
9l -o o.test_dirread test_dirread.o dirread_david2.o 
-bash$ o.test_dirread .
.DS_Store root 501 416 0
_mp9dir.c root 501 20320 0
_p9dir.c root 501 2000106 0
a.out root 501 710 0
a1.c root 501 572 0
b1.c root 501 243 0
dirread.c.orig root 501 743 0
dirread1.c root 501 137 0
dirread_david.c root 501 473 0
...
-bash$ o.test_dirread /usr/bin |wc
 7703850   20936
-bash$ o.test_dirread -a /usr/bin |wc
 7703850   20936
-bash$ o.test_dirread /dev |wc
 32016007739
-bash$ o.test_dirread -a /dev |wc
 32016007739
-bash$ 

#
#   mine
#

-bash$ mk
9c -D__DARWIN_64_BIT_INO_T test_dirread.c
9c -D__DARWIN_64_BIT_INO_T mdirread2.c
9c -D__DARWIN_64_BIT_INO_T _mp9dir.c
9l -o o.test_dirread test_dirread.o mdirread2.o _mp9dir.o 
-bash$ o.test_dirread .
.DS_Store arisawa staff 644 6148
_mp9dir.c arisawa staff 644 4948
_mp9dir.o arisawa staff 644 10284
_p9dir.c arisawa staff 444 4733
a.out arisawa staff 755 9552
a1.c arisawa staff 644 741
b1.c arisawa staff 644 2390
dirread.c.orig arisawa staff 444 3699
dirread1.c arisawa staff 644 3790
dirread_david.c arisawa staff 644 3768
...
-bash$ o.test_dirread /usr/bin |wc
11085540   33034
-bash$ o.test_dirread -a /usr/bin |wc
11085540   33034
-bash$ o.test_dirread /dev |wc
 3521760   10308
-bash$ o.test_dirread -a /dev |wc
 3521760   10308
-bash$ 

David idea is nice. I borrowed the idea:
dir = fdopendir(dup(fd));
in mdirread2.c



mkfile
Description: Binary data
 

mdirread2.c
Description: Binary data
 

_mp9dir.c
Description: Binary data


NOTE on _p9dir.c

(A) d->length
I observed opening character device can make a problem.
I think length of those device is allowed to assign 0.

if(S_ISBLK(lst->st_mode) || S_ISCHR(lst->st_mode)){
if((fd = open(name, O_RDONLY)) >= 0){
d->length = disksize(fd, st);
close(fd);
}
}

(B) DMDEVICE
you will find the code in _p9dir.c

else if(S_ISBLK(st->st_mode)){
d->mode |= DMDEVICE;
d->qid.path = ('b'<<16)|st->st_rdev;
}
else if(S_ISCHR(st->st_mode)){
d->mode |= DMDEVICE;
d->qid.path = ('c'<<16)|st->st_rdev;
}

but I prefer
else if(S_ISBLK(st->st_mode)){
d->mode |= DMBLOCK;
d->qid.path = ('b'<<16)|st->st_rdev;
}
else if(S_ISCHR(st->st_mode)){
d->mode |= DMCHAR;
d->qid.path = ('c'<<16)|st->st_rdev;
}

(C) I fixed some codes that produce wrong uid and gid.

comments welcome


> 2017/04/12 16:05、David Arroyo <dr...@aqwari.net> のメール：
> 
> The problem is twofold;
> 
> * The function exits early if it can't read a max-length directory
> entry, so that entry is "skipped" in subsequent calls to mygetdents.
> * As you said, we also lose any buffered dirents that haven't been
> returned from readdir yet.
> 
> I think these are both fixable problems, but it may not be worth it.
> Ori's suggestion to use Getdirentries64 on OSX might be  better.
> 
> David
> 
> On Tue, Apr 11, 2017, at 10:33 PM, arisawa wrote:
>> I did more test on david code and found a problem.
>> 
>> -bash$ mk -f mkfile_david
>> -bash$ o.test_dirread -a /usr/bin |wc
>>10844336   27266
>> -bash$ o.test_dirread /usr/bin |wc
>>10844336   27266
>> -bash$ ls /usr/bin |wc
>>110811089719
>> 
>> option -a is for dirreadall.
>> 1108 - 1084 entries are lost.
>> 
>> they are:
>> o.test_dirread /usr/bin | awk '{print $1}' | sort >/tmp/a
>> ls /usr/bin | sort >/tmp/b
>> diff /tmp/a /tmp/b
>> 
>> -bash$ diff /tmp/a /tmp/b
>> 21a22
>>> SplitForks
>> 240a242,246
>>> easy_i

Re: [9fans] p9p: 9 ls /dev

[arisawa]

I did more test on david code and found a problem.

-bash$ mk -f mkfile_david
-bash$ o.test_dirread -a /usr/bin |wc
10844336   27266
-bash$ o.test_dirread /usr/bin |wc
10844336   27266
-bash$ ls /usr/bin |wc
110811089719

option -a is for dirreadall.
1108 - 1084 entries are lost.

they are:
o.test_dirread /usr/bin | awk '{print $1}' | sort >/tmp/a
ls /usr/bin | sort >/tmp/b
diff /tmp/a /tmp/b

-bash$ diff /tmp/a /tmp/b
21a22
> SplitForks
240a242,246
> easy_install-2.6
> easy_install-2.7
> efax
> efix
> egrep
461a468,473
> kcc
> kdestroy
> kextutil
> keytool
> kgetcred
> kill.d
675a688,694
> piconv
> piconv5.16
> piconv5.18
> pidpersec.d
> pkgbuild
> pkill
> pl
880a900,904
> spfquery5.18
> splain
> splain5.16
> splain5.18
> split

sorry if I make a mistake, but I suspect readdir_r() has a buffer,
which can make a problem in using dup().

Kenji Arisawa.

> 2017/04/09 13:18、arisawa <karis...@gmail.com> のメール：
> 
> thanks david.
> 
> using dup() is very nice idea!
> your code works with
>   CFLAGS=-D__DARWIN_64_BIT_INO_T  # manual is wrong
> and a fix:
> //buf = ((char*)buf) + d_reclen(buf);
>   buf = (struct dirent *)(((char*)buf) + d_reclen(buf));
> and adding
>   #define NAME_MAX 256
> in somewhere.
> 
> now /dev is readable.
> 
> one problem is left.
> 
> my test code:
>   fd = open(dirname,OREAD);
>   if(fd < 0)
>   fatal("%s open error",dirname);
>   while((n = dirread(fd, )) > 0){
>   print("#DBG n=%d\n",n);
>   for(i = 0; i < n; i++)
>   print("%s %s %s \n", db[i].name, db[i].uid, db[i].gid);
>   }
>   close(fd);
> shows for dirname=$HOME
>   ...
>   arch root 501 
>   bin root 501 
>   ...
> but they should be
>   arch arisawa staff 
>   bin arisawa staff
> this problem comes from _p9dir() that is used in dirpackage().
> 
> Kenji Arisawa
> 
> 
>> 2017/04/08 18:07、David Arroyo <dr...@aqwari.net> のメール：
>> 
>> Ignore my previous post, I was tired and forgot about dup(). How about
>> something like this? (attached)
>> 
>> I only tested this on Ubuntu, I don't have an OS X machine. I still went
>> with readdir_r because the AIX and Solaris man pages for readdir were
>> vague about its behavior when called from multiple threads (glibc, musl,
>> FreeBSD look pretty safe).
>> 
>> Cheers,
>> David
>> 
>> On Sat, Apr 8, 2017, at 03:27 AM, David Arroyo wrote:
>>> This should be doable with some combination of fdopendir(3) and
>>> readdir(3). I'm not sure how to avoid leaking memory through the
>>> returned DIR pointer and any memory allocated with by readdir(3).
>>> This is usually free'd by closedir(3), which we can't use without
>>> closing the underlying file.
>>> 
>>> It should be OK to use free() on the return value of fdopendir, and
>>> stick to the uglier readdir_r(3) interface. I can definitely see why
>>> Russ went with  the simpler  system-specific interfaces on this.
>>> 
>>> David
>>> 
>>> On Sat, Apr 8, 2017, at 02:46 AM, Ori Bernstein wrote:
>>>> On Sat, 8 Apr 2017 15:21:47 +0900, arisawa <karis...@gmail.com> wrote:
>>>> 
>>>>> but how to?
>>>>> 
>>>>> unix doesn’t have something like fdreaddir(int fd).
>>>>> my guess: russ unwillingly used a low level function such as
>>>>> int getdirentries(int fd, char *buf, int nbytes, long *basep).
>>>>> 
>>>>> readdirall() might be OK in regular usage.
>>>> 
>>>> I don't use OSX regularly, although I do maintain the syscall
>>>> layer for Myrddin on it.
>>>> 
>>>> Getdirentries64 exists, and rudimentary testing doesn't show
>>>> any difficulties with using it.
>>>> 
>>>> -- 
>>>>   Ori Bernstein
>>>> 
>>> 
>> 
> 

Re: [9fans] p9p: 9 ls /dev

[arisawa]

thanks david.

using dup() is very nice idea!
your code works with
   CFLAGS=-D__DARWIN_64_BIT_INO_T   # manual is wrong
and a fix:
//  buf = ((char*)buf) + d_reclen(buf);
buf = (struct dirent *)(((char*)buf) + d_reclen(buf));
and adding
#define NAME_MAX 256
in somewhere.

now /dev is readable.

one problem is left.

my test code:
fd = open(dirname,OREAD);
if(fd < 0)
fatal("%s open error",dirname);
while((n = dirread(fd, )) > 0){
print("#DBG n=%d\n",n);
for(i = 0; i < n; i++)
print("%s %s %s \n", db[i].name, db[i].uid, db[i].gid);
}
close(fd);
shows for dirname=$HOME
...
arch root 501 
bin root 501 
    ...
but they should be
    arch arisawa staff 
bin arisawa staff
 this problem comes from _p9dir() that is used in dirpackage().

Kenji Arisawa


> 2017/04/08 18:07、David Arroyo <dr...@aqwari.net> のメール：
> 
> Ignore my previous post, I was tired and forgot about dup(). How about
> something like this? (attached)
> 
> I only tested this on Ubuntu, I don't have an OS X machine. I still went
> with readdir_r because the AIX and Solaris man pages for readdir were
> vague about its behavior when called from multiple threads (glibc, musl,
> FreeBSD look pretty safe).
> 
> Cheers,
> David
> 
> On Sat, Apr 8, 2017, at 03:27 AM, David Arroyo wrote:
>> This should be doable with some combination of fdopendir(3) and
>> readdir(3). I'm not sure how to avoid leaking memory through the
>> returned DIR pointer and any memory allocated with by readdir(3).
>> This is usually free'd by closedir(3), which we can't use without
>> closing the underlying file.
>> 
>> It should be OK to use free() on the return value of fdopendir, and
>> stick to the uglier readdir_r(3) interface. I can definitely see why
>> Russ went with  the simpler  system-specific interfaces on this.
>> 
>> David
>> 
>> On Sat, Apr 8, 2017, at 02:46 AM, Ori Bernstein wrote:
>>> On Sat, 8 Apr 2017 15:21:47 +0900, arisawa <karis...@gmail.com> wrote:
>>> 
>>>> but how to?
>>>> 
>>>> unix doesn’t have something like fdreaddir(int fd).
>>>> my guess: russ unwillingly used a low level function such as
>>>> int getdirentries(int fd, char *buf, int nbytes, long *basep).
>>>> 
>>>> readdirall() might be OK in regular usage.
>>> 
>>> I don't use OSX regularly, although I do maintain the syscall
>>> layer for Myrddin on it.
>>> 
>>> Getdirentries64 exists, and rudimentary testing doesn't show
>>> any difficulties with using it.
>>> 
>>> -- 
>>>Ori Bernstein
>>> 
>> 
> 

Re: [9fans] p9p: 9 ls /dev

[arisawa]

but how to?

unix doesn’t have something like fdreaddir(int fd).
my guess: russ unwillingly used a low level function such as
int getdirentries(int fd, char *buf, int nbytes, long *basep).

readdirall() might be OK in regular usage.


> 2017/04/08 13:06、Lyndon Nerenberg <lyn...@orthanc.ca> のメール：
> 
> 
>> On Apr 7, 2017, at 6:18 PM, arisawa <karis...@gmail.com> wrote:
>> 
>> the problem comes from getdirentries() used in $P9P/src/lib9/dirread.c, I 
>> think.
>> 
>> man getdirentries(2) of OSX says:
> 
> And, dare I quote a Linux manpage, but getdirentries(3) there says:
> 
>> CONFORMING TO
>>   Not  in  POSIX.1-2001.   Present  on the BSDs, and a few other systems.
>>   Use opendir(3) and readdir(3) instead.
> 
> The fix should be simple enough.
> 
> --lyndon
> 
> 

Re: [9fans] p9p: 9 ls /dev

[arisawa]

thanks for response.

the problem comes from getdirentries() used in $P9P/src/lib9/dirread.c, I think.

man getdirentries(2) of OSX says:

NOTES
 getdirentries() should rarely be used directly; instead, opendir(3) and
 readdir(3) should be used.

 As of Mac OS X 10.6, getdirentries() is deprecated, and it is recommended 
that
 applications use readdir(3) rather than using getdirentries() directly.  
Due
 to limitations with the system call, getdirentries() will not work with 
64-bit
 inodes; in order to use getdirentries(), _DARWIN_NO_64_BIT_INODE must be
 defined.  See stat(2) for more information on _DARWIN_NO_64_BIT_INODE and 
its
 other effects.



> 2017/04/07 10:18、Lyndon Nerenberg <lyn...@orthanc.ca> のメール：
> 
> 
>> On Apr 6, 2017, at 5:49 AM, arisawa <karis...@gmail.com> wrote:
>> 
>> on my system (on osx(10.10 and 10.11) with plan9port-20140306 (latest port 
>> from russ))
>> the next command fails. that is,
>> 9 ls /dev
>> does not return to shell.
> 
> It also hangs on my 10.12.4 system.  Mind you, I haven't updated/rebuilt P9P 
> on this machine is a long time ...
> 
> 

[9fans] p9p: 9 ls /dev

[arisawa]

hello 9fans,

this is a question about plan9port.

on my system (on osx(10.10 and 10.11) with plan9port-20140306 (latest port from 
russ))
the next command fails. that is,
  9 ls /dev
does not return to shell.

how about your system?

on the other hand, my freebsd-11.0 with same plan9port is OK.

my experiments show:
the problem of osx comes from dirreadall()
the function call works for freebsd but not for osx.

anyone has fixed this problem?

Kenji Arisawa

Re: [9fans] pipe: bug or feature?

[arisawa]

thanks,

that is my fault.
it should be
while((n = read(fd,buf0,sizeof(buf0)-1)) > 0){
and
while((n = read(pfd[0],buf,sizeof(buf)-1)) > 0){

> 2017/04/02 16:34、Skip Tavakkolian <skip.tavakkol...@gmail.com> のメール：
> 
> this is either a bug in devpipe or the documentation is misleading. the man 
> page seems to say that the pair of fd's returned by pipe(2) are symmetrical, 
> but it matters which fd of the pair is used for writing.  if you switch 
> around pfd[0] and pfd[1], it works as you'd expect.
> 
> On Fri, Mar 31, 2017 at 5:29 PM arisawa <karis...@gmail.com> wrote:
> Hello,
> 
> I was playing with an experimental code on pipe and met with a problem which 
> I don’t understand.
> 
> the program reads a file and writes it to one end of pipe and then reads it 
> from another end of pipe.
> the buffer for writing pipe is named buf0, and for reading pipe is named buf.
> and I found the program does not finish unless sizeof(buf) > sizeof(buf0).
> is this a bug or feature of pipe?
> 
> Kenji Arisawa
> 
> === BEGIN a.c ===
> #include 
> #include 
> 
> char *argv0;
> 
> void
> usage(void)
> {
> fprint(2,"usage: %s file\n",argv0);
> exits("usage");
> }
> 
> void
> main(int argc, char *argv[])
> {
> int fd,pfd[2];
> char buf[256];
> char buf0[256];
> /* need to be sizeof(buf) > sizeof(buf0)
>  * but this condition is very curious to me */
> int n;
> char *file;
> argv0 = argv[0];
> argc--;argv++;
> USED(argc);
> if(argv[0] == nil)
> usage();
> file = argv[0];
> fd = open(file,OREAD);
> if(fd < 0)
> sysfatal("no such file");
> 
> if(pipe(pfd) < 0)
> sysfatal("pipe error");
> print("pfd: %d %d\n",pfd[0],pfd[1]);
> 
> while((n = read(fd,buf0,sizeof(buf0))) > 0){
> print("read: %d %s\n",n,file);
> n = write(pfd[1],buf0,n);
> print("write: %d\n",n);
> }
> close(pfd[1]);
> while((n = read(pfd[0],buf,sizeof(buf))) > 0){
> buf[n] = 0;
> print("%d %s\n",n,buf);
> }
> print("%d\n",n);
> 
> exits(nil);
> }
> === END a.c ===

[9fans] pipe: bug or feature?

[arisawa]

Hello,

I have been playing with an experimental code on pipe.
the program read a file and write it to one end of pipe and then read it from 
another end of pipe.
the buffer for writing pipe is named buf0, and for reading pipe is named buf.
and I found the program does not finish unless sizeof(buf) > sizeof(buf0).
is this a bug or feature of pipe?

Kenji Arisawa

=== BEGIN a.c ===
#include 
#include 

char *argv0;

void
usage(void)
{
fprint(2,"usage: %s file\n",argv0);
exits("usage");
}

void
main(int argc, char *argv[])
{
int fd,pfd[2];
char buf[256];
char buf0[256];
/* need to be sizeof(buf) > sizeof(buf0)
 * but this condition is very curious to me */
int n;
char *file;
argv0 = argv[0];
argc--;argv++;
USED(argc);
if(argv[0] == nil)
usage();
file = argv[0];
fd = open(file,OREAD);
if(fd < 0)
sysfatal("no such file");

if(pipe(pfd) < 0)
sysfatal("pipe error");
print("pfd: %d %d\n",pfd[0],pfd[1]);

while((n = read(fd,buf0,sizeof(buf0))) > 0){
print("read: %d %s\n",n,file);
n = write(pfd[1],buf0,n);
print("write: %d\n",n);
}
close(pfd[1]);
while((n = read(pfd[0],buf,sizeof(buf))) > 0){
buf[n] = 0;
print("%d %s\n",n,buf);
}
print("%d\n",n);

exits(nil);
}
=== END a.c ===

[9fans] pipe: bug or feature?

[arisawa]

Hello,

I was playing with an experimental code on pipe and met with a problem which I 
don’t understand.

the program reads a file and writes it to one end of pipe and then reads it 
from another end of pipe.
the buffer for writing pipe is named buf0, and for reading pipe is named buf.
and I found the program does not finish unless sizeof(buf) > sizeof(buf0).
is this a bug or feature of pipe?

Kenji Arisawa

=== BEGIN a.c ===
#include 
#include 

char *argv0;

void
usage(void)
{
fprint(2,"usage: %s file\n",argv0);
exits("usage");
}

void
main(int argc, char *argv[])
{
int fd,pfd[2];
char buf[256];
char buf0[256];
/* need to be sizeof(buf) > sizeof(buf0)
 * but this condition is very curious to me */
int n;
char *file;
argv0 = argv[0];
argc--;argv++;
USED(argc);
if(argv[0] == nil)
usage();
file = argv[0];
fd = open(file,OREAD);
if(fd < 0)
sysfatal("no such file");

if(pipe(pfd) < 0)
sysfatal("pipe error");
print("pfd: %d %d\n",pfd[0],pfd[1]);

while((n = read(fd,buf0,sizeof(buf0))) > 0){
print("read: %d %s\n",n,file);
n = write(pfd[1],buf0,n);
print("write: %d\n",n);
}
close(pfd[1]);
while((n = read(pfd[0],buf,sizeof(buf))) > 0){
buf[n] = 0;
print("%d %s\n",n,buf);
}
print("%d\n",n);

exits(nil);
}
=== END a.c ===

[9fans] ipv6on

[arisawa]

hello,

in /rc/bin/ipv6on we (labs,9atom and 9front) have the following code.
ip/ipconfig $xdir loopback /dev/nulladd $mev6 /128

this code is curious to me.
the code doesn’t put ipv6 loopback address "::1" to /net/ipselftab.
and, why we need $mev6 (my ipv6 address) for simply adding loopback address  
"::1" to /net/ipselftab?

isn’t it enough the code below?
ip/ipconfig $xdir loopback /dev/nulladd ::1 /128

it seems this code is working for me.

Kenji Arisawa

Re: [9fans] 9front on raspberry pi

[arisawa]

Hello,

> 2016/11/07 8:29、Chris McGee  のメール：
> 
> Hi All,
> 
> I have cleaned up some of the concurrency code and USB. The new release is 
> here:
> https://github.com/sirnewton01/rpi-9front/releases/tag/nov2016-2
> 
> Thanks,
> Chris

many thanks, I will try.

by the way I said about raspi 1
> the display size is 1920x1200.
> when I try to resize a window, the mouse cursor flips and it is difficult to 
> resize.
This phenomenon was stopped when I connected lan cable.
I don’t know the reason.

I looked the source code and I guess for raspi 1:
Plan9   BCM pin
GPIO0   17  11
GPIO1   18  12
GPIO2   27  13
GPIO3   22  15
GPIO4   23  16
GPIO5   24  18
GPIO6   25  18
GPIO74   7
GPIO8   28  24
GPIO9   29  21
GPIO10  30  ?
GPIO11  31  ?
SDA  2   3
SCL  3   5
CE1  7  26
CE0  8  24
MISO 9  21
MOSI10  19
SCLK11  23
TxD 14   8
RxD 15  10

and I tried some experiments.

(a) turn led light on/off that is connected to GPIO0 pin

term% echo function out GPIO0 >ctl
term% echo 1 > GPIO0
term% echo 0 > GPIO0
term% 

the result is OK.

(b) read GPIO1 status

term% echo function in GPIO1 >ctl

I expected:
term% cat GPIO1 # low voltage
0
term%

however I have:
term% cat GPIO1 # low voltage
00...

I expected:
term% cat GPIO1 # high voltage
1
term%

however I have:
term% cat GPIO1
11...

is this a feature or bug?

Re: [9fans] 9front on raspberry pi

[arisawa]

hello Chris,

> 2016/11/02 20:17、Chris McGee  のメール：
> 
> What's wrong with the large display?

the display size is 1920x1200.
when I try to resize a window, the mouse cursor flips and it is difficult to 
resize.

Re: [9fans] 9front on raspberry pi

[arisawa]

sorry 

> mount -a '#G' /dev
shoud be
bind -a '#G' /dev

> 2016/11/02 19:47、arisawa <aris...@ar.aichi-u.ac.jp> のメール：
> 
> hi steve
> 
>> 2016/11/02 16:57、Steve Simon <st...@quintile.net> のメール：
>> 
>> can you tell me what the gpio file system looks like
> 
> try
>   ls -l '#G'
> them you will find some files such as
>   #G/gpio/CE0
>   #G/gpio/CE1
>   #G/gpio/GPI00
>   #G/gpio/GPI01
>   ...
>   #G/gpio/ctl
>   #G/gpio/event
> but something weird.
> term% mount -a '#G' /dev
> mount: can’t open '#G': permission denied
> I don’t know the reason.
> 
> I haven’t tried GPIO nor mDNS yet, sorry.
> 
> using large display is frustrating...
> my portable HDMI display of 1280x800 works fine.
> 
> 

Re: [9fans] 9front on raspberry pi

[arisawa]

hi steve

> 2016/11/02 16:57、Steve Simon  のメール：
> 
> can you tell me what the gpio file system looks like

try
ls -l '#G'
them you will find some files such as
#G/gpio/CE0
#G/gpio/CE1
#G/gpio/GPI00
#G/gpio/GPI01
...
#G/gpio/ctl
#G/gpio/event
but something weird.
term% mount -a '#G' /dev
mount: can’t open '#G': permission denied
I don’t know the reason.

I haven’t tried GPIO nor mDNS yet, sorry.

using large display is frustrating...
my portable HDMI display of 1280x800 works fine.

Re: [9fans] 9front on raspberry pi

[arisawa]

I’ve tried both pi1 and pi2.
both devices successfully boot up.

my impression only in primitive usage is:
pi2 is fine. thanks Chris!
pi1 is a bit unsteady on usb device. usb keyboard is sometimes accidentally 
detached.


> 2016/11/02 14:05、arisawa <aris...@ar.aichi-u.ac.jp> のメール：
> 
> thanks, i will try.
> 
> is this for pi1 or pi2 or both?
> 
>> 2016/11/02 10:35、Chris McGee <newton...@gmail.com> のメール：
>> 
>> Hi All,
>> 
>> I have released an experimental 9front raspberry pi image that I use for my 
>> cluster.
>> https://github.com/sirnewton01/rpi-9front/releases/tag/nov-2016
>> 
>> Highlights:
>> -Latest 9front release 2016-10-27
>> -Merged in Richard Millar’s kernel from a couple of months ago
>> -Retains 9front GPIO filesystem structure
>> -Link local ipv4 address on boot (low likelihood of collisions)
>> -Discovery of other nodes using multicast DNS through the ‘find9p’ command
>> -9fs mount other nodes on the network
>> -Go 1.7.3
>> -Git script (works with github and google source repos)
>> 
>> Cheers,
>> Chris
> 
> 

Re: [9fans] 9front on raspberry pi

[arisawa]

thanks, i will try.

is this for pi1 or pi2 or both?

> 2016/11/02 10:35、Chris McGee  のメール：
> 
> Hi All,
> 
> I have released an experimental 9front raspberry pi image that I use for my 
> cluster.
> https://github.com/sirnewton01/rpi-9front/releases/tag/nov-2016
> 
> Highlights:
> -Latest 9front release 2016-10-27
> -Merged in Richard Millar’s kernel from a couple of months ago
> -Retains 9front GPIO filesystem structure
> -Link local ipv4 address on boot (low likelihood of collisions)
> -Discovery of other nodes using multicast DNS through the ‘find9p’ command
> -9fs mount other nodes on the network
> -Go 1.7.3
> -Git script (works with github and google source repos)
> 
> Cheers,
> Chris

Re: [9fans] plan9.bell-labs.com hates AppleWebKit?

[arisawa]

I can get proper response from http://plan9.bell-labs.com/sources/ by using 
mac/osx safari.


> 2016/10/03 2:42、James A. Robinson  のメール：
> 
> So... Does Alcatel-Lucent have a problem with AppleWebKit
> users on principle?
> 
> It looks to me as though my problem with browsing around
> under http://plan9.bell-labs.com/sources/ (and other subpages)
> is because the server doesn't like the User-Agent string:
> 
> $ telnet plan9.bell-labs.com 80
> Trying 135.104.24.16...
> Connected to plan9.bell-labs.com.
> Escape character is '^]'.
> GET /sources/contrib/ HTTP/1.1
> Host: plan9.bell-labs.com
> Connection: keep-alive
> Cache-Control: max-age=0
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) 
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36
> Accept: 
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> DNT: 1
> Accept-Encoding: gzip, deflate, sdch
> Accept-Language: en-US,en;q=0.8
> 
> HTTP/1.1 200 OK
> Connection closed by foreign host.
> 
> And here it is again w/o the User-Agent string:
> 
> $ telnet plan9.bell-labs.com 80
> Trying 135.104.24.16...
> Connected to plan9.bell-labs.com.
> Escape character is '^]'.
> GET /sources/contrib/ HTTP/1.1
> Host: plan9.bell-labs.com
> Connection: keep-alive
> Cache-Control: max-age=0
> Upgrade-Insecure-Requests: 1
> Accept: 
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> DNT: 1
> Accept-Encoding: gzip, deflate, sdch
> Accept-Language: en-US,en;q=0.8
> 
> HTTP/1.1 200 OK
> Server: Plan9
> Date: Sun, 02 Oct 2016 17:29:09 GMT
> Connection: close
> Last-Modified: Fri, 14 Mar 2014 22:14:11 GMT
> Content-Type: text/html
> 
> [... proper body returned...]
> 
> I tried playing around with the UA value and found that if I change 
> AppleWebKit to something else such as AppleWebKis I get a
> response...
> 
> Jim
> 

Re: [9fans] bug in authdial()

[arisawa]

hello skip,

it is too late but I should say many thanks.

> 2016/05/21 7:04、Skip Tavakkolian <9...@9netics.com> のメール：
> 
> supermic% time ./cpu -h grid.nyx.link -k 'dom=outside.plan9.bell-labs.com' -c 
> pwd
> dial took: 165268068 ns
> negotiate auth took: 159047373 ns
> factotum autenticate took: 699255914 ns
> lclnoteproc time: 702945750 ns
> far end setup time: 157257845 ns
> /usr/fst
> 0.00u 0.00s 7.58r  ./cpu -h grid.nyx.link -k 
> dom=outside.plan9.bell-labs.com ...
> supermic%  time ./cpu -h grid.nyx.link -k 'dom=outside.plan9.bell-labs.com' 
> -c pwd
> dial took: 158312233 ns
> negotiate auth took: 155598573 ns
> factotum autenticate took: 681558002 ns
> lclnoteproc time: 684863443 ns
> far end setup time: 151972579 ns
> /usr/fst
> 0.00u 0.01s 7.22r  ./cpu -h grid.nyx.link -k 
> dom=outside.plan9.bell-labs.com ...
> supermic%  time ./cpu -h grid.nyx.link -k 'dom=outside.plan9.bell-labs.com' 
> -c pwd
> dial took: 176752321 ns
> negotiate auth took: 175402567 ns
> factotum autenticate took: 746787405 ns
> lclnoteproc time: 749881615 ns
> far end setup time: 172600395 ns
> /usr/fst
> 0.00u 0.03s 8.17r  ./cpu -h grid.nyx.link -k 
> dom=outside.plan9.bell-labs.com ...
> supermic% 
> 
> 

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?

Re: [9fans] bug in authdial()

[arisawa]

parallel dialing would be fine.
I guess both cinap and erik have examined labs code.
any problem with it?

> 2016/05/21 7:25、Charles Forsyth  のメール：
> 
> 
> 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

Re: [9fans] bug in authdial()

[arisawa]

I am sorry that I didn’t give enough information but I din’t know there is so 
much difference
on the subject among 9front, 9atom and labs plan9.

> 2016/05/21 7:04、Skip Tavakkolian <9...@9netics.com> のメール：
> 
> i'm a little confused by the discussion of ...

Re: [9fans] bug in authdial()

[arisawa]

nice idea.
I’ve put an option to cs so that il isn’t listed first.

> 2016/05/20 0:48、Charles Forsyth  のメール：
> 
> It's not just il. There are other networks, other protocols, other than tcp 
> and IP.
> It's one of the advantages of plan 9 that it's easy to try and use new ones.
> cs could present a different search list when there's only one way to get 
> somewhere.
> as a quick fix for everything, if you're not using il, remove it from the 
> list in ndb/cs.c, and cs won't suggest it.
> 
> 
> On 19 May 2016 at 16:43,  wrote:
> > cinap is right but I wonder if we should take care of IL forever.
> 
> Yes.
> 
> Lucio.
> 
> 
> 

Re: [9fans] bug in authdial()

[arisawa]

cinap is right but I wonder if we should take care of IL forever.

> 2016/05/18 18:14、cinap_len...@felloff.net のメール：
> 
> yes, passing netroot to netmkaddr() is wrong. however, i dont see where
> we pass anything other than netroot=nil to authdial().
> 
> i suspect what you'r experiencing is that dial() tried IL first (with
> !fasttimeout option), which fails and then tries TCP causing the delay.
> 
> so you changing it to try tcp first gets rid of the delay (but will break
> the unlikely case where you got an authserver running on IL only as tcp
> has no fast timeout option).
> 
> --
> cinap
> 

Re: [9fans] bug in authdial()

[arisawa]

hello,

thanks for the information.
the lookup depends on dns cache but I also don’t think it has a problem.
I think the negotiation process is innocent.
plan9 auth negotiation is fairly simple, that needs only a single step:
C→A:  ticket request
A→C:  encrypted ticket
I measured the times that are required for the auth server to complete the 
ticket request.
they are only a few milliseconds.

dialing time from client  to auth server is the problem.


> 2016/05/19 2:03、Skip Tavakkolian <skip.tavakkol...@gmail.com> のメール：
> 
> i don't think it's the auth lookup:
> 
> supermic% time ndb/csquery /net/cs net!luna.nyx.link!ticket
> /net/tcp/clone 115.36.102.252!567
> /net/tcp/clone 2402:6b00:4040:b600::8!567
> 0.00u 0.00s 0.34r  ndb/csquery /net/cs net!luna.nyx.link!ticket
> supermic% time ndb/csquery /net/cs net!grid.nyx.link!cpu
> /net/tcp/clone 115.36.102.252!17010
> /net/tcp/clone 2402:6b00:4040:b600::9!17010
> 0.00u 0.00s 0.01r  ndb/csquery /net/cs net!grid.nyx.link!cpu
> supermic% 
> 
> i suspect it's auth negotiations.
> 
> 
> 
> On Wed, May 18, 2016 at 6:07 AM Charles Forsyth <charles.fors...@gmail.com> 
> wrote:
> 
> On 18 May 2016 at 01:43, arisawa <aris...@ar.aichi-u.ac.jp> wrote:
> -   p = netmkaddr(nt->val, netroot, "ticket");
> rv = dial(p, 0, 0, 0);
> if(rv >= 0)
> break;
> 
> +   p = netmkaddr(nt->val, “tcp", "ticket");
> rv = dial(p, 0, 0, 0);
> if(rv >= 0)
> break;
> +   p = netmkaddr(nt->val, “il", "ticket");
> +   rv = dial(p, 0, 0, 0);
> +   if(rv >= 0)
> +   break;
> 
> But that's just (eventually) moving the cs search into every application and 
> bound to specific network types.
> Why is the cs search with "net" so slow?

Re: [9fans] cpu command latency

[arisawa]

Hello,

fixing authdial bug I got remarkable result.

I measured using mobile wireless network (the bandwidth is a few tens mega bps).

before fixing:
0.00u 0.00s 44.73r   cpu -h grid.nyx.link -k 
dom=outside.plan9.bell-labs.com ...
0.00u 0.00s 9.35rcpu -h grid.nyx.link -k 
dom=outside.plan9.bell-labs.com ...
0.00u 0.01s 9.39rcpu -h grid.nyx.link -k 
dom=outside.plan9.bell-labs.com ...

after fixing:
0.00u 0.01s 14.59r   cpu -h tcp!grid.nyx.link -k dom=luna.nyx.link ...
0.00u 0.04s 7.65rcpu -h tcp!grid.nyx.link -k dom=luna.nyx.link ...
0.00u 0.00s 7.51rcpu -h tcp!grid.nyx.link -k dom=luna.nyx.link ...

you need to recompile libauthsrv, factotum and kernel.
I am happy if anyone send me data from outside of japan.
putting “tcp!” is clumsy. fixing cpu.c is also desirable.

p.s. thanks skip for the suggestion.

Kenji Arisawa

> 2016/05/14 22:30、arisawa <aris...@ar.aichi-u.ac.jp> のメール：
> 
> Hello
> 
> this is a partial report of cpu command latency.
> 
> we have code below in rexcall() of cpu.c 
> 
>   na = netmkaddr(host, 0, service);
>   //na = netmkaddr(host, “tcp”, service);//DBG
>   syslog(0,"cpu","rexcall:netmkaddr %lld μsec; 
> %s",(nsec()-t0)/1000,na);//DBG
>   procsetname("dialing %s", na);
>   syslog(0,"cpu","rexcall:dialing %lld μsec; 
> %s",(nsec()-t0)/1000,na);//DBG
>   if((*fd = dial(na, 0, devdir, 0)) < 0)
>   return "can't dial";
>   syslog(0,"cpu","rexcall:dial %lld μsec",(nsec()-t0)/1000);//DBG
> 
> lines with “DBG” are code added for measurement.
> looking the result I found dial() takes as much as on second in my home 
> network!
> 
>   vbt May 14 21:27:52 rexcall:netmkaddr 122 μsec; net!io!ncpu
>   vbt May 14 21:27:52 rexcall:dialing 592 μsec; net!io!ncpu
>   vbt May 14 21:27:53 rexcall:dial 1161556 μsec
> 
>   vbt May 14 21:27:57 rexcall:netmkaddr 677 μsec; net!io!ncpu
>   vbt May 14 21:27:57 rexcall:dialing 1082 μsec; net!io!ncpu
>   vbt May 14 21:27:58 rexcall:dial 1109949 μsec
> 
> replacing
>   na = netmkaddr(host, 0, service);
> by
>   na = netmkaddr(host, “tcp”, service);
> we get much better performance as shown below.
>   vbt May 14 22:21:18 rexcall:netmkaddr 489 μsec; tcp!io!ncpu
>   vbt May 14 22:21:18 rexcall:dialing 861 μsec; tcp!io!ncpu
>   vbt May 14 22:21:18 rexcall:dial 3099 μsec
> 
>   vbt May 14 22:21:22 rexcall:netmkaddr 565 μsec; tcp!io!ncpu
>   vbt May 14 22:21:22 rexcall:dialing 977 μsec; tcp!io!ncpu
>   vbt May 14 22:21:22 rexcall:dial 7287 μsec
> 
> isn’t it better the default net be “tcp”?
> even if you do want “net”, you can do
>   cpu -h net!host 
> 
> Kenji Arisawa
> 
> 
> 
>> 2016/05/13 0:40、Skip Tavakkolian <skip.tavakkol...@gmail.com> のメール：
>> 
>> it might be worth instrumenting the cpu command to time the authenticaiton 
>> step. i think that's where the problem is.
>> 
>> On Wed, May 11, 2016 at 3:39 PM Skip Tavakkolian 
>> <skip.tavakkol...@gmail.com> wrote:
>> what's the latency caused by the auth step?
>> FYI, from Seattle I see about 8 seconds to establish but as Charles noted, 
>> it's reasonably fast after that.
>> 
>> 
>> On Wed, May 11, 2016 at 2:05 PM arisawa <aris...@ar.aichi-u.ac.jp> wrote:
>> Hello,
>> 
>> we can measure the latency that comes from network connection
>> by executing simple program such as telnet or something others
>> to the port 8006 of grid.nyx.link. the content is:
>> #!/bin/rc
>> cat $net/local
>> cat $net/remote
>> 
>> yes the DNS may make a problem in IPv4/IPv6 mixed environment.
>> my server supports both IPs.
>> the cpu command will select IPv4. the command does not have “-6” option.
>> If we want to connect by IPv6, literal IP address is required in the 
>> argument of the command.
>> 
>> Kenji Arisawa
>> 
>>> In my experience, it's almost unfailingly the DNS that slows down
>>> establishing an Internet session of any type.
>>> 
>>> Lucio.
>> 
>>> 2016/05/12 0:23、Kenny Lasse Hoff Levinsen <kennylevin...@gmail.com> のメール：
>>> 
>>> Well, based on the 9fs test that was posted, I'd think dial is being 
>>> awfully slow.
>>> 
>>> Maybe try something simpler? aux/listen1 echo hello and a simple network 
>>> connection?
>>> 
>>> Best regards,
>>> Kenny Levinsen
>>> 
>>> On 11. maj 2016, at 16.13, Charles Forsyth <charles.fors...@gmail.com> 
>>> wrote:
>>> 
>>>> 
>>>> On 11 May 2016 at 14:44, Kenny Lasse Hoff Levinsen 
>>>> <kennylevin...@gmail.com> wrote:
>>>> Delete the channel from /srv in the loop to test a full remote mount 
>>>> dance, including the initial dial. It shouldn't take 3s to dial, though.
>>>> 
>>>> There's something initially slow in connecting to  grid.nyx.link with cpu, 
>>>> and setting up, but once there it's fine.
>> 
>> 
> 
> 

[9fans] bug in authdial()

[arisawa]

Hello,

authdial() is slow. so I have inspected the code:
/sys/src/libauthsrv/authdial.c
I suspect netroot causes the problem.

int
authdial(char *netroot, char *dom)
{
[snip]

if(dom == nil)
/* look for one relative to my machine */
return dial(netmkaddr("$auth", netroot, "ticket"), 0, 0, 0);

/* look up an auth server in an authentication domain */
p = csgetvalue(netroot, "authdom", dom, "auth", );

/* if that didn't work, just try the IP domain */
if(p == nil)
p = csgetvalue(netroot, "dom", dom, "auth", );

[snip]

for(nt = t; nt != nil; nt = nt->entry) {
if(strcmp(nt->attr, "auth") == 0) {
p = netmkaddr(nt->val, netroot, "ticket");
rv = dial(p, 0, 0, 0);
if(rv >= 0)
break;
}
}

[snip]
}

man authsrv(2) says:
the default of netroot in authdial(char *netroot, char *ad) is “/net”
and consistent with the synopsis of csgetvalue(char *netroot, char *attr, char 
*val,….).

on the other hand the synopsis of netmkaddr is
char* netmkaddr(char *addr, char *defnet, char *defservice)
the defnet takes values nil, “tcp”, “il”, etc.

as the result, netroot in the first argument of authdial() works only if it is 
nil, which makes authdial()
very slow.

I think that should be fixed for example:

-   p = netmkaddr(nt->val, netroot, "ticket");
rv = dial(p, 0, 0, 0);
if(rv >= 0)
break;

+   p = netmkaddr(nt->val, “tcp", "ticket");
rv = dial(p, 0, 0, 0);
if(rv >= 0)
break;
+   p = netmkaddr(nt->val, “il", "ticket");
+   rv = dial(p, 0, 0, 0);
+   if(rv >= 0)
+       break;


NOTE that
return dial(netmkaddr("$auth", netroot, "ticket"), 0, 0, 0);
should be also fixed.

Kenji Arisawa

Re: [9fans] cpu command latency

[arisawa]

Hello

this is a partial report of cpu command latency.

we have code below in rexcall() of cpu.c 

na = netmkaddr(host, 0, service);
//na = netmkaddr(host, “tcp”, service);//DBG
syslog(0,"cpu","rexcall:netmkaddr %lld μsec; 
%s",(nsec()-t0)/1000,na);//DBG
procsetname("dialing %s", na);
syslog(0,"cpu","rexcall:dialing %lld μsec; 
%s",(nsec()-t0)/1000,na);//DBG
if((*fd = dial(na, 0, devdir, 0)) < 0)
return "can't dial";
syslog(0,"cpu","rexcall:dial %lld μsec",(nsec()-t0)/1000);//DBG

lines with “DBG” are code added for measurement.
looking the result I found dial() takes as much as on second in my home network!

vbt May 14 21:27:52 rexcall:netmkaddr 122 μsec; net!io!ncpu
vbt May 14 21:27:52 rexcall:dialing 592 μsec; net!io!ncpu
vbt May 14 21:27:53 rexcall:dial 1161556 μsec

vbt May 14 21:27:57 rexcall:netmkaddr 677 μsec; net!io!ncpu
vbt May 14 21:27:57 rexcall:dialing 1082 μsec; net!io!ncpu
vbt May 14 21:27:58 rexcall:dial 1109949 μsec

replacing
na = netmkaddr(host, 0, service);
by
na = netmkaddr(host, “tcp”, service);
we get much better performance as shown below.
vbt May 14 22:21:18 rexcall:netmkaddr 489 μsec; tcp!io!ncpu
vbt May 14 22:21:18 rexcall:dialing 861 μsec; tcp!io!ncpu
vbt May 14 22:21:18 rexcall:dial 3099 μsec

vbt May 14 22:21:22 rexcall:netmkaddr 565 μsec; tcp!io!ncpu
vbt May 14 22:21:22 rexcall:dialing 977 μsec; tcp!io!ncpu
vbt May 14 22:21:22 rexcall:dial 7287 μsec

isn’t it better the default net be “tcp”?
even if you do want “net”, you can do
cpu -h net!host 

Kenji Arisawa



> 2016/05/13 0:40、Skip Tavakkolian <skip.tavakkol...@gmail.com> のメール：
> 
> it might be worth instrumenting the cpu command to time the authenticaiton 
> step. i think that's where the problem is.
> 
> On Wed, May 11, 2016 at 3:39 PM Skip Tavakkolian <skip.tavakkol...@gmail.com> 
> wrote:
> what's the latency caused by the auth step?
> FYI, from Seattle I see about 8 seconds to establish but as Charles noted, 
> it's reasonably fast after that.
> 
> 
> On Wed, May 11, 2016 at 2:05 PM arisawa <aris...@ar.aichi-u.ac.jp> wrote:
> Hello,
> 
> we can measure the latency that comes from network connection
> by executing simple program such as telnet or something others
> to the port 8006 of grid.nyx.link. the content is:
> #!/bin/rc
> cat $net/local
> cat $net/remote
> 
> yes the DNS may make a problem in IPv4/IPv6 mixed environment.
> my server supports both IPs.
> the cpu command will select IPv4. the command does not have “-6” option.
> If we want to connect by IPv6, literal IP address is required in the argument 
> of the command.
> 
> Kenji Arisawa
> 
> > In my experience, it's almost unfailingly the DNS that slows down
> > establishing an Internet session of any type.
> >
> > Lucio.
> 
> > 2016/05/12 0:23、Kenny Lasse Hoff Levinsen <kennylevin...@gmail.com> のメール：
> >
> > Well, based on the 9fs test that was posted, I'd think dial is being 
> > awfully slow.
> >
> > Maybe try something simpler? aux/listen1 echo hello and a simple network 
> > connection?
> >
> > Best regards,
> > Kenny Levinsen
> >
> > On 11. maj 2016, at 16.13, Charles Forsyth <charles.fors...@gmail.com> 
> > wrote:
> >
> >>
> >> On 11 May 2016 at 14:44, Kenny Lasse Hoff Levinsen 
> >> <kennylevin...@gmail.com> wrote:
> >> Delete the channel from /srv in the loop to test a full remote mount 
> >> dance, including the initial dial. It shouldn't take 3s to dial, though.
> >>
> >> There's something initially slow in connecting to  grid.nyx.link with cpu, 
> >> and setting up, but once there it's fine.
> 
> 

Re: [9fans] cpu command latency

[arisawa]

thanks skip for the information.

> 2016/05/12 7:39、Skip Tavakkolian <skip.tavakkol...@gmail.com> のメール：
> FYI, from Seattle I see about 8 seconds to establish but as Charles noted, 
> it's reasonably fast after that.

I am glad if you can show me the raw data measured by
for(i in 1 2 3){
time cpu -h HOST -k ‘dom=DOM’ -c pwd
sleep 3
}

thanks in advance.
Kenji Arisawa

Re: [9fans] cpu command latency

[arisawa]

Hello,

> 2016/05/11 22:44、Kenny Lasse Hoff Levinsen <kennylevin...@gmail.com> のメール：
> 
> Delete the channel from /srv in the loop to test a full remote mount dance, 
> including the initial dial. It shouldn't take 3s to dial, though.
thanks for the advice.
I retried

for(i in 1 2 3){
time 9fs $host
#unmount /n/$host
rm /srv/$host
sleep 3
}

term% try -m sources outside.plan9.bell-labs.com arisawa
post...
0.00u 0.01s 1.31r9fs sources
post...
0.00u 0.03s 0.69r9fs sources
post...
0.00u 0.00s 0.58r9fs sources
term% 

term% try -m sources outside.plan9.bell-labs.com arisawa
post...
0.00u 0.01s 1.30r9fs sources
post...
0.00u 0.01s 0.60r9fs sources
post...
0.00u 0.01s 0.55r9fs sources
term% 

for(i in 1 2 3){
time 9fs $host
unmount /n/$host
#rm /srv/$host
sleep 3
}

term% try -m sources outside.plan9.bell-labs.com arisawa
post...
0.00u 0.00s 1.25r9fs sources
0.00u 0.01s 0.18r9fs sources
0.00u 0.00s 0.19r9fs sources
term% 

term% try -m sources outside.plan9.bell-labs.com arisawa
post...
0.00u 0.00s 1.26r9fs sources
0.00u 0.00s 0.19r9fs sources
0.00u 0.01s 0.20r9fs sources
term% 

the values reported yesterday are:
0.00u 0.00s 3.73r9fs sources
0.00u 0.00s 0.71r9fs sources
0.00u 0.00s 0.21r9fs sources
which shows mount latency depends much on the network condition.

Re: [9fans] cpu command latency

[arisawa]

Hello,

we can measure the latency that comes from network connection
by executing simple program such as telnet or something others
to the port 8006 of grid.nyx.link. the content is:
#!/bin/rc
cat $net/local
cat $net/remote

yes the DNS may make a problem in IPv4/IPv6 mixed environment.
my server supports both IPs.
the cpu command will select IPv4. the command does not have “-6” option.
If we want to connect by IPv6, literal IP address is required in the argument 
of the command.

Kenji Arisawa

> In my experience, it's almost unfailingly the DNS that slows down
> establishing an Internet session of any type.
> 
> Lucio.

> 2016/05/12 0:23、Kenny Lasse Hoff Levinsen <kennylevin...@gmail.com> のメール：
> 
> Well, based on the 9fs test that was posted, I'd think dial is being awfully 
> slow.
> 
> Maybe try something simpler? aux/listen1 echo hello and a simple network 
> connection?
> 
> Best regards,
> Kenny Levinsen
> 
> On 11. maj 2016, at 16.13, Charles Forsyth <charles.fors...@gmail.com> wrote:
> 
>> 
>> On 11 May 2016 at 14:44, Kenny Lasse Hoff Levinsen <kennylevin...@gmail.com> 
>> wrote:
>> Delete the channel from /srv in the loop to test a full remote mount dance, 
>> including the initial dial. It shouldn't take 3s to dial, though.
>> 
>> There's something initially slow in connecting to  grid.nyx.link with cpu, 
>> and setting up, but once there it's fine.

Re: [9fans] cpu command latency

[arisawa]

thanks charles for your quick response.

the times below are mount latency just after rebooting.
the first is much larger than others.
0.00u 0.00s 3.73r9fs sources
0.00u 0.00s 0.71r9fs sources
0.00u 0.00s 0.21r9fs sources
with the script below:
for(i in 1 2 3){
time 9fs $host
unmount /n/$host
sleep 3
}
}

probably cpu command latency will show similar behavior with much more time.

Kenji Arisawa

[9fans] cpu command latency

[arisawa]

Hello,

some people say that cpu command latency will be so big that world wide grid 
computing using cpu command will be useless because of the latency. 
unfortunately I don’t have experimental data.
it seems bell-labs grid servers are now closed.
latency data between japan and other country will be enough.

I want to have those times:
for(i in 1 2 3){
time cpu -h HOST -k ‘dom=DOM’ -c pwd
sleep 3
}
they are cache sensitive. therefore, we need to restart the plan9 terminal in 
the experiment.
if there are open grid servers for 9fans, I would do myself. let me know if you 
know, please.
I am also happy if someone give me data by accessing my grid server.
then the HOST is grid.nyx.link and the DOM is outside.plan9.bell-labs.com and 
need your bell-labs key in factotum.

thanks in advance.
Kenji Arisawa

Re: [9fans] 9Cloud Source

[arisawa]

where is patch on http://9p.io/ ?
there are your patch on sources

grid% ls -l /n/sources/patch/syscall-*
--rw-rw-r-- M 105 fst sys 35842 Mar 17 09:52 
/n/sources/patch/syscall-exportfs/chan.c
--rw-rw-r-- M 105 fst sys 35357 Mar 17 09:52 
/n/sources/patch/syscall-exportfs/chan.c.orig
--rw-rw-rw- M 105 fst sys27 Mar 17 09:51 
/n/sources/patch/syscall-exportfs/email
--rw-rw-r-- M 105 fst sys 25215 Mar 17 09:52 
/n/sources/patch/syscall-exportfs/exportfs.c
--rw-rw-r-- M 105 fst sys   306 Mar 17 09:52 
/n/sources/patch/syscall-exportfs/files
--rw-rw-r-- M 105 fst sys 20634 Mar 17 09:51 
/n/sources/patch/syscall-exportfs/libc.h
--rw-rw-r-- M 105 fst sys 20598 Mar 17 09:51 
/n/sources/patch/syscall-exportfs/libc.h.orig
--rw-rw-r-- M 105 fst sys  4594 Mar 17 09:52 
/n/sources/patch/syscall-exportfs/mkfile
--rw-rw-r-- M 105 fst sys  4580 Mar 17 09:52 
/n/sources/patch/syscall-exportfs/mkfile.orig
--rw-rw-r-- M 105 fst sys 0 Mar 17 09:51 
/n/sources/patch/syscall-exportfs/notes
--rw-rw-r-- M 105 fst sys 23608 Mar 17 09:52 
/n/sources/patch/syscall-exportfs/portdat.h
--rw-rw-r-- M 105 fst sys 23541 Mar 17 09:52 
/n/sources/patch/syscall-exportfs/portdat.h.orig
--rw-rw-r-- M 105 fst sys 11501 Mar 17 09:52 
/n/sources/patch/syscall-exportfs/portfns.h
--rw-rw-r-- M 105 fst sys 11440 Mar 17 09:52 
/n/sources/patch/syscall-exportfs/portfns.h.orig
--rw-rw-r-- M 105 fst sys   229 Mar 17 09:53 
/n/sources/patch/syscall-exportfs/readme
--rw-rw-r-- M 105 fst sys   986 Mar 17 09:52 
/n/sources/patch/syscall-exportfs/sys.h
--rw-rw-r-- M 105 fst sys   967 Mar 17 09:52 
/n/sources/patch/syscall-exportfs/sys.h.orig
--rw-rw-r-- M 105 fst sys  8853 Mar 17 09:52 
/n/sources/patch/syscall-exportfs/syscallfmt.c
--rw-rw-r-- M 105 fst sys  8853 Mar 17 09:52 
/n/sources/patch/syscall-exportfs/syscallfmt.c.orig
--rw-rw-r-- M 105 fst sys  3403 Mar 17 09:52 
/n/sources/patch/syscall-exportfs/systab.h
--rw-rw-r-- M 105 fst sys  3341 Mar 17 09:52 
/n/sources/patch/syscall-exportfs/systab.h.orig
grid% 

> 2016/03/17 10:16、Skip Tavakkolian  のメール：
> 
> I couldn't find it on 9p.io, so I'm not sure what happened. I recall that I 
> screwed up the first two attempts and had to ask David to clean them up for 
> me.
> 
> Anyhow, I submitted the patch to Labs' sources a few minutes ago: 
> /n/sources/patch/syscall-exportfs
> 
> 
> On Wed, Mar 16, 2016 at 5:18 PM Skip Tavakkolian  
> wrote:
> i mean "syscall-exportfs"
> 
> 
> On Wed, Mar 16, 2016 at 5:10 PM Skip Tavakkolian  
> wrote:
> i submitted the patch to 9p.io some time ago; it was under "syscall-exprotfs".
> 
> 
> On Wed, Mar 16, 2016 at 4:16 PM hiro <23h...@gmail.com> wrote:
> Hello Skip, is there a way I could receive the patch for export?
> 
> On 7/15/15, Skip Tavakkolian <9...@9netics.com> wrote:
> > assuming you mean 9PCloud (otherwise ignore this):
> >
> > i plan to put the 9P javascript sources on github or bitbucket.  you
> > can view the sources using the debugger in chrome.  they're all
> > dual-licensed (MIT and GPLv2).  i also plan to make a simple version
> > of the namespace "janitor" (brucee coined the term) that uses factotum
> > handle auth.  it will be in the same source repo.
> >
> > the backend uses a custom Plan 9 cpu that includes the "export"
> > (exportfs) system call.  the patch for export was submitted to all
> > fronts, popular or otherwise (Labs, 9p.io, 9atom, 9front).
> >
> >> Hi guys,
> >>
> >> Was wondering if the source of 9Cloud was available for perusal? Just
> >> logged in, looks great!
> >>
> >> Many thanks!
> >>
> >> Shane.
> >
> >
> >
> 

Re: [9fans] rtl8169 gbe slow

[arisawa]

hello,

rtl8169 is popular in cheap MB, so it is installed in my many MBs.
however, cat /dev/kmesg claims:
rtl8169: oui 0x732 phyno 1, macv = 0x3c00 phyv = 0x0002
#l0: rtl8169: 100Mbps port 0xD000 irq 10: 001fd0169891

the “100Mbps" in the message is correct or not?

I also feel rtl8169 is slow, so I replace on-board rtl8169 by intel’s card  if 
possible.



> 2016/02/18 22:22、erik quanstrom  のメール：
> 
> the 8169 driver is pretty fast.  I've measured it at more than 500mbps.
> it sounds like something else is misbehaving.  what does
> /dev/irqstat say.  I bet something is stuck.
> 
> - erik
> 
> 
> On Feb 18, 2016 3:30 AM, tlaro...@polynum.com wrote:
>> 
>> Hello, 
>> 
>> I have finally managed to install plan9 on my new workstation. 
>> 
>> By putting back the keyboard on the PS2 connector, I have solved some 
>> unfelicities (with the USB->legacy emulation, the keyboard switched 
>> every other typing to UPPERCASE...). 
>> 
>> The mouse, still USB connected and hence "emulated" by the BIOS, 
>> does not react very gracefully but I will see if I can play with 
>> the acceleration and the resolution to have a better terminal. (Or 
>> if I manage to find a long enough cable to have a COM slot back since 
>> there is the bare connector on the motherboard; in this case I will go 
>> back to a com mouse and will be able to probe USB for other 
>> devices---external disks.) 
>> 
>> One thing is inconvenient: I have a rtl8169 gbe pci-e ether card, but 
>> when testing the compilation of kerTeX (it has been fixed: it works for 
>> the last release; rio to come for METAFONT), the throughput with hget is 
>> abysmal: 30kB/s... The disk is not a fault, reacting well enough (I have 
>> plenty of RAM and the blocks cache for fossil is set to 3000---it could 
>> be obviously higher). 
>> 
>> Setting the mtu to jumbo packet does not help. 
>> 
>> Is there something to tune or is it simply that the chip is not well 
>> supported? 
>> 
>> TIA 
>> -- 
>> Thierry Laronde  
>>  http://www.kergis.com/ 
>>  http://www.arts-po.fr/ 
>> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C 
>> 
>> 

Re: [9fans] file descriptor leak

[arisawa]

the logic (code? usage?) of system(int fd, char *cmd) is ugly.
thanks for fixing, cinap.

charies may be speaking right point, because the dns server is running only for 
my home use.
only my family uses the dns service. my home network is very simple.I have 
never used /net.alt for that.

the dns had been running on file server and sometimes (once a month or so) 
failed into trouble.
a few weeks ago, I separated it from file server so that I can see the trouble 
really comes from dns.

the contents of /proc/N/fs are shown below.
it seems /dev/null is not the criminal as charies suggested.
how to find fd leakage?

thanks in advance


io% ps|grep dns
arisawa 2480:00   0:00  348K Awaitdns
arisawa 2490:00   0:0014584K Preaddns
arisawa 2500:12   0:1214576K Preaddns
io% cat /proc/^(248 249 250)^/fd
/usr/arisawa
  0 r  M8 (0005 0 00)  81921 /dev/cons
  1 w  c0 (0002 0 00) 01 #c/cons
  2 w  c0 (0002 0 00) 0  193 #c/cons
  3 r  c0 (000f 0 00) 04 /dev/random
  4 w  M   22 (ce7e 54050 40)  8192  1098023 /sys/log/dns
  5 r  c0 (0001 0 00) 0  6873616 /dev/bintime
  6 r  M   22 (929e 3098 00)  819210949 /lib/ndb/local
  7 r  M   22 (929b 47 00)  819210242 /lib/ndb/common
  8 r  I0 (0004 3 00) 0  127 /net/ndb
  9 rw |0 (0fc1 0 00) 65536 3954 #|/data
 11 w  s0 (0009 0 00) 02 #s/dns
/usr/arisawa
  0 r  M8 (0005 0 00)  81921 /dev/cons
  1 w  c0 (0002 0 00) 01 #c/cons
  2 w  c0 (0002 0 00) 0  193 #c/cons
  3 r  c0 (000f 0 00) 04 /dev/random
  4 w  M   22 (ce7e 54050 40)  8192  1098023 /sys/log/dns
  5 r  c0 (0001 0 00) 0  6873816 /dev/bintime
  6 r  M   22 (929e 3098 00)  819210949 /lib/ndb/local
  7 r  M   22 (929b 47 00)  819210242 /lib/ndb/common
  8 r  I0 (0004 3 00) 0  127 /net/ndb
  9 rw |0 (0fc1 0 00) 65536 3954 #|/data
 11 w  s0 (0009 0 00) 02 #s/dns
 12 rw I0 (0002002d 0 00) 0 3362 /net/udp/1/data
/usr/arisawa
  0 r  M8 (0005 0 00)  81921 /dev/cons
  1 w  c0 (0002 0 00) 01 #c/cons
  2 w  c0 (0002 0 00) 0  193 #c/cons
  3 r  c0 (000f 0 00) 04 /dev/random
  4 w  M   22 (ce7e 54050 40)  8192  1098023 /sys/log/dns
  5 r  c0 (0001 0 00) 0  6873824 /dev/bintime
  6 r  M   22 (929e 3098 00)  819210949 /lib/ndb/local
  7 r  M   22 (929b 47 00)  819210242 /lib/ndb/common
  8 r  I0 (0004 3 00) 0  127 /net/ndb
  9 rw |0 (0fc1 0 00) 65536 3954 #|/data
 11 w  s0 (0009 0 00) 02 #s/dns
 12 rw I0 (0002002d 0 00) 0 3362 /net/udp/1/data
io% 


> 2016/02/17 7:24、Charles Forsyth <charles.fors...@gmail.com> のメール：
> 
> 
> On 16 February 2016 at 15:52, arisawa <aris...@ar.aichi-u.ac.jp> wrote:
> 
> I have observed warning messages from dns server:
> dns 30792: warning process exceeded 100 file descriptors
> dns 30888: warning process exceeded 200 file descriptors
> 
> It's worth noting that this message doesn't necessarily mean you've got a 
> file descriptor leak.
> It might, but at the start it just means that a process (or process group 
> sharing a file descriptor group) has many file descriptors open.
> That could happen if a server with many clients has a file descriptor per 
> client and then client requests open some more.
> 
> ndb/dns in particular will try user-level requests in parallel, and those in 
> turn can lead to several concurrent
> queries to various name servers at a given level (root itself has 13). Web 
> browser clients will fetch page
> elements concurrently. That's why it's useful to check the /proc/N/fd file to 
> try to see what they are.
> (Not just for ndb/dns, but for other applications that provoke the message.)
> Arguably, if you're using the system in a real, Internet-facing application, 
> the warning message might
> be obsolete, compared to the time when even 100 clients was a big network.

[9fans] file descriptor leak

[arisawa]

Hello,

I have observed warning messages from dns server:
dns 30792: warning process exceeded 100 file descriptors
dns 30888: warning process exceeded 200 file descriptors
…

probably the file descriptor leak comes from dnresolve.c

udpquery(Query *qp, char *mntpt, int depth, int patient, int inns)
{
…
msg = system(open("/dev/null", ORDWR), "outside");
…
}

char *
system(int fd, char *cmd)
{
int pid, p, i;
static Waitmsg msg;

if((pid = fork()) == -1)
sysfatal("fork failed: %r");
else if(pid == 0){
dup(fd, 0);
close(fd);
for (i = 3; i < 200; i++)
close(i);   /* don't leak fds */
execl("/bin/rc", "rc", "-c", cmd, nil);
sysfatal("exec rc: %r");
}
for(p = waitpid(); p >= 0; p = waitpid())
if(p == pid)
return msg.msg;
return "lost child";
}

fd is lost if pid > 0

my server is running on 9front. however both 9atom and bell-labs use same 
routine.

Kenji Arisawa

Re: [9fans] 9pfuse and u9fs

[arisawa]

thanks for your reply.

the server mmac is mac and mountable from plan9 using 9fs.
auth method is set to p9any in u9fs setting.
In the experiment, I once (and only once) requested password

-bash$ 9fs mmac

!adding key: role=client proto=p9sk1 dom=mmac
user[arisawa]: 
password: 
!
authdial: Connection refused
-bash$ 

I don’t know why I am refused.
the password is probably registered to factotum

-bash$ 9 mount /srv/factotum /mnt/factotum
-bash$ cat /mnt/factotum/ctl
key dom=mmac proto=p9sk1 role=client user=arisawa !password?
-bash$

however

-bash$ 9pfuse /srv/mmac /n/mmac
9pfuse: fsmount: fid unknown or out of range
-bash$

has anyone experienced similar problem?



> 2016/02/16 20:51、David Arroyo <dr...@aqwari.net> のメール：
> 
> I have definitely used 9pfuse to mount a u9fs file server before. What auth 
> method did you choose for u9fs?
> 
> David 
> 
> On February 16, 2016 5:20:51 AM EST, arisawa <aris...@ar.aichi-u.ac.jp> wrote:
> Hello 9fans,
> 
> my 9pfuse on macbook works fine in communicating plan9 file server.
> however mounting u9fs fails with the message:
> -bash$ 9pfuse /srv/mmac /n/mmac
> 9pfuse: fsmount: fid unknown or out of range
> -bash$ 
> how to understand this message?
> does anyone succeed in mounting u9fs?
> 
> it would be great if 9pfuse can mount u9fs
> 
> Kenji Arisawa
> 
> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

[9fans] 9pfuse and u9fs

[arisawa]

Hello 9fans,

my 9pfuse on macbook works fine in communicating plan9 file server.
however mounting u9fs fails with the message:
-bash$ 9pfuse /srv/mmac /n/mmac
9pfuse: fsmount: fid unknown or out of range
-bash$ 
how to understand this message?
does anyone succeed in mounting u9fs?

it would be great if 9pfuse can mount u9fs

Kenji Arisawa

[9fans] mirror of sources of bell-labs

[arisawa]

Hello 9fans,

I added mirror page of sources of bell-labs.
look http://p9.nyx.link/sources
I am afraid the page has a problem with copyright or something else.
if so, please inform me.
I will remove them if necessary.

Kenji Arisawa

Re: [9fans] bug in exportfs

[arisawa]

Hello,

> 2016/02/15 7:57、Charles Forsyth  のメール：
> 
> 
> On 14 February 2016 at 16:38,  wrote:
> i could imagine the filtering being usefull when cpu'ing to foreign machines,
> as a server can easily compromize your system when cpu exports your whole
> local namespace
> 
> You'd still be better off using a custom nsfile to control it, running that 
> cpu in
> a more restricted name space from the start, so leaks are impossible.

filtering of exportfs is handy if it works well.
for example, assume we want to exclude all files of name that begins with “.”,
then it is probably difficult to do so using only nsfile.

the “+” filtering is almost useless.
it will not be difficult to rewrite the current code so that we have better 
matching rule.
(I think ordering of pattern sequence should be used in evaluation.)
however the change may break something others.
(but I doubt the “+” filtering is really used)

Re: [9fans] bell-labs wiki page

[arisawa]

Hello 9fans,

I also have constructed mirror page of Plan 9 Wiki just now.
please try.

http://p9.nyx.link/wiki/plan_9_wiki/

> 2016/02/10 12:32、arisawa <aris...@ar.aichi-u.ac.jp> のメール：
> 
> many thanks.
> 
>> 2016/02/10 10:45、R. Lucas van Ryn <rvan+pl...@sdf.org> のメール：
>> 
>> On Wed, Feb 10, 2016 at 10:40:21AM +0900, arisawa wrote:
>>> bell-labs wiki page is down.
>>> 
>>> is there any mirror of that wiki?
>> 
>> There is http://9p.io/wiki/plan9/plan_9_wiki/
>> 
> 
> 

[9fans] bell-labs wiki page

[arisawa]

hello 9fans,

bell-labs wiki page is down.
both
http://www.cs.bell-labs.com/wiki/plan9//plan_9_wiki/
and
http://www.cs.bell-labs.com/wiki/plan9/plan_9_wiki/
says:
Object not found

is there any mirror of that wiki?

Kenji Arisawa

Re: [9fans] bell-labs wiki page

[arisawa]

many thanks.

> 2016/02/10 10:45、R. Lucas van Ryn <rvan+pl...@sdf.org> のメール：
> 
> On Wed, Feb 10, 2016 at 10:40:21AM +0900, arisawa wrote:
>> bell-labs wiki page is down.
>> 
>> is there any mirror of that wiki?
> 
> There is http://9p.io/wiki/plan9/plan_9_wiki/
> 

Re: [9fans] WiFi for Plan9

[arisawa]

thanks cinap,

your advice resolved my problem.
aux/wpa is pretty wise!

> 2016/01/31 6:37、cinap_len...@felloff.net のメール：
> 
> aux/wpa doesnt need to be restarted really. it uses factotum to derive
> the psk using the current essid read from the wifi drivers ifstats file.
> so to switch essid's you can just set essid with echo essid  > 
> /net/etherX/clone
> or the ctl file. (note, you can read the ifstats file to see the list of ap's 
> it found).
> 
> if you run a key prompter like aux/fgui, it should prompt for the
> password. otherwise you need to have the key in factotum for that essid like:
> 
> key proto=wpapsk role=client essid=XXX !password=YYY
> 
> --
> cinap
> 

[9fans] WiFi for Plan9

[arisawa]

Hello 9fans,

I have installed plan9(9front) to EeePC 901 so that I can test IPv6 from wan 
side.
aux/wpa works fine.
however I don’t know how to switch to other essid.
I tryed:
Kill wpa
ip/ipconfig unbind
Kill ipconfig
but these operations doesn’t help go back to starting point.
now I reboot and reconnect to other essid.
anyone knows better way?

Kenji Arisawa

Re: [9fans] a question on csquery

[arisawa]

hello erik,

did you try ndb/csquery on the machine named dual?


> 2016/01/10 1:18、erik quanstrom  のメール：
> 
>>> tcp!io.local!1
>> /net/tcp/clone 192.168.0.5!1
>> /net/tcp/clone 2402:6b00:22cd:bf80::5!1
>>> 
>> io% 
>> 
>> is there any reason that csquery should not show both IPs
>> when address is sysname on that csquery command is executed?
> 
> perhaps a dns failure?  i am not seeing this
> 
> for this entry
>   ip=10.1.1.19 ip=2402:6b00:22cd:bf80::6 sys=dual dom=dual.quanstro.net
> i get
> 
>> tcp!dual!1
> /net/tcp/clone 10.1.1.19!1
> /net/tcp/clone 2402:6b00:22cd:bf80::6!1
>> tcp!dual.quanstro.net!1
> /net/tcp/clone 10.1.1.19!1
> /net/tcp/clone 2402:6b00:22cd:bf80::6!1
> 
> - erik
> 

Re: [9fans] a question on csquery

[arisawa]

hello erik,

> there is no machine named "dual".  it was just a set of ndb entries.
> i tried the same experiment with a machine i have, and got the same
> result.
> 
> - erik
> 

hmmm… then it seems that problem is only to me.
thanks for your experiments!

[9fans] a question on csquery

[arisawa]

hello,

I have the following entries in /lib/ndb/local.

sys=io
dom=io.local
ether=001fd0169891
ip=192.168.0.5
ip=2402:6b00:22cd:bf80::5

sys=hebe
dom=hebe.local
ether=6805ca0a0bf2
ip=192.168.0.6
ip=2402:6b00:22cd:bf80::6


io% ndb/csquery
> tcp!hebe!1
/net/tcp/clone 192.168.0.6!1
/net/tcp/clone 2402:6b00:22cd:bf80::6!1
> tcp!hebe.local!1
/net/tcp/clone 192.168.0.6!1
/net/tcp/clone 2402:6b00:22cd:bf80::6!1
> tcp!io!1
/net/tcp/clone 192.168.0.5!1### does not show both IPs
> tcp!io.local!1
/net/tcp/clone 192.168.0.5!1
/net/tcp/clone 2402:6b00:22cd:bf80::5!1
>
io% 

is there any reason that csquery should not show both IPs
when address is sysname on that csquery command is executed?

Kenji Arisawa

Re: [9fans] need a REAL WORKING iso

[arisawa]

hello,

I have recently reinstalled 9pi.
-rw-r-@ 1 arisawa  staff  127695824  1  1 18:38 9pi.img.gz
which is downloaded from plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz
the img works fine with 8GB sd card (4GB is OK?)
I don’t experience your problem.

in 9front distribution we can also have 9pif, compile is required though.
I have compiled but not tried yet.

> /dev/keymap
probably /dev/kbmap

> 9fs sources 
works for me

Kenji Arisawa


> 2016/01/01 20:54、Francois Pussault <fpussa...@contactoffice.fr> のメール：
> 
> hello all
> 
> where can i get a iso file for 9front or plan9 for raspberry pi 
> 
> 
> I have the bell-labs./contrib/miller one but it is all 
> stuck/restricted.  even writting to /dev/keymap is impossible...
> neither mounting 9fs sources and so on.just unusable at all no inst dir 
> ... etc so it is just a brick
> 
> I ve allready had one about one year ago that permitted to call inst/textonly 
> to have a real plan9 station on the RPI fullfeatured and fonctionnal...
> 
> do you have a link that or simillar iso file ?
> 
> thanks
> 
> Cordialement
> Francois Pussault
> 10 chemin de négo saoumos
> apt 202 - bat 2
> 31300 Toulouse
> +33 6 17 230 820   +33 5 34 365 269 
> fpussa...@contactoffice.fr
> 

Re: [9fans] bug or feature ? --- ip/ping -6

[arisawa]

hello,

I did nothing about original ping options, so they should work as they have 
been.
I am afraid I have removed too much.
the new ping is here. test, please.



ping.c
Description: Binary data




> 2015/12/31 7:43、Kenny Lasse Hoff Levinsen  のメール：
> 
> It is not a common factor if you ping broadcast. That is, the local address 
> is common, the remote is not.
> 
> joushou
> 
>> On 30 Dec 2015, at 20:05, Steve Simon  wrote:
>> 
>> I would display the IP address once only, rather on every line; as it is a 
>> common factor.
>> 
>> -Steve
>> 
>> 
>>> On 30 Dec 2015, at 15:26, Kurt H Maier  wrote:
>>> 
 On Wed, Dec 30, 2015 at 03:05:33PM +, Steve Simon wrote:
 If I where redesigning ping I wouldn't repeat any info that is common on 
 each line - I.e. ip addresses or the column titles: rtt, ave etc.
 
 consider plan9's ps(1) which has no column titles. they are described in 
 the man page and are obvious from the context once you have read the man 
 page once.
 
 Having said this, I understand that tradition is also a strong guiding 
 principal.
 
 -Steve
>>> 
>>> I have no opinion on the labeling, but dropping the IPs from the output
>>> would make this tool useless for logging data.
>>> 
>>> khm
>> 
> 
> 

[9fans] bug or feature ? --- ip/ping -6

[arisawa]

hello,

is the following output of ping reasonable enough?


io% 6.ping -an3 hebe
sending 3 64 byte messages 1000 ms apart to icmp!192.168.0.6!1
192.168.0.5 -> 192.168.0.6
0: 192.168.0.6 -> 192.168.0.5 rtt 88 µs, avg rtt 88 µs, ttl = 255
1: 192.168.0.6 -> 192.168.0.5 rtt 83 µs, avg rtt 85 µs, ttl = 255
2: 192.168.0.6 -> 192.168.0.5 rtt 80 µs, avg rtt 83 µs, ttl = 255

io% 6.ping -an3 192.168.0.6
sending 3 64 byte messages 1000 ms apart to icmp!192.168.0.6!1
192.168.0.5 -> 192.168.0.6
0: 192.168.0.6 -> 192.168.0.5 rtt 107 µs, avg rtt 107 µs, ttl = 255
1: 192.168.0.6 -> 192.168.0.5 rtt 84 µs, avg rtt 95 µs, ttl = 255
2: 192.168.0.6 -> 192.168.0.5 rtt 95 µs, avg rtt 95 µs, ttl = 255

io% 6.ping -an3 2402:6b00:22cd:bf80::6
sending 3 64 byte messages 1000 ms apart to icmpv6!2402:6b00:22cd:bf80::6!1
2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6
0: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 103 µs, avg rtt 103 µs, 
ttl = 255
1: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 96 µs, avg rtt 99 µs, 
ttl = 255
2: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 83 µs, avg rtt 94 µs, 
ttl = 255

io% 6.ping -6an3 hebe
sending 3 64 byte messages 1000 ms apart to icmpv6!2402:6b00:22cd:bf80::6!1
2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6
0: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 101 µs, avg rtt 101 µs, 
ttl = 255
1: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 82 µs, avg rtt 91 µs, 
ttl = 255
2: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 89 µs, avg rtt 90 µs, 
ttl = 255

io% 6.ping -6an3 192.168.0.6
sending 3 64 byte messages 1000 ms apart to icmp!192.168.0.6!1
192.168.0.5 -> 192.168.0.6
0: 192.168.0.6 -> 192.168.0.5 rtt 90 µs, avg rtt 90 µs, ttl = 255
1: 192.168.0.6 -> 192.168.0.5 rtt 94 µs, avg rtt 92 µs, ttl = 255
2: 192.168.0.6 -> 192.168.0.5 rtt 90 µs, avg rtt 91 µs, ttl = 255

io% 6.ping -6an3 2402:6b00:22cd:bf80::6
sending 3 64 byte messages 1000 ms apart to icmpv6!2402:6b00:22cd:bf80::6!1
2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6
0: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 101 µs, avg rtt 101 µs, 
ttl = 255
1: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 272 µs, avg rtt 186 µs, 
ttl = 255
2: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 102 µs, avg rtt 158 µs, 
ttl = 255

code is simplified.

io% ls -l
--rw-rw-r-- M 327 arisawa arisawa  9942 Dec 30 21:27 ping.c
--rw-rw-r-- M 327 arisawa arisawa 10943 Dec 28 15:59 ping.c.orig
io% 

Kenji Arisawa



> 2015/12/28 18:04、arisawa <aris...@ar.aichi-u.ac.jp> のメール：
> 
> hello 9fans,
> 
> I have once posted the message below to 9front mailing list.
> however looking the origin of the problem, now I think better place is 9fans.
> 
> == message posted to 9front mailing list ==
> 
> I am feeling weird that ip/ping -6 does not ping to ipv6 address with 
> /lib/ndb/local.
> 
> # sys=io
> # ip=192.168.0.5
> # ip=2402:6b00:22cd:bf80::5
> #
> hebe% ip/ping -6a io
> sending 32 64 byte messages 1000 ms apart to icmpv6!io!1
>   2402:6b00:22cd:bf80::6 -> 192.168.0.5
> 0: 192.168.0.5 -> 192.168.0.6 rtt 104 µs, avg rtt 104 µs, ttl = 255
> 1: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 94 µs, ttl = 255
> 2: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 91 µs, ttl = 255
> 3: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 89 µs, ttl = 255
> 
> this weirdness comes from the order of ip attributes.
> 
> # sys=io
> # ip=2402:6b00:22cd:bf80::5
> # ip=192.168.0.5
> #
> hebe% ip/ping -6a io
> sending 32 64 byte messages 1000 ms apart to icmpv6!io!1
>   2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5
> 0: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 102 µs, avg rtt 102 
> µs, ttl = 255
> 1: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 88 µs, avg rtt 95 µs, 
> ttl = 255
> 2: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 84 µs, avg rtt 91 µs, 
> ttl = 255
> 3: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 104 µs, avg rtt 94 
> µs, ttl = 255
> 
> is this a feature or a bug?
> 
> Kenji Arisawa

[9fans] bug or feature ? --- ip/ping -6

[arisawa]

hello 9fans,

I have once posted the message below to 9front mailing list.
however looking the origin of the problem, now I think better place is 9fans.

== message posted to 9front mailing list ==

I am feeling weird that ip/ping -6 does not ping to ipv6 address with 
/lib/ndb/local.

#   sys=io
#   ip=192.168.0.5
#   ip=2402:6b00:22cd:bf80::5
#
hebe% ip/ping -6a io
sending 32 64 byte messages 1000 ms apart to icmpv6!io!1
2402:6b00:22cd:bf80::6 -> 192.168.0.5
0: 192.168.0.5 -> 192.168.0.6 rtt 104 µs, avg rtt 104 µs, ttl = 255
1: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 94 µs, ttl = 255
2: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 91 µs, ttl = 255
3: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 89 µs, ttl = 255

this weirdness comes from the order of ip attributes.

#   sys=io
#   ip=2402:6b00:22cd:bf80::5
#   ip=192.168.0.5
#
hebe% ip/ping -6a io
sending 32 64 byte messages 1000 ms apart to icmpv6!io!1
2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5
0: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 102 µs, avg rtt 102 µs, 
ttl = 255
1: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 88 µs, avg rtt 95 µs, 
ttl = 255
2: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 84 µs, avg rtt 91 µs, 
ttl = 255
3: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 104 µs, avg rtt 94 µs, 
ttl = 255

is this a feature or a bug?

Kenji Arisawa

Re: [9fans] bug in exportfs

[arisawa]

No.

The difficulty is in the pattern matching rule.
If we want to export only /usr/glenda, then the pattern matching filer must pass
/usr
/usr/glenda
and must not pass
/usr/

have you get solution?

> 2015/12/22 18:25、Peter Hull <peterhul...@gmail.com> のメール：
> 
> Mr Arisawa,
> Did you get any answers to this?
> Peter
> 
> 
> On Thu, 17 Dec 2015 at 13:06 arisawa <aris...@ar.aichi-u.ac.jp> wrote:
> Thanks for your replay.
> however I don’t understand the intention of the manual.
> real needs in exporting is to export some different directories.
> it is impossible to do so under current code.
> can anyone show an example that exports two or more directories?
> 
> > 2015/12/17 20:40、Peter Hull <peterhul...@gmail.com> のメール：
> >
> > On Wed, Dec 16, 2015 at 11:31 PM, arisawa <aris...@ar.aichi-u.ac.jp> wrote:
> >> It seems cpu command is buggy in -P option.
> >> the sources of the problem is in command option -P of exportfs.
> >
> > I had a look at the manpage for exportfs(4), it says: "For a file to
> > be exported, all lines with a prefix + must match and all those with
> > prefix - must not match." (http://man.9front.org/4/exportfs)
> >
> > So isn't the original code correct according to the manpage? If any of
> > the regexps in 'include' fail to match, the function returns -1, then
> > if any in 'exclude' do match, -1 is returned.
> >
> >> patternfile sample
> >> + /usr/arisawa
> >> + /usr/glenda
> >> - /adm
> >> - /sys/log
> >> - /mail
> >> - /usr/.*
> >>
> > Is this sample invalid - no path could match /usr/arisawa and
> > /usr/glenda at the same time?
> >
> > Pete
> 
> I said:
> 
> > int
> > excludefile(char *path)
> > {
> >   Reprog **re;
> >   char *p;
> >
> >   if(*(path+1) == 0)
> >   p = "/";
> >   else
> >   p = path+1;
> >
> >   DEBUG(DFD, "checking %s\n", p);
> >   for(re = include; *re != nil; re++){
> > - if(regexec(*re, p, nil, 0) != 1){
> > + if(regexec(*re, p, nil, 0) == 1){
> >   DEBUG(DFD, "excluded+ %s\n", p);
> > - return -1;
> > + return 0;
> >   }
> >   }
> >   for(re = exclude; *re != nil; re++){
> >   if(regexec(*re, p, nil, 0) == 1){
> >   DEBUG(DFD, "excluded- %s\n", p);
> >   return -1;
> >   }
> >   }
> >   return 0;
> > }
> >
> >
> > patternfile sample
> > + /usr/arisawa
> > + /usr/glenda
> > - /adm
> > - /sys/log
> > - /mail
> > - /usr/.*
> 
> however this code has still a problem.
> 
> trailing ‘/‘ is removed in p even if p is a directory.
> assume we have users:
> /usr/rob
> and
> /usr/robin
> then we cannot export only /usr/rob.
> if we wish control this problem, we need tailing ‘/‘ for directory.
> then the code should be
> 
> excludefile(char *path)
> {
> Reprog **re;
> char *p,*s;
> Dir *dir;
> 
> if(*(path+1) == 0)
> p = "/";
> else
> p = path+1;
> 
> s = p + strlen(p) - 1; /* tail */
> dir = dirstat(p);
> /* should not be nil */
> if((dir->mode)){
> /* we have room to append '/'
> *  look makepath() in exportfs.c */
>     *++s = '/';
> *++s = 0;
> }
> 
> DEBUG(DFD, "checking %s\n", p);
> for(re = include; *re != nil; re++){
> if(regexec(*re, p, nil, 0) == 1){
> DEBUG(DFD, "excluded+ %s\n", p);
> return 0;
> }
> }
> for(re = exclude; *re != nil; re++){
> if(regexec(*re, p, nil, 0) == 1){
> DEBUG(DFD, "excluded- %s\n", p);
> return -1;
> }
> }
> return 0;
> }
> 
> then patternfile sample become:
> 
> + /usr/arisawa/.*
> + /usr/glenda/.*
> - /adm/
> - /sys/log/
> - /mail/
> - /usr/.+
> 
> adding tailing ‘/‘ in p makes the pattern file incompatible to existing one.
> I don’t know it is better to do so.
> 
> 
> 

Re: [9fans] 9grid again

[arisawa]

Hello 9fans.

I have started a new 9grid server with some services.
Please look http://p9.nyx.link/9grid2/9grid.html for details.
This is an experimental service.
If you noticed something bad, please inform me.

Kenji Arisawa

> 2015/11/12 16:30、arisawa <aris...@ar.aichi-u.ac.jp> のメール：
> 
> hello,
> 
> I am considering a new project that is related to big data.
> assume we have data on several distributed server.
> current common approach is:
> downloading these data from servers to local side and process them.
> however data is big but program is small. 
> if the data is 1GB order, this approach is practically infeasible.
> 9grid enables opposite approach:
> login to servers and process the data there and gather the results.
> we have all the tools that are necessary to do this as much as 10 years ago.
> what is lacking is target data.
> any idea?
> 
> Kenji Arisawa
> 
> 

Re: [9fans] bug in exportfs

[arisawa]

Thanks for your replay.
however I don’t understand the intention of the manual.
real needs in exporting is to export some different directories.
it is impossible to do so under current code.
can anyone show an example that exports two or more directories?

> 2015/12/17 20:40、Peter Hull <peterhul...@gmail.com> のメール：
> 
> On Wed, Dec 16, 2015 at 11:31 PM, arisawa <aris...@ar.aichi-u.ac.jp> wrote:
>> It seems cpu command is buggy in -P option.
>> the sources of the problem is in command option -P of exportfs.
> 
> I had a look at the manpage for exportfs(4), it says: "For a file to
> be exported, all lines with a prefix + must match and all those with
> prefix - must not match." (http://man.9front.org/4/exportfs)
> 
> So isn't the original code correct according to the manpage? If any of
> the regexps in 'include' fail to match, the function returns -1, then
> if any in 'exclude' do match, -1 is returned.
> 
>> patternfile sample
>> + /usr/arisawa
>> + /usr/glenda
>> - /adm
>> - /sys/log
>> - /mail
>> - /usr/.*
>> 
> Is this sample invalid - no path could match /usr/arisawa and
> /usr/glenda at the same time?
> 
> Pete

I said:

> int
> excludefile(char *path)
> {
>   Reprog **re;
>   char *p;
> 
>   if(*(path+1) == 0)
>   p = "/";
>   else
>   p = path+1;
> 
>   DEBUG(DFD, "checking %s\n", p);
>   for(re = include; *re != nil; re++){
> - if(regexec(*re, p, nil, 0) != 1){
> + if(regexec(*re, p, nil, 0) == 1){
>   DEBUG(DFD, "excluded+ %s\n", p);
> - return -1;
> + return 0;
>   }
>   }
>   for(re = exclude; *re != nil; re++){
>       if(regexec(*re, p, nil, 0) == 1){
>   DEBUG(DFD, "excluded- %s\n", p);
>   return -1;
>   }
>   }
>   return 0;
> }
> 
> 
> patternfile sample
> + /usr/arisawa
> + /usr/glenda
> - /adm
> - /sys/log
> - /mail
> - /usr/.*

however this code has still a problem.

trailing ‘/‘ is removed in p even if p is a directory.
assume we have users:
/usr/rob
and
/usr/robin
then we cannot export only /usr/rob.
if we wish control this problem, we need tailing ‘/‘ for directory.
then the code should be

excludefile(char *path)
{
Reprog **re;
char *p,*s;
Dir *dir;

if(*(path+1) == 0)
p = "/";
else
p = path+1;

s = p + strlen(p) - 1; /* tail */
dir = dirstat(p);
/* should not be nil */
if((dir->mode)){
/* we have room to append '/'
*  look makepath() in exportfs.c */
*++s = '/';
*++s = 0;
}

DEBUG(DFD, "checking %s\n", p);
for(re = include; *re != nil; re++){
if(regexec(*re, p, nil, 0) == 1){
DEBUG(DFD, "excluded+ %s\n", p);
return 0;
}
}
for(re = exclude; *re != nil; re++){
if(regexec(*re, p, nil, 0) == 1){
DEBUG(DFD, "excluded- %s\n", p);
return -1;
}
}
return 0;
}

then patternfile sample become:

+ /usr/arisawa/.*
+ /usr/glenda/.*
- /adm/
- /sys/log/
- /mail/
- /usr/.+

adding tailing ‘/‘ in p makes the pattern file incompatible to existing one.
I don’t know it is better to do so.

Re: [9fans] unmount

[arisawa]

I said:

> 2015/12/01 12:24、arisawa <aris...@ar.aichi-u.ac.jp> のメール：
> 
> Hello 9fans,
> 
> current kernel allows unmount even if after rfork m.
> this feature makes sandboxing difficult.
> can anyone explain this feature is necessary?
> 
> Kenji Arisawa

I make a protection for unmounting after rfork -m and now testing.
my idea is: protecting unmount with a single argument.
it seems the following code is working, however I am not sure this is OK.
any comment welcome.

/sys/src/9/port/sysfile.c:

sysunmount(va_list list)
{
Chan *cmount, *cmounted;
char *name, *old;

name = va_arg(list, char*);
old = va_arg(list, char*);

/*  a protection for 'unmount' after 'rfork m'
*   we can reject any unmount, however it might not be user 
friendly to do so.
*   more moderate way might be disallowing
*   unmount mntpoint# sigle argument
*   it is ideal though: we disalow unmount dirs that are mounted 
before rfork m.
*   probably we need this protection also in regular kernel
*
*   print("name=%s old=%s\n",name,old);
*   the output is, e.g,
*   name=srv/factorum
*   old=/mnt
*   -Kenar- */

if(up->pgrp->noattach && (name == nil)){
error(Eperm);
return 0;
}

[9fans] unmount

[arisawa]

Hello 9fans,

current kernel allows unmount even if after rfork m.
this feature makes sandboxing difficult.
can anyone explain this feature is necessary?

Kenji Arisawa

[9fans] 9grid again

[arisawa]

hello,

I am considering a new project that is related to big data.
assume we have data on several distributed server.
current common approach is:
downloading these data from servers to local side and process them.
however data is big but program is small. 
if the data is 1GB order, this approach is practically infeasible.
9grid enables opposite approach:
login to servers and process the data there and gather the results.
we have all the tools that are necessary to do this as much as 10 years ago.
what is lacking is target data.
any idea?

Kenji Arisawa

[9fans] blank line in /lib/ndb/local

[arisawa]

Hello,

manual ndb(6) says: "Each line starting without white space starts a new tuple. 
Lines starting with # are comments.”

assume we have an entry such as:
dom=foo
# a blank line follows

auth=bar

if the blank line contains a white space, then
ndb/query dom foo auth
will produce
dom=foo auth=bar
on the other hand, if the blank line is empty, then the command will produce
dom=foo

Is this a bug or a specification?
I want to believe this is a bug.

Kenji Arisawa

Re: [9fans] blank line in /lib/ndb/local

[arisawa]

hello,

your blank line doesn’t have a white space.

> 2015/11/10 12:02、erik quanstrom  のメール：
> 
> On Mon Nov  9 04:32:24 PST 2015, aris...@ar.aichi-u.ac.jp wrote:
>> Hello,
>> 
>> manual ndb(6) says: "Each line starting without white space starts a new 
>> tuple. Lines starting with # are comments.”
>> 
>> assume we have an entry such as:
>> dom=foo
>>  # a blank line follows
>> 
>>  auth=bar
>> 
>> if the blank line contains a white space, then
>>  ndb/query dom foo auth
>> will produce
>>  dom=foo auth=bar
>> on the other hand, if the blank line is empty, then the command will produce
>>  dom=foo
>> 
>> Is this a bug or a specification?
>> I want to believe this is a bug.
> 
> i can't replicate this:
> 
> ; cat a.db
> dom=fu
>   # comment
> 
>   auth=bar
> ; ndb/query -f a.db dom fu
> dom=fu 
> 
> 
> - erik

Re: [9fans] blank line in /lib/ndb/local

[arisawa]

yes, your right.
the manual says what the code does.
however I don’t think it is a good idea to make sense in white spaces within 
blank line.
probably the code does not suppose blank lines within ndb entry.

> 2015/11/10 13:05、erik quanstrom  のメール：
> 
> On Mon Nov  9 20:03:06 PST 2015, aris...@ar.aichi-u.ac.jp wrote:
>> hello,
>> 
>> your blank line doesn’t have a white space.
>> 
>>> 2015/11/10 12:02、erik quanstrom  のメール：
>>> 
>>> On Mon Nov  9 04:32:24 PST 2015, aris...@ar.aichi-u.ac.jp wrote:
 Hello,
 
 manual ndb(6) says: "Each line starting without white space starts a new 
 tuple. Lines starting with # are comments.”
> 
> exactly.  that's what the manual says.  an otherwise blank like with only 
> whitespace would
> fit the definition of a line starting with whitespace, therefore not starting 
> a new tuple.
> 
> - erik
> 

Re: [9fans] 9vx on OSX

[arisawa]

Hello,

thanks all.

> mine is weird: when I type “abc”, I have “aabbcc”.

I replaced 9vx (not only 9vx binary but whole set of 9vx package) on Yosemite 
by the one that is working on Mountain Lion.
however the problem is not fixed.

probably that is only to me.
some differences in environment makes problem.

Kenji Arisawa

[9fans] 9vx on OSX

[arisawa]

Hello,

does anyone have 9vx that is working on recent osx (Yosemite for example)?

mine is weird: when I type “abc”, I have “aabbcc”.

Kenji Arisawa

Re: [9fans] manual qer(8)

[arisawa]

thanks.
anyway, simple “runq” does not work.
should be fixed.

> 2015/09/26 18:11、Charles Forsyth <charles.fors...@gmail.com> のメール：
> 
> 
> On 26 September 2015 at 06:29, arisawa <aris...@ar.aichi-u.ac.jp> wrote:
> I think “runq” should be replaced by “upas/runq”
> 
> mine has /bin/upas/runq -a /mail/queue /mail/lib/remotemail

Re: [9fans] dns message

[arisawa]

thank you erik.
you are very careful!
I didn’t aware that garbage.
however removing “ip” does not fix my problem.
looking source code I guess: names that are not followed by “=“ are just 
discarded.
I want to know whether this is only to me.

erik, thanks again!

> 2015/09/27 0:28、erik quanstrom  のメール：
> 
>> ipnet=local ip=192.168.0.0 ipmask=255.255.255.0
>>  ipgw=192.168.0.1
>>  smtp=ar
> !>ntp=ntp.jst.mfeed.ad.jp ip
>>  auth=hebe
>>  fs=hebe
>>  # the dns values are advertised by DHCP server
>>  # we assume that dhcpd is running on the same ip. look /cfg/common/cpurc
>>  dns=192.168.0.6
> 
> this is an indication of an issue.
> 
> the ntp line has a trailing ip, which may be confusing the dns client.
> 
> - erik
> 

[9fans] manual qer(8)

[arisawa]

Hello,

qer(8) says:
 Runq is often called from cron(8) by an entry such as

   0,10,20,30,40,50 * * * * kremvax
   runq -a /mail/queue /mail/lib/remotemail

I think “runq” should be replaced by “upas/runq”

Kenji Arisawa

[9fans] dns message

[arisawa]

Hello,

running dns with -rs options
I have a lot of messages in /sys/log/dns

term% tail dns
hebe Sep 26 07:17:20 rejecting my ip 192.168.0.6 as local dns server
hebe Sep 26 07:19:34 rejecting my ip 192.168.0.6 as local dns server
hebe Sep 26 07:19:37 rejecting my ip 192.168.0.6 as local dns server

these messages come from:

 dblookup.c 

addlocaldnsserver(DN *dp, int class, char *ipaddr, int i)
{
...
/* reject our own ip addresses so we don't query ourselves via udp */
if (myaddr(ipaddr))
return;


myaddr(char *addr)
{
char *line, *sp;
char buf[64];
Biobuf *bp;

if(ipcmp(ipaddr, IPnoaddr) == 0)
if(myipaddr(ipaddr, mntpt) < 0)
return -1;

snprint(buf, sizeof buf, "%I", ipaddr);
if (strcmp(addr, buf) == 0) {
dnslog("rejecting my ip %s as local dns server", addr);
return 1;
}


 /lib/ndb/local 
ipnet=local ip=192.168.0.0 ipmask=255.255.255.0
ipgw=192.168.0.1
smtp=ar
ntp=ntp.jst.mfeed.ad.jp ip
auth=hebe
fs=hebe
# the dns values are advertised by DHCP server
# we assume that dhcpd is running on the same ip. look /cfg/common/cpurc
dns=192.168.0.6

yes my dns is running on 192.168.0.6

any wrong setting in /lib/ndb/local?
if not, I think these warning messages are annoying.

Kenji Arisawa

[9fans] ipv6on bug?

[arisawa]

Hello,

in /rc/bin/ipv6on, we have:

mev6=`{ndb/query -f $ndbf sys $sysname ipv6}
if (~ $#sysname 0 || ~ $sysname '')
mev6=`{ndb/query -f $ndbf sys $sysname ip | grep :}

this code is something curious. 
bug?

mev6=`{ndb/query -f $ndbf sys $sysname ipv6}
if (~ $#mev6 0 || ~ $mev6 ‘')   ### s/sysname/mev6/g
mev6=`{ndb/query -mf $ndbf sys $sysname ip | grep :}### 
s/-f/-mf/


Kenji Arisawa

Re: [9fans] ipv6 and ndb/csquery

[arisawa]

Thanks cinap,

your detailed explanation will be helpful to me and all others.

Kenji Arisawa


 2015/07/12 0:37、cinap_len...@felloff.net のメール：
 
 when you query /net/dns, it differentiates between ip (A) and ipv6
 () records. so querying for ip only yields ipv4 addresses and
 querying for ipv6 yields ipv6 addresses only. it shouldnt matter if
 you use ip= or ipv6= attribute in ndb for this, as ndb/dns is smart
 enogth to check the value of the attribute and figure out if its for
 and A or  record.
 
 now ndb/cs is concerned about finding an addresses that is reachable
 from your system. i think that is why it reorders the results
 based on local ip interfaces. in any case, ndb/cs will query dns
 for both ipv4 and ipv6 addresses unless you give it (v4 only flag -4).
 
 when ndb/cs looks for an address in the network database, it only looks
 for the ip= attribute and ignores ipv6= attributes (these are for dns only).
 
 so if you have no ipv6 connectivity on the lan, but you want to put
 ipv6  records in your dns server (to serve to the outside world?),
 use the ipv6= attribute in ndb as network database lookups will
 ignore the ipv6= stuff.
 
 when you have both ipv4 and ipv6 connectivity, you can just use
 ip= attribute for both v4 and v6 addresses, then network database
 lookup will yield both. 
 
 when a domain has multiple ip addresses, dns will randomize the
 list of results (for a specific record type). ndb/cs queries dns
 for v4 addresses first and v6 addresses last, the (randomized)
 v4 addresses appear before the (randomized) v6 addresses
 (unless cs did reorder the list as it found the v6 address to be
 reachable directly the by a local network interface).
 
 the results from network database are not randomized (but can be
 reordered) by ndb/cs:
 
 sys=testa ip=89.186.156.12 
   ip=2001:470:1f0a:a61::2
 
 sys=testb ip=2001:470:1f0a:a61::2
   ip=89.186.156.12 
 
 net!testa!*
 /net.alt/il/clone 89.186.156.12!*!fasttimeout
 /net.alt/il/clone 2001:470:1f0a:a61::2!*!fasttimeout
 /net.alt/tcp/clone 89.186.156.12!*
 /net.alt/tcp/clone 2001:470:1f0a:a61::2!*
 /net.alt/il/clone 89.186.156.12!*
 /net.alt/il/clone 2001:470:1f0a:a61::2!*
 net!testb!*
 /net.alt/il/clone 2001:470:1f0a:a61::2!*!fasttimeout
 /net.alt/il/clone 89.186.156.12!*!fasttimeout
 /net.alt/tcp/clone 2001:470:1f0a:a61::2!*
 /net.alt/tcp/clone 89.186.156.12!*
 /net.alt/il/clone 2001:470:1f0a:a61::2!*
 /net.alt/il/clone 89.186.156.12!*
 
 dial() processes the list from cs in sequential order, unless
 you use geoffs parallel dial implementation which connects to
 some bounded number of addresses in parallel.
 
 still the ordering of what cs returns is in most prefered first,
 and it is up to cs to define that order. like it *could* decide to
 always put ipv6 addresses first, but i think this was not done because
 in the labs the v6 network was less reliable than the v4 network?
 
 --
 cinap
 

Re: [9fans] ipv6 and ndb/csquery

[arisawa]

Thanks.
It seems you are right.

I have been playing with ipv6 and yet i don’t understand something.
What is the rule to select an IP if we allow multiple IPs for a dom?
Maybe case by case. But how to select ipv6 in case of telnet?

 2015/07/07 2:01、cinap_len...@felloff.net のメール：
 
 i dont know for sure but could it be that cs resolves
 these local domains thru ndb? and then ignores your
 ipv6= attibures in ndb?
 
 i use ip= attribute in my ndb for both v4 and v6 addresses
 and that works fine.
 
 --
 cinap
 

[9fans] ipv6 and ndb/csquery

[arisawa]

Hello,

I am currently trying ipv6 of Plan9.

with a line
ip=192.168.0.3 ipv6=fe80::6a05:caff:fe00:fc34 ether=6805ca00fc34
sys=maia
in /lib/ndb/local, and executing
ipv6on
I tried dnsquery and csquery.

ii seems dnsquery is OK

term% ndb/dnsquery
 maia
maia.local ip   192.168.0.3
 maia ipv6
maia.local ipv6 fe80::6a05:caff:fe00:fc34
 www.google.com
www.google.com ip   173.194.117.212
www.google.com ip   173.194.117.211
www.google.com ip   173.194.117.210
www.google.com ip   173.194.117.208
www.google.com ip   173.194.117.209
 www.google.com ipv6
www.google.com ipv6 2404:6800:4004:80c::1014


however I don’t understand the behavior of csquery

term% ndb/csquery
 tcp!maia!*
/net/tcp/clone 192.168.0.3!*
 tcp!www.google.com!*
/net/tcp/clone 173.194.117.210!*
/net/tcp/clone 173.194.117.208!*
/net/tcp/clone 173.194.117.209!*
/net/tcp/clone 173.194.117.211!*
/net/tcp/clone 173.194.117.212!*
/net/tcp/clone 2404:6800:4004:80c::1014!*


why csquery does not show ipv6 address of maia?

Kenji Arisawa

Re: [9fans] Plan9 DNS server

[arisawa]

thanks all.
now I have achieved my goal.


 2015/06/22 19:34、lu...@proxima.alt.za のメール：
 
 how to enable locally assigned name resolution such as maia?
 
 The dns man page requires careful reading, but all the details are in
 there.  I have a pretty complex DNS configuration and it seems to
 cause the server to fail more frequently than I like.  But the
 functionality I need is there, just with one or more weak spots that I
 have not been able to identify.
 
 Lucio.
 
 

[9fans] Plan9 DNS server

[arisawa]

Hello,

how to make DNS server that serves for computers on my home network?
I tried:
ndb/dns -rs

192.168.0.3 is my server’s IP.
the name is “maia” and registered /lib/ndb/local as
sys=maia dom=maia.local

-bash$ nslookup
 www.google.com
Server: 192.168.0.3
Address:192.168.0.3#53

Non-authoritative answer:
Name:   www.google.com
Address: 216.58.220.228
 maia
Server: 192.168.0.3
Address:192.168.0.3#53

** server can't find maia: NXDOMAIN
 maia.local
Server: 192.168.0.3
Address:192.168.0.3#53

** server can't find maia.local: NXDOMAIN
 

how to enable locally assigned name resolution such as maia?
I have many computers on my home network. currently I am registering them to 
/etc/hosts.
but that is a pain.

Kenji Arisawa

Re: [9fans] protection against resource exhaustion

[arisawa]

Hi, erik,

Thanks a lot!

 2015/01/29 15:42、erik quanstrom quans...@quanstro.net のメール：
 
 i hope i haven't overplayed my argument.  i am for real solutions to this 
 issue.
 i'm not for the current solution, or more complicanted variants.

Re: [9fans] protection against resource exhaustion

[arisawa]

Thanks for all.

I have looked old source code /sys/src/9/port/proc.c, and found the next code 
exists from very old day.

lock(procalloc);
for(;;) {
if((p = procalloc.free) != nil)
break;

snprint(msg, sizeof msg, no procs; %s forking,
up != nil ? up-text: kernel);
unlock(procalloc);
resrcwait(msg);
lock(procalloc);
}
procalloc.free = p-qnext;
unlock(procalloc);

and rfork(2) says:
Rfork will sleep, if necessary, until required process resources are 
available.
which is also exists from old day.

Nevertheless all programs, I believe, in /sys/src are written assuming rfork() 
may return -l:
switch(rfork(….)){
case -1:
  …
}

Any merit?

Re: [9fans] protection against resource exhaustion

[arisawa]

we don’t have perfect solution.
nevertheless, we must protect system.

if we search ideal (or nearly ideal) solution, we should assign limited 
resource to each user.
however this is a big job, I believe.

current plan9 system is running under shared resource model.
under this model, it is very hard to protect system from evil-minded users.

keeping this model, we can do something that is, of course, imperfect (but easy 
to implement, I believe).
for example:
(a) select processes that should keep running. (with resrcwait flag, for 
example)
(b) kill processe that failed to be allocated resource if it doesn’t has 
resrcwait flag.

this strategy has following problems:
(1) innocent processes may be killed.
the probability is small if the origin is careless program, but can be large by 
evil-mined program.
(2) error return from malloc() and fork() are disabled.

 2015/01/27 23:10、erik quanstrom quans...@quanstro.net のメール：
 
 i think it will go the same way with fork protection.  how do you tell 
 which program
 is at fault?  how do you tell a program forking at high frequency, with 
 short lived
 children from a fork bomb?  (such as a busy web server.)
 
 only system administrator knows which processes should keep running.
 
 do you wake him up in the middle of the night if this happens to arbitrate?
 this knowledge of what should be preserved may only be post facto knowledge.
 i'll know what to kill off once i see what's running.  which assumes a 
 working
 fork, at least for the administrator.
 
 in any event, i'd be interested in code that does do a good job, especially
 if it passes tests other than the trivial fork bomb, such as many users 
 contributing
 to exhaustion.
 
 I have beeb writing codes believing those error return is working.
 
 do you have tests?  did you write a test malloc that will fail when called
 at every location, and ensure sane behavior?
 
 - erik
 

Re: [9fans] protection against resource exhaustion

[arisawa]

Hello,

 nonetheless, i have experience running multi-user plan 9 systems, and users
 were not usually the issue.

Eric’s users are all gentleman, all careful people and all skillful programmers.
If your system is served for university students, you will have different 
thought.

 i think you've turned a problem with bounded recovery time into a
 situation where the recovery code itself will inadvertently dos attack its
 users.

in case that a process failed in getting resource such as memory or process, 
what it should do is very limited: puts out some message and exits.
this is right behavior.
I have never seen programs that retry malloc() or fork() until succeed.
if all processes retry them, the system will get down.
this is what I have observed in current plan9 kernel.

if any one has cleaner solution, i.e., a solution that never kill innocent 
process,
I want to see it.

Re: [9fans] protection against resource exhaustion

[arisawa]

Hello,

 i think it will go the same way with fork protection.  how do you tell which 
 program
 is at fault?  how do you tell a program forking at high frequency, with short 
 lived
 children from a fork bomb?  (such as a busy web server.)

only system administrator knows which processes should keep running.
therefore, as Lyndon mentioned, we need a mark “don’t kill by resource 
exhaustion” to processes.
if automatic determination is desired, the last stage of /rc/bin/cpurc and 
/rc/bin/termrc may be the right place.

 i'm not sure i understand what you mean by traditional programming style 
 here
 as plan 9 exists in part to break unix rules.

as Eric mentioned, we have many many codes such as
p = malloc(n);
if(p == nil){
...
}
or
switch(pid = fork()) {/* assign = */
case -1:
sysfatal(fork: %r);
case 0:
...
default:
...
}
I have beeb writing codes believing those error return is working.

Re: [9fans] protection against resource exhaustion

[arisawa]

Hello,

I have been playing the following program.
I tried on official plan9, 9front, and 9atom.
none of them showed messages that come from:
sysfatal(fork: %r”);
sysfatal(exec: %r);
I suspect that
fork()
does not return -1 even if it failed in creating new process.

Be ware this program may cause system panic.

#include u.h
#include libc.h
#define ERRLEN 256

static int
waitfor(int pid, char *msg)
{
Waitmsg *w;
while((w = wait()) != nil){
if(w-pid == pid){
strncpy(msg, w-msg, ERRMAX);
free(w);
return 0;
}
free(w);
}
return -1;
}

int
run(char *path, char *cmd)
{
int pid;
int status;
int n;
char *args[32];
char msg[ERRLEN];

n = tokenize(cmd, args, 32);
args[n] = nil;

switch(pid = fork()) {/* assign = */
case -1:
sysfatal(fork: %r);
case 0:
close(0);
exec(path, args);
sysfatal(exec: %r);
default:
break;
}
status = waitfor(pid, msg);
if(status  0){
werrstr(waitfor: %r);
return -1;
}
return 0;
}

void main(int argc, char *argv[])
{   char *e;
int n;
int m = 100;
char buf[32];
ARGBEGIN{
case 'm':   m = atoi(ARGF());
break;
default: sysfatal(usage);
}ARGEND

if(argv[0])
n = atoi(argv[0]);
else
n = 0;
if(n == m)
sysfatal(stop);

print(%d\n,n);
snprint(buf,sizeof(buf),8.out -m %d %d,m,n + 1);
run(./8.out, buf);
exits(nil);
}

Re: [9fans] protection against resource exhaustion

[arisawa]

Hello,

many of resource exhaustion come from careless programming.
I would like such processes to be killed immediately.
throwing up to broken state might be better.
I prefer an option to plan9.ini that enable resrcwait(), because the call breaks
traditional programming style and probably we need more time to have 
right solution.

 2015/01/26 23:13、erik quanstrom quans...@quanstro.net のメール：
 
 On Mon Jan 26 03:43:36 PST 2015, aris...@ar.aichi-u.ac.jp wrote:
 Hello,
 
 I have been playing the following program.
 I tried on official plan9, 9front, and 9atom.
 none of them showed messages that come from:
  sysfatal(fork: %r”);
  sysfatal(exec: %r);
 I suspect that
  fork()
 does not return -1 even if it failed in creating new process.
 
 exactly.
 
 the reason it never returns -1, is that introduces a new failure case in
 every program running, and testing seems like a huge pain.  just
 testing for handles fork returning -1 is not good enough, it has to have
 a reasonable strategy for deailing with no procs.  this is hard to get right.
 just reboot.  i have never been able to recover a system that hit noprocs.
 i ended up wasting people's time trying.
 
 - erik
 
 ps.  how may lines like this have you seen.
 
   p = malloc(n);
   if(p == nil){
   ...
   }
 
 is this really useful in most tools?
 

Re: [9fans] protection against resource exhaustion

[arisawa]

thank you, mischief.

considering after I have posted previous mail, 
I have come to think that the script below should fail with error and stop 
execution.

maia% cat foo
#!/bin/rc
./foo
maia% 

current rc does not stop execution.
probably not due to protection problem by kernel.
there must be a bug in rc.

Kenji Arisawa

 2015/01/25 15:16、arisawa aris...@ar.aichi-u.ac.jp のメール：
 
 
 Hello 9fans
 
 my mac has a protection below:
 -bash$ cat foo
 #!/bin/sh
 ./foo
 -bash$ ./foo
 ./foo: fork: Resource temporarily unavailable
 -bash$ 
 
 on the other hand, Plan 9 does not.
 kernel is protected against such programs, however they are not killed.
 therefore no new process can be created.
 
 does anyone have idea to fix the problem?
 
 Kenji Arisawa
 
 

[9fans] protection against resource exhaustion

[arisawa]

Hello 9fans

my mac has a protection below:
-bash$ cat foo
#!/bin/sh
./foo
-bash$ ./foo
./foo: fork: Resource temporarily unavailable
-bash$ 

on the other hand, Plan 9 does not.
kernel is protected against such programs, however they are not killed.
therefore no new process can be created.

does anyone have idea to fix the problem?

Kenji Arisawa

Re: [9fans] bug in rc(1) ?

[arisawa]

OK, thanks

 2014/11/29 13:57、minux minux...@gmail.com のメール：
 
 On Fri, Nov 28, 2014 at 11:42 PM, arisawa aris...@ar.aichi-u.ac.jp wrote:
 rc(1) says:
 
  rfork [nNeEsfFm]
   Become a new process group using rfork(flags) where
   flags is composed of the bitwise OR of the rfork flags
   specified by the option letters (see fork(2)). If no
   flags are given, they default to ens.  The flags and
   their meanings are: n is RFNAMEG; N is RFCNAMEG; e is
   RFENVG; E is RFCENVG; s is RFNOTEG; f is RFFDG; F is
   RFCFDG; and m is RFNOMNT.
 
 this sounds to me
rfork
 is equivalent to
rfork ens
 yes. it also agrees with the source code.
 http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/rc/plan9.c:/^execnewpgrp

[9fans] bug in rc(1) ?

[arisawa]

rc(1) says:

  rfork [nNeEsfFm]
   Become a new process group using rfork(flags) where
   flags is composed of the bitwise OR of the rfork flags
   specified by the option letters (see fork(2)). If no
   flags are given, they default to ens.  The flags and
   their meanings are: n is RFNAMEG; N is RFCNAMEG; e is
   RFENVG; E is RFCENVG; s is RFNOTEG; f is RFFDG; F is
   RFCFDG; and m is RFNOMNT.

this sounds to me
rfork
is equivalent to
rfork ens

or am I misunderstanding?

Kenji Arisawa

Re: [9fans] rc: null list in concatenation

[arisawa]

 2014/11/25 15:56、tre...@india.com のメール：
 
 a = `{ls file}^test; echo 'this part is not executed if file doesn''t exist'

probably your question is as follows:

maia% a = `{ls file}^test; echo 'this part is not executed if file doesn''t 
exist'
ls: file: 'file' directory entry not found
rc: null list in concatenation
maia% 

on the other hand,

maia% ls file;  echo 'this part is not executed if file doesn''t exist'
ls: file: 'file' directory entry not found
this part is not executed if file doesn't exist
maia% 

a similar  thing is:
maia% (aa bb)=; echo 
rc: variable name not singleton!
maia% 

perhaps this is a feature.
rc stops execution if there is an error in grammar.

Re: [9fans] rc: null list in concatenation

[arisawa]

example is required.

 2014/11/25 13:24、tre...@india.com のメール：
 
 Hello everyone.
 
 I'm curious about the behavior of rc concatenating null strings (brakes
 execution on error...).  It's a feature, rationally thought-out, or a bug?
 
 If anyone can tell me the story behind, I'll be grateful.
 
 trebol.
 
 P.D.
 Sorry for previous mail without subject.
 
 

Re: [9fans] Pjpeg in /sys/lib/mimetype

[arisawa]

Hello,

I believe the line:
.jpgimage   pjpeg   -   y
should be removed.

I found another curiosity in the file.
term% grep compress /sys/lib/mimetype
.Z  -   -   compressm
.tazapplication x-tar   compressm
.trzapplication x-tar   compressm
.z  -   -   compressm
.Z  -   -   compressm
term% 
Does this mean that file suffixes are case sensitive in determining the mime 
type?
If so, should files with suffix “.JPG” be renamed to “.jpg” ?

Kenji Arisawa

2014/11/14 21:13、arisawa aris...@ar.aichi-u.ac.jp のメール：

 Hello,
 
 It is curious for me that .jpg has two entries in /sys/lib/mimetype.
 term% grep jpeg /sys/lib/mimetype
 .jfif image   jpeg-   y
 .jfif-tbnlimage   jpeg-   y
 .jpe  image   jpeg-   y
 .jpeg image   jpeg-   y
 .jpg  image   jpeg-   y
 .jpg  image   pjpeg   -   y
 term%
 
 The file is currently consulted by only two applications: mail and httpd.
 I thought that the file provides conventional way to determine mime type from 
 file suffix.
 If so, what is the mime type for foo.jpg?
 
 Kenji arisawa
 
 

[9fans] inconsistent comparison?

[arisawa]

Hello,

/sys/lib/mimetype is referenced in three files:
/sys/src/cmd/ip/httpd/content.c # for outgoing file
/sys/src/cmd/upas/marshal/marshal.c # for outgoing file
/usr/arisawa/src/upas/vf/vf.c   # for incoming file

the codes are as follows.

/sys/src/cmd/ip/httpd/content.c
/sys/src/cmd/ip/httpd/content.c
while((p = strrchr(buf, '.')) != nil){
for(s = suffixes; s; s = s-next){
if(strcmp(p, s-suffix) == 0){
if(s-generic != nil  type == nil)
type = hmkcontent(hc, s-generic, 
s-specific, nil);
if(s-encoding != nil  enc == nil)
enc = hmkcontent(hc, s-encoding, nil, 
nil);
}
}
*p = 0;
}

/sys/src/cmd/upas/marshal/marshal.c
/* try the mime types file */
if(p != nil){
if(mimetypes == nil)
readmimetypes();
for(c = mimetypes; c != nil  c-ext != nil; c++)
if(strcmp(p, c-ext) == 0){
a-type = c-type;
a-ctype = c;
return a;
}
}


/sys/src/cmd/upas/vf/vf.c
for(m = mtypes; m != nil; m = m-next)
if(cistrcmp(p, m-ext) == 0){
switch(m-class){
case 'm':
case 'y':
return 0;
case 'p':
*p = 0;
rv = badfile(name);
*p = '.';
return rv;
case 'r':
return 2;
}
}


these codes are in 9front but probably same as both official plan9 and 9atom.
note that vf.c uses cistrcmp() but others use strcmp().
this these are intensional?

[9fans] Pjpeg in /sys/lib/mimetype

[arisawa]

Hello,

It is curious for me that .jpg has two entries in /sys/lib/mimetype.
term% grep jpeg /sys/lib/mimetype
.jfif   image   jpeg-   y
.jfif-tbnl  image   jpeg-   y
.jpeimage   jpeg-   y
.jpeg   image   jpeg-   y
.jpgimage   jpeg-   y
.jpgimage   pjpeg   -   y
term%

The file is currently consulted by only two applications: mail and httpd.
I thought that the file provides conventional way to determine mime type from 
file suffix.
If so, what is the mime type for foo.jpg?

Kenji arisawa

[9fans] pjpeg in /sys/lib/memetype

[Kenji Arisawa]

Hello 9fans,

It is curious for me that .jpg has two lines in /sys/lib/mimetype.
term% grep jpeg /sys/lib/mimetype
.jfif   image   jpeg-   y
.jfif-tbnl  image   jpeg-   y
.jpeimage   jpeg-   y
.jpeg   image   jpeg-   y
.jpgimage   jpeg-   y
.jpgimage   pjpeg   -   y
term%

The file is currently consulted by only two applications: mail and httpd.
I have thought that the file provides conventional way to determine mime type 
from file suffix. If so, what is the mime time for foo.jpg?

Kenji Arisawa

Re: [9fans] shell functions

[arisawa]

thanks for all.
our conclusion is: worthless to fix.

Kenji Arisawa

Re: [9fans] shell functions

[arisawa]

Hi, Richard,

Problems comes from careless CGI handling.

keep the following result in mind 
term% 'fn#foo'='fn foo {echo yes}; echo no
'
term% rc
no
term%

today, we have a number of malicious request to our web server.
assume a web server accept a request with a query
query='fn#foo=fn%20foo%20{echo%20yes};%20echo%20no%0a’
if the query is processed as follows: (the explanation is only for demo)
term% query='fn#foo=fn%20foo%20{echo%20yes};%20echo%20no%0a'
term% echo $query
fn#foo=fn%20foo%20{echo%20yes};%20echo%20no%0a
term% ifs='=' a=`{echo -n $query}
term% b=`{echo -n $a(2) | sed 's/%20/ /g; s/%0a/\n/g'}
term% echo -n $b
fn foo {echo yes}; echo no

term% $a(1)=$b
term% rc
no
term%

we can avoid such attacks by putting a prefix (say ‘QS_' as Pegasus does) at 
the last stage.
QS_$a(1)=$b

assume the input field is “name”, then some people believe $a(1) is “name”, and 
may carelessly 
execute for simplicity
$a(1)=$b
and such CGI will work for almost all cases (because they are not malicious).

even if extra command in
fn foo {…}; maliciouscommand
is removed in starting rc, careless handling makes problem.
however it is much different in dangerousness between some environment variable 
are destroyed
and arbitrary commands can be executed. 

Kenji Arisawa

2014/09/28 18:39、Richard Miller 9f...@hamnavoe.com のメール：

 when rc is invoked, rc reconstructs shell variable and shell functions using 
 files in /env/.
 in case of shell functions, rc evaluates whole data in the file.
 this feature makes problem if the content is
  fn foo {…}; maliciouscommand
 
 How would a malicious agent put something into /env?  If it's possible,
 how is this different from putting something into $home/bin/rc or
 binding something into /rc/bin ?
 
 

Re: [9fans] shell functions

[arisawa]

Hello,

when rc is invoked, rc reconstructs shell variable and shell functions using 
files in /env/.
in case of shell functions, rc evaluates whole data in the file.
this feature makes problem if the content is
fn foo {…}; maliciouscommand
I think this problem must be fixed.

Kenji Arisawa

2014/09/27 23:40、Christian Neukirchen chneukirc...@gmail.com のメール：
 
 The problem could be completely avoided if the '{}' were implicit, that
 is, store 
 
 fn foo { echo bar }
 
 as
 
 fn#foo=echo bar
 
 (Also, I heard Research Unix v8 sh(1) stored functions in the environment
 as foo(){ ... }, i.e. without =.  So this never clashes with any
 variable.  Not sure if that works portably enough for plan9port, though.)
 
 -- 
 Christian Neukirchen  chneukirc...@gmail.com  http://chneukirchen.org
 
 

[9fans] segattach in telnetd

[arisawa]

Hello,

we have an example for segattach() in /sys/src/cmd/ip/telnetd.c

void*
share(ulong len)
{
uchar *vastart;

vastart = sbrk(0);
if(vastart == (void*)-1)
return 0;
vastart += 2*1024*1024;

if(segattach(0, shared, vastart, len) == (void*)-1)
return 0;

return vastart;
}

I think it should be
-   if(segattach(0, shared, vastart, len) == (void*)-1)
+   if((vastart = segattach(0, shared, vastart, len)) == (void*)-1)

Kenji Arisawa

Re: [9fans] segattach in telnetd

[arisawa]

Hello,

I think 
vastart += 2*1024*1024; 
is weird.
if we look /proc/$ip/segment in share(), we will have better solution.
but I am not convinced we should apply the solution.
because we seldom needs shared segment.

I haven’t had any trouble with telnetd.
I needed shared segment for special purpose in my program (Pegasus).

thanks

2014/09/14 12:17、cinap_len...@felloff.net のメール：

 why? segattach() gets an explicit address here and
 it should round va down and va+len up as neccesary
 to make them page aligned. but the initial passed
 range should be covered by the created segment
 in any case.
 
 do you have any trouble with telnet that is fixed
 by your change?
 
 --
 cinap