Re: [9fans] recommendations on cpu fossil permissions
As bootes, I can do: # /usr/glenda/bin/rc/pull but typically get something like: error: copying /n/boot/sys/src/9/pc/sdata.c: '/tmp/replica0651' permission denied I think you could just start ramfs(4) before you pull, or otherwise get a writable /tmp in bootes' namespace, to prevent the error above. You can use wstat (in fossilcons(8)) to change uid on files. -Josh
Re: [9fans] 9pfuse adventure
Hi! well, i have been having this error for quite a while with 9pfuse. on amd64 linux (archlinux), i couldn't even ls a mounted directory, now that i have a 32 bit system, ls works, but cp doesn't (i have no idea if it hasanything to do with the arch, though). this is how i mount sources with p9p: $ 9fs sources $ 9 mount `namespace`/sources /tmp/sources then ls in a directory in /tmp/sources works, but when i try to copy, attached is the output. I'm open to testing whatever fixes you might suggest. regs John On Wed, 13 Feb 2008 04:40:27 +0900 sqweek <[EMAIL PROTECTED]> wrote: > On Feb 9, 2008 4:25 AM, Russ Cox <[EMAIL PROTECTED]> wrote: > > > provide any facility to attach as a different user. So, I modified the > > > attach strategy to look for a USER environment variable before falling > > > back on getuser(). I've attached the diff, hopefully I got everything. > > > > The name in the attach is almost just a comment. > > What matters is the name used inside the authentication > > protocol. (The name in the attach is really only there for > > non-authenticated connections.) So these changes > > shouldn't be necessary. > > Hm, I guess u9fs is misbehaving then? > > > This is the problem: you should never be prompted for a > > role=speakfor key. You should be prompted for a role=client key. > > If that happened correctly then I think things would have just > > worked. Try pre-loading a role=client key into factotum and > > see if that works better. > > I'm pretty sure I did have a role=client key in factotum in my > previous attempts, added by drawterm (I have a cpu/authserver on my > home network aswell, with the same user/pass/dom as my u9fs.key). I > reran the tests to be sure, the log is below. It turns out I only get > asked for a speakfor key when using my modified USER code, but it's > still the only way I've got a usable connection. > I had a quick look at u9fs and it does appear to be checking against > the Tattach uname in p9anyattach(), but if that check was failing I > should be getting "authentication failed" not "unknown user". > Um, but that was a pretty silly place to look anyway. There's only > one place "unknown user" is actually returned, and that is after > uname2user fails in rattach() (which was probably the original reason > for my USER hack). > I suspect there is no good solution here since if you called > uname2user() on the auth username, every user would connect with the > same permissions (I assume everyone connecting needs an auth key > matching /etc/u9fs.key?). Maybe it would work with tighter coupling > with the auth server? I never fully grasped the reason behind > /etc/u9fs.key... Otherwise, u9fs needs to be told remotely what uid to > use. > > $ 9p read factotum/ctl > key dom=sqweek.dnsdojo.org proto=p9sk1 role=client user=sqweek !password? > > $ rm `namespace`/wren > $ srv -a sqweek.dnsdojo.org wren > $ 9p ls wren/ > 9p: mount: unknown user > $ USER=sqweek /opt/plan9/src/cmd/o.9p ls wren/ > /opt/plan9/src/cmd/o.9p: mount: unknown user > > $ rm `namespace`/wren > $ srv sqweek.dnsdojo.org wren > $ 9p ls wren/ > 9p: mount: unknown user > $ USER=sqweek /opt/plan9/src/cmd/o.9p ls wren/ > !adding key: role=speakfor proto=p9sk1 dom=sqweek.dnsdojo.org > > -sqweek, thinking he should probably have set inferno up a long time ago cp.output Description: Binary data
[9fans] intel 82598 10gbe
i've submitted a second coraid 10gbe driver to sources for the intel 82598 dual port pcie controller. it should be in the current distribution. the 82598 is intel's second generation 10gbe chipset. it requires no (loaded) firmware, supports up to 16k jumbo frames and is simplier than intel's prior gbe offerings. - erik
Re: [9fans] EWOULDBLOCK in APE
On Mar 21, 2008, at 12:07 AM, Skip Tavakkolian wrote: a couple of weeks ago brucee and i were looking for "wood block" on linux :) here's a little torture: which header file has the errno's on linux? On the contrary: none of them, because if SCO doesn't realize that once they release Unix as OSS they can't sue Torvalds over errno.h there will be none. Why did AT&T sell the rights to Unix in the first place? And why not also V8/V9/V10?
[9fans] IWP9 2008
The web page for the next iwp9 is now available http://iwp9.inf.uth.gr/ Please note the important dates: Aug 31: Paper submission deadline Sep 21: Acceptance notification Oct 12: Camera ready version Oct 12: Registration deadline Oct 30-31: Workshop The PC will be announced soon.
Re: [9fans] IWP9 2008
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > The PC will be announced soon. > "PC" meaning what? D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFH4+veyWX0NBMJYAcRAm5HAKCNQL01wjN6UXAWOK260btBtfEOnACfW5Q3 K1oitsWXMqtHc1xfm3R//+4= =jl+c -END PGP SIGNATURE-
[9fans] 9bench: lmbench for Plan 9
I've just finished porting what we thought were the 8 most useful benchmarks from the lmbench v.2 suite to run natively in Plan 9. The benchmarks are: bw_file_rd: Measure file read bandwidth bw_mem: Measure memory bandwidth for a several different operations bw_pipe: Measure pipe bandwidth bw_tcp: Measure tcp bandwidth on the local machine lat_ctx: Measure context switch latency lat_syscall: Measure system call latency lat_tcp: Measure tcp latency on local system lat_udp: Measure udp latency on local system As I note in the README, lmbench's license carries the additional restriction that you cannot publish results from modified benchmarks, so keep your results to yourself. The source is in /n/sources/contrib/john/9bench.tgz John
Re: [9fans] IWP9 2008
Program Committee The PC will be announced soon. "PC" meaning what?
Re: [9fans] 9bench: lmbench for Plan 9
> As I note in the README, lmbench's license carries the additional > restriction that you cannot publish results from modified benchmarks, > so keep your results to yourself. doesn't generating unpublishable results defeat the purpose of a benchmark? - erik
Re: [9fans] 9bench: lmbench for Plan 9
On Fri, Mar 21, 2008 at 10:51 AM, erik quanstrom <[EMAIL PROTECTED]> wrote: > > As I note in the README, lmbench's license carries the additional > > restriction that you cannot publish results from modified benchmarks, > > so keep your results to yourself. > > doesn't generating unpublishable results defeat the purpose of a benchmark? what is the purpose? ron
Re: [9fans] 9bench: lmbench for Plan 9
> On Fri, Mar 21, 2008 at 10:51 AM, erik quanstrom <[EMAIL PROTECTED]> wrote: > > > As I note in the README, lmbench's license carries the additional > > > restriction that you cannot publish results from modified benchmarks, > > > so keep your results to yourself. > > > > doesn't generating unpublishable results defeat the purpose of a benchmark? > > what is the purpose? i would assume that the main reason to go with an official benchmark is to compare results. if you don't need to compare results and you want to tell if something you've changed has made things faster or slower, i would think rolling one's own would be simple and effective. "time dd ..." is often a great relative measure. - erik
[9fans] System call mania
Hello. I was recently looking in libc when I noticed a few things about system calls: 1) brk and sbrk are implemented atop brk_, which is not documented 2) the seek function seems to be a system call, but the alpha folder defines a function seek which calls _seek 3) Some items in that file have underscores, like BRK_ and _READ This leads me to the following question: what exactly are the system calls in Plan 9? Thanks.
Re: [9fans] System call mania
On 3/22/08, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > Hello. I was recently looking in libc when I noticed a few things > about system calls: > > 1) brk and sbrk are implemented atop brk_, which is not documented > 2) the seek function seems to be a system call, but the alpha folder > defines a function seek which calls _seek > 3) Some items in that file have underscores, like BRK_ and _READ > > This leads me to the following question: what exactly are the system > calls in Plan 9? > grep -i syscall /sys/src/9/port iru
Re: [9fans] System call mania
That confirmed one suspicion: the REAL calls are those who are simply named in /sys/src/libc/9syscall/sys.h, and that the USER-LEVEL calls are a big mess in libc. Thanks! On Mar 22, 2008, at 12:16 AM, Iruata Souza wrote: On 3/22/08, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: Hello. I was recently looking in libc when I noticed a few things about system calls: 1) brk and sbrk are implemented atop brk_, which is not documented 2) the seek function seems to be a system call, but the alpha folder defines a function seek which calls _seek 3) Some items in that file have underscores, like BRK_ and _READ This leads me to the following question: what exactly are the system calls in Plan 9? grep -i syscall /sys/src/9/port iru
Re: [9fans] System call mania
On 3/22/08, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > That confirmed one suspicion: the REAL calls are those who are simply > named in /sys/src/libc/9syscall/sys.h, and that the USER-LEVEL calls > are a big mess in libc. Thanks! > doesn't the name system call suggests you something? iru
Re: [9fans] System call mania
It suggests to me that these calls are the lowest level of communication with the kernel. I once thought that all system calls could be called by a program :-P On Mar 22, 2008, at 12:41 AM, Iruata Souza wrote: On 3/22/08, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: That confirmed one suspicion: the REAL calls are those who are simply named in /sys/src/libc/9syscall/sys.h, and that the USER-LEVEL calls are a big mess in libc. Thanks! doesn't the name system call suggests you something? iru
Re: [9fans] System call mania
On Fri, Mar 21, 2008 at 9:44 PM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > It suggests to me that these calls are the lowest level of > communication with the kernel. I once thought that all system calls > could be called by a program :-P > why do you think that they can't be? ron
