Re: [9fans] Acme and unicode

[hugo rivera]

Thanks a lot for your help, I am not sure what I was doing, but now
everything is ok.
Saludos

Hugo

[9fans] libbio and large files

[Jeff Sickel]

This question may be more applicable when addressing p9p on other  
systems:


I'm seeking a little clarification about Bopen and reading through  
files larger than (2^31 bytes).  Other host systems where p9p works  
(very well I might add) tend to have different definitions for off_t  
depending on 32/64 bit support (some require off64_t while others do  
contortions around redefining off_t depending on the joy of compiler  
flags, both leading to other incantations that may require  
orthodontia), how does one go about ensuring that their host OS does  
properly access large files properly when using libbio?


Also--shouldn't binit.c:125 in p9p be updated to the changes found on  
sources?


cpu % history -D binit.c
...
/n/sourcesdump/2008/0430/plan9/sys/src/libbio/binit.c:108 c /n/ 
sourcesdump/2005/0829/plan9/sys/src/libbio/binit.c:108

f = open(name, OREAD);
...


-jas

Re: [9fans] P9P on Solaris

[Brian L. Stuart]

> I'm sorry about that.  There aren't supposed to be 
> anonymous unions and structs in the source code,
> but they creep in.  I've removed them from hfs.h.

Thanks, that got me farther.  I was able to coerce it
to build the libraries and some applications.  But,
surprise surprise, the threading isn't working.  In
playing the the tprimes thread test program, I've found
that it's aborting in needstack().  The first time
it gets called, t->stk==f334, t->id==4280014785
and t->stksize==10.  The next time it gets called
(using the same _Thread structure instance), t->stk==0,
t->id==0, and t->stksize==213456.  So it looks like
something is scribbling on that structure.

That's as far as I've gotten today.  I'm trying to
get vbackup running on Solaris.  It's not critical,
but it'd be nice.

> I gave up long ago on keeping Solaris builds working
> myself.  Logging into a Solaris machine is like going
> back in time.  I'm happy to accept patches though.

I completely understand.  If I get any real success,
I'll pass along the patches.

Thanks,
BLS

[9fans] blbooks.html

[Pietro Gagliardi]

Hello. Does anyone know what happened to http://www.bell-labs.com/blbooks.html 
 and what the list there is? Thanks.

Re: [9fans] P9P on Solaris

[Russ Cox]

> Thanks, that got me farther.  I was able to coerce it
> to build the libraries and some applications.  But,
> surprise surprise, the threading isn't working.  In
> playing the the tprimes thread test program, I've found
> that it's aborting in needstack().  The first time
> it gets called, t->stk==f334, t->id==4280014785
> and t->stksize==10.  The next time it gets called
> (using the same _Thread structure instance), t->stk==0,
> t->id==0, and t->stksize==213456.  So it looks like
> something is scribbling on that structure.

That's probably because the stack pointer points at
the wrong end of the stack.  There are some magic
#defines you can put in that change the meaning of
the stack pointer field that you pass to makecontext
on Solaris.  In one mode you set ss_sp to point at 
the top of thestack; in the other mode, the bottom.
The different versions of Solaris differ on which mode
is the default and whether the other mode is even 
available.  This is the specific reason I gave up.  If someone
lined up Solaris 5.8, 5.9, and 5.10 boxes and wrote
code that worked on all of them, that would be fantastic.
g sigh $PLAN9/src/libthread/thread.c
You may be able to solve your particular problem by 
changing that #if to #if 1.

> That's as far as I've gotten today.  I'm trying to
> get vbackup running on Solaris.  It's not critical,
> but it'd be nice.

Once you get the thread library working,
you will probably have to add support for
the Solaris FS to libdiskfs, unless it is the
same FFS that BSD uses.

Russ

[9fans] x86 segment register

[cinap_lenrek]

Hi,

while implementing TLS support for linuxemu in Plan9 pc kernel i
learned that loading segment registers referencing bogus descriptors
generates a GP fault...  in the noted() function from pc/trap.c here
is a comment and code, that kills the program if a note-handler tries
to change segment registers to something other than the user data
segment.

found, that you can crash the kernel by writing bogus segment
registers via devproc regs file (/proc/$pid/regs).  devproc overrides
the (saved) registers of a process by calling setregisters() in
pc/trap.c.  this function takes care of not changing the segment
registers cs and ss for exact that reason, but on the other hand
allows modification of ds, es, fs and gs what can result in a
kernelpanic too when forkret() in pc/l.s tries to load/restore them.
is here a special reason for allowing change of that registers?
otherwhise maybe handle them like cs and ss?


void
setregisters(Ureg* ureg, char* pureg, char* uva, int n)
{
ulong flags;
ulong cs;
ulong ss;
+   ulong ds, es, fs, gs;

flags = ureg->flags;
cs = ureg->cs;
ss = ureg->ss;
+   ds = ureg->ds;
+   es = ureg->es;
+   fs = ureg->fs;
+   gs = ureg->gs;
memmove(pureg, uva, n);
ureg->flags = (ureg->flags & 0x00FF) | (flags & 0xFF00);
ureg->cs = cs;
ureg->ss = ss;
+   ureg->ds = ds;
+   ureg->es = es;
+   ureg->fs = fs;
+   ureg->gs = gs;
}

i attached a test program to this email to reproduce the thing.

cinap
#include 
#include 
#include 

void main(int argc, char *argv[])
{
int fd;
char name[64];
struct Ureg reg;

snprint(name, sizeof(name), "/proc/%d/regs", getpid());
if((fd = open(name, ORDWR)) < 0){
fprint(2, "cant open my regs: %r\n");
exits("open");
}

if(read(fd, ®, sizeof(reg)) < 0){
fprint(2, "read of regs failed: %r\n");
exits("read");
}
reg.gs = 666; /* some shit */
if(write(fd, ®, sizeof(reg)) < 0){
fprint(2, "write of regs failed: %r\n");
exits("write");
}

fprint(2, "fixed!\n");
close(fd);
}