[9fans] Is the go9p project still maintained?
Hi Thanks to everybody who answered. I posted another comment to the issue 34 https://code.google.com/p/go9p/issues/detail?id=34#c2 where explained the use case and provided the diagnostics for the problem. Briefly, the problem is: when using 9p kernel mounts in Linux over a domain socket, a 9p server program never gets a valid numeric user ID, just -1 regardless of the username. Even if there was a way to pass desired numeric UID to a 9p server, this would make little sense in case of a remote connection because on the remote system the same user would have different (and often unknown numeric ID). So even in the .u mode, fallback character username recognition is necessary to use if no valid numeric user ID can be provided. Thanks. -- Dmitry Golubovsky Anywhere on the Web
[9fans] Is the go9p project still maintained?
Hi Just wondering if the project https://code.google.com/p/go9p/ is actively maintained these days? I used it in my project, but fixing issue 30 broke it. I opened issue 34 https://code.google.com/p/go9p/issues/detail?id=34 which also contains a suggested patch. No response since then. If the project's active repo moved please let me know, I'll resubmit the issue there. If the project is not maintained anymore I'll take care of it in my project's local repo. Thanks. -- Dmitry Golubovsky Anywhere on the Web
[9fans] plan9port and procexecl
Hi,
I have a piece of code which compiles and works fine in Plan9:
void
execproc(void *v)
{
Channel *sync;
Exec *e;
int q[2];
char *cmd;
threadsetname(execproc);
e = v;
q[0] = e-q[0];
q[1] = e-q[1];
cmd = e-cmd;
sync = e-sync;
rfork(RFFDG);
free(e);
if(q[0]){
dup(q[1], 1);
close(q[0]);
close(q[1]);
}
procexecl(sync, /bin/rc, rc, -c, cmd, 0);
sysfatal(can't exec);
}
(partly stolen from abaco, it runs a command in a proc and pipes the
output).
In plan9port the compiler complains for undefined procexecl, and the
linker fails.
What would be the closest analog of procexecl for plan9port?
Thanks.
Re: [9fans] 9vx and create (...DMEXCL)
Hi, OK, thanks for the clue. Unfortunately, this (devfs-posix.c in 9vx): if(perm ~(DMDIR|0777)) error(Ebadarg); generates the error, and the values of DMEXCL and DMAPPEND do not seem to fit into Unix permissions. So these won't work in 9vx as long as the host filesystem is used*. * Unless the host FS is ext?fs and the kernel supports extended attributes which may require specific patches On Dec 22, 4:50Â am, fors...@terzarima.net (Charles Forsyth) wrote: no, it won't: OEXCL, perhaps, but not DMEXCL. i'd have thought it should be used in fscreate, though, to help chan.c implement OEXCL correctly. fscreate should fail if the file exists, but perhaps that happens another way. Dmitry.
Re: [9fans] 9vx srashes when idle
On Oct 26, 1:06Â am, rminn...@gmail.com (ron minnich) wrote:
this info needs more info.
what OS? What version? What compiler? What version?
thanks
ron
Died again (less than a minute after start)
I started 9vx -t, maximized 9vx window, killed acme and shell window
that are created by the profile, opened one shell window, did notning
in it, put 9vx window into background.
./9vx -t
init: starting /bin/rc
upas/fs: opening /mail/box/dima/mbox: '/mail/box/dima' does not exist
echo: write error: unknown control message accelerated
echo: write error: unknown control message res 3
cpu0: registers for stats 76
FLAGS=0 TRAPP0 ECODE=0 PCsB1 USPÿFFCD8
AX BX 0E64 CX 0E83 DX
SI 0DF4 DI 00022B45 BP
9vx panic: unknown trap/intr: 0x500
aborting, to dump core.
Aborted
Another experiment.
Started 9vx -t, maximized window, put it into background. It was there
for several minutes, no crash. Then I killed initial acme and shell
window, started new shell window. It chashed:
init: starting /bin/rc
upas/fs: opening /mail/box/dima/mbox: '/mail/box/dima' does not exist
echo: write error: unknown control message accelerated
echo: write error: unknown control message res 3
cpu0: registers for stats 76
FLAGS=0 TRAPP0 ECODE=0 PC{CA USPÿFFD44
AX BX 00022B40 CX 0DF4 DX 00022000
SI 0DF4 DI BP
9vx panic: unknown trap/intr: 0x500
aborting, to dump core.
Aborted
Re: [9fans] 9vx srashes when idle
Hi, On Oct 26, 1:06Â am, rminn...@gmail.com (ron minnich) wrote: this info needs more info. what OS? What version? What compiler? What version? thanks ron uname -a Linux archgui 2.6.27-ARCH #1 SMP PREEMPT Sun Dec 21 09:31:10 UTC 2008 i686 QEMU Virtual CPU version 0.9.1 AuthenticAMD GNU/Linux that is, a VM (Arch Linux) running under KVM on Ubuntu Intrepid (64bit host) kvm --help QEMU PC emulator version 0.9.1 (kvm-72), Copyright (c) 2003-2008 Fabrice Bellard gcc --version gcc (GCC) 4.3.2 Copyright (C) 2008 Free Software Foundation, Inc. Thanks. Dmitry
Re: [9fans] 9vx srashes when idle
One more kind of trap (did not cause crash) - not sure when exactly it happened: 76 stats fault 0x33c no segment segment 0xf00 0x1000 segment 0x1000 0x1b000 segment 0x1b000 0x22000 segment 0x22000 0x3a000 76 stats: unhandled fault va=33c [97df233c] eip=33c cpu0: registers for stats 76 FLAGS=0 TRAP=0 ECODE=0 PC=33C USP=E48 AX 00038F1C BX 0DF4 CX 00022D08 DX 00039254 SI 00038F18 DI 00038F1C BP Has anyone else seen these dumps with 9vx?
Re: [9fans] Two suggestions for ape (was: egrep for Plan9)
Tim, On Oct 23, 2:23Â pm, news...@lava.net (Tim Newsham) wrote: What if you just made a command gnuconfig which rewrote the configure script, fixing the minor defects, and ran the result? Or bound in a dummy ls and egrep before executing the real configure script? Lets keep the infection contained. If I need to fix this for my project only, I have already done that. The problem is, everyone who generates configure by this version (or some range of versions) of autoconf would run into this because this is inserted in the configure's initialization code without any feature tests requested by configure.ac Since the purpose of ape is to emulate the environment configure is expected to run in, and such mismatch has been found, it migh be easier to fix ape than to convince maintaners of autoconf to fix on their side... Dmitry.
Re: [9fans] Two suggestions for ape (was: egrep for Plan9)
On Oct 26, 9:21Â am, 23h...@googlemail.com (hiro) wrote: Since the purpose of ape is to emulate the environment configure is expected to run in, and such mismatch has been found, it migh be easier to fix ape than to convince maintaners of autoconf to fix on their side... Why are you so sure they wouldn't fix it? Have you or has anybody you know tried something like this already? Because even if they fix it in the current (or perhaps the nearest future) version (in repos now) of autoconf this would not apply retroactively to previous/current versions everyone has. Besides, one thing (very long regexp to match all ASCII letters and numbers in a CPP directive - see the thread on awk incompatibility) is done on purpose: they specifically wanted to avoid character ranges (perhaps wrt some locales where a-z range might also include letters with diacritics, but this is only my guess). Regexp buffer length limitation in Plan9 awk may be more fundamental problem. Well, these problems arise only if one wants to have a port for Plan9 share the sources with upstream (hence to have common configure scripts, Makefiles, tools, etc.) If a fork-style port for Plan9 is considered then of course everything may be adjusted properly (like configure is not needed at all because there is only one configuration, etc.). Thanks.
Re: [9fans] 9vx srashes when idle
On Oct 26, 11:09Â am, rminn...@gmail.com (ron minnich) wrote: Has anyone else seen these dumps with 9vx? never seen anything like it, which leads me to wonder if you are not tickling a bug in the virtualization. ron- Hide quoted text - - Show quoted text - It could be since it is twice virtualized ;)
Re: [9fans] Two suggestions for ape (was: egrep for Plan9)
Charles, On Oct 23, 10:40Â am, fors...@terzarima.net (Charles Forsyth) wrote: it's /rc/bin/ape/ls that would change, not Plan 9's ls-proper. Of course ape's one. As well as I am proposing to add egrep to ape's tree not Plan9's native tree. what does autoconf do with the `inode number'? In fact, nothing is done with inode number. Autoconf generates code to obtain the current directory which involves ls -di. Here is the macro in /usr/share/autoconf/autoconf/general.m4 that causes the problem: # _AC_INIT_DIRCHECK # - # Set ac_pwd, and sanity-check it and the source and installation directories. # # (This macro is AC_REQUIREd by _AC_INIT_SRCDIR, so it has to be AC_DEFUNed.) # AC_DEFUN([_AC_INIT_DIRCHECK], [m4_divert_push([PARSE_ARGS])dnl ac_pwd=`pwd` test -n $ac_pwd ac_ls_di=`ls -di .` ac_pwd_ls_di=`cd $ac_pwd ls -di .` || AC_MSG_ERROR([Working directory cannot be determined]) test X$ac_ls_di = X$ac_pwd_ls_di || AC_MSG_ERROR([pwd does not report name of working directory]) m4_divert_pop([PARSE_ARGS])dnl ])# _AC_INIT_DIRCHECK I have redefined the macro locally to use only ls -d, it works. the problem is, as can be seen: ls -di is hardcoded in assumption that every ls understands it. I use autoconf 2.63. This macro might be different in older versions. I am currently looking at configure in the same project archive created with 2.59 (in 2007), I cannot see traces of this macro there, although configure.ac was likely the same. This test (as well as egrep test) is something autoconf uses for internal purposes. Jason: I understand your reasoning. However if two small fixes would unblock execution of many projects' configure on Plan9 IMHO they are worth making; they won't break anything. Thanks. Dmitry
Re: [9fans] ape/psh can't exec in 9vx
On Oct 19, 11:50Â am, r...@swtch.com (Russ Cox) wrote: /bin/sh: uname: cannot execute - Access denied I believe that if you build a new binary from the sources instead of using the pre-compiled binary, this bug is fixed. The binaries are lagging behind the actual source code. Yes, doing the both things have helped.
Re: [9fans] ape/psh (still) can't exec in 9vx
On Oct 19, 11:50Â am, mirtchov...@gmail.com (andrey mirtchovski) wrote: % ape/psh $ uname /bin/sh: uname: cannot execute - Access denied % cd /sys/src/ape % mk install mk lib.install mk cmd.install mk 9src.install [...] cp 8.tar /386/bin/ape/tar % ape/psh $ uname Plan9 $ OK, maybe I just did not complete the whole thing. I'll try this. Thanks.
Re: [9fans] ape/psh can't exec in 9vx
On Oct 19, 11:50Â am, r...@swtch.com (Russ Cox) wrote: /bin/sh: uname: cannot execute - Access denied I believe that if you build a new binary from the sources instead of using the pre-compiled binary, this bug is fixed. The binaries are lagging behind the actual source code. Russ OK, I'll try both this and what Andrey recommended. Thanks.
