> 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
