[9fans] P9P on Solaris

[9fans] P9P on Solaris

[Brian L. Stuart]

What compiler has been successfully used to build
p9p on Solaris?  I've got a Solaris 9 install and
have tried the gcc 2.95 from the extras cd and Sun
Studio 11 and both have heartburn on the anonymous
unions and structs used in hfs.h in libdiskfs.

Thanks,
BLS

Re: [9fans] P9P on Solaris

[Russ Cox]

> What compiler has been successfully used to build
> p9p on Solaris?  I've got a Solaris 9 install and
> have tried the gcc 2.95 from the extras cd and Sun
> Studio 11 and both have heartburn on the anonymous
> unions and structs used in hfs.h in libdiskfs.

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.

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.

Russ

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==f3333334, 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

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==f3333334, 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

Re: [9fans] P9P on Solaris

[Brian L. Stuart]

> 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
> ...
> 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.

I know it's been a while, but that got me farther.  The
odd thing is that I had already played with the magic
define, but it seems that __sun__ wasn't getting set.
I'll take a look at that before I send any patches.
It turns out that Solaris does use the FFS, but it
uses version 1.  So I did some work on V1 to get it
working.  I'm hoping that all the other instances of
FFS are V2 so that we don't have to figure out some
way to handle both.

Anyway, the main changes:
- It would appear that FFS V2 specifies most things
in terms of blocks, but V1 in terms of fragments.
I think the changes I made to handle V1 will still
work with V2, but I don't have a V2 machine set up
at the moment to test it on.
- There's also a discrepancy between the V1 inode
defined in ffs.h and the one defined in the Solaris
header files.  It ends up messing up the UID and
GID fields.
- Then there's byte ordering.  In the setup I'm playing
with, venti is running on a 386 taking vbackup blocks
from a SPARC. So I added conditional byte swapping
to the handling of the superblock, the cylinder blocks,
the inodes and the directory entries.  It basically
looks at the magic number and if it would be correct
swapped, we take that as good enough and set a flag
to swap everything.
- Because I'm introducing venti into a UNIX environment
instead of putting a UNIX machine in a Plan 9 environment,
I need to at least have the option of traditional
superuser behavior.  So I added an insecure (-i) flag
to vnfs.  It turns off the mapping from UID/GID 0 to
-1.  Then in ffs.c, I allowed the traditional uid 0
gets all access.

I think that's all.  At least it's the big stuff.  Once
I get the code cleaned up, I'll send some patches.

Thanks for the help,
BLS

Re: [9fans] P9P on Solaris

[Russ Cox]

> I know it's been a while, but that got me farther.  The
> odd thing is that I had already played with the magic
> define, but it seems that __sun__ wasn't getting set.

Bug in 9c.  Fixed and pushed.

> - There's also a discrepancy between the V1 inode
> defined in ffs.h and the one defined in the Solaris
> header files.  It ends up messing up the UID and
> GID fields.

Please compare against the BSD sources if you get
a chance -- I hope I just misread the data structure.

> the inodes and the directory entries.  It basically
> looks at the magic number and if it would be correct
> swapped, we take that as good enough and set a flag
> to swap everything.

Great, thanks.

> - Because I'm introducing venti into a UNIX environment
> instead of putting a UNIX machine in a Plan 9 environment,
> I need to at least have the option of traditional
> superuser behavior.  So I added an insecure (-i) flag
> to vnfs.  It turns off the mapping from UID/GID 0 to
> -1.  Then in ffs.c, I allowed the traditional uid 0
> gets all access.

It's interesting you view that as Plan 9-specific.
I was just mimicking the usual Unix NFS behavior.

Russ

Re: [9fans] P9P on Solaris

[Brian L. Stuart]

> > I know it's been a while, but that got me farther.  The
> > odd thing is that I had already played with the magic
> > define, but it seems that __sun__ wasn't getting set.
>
> Bug in 9c.  Fixed and pushed.

Cool.

> Please compare against the BSD sources if you get
> a chance -- I hope I just misread the data structure.

I will.  I've got a couple NetBSD machines at home I can
check, but I'd bet they're V2, and the bug was only in
the V1 inode structure.  I might play archaeologist
and see what BSD4.3 or 4.4 have.

> > - Because I'm introducing venti into a UNIX environment
> > instead of putting a UNIX machine in a Plan 9 environment,
> > I need to at least have the option of traditional
> > superuser behavior.  So I added an insecure (-i) flag
> > to vnfs.  It turns off the mapping from UID/GID 0 to
> > -1.  Then in ffs.c, I allowed the traditional uid 0
> > gets all access.
>
> It's interesting you view that as Plan 9-specific.
> I was just mimicking the usual Unix NFS behavior.

Unless my brain cells are dying of old age, I seem to
remember that most implementations allow that behavior
to be turned on or off in the file that defines the
exports.  And before this, I had been playing with
the Plan 9 nfs server and came across how it squashes
everything to none.  Rob's comments seemed to indicate
that the rationale was that UNIX security is too weak
to be trusted in a Plan 9 environment.  It was all
that rolling around in my head that had me looking
at it from that perspective.

Thanks,
BLS