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 prev
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 p9
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 prio
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 a
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
-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-
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:
Program Committee
The PC will be announced soon.
"PC" meaning what?
> 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
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 r
> 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 unp
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 h
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
> defin
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
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
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 suspi
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
17 matches
Mail list logo
