Re: [9fans] 9vx

["Russ Cox" <rsc@swtch.com>]

Replying to many messages/threads ...

----------
> i've not had a chance to look through the sources.  is a windows port
> feasible?

It should be doable.  You need equivalents of mmap,
mprotect, munmap, signal handlers, timer signals,
and some function to install new segment descriptors.
All of these exist on Windows XP.  The last may or may
not exist anymore on Vista; I have heard conflicting reports.

It's doable, but you'd have to be comfortable with writing
and debugging very low-level code.  It is close to bringing
Plan 9 up on a new machine.  Easier to debug than real
hardware, but that's not saying much.  And getting floating
point working is typically more difficult than on real hardware,
since the hardware has an accurate manual.


----------
> If you call translating the X API to Win32 or C++ .NET feasible, then yes!
> I'm struggling to Cocoa-ize it. It seems like a much easier job than with
> drawterm.

The graphics code should be the least of your problems.
That code hasn't been changed much since drawterm,
so you should be able to just drop the drawterm version in.

> I believe the only folder you need to update is src/9vx/x11. It's seven
> files of pure evil.

Thanks for the ringing endorsement.

> I'm struggling to Cocoa-ize it. It seems like a much easier job than with
> drawterm.

Instead of starting over, just drop in the drawterm code
and adjust until it fits.  It's almost exactly the same interface.

In fact much of the code is exactly the same as drawterm,
there's just this new x86 engine dropped into the mix.
I would definitely look there first if I wanted to add something.


----------
> I haven't looked at anything at all, but I've also never seen such a
> happy reception on this list.  Please excuse the possible stupidity of
> this question: is a Plan 9 port feasible?

Not with Plan 9 as it stands right now.  The virtual memory
system is really not set up for page-at-a-time mappings
like 9vx needs, and there's no facility to create new segment
descriptors, though that would be easier to fix.  One also
wonders what use it would be.  You could just start a new
shell and fiddle with its name space instead.


----------
>> Well, unless I'm missing something either obvious
>> or clever, the answer is no.  A Linux special file
>> looks like a zero length regular file to 9vx.  I
>> probably should have expected that.
>
> the bits from p9p's _p9dir.c which were discussed the
> other day could be used to solve that problem.

Added these yesterday afternoon (still have to set up
a public repository somewhere.)

> I guess I'll sleep on the question of whether to just
> use regular files or do something like a driver to
> go with devsd.

I added devsd and wrote an sd loopback yesterday afternoon.
It worked pretty well except that when I ran fdisk,
/dev/sd00/data disappeared.  I was going to debug that
before saying anything.

vx32% ls -l /dev/sd*
--rw-r----- S 0 rsc rsc 0 Jun 27 15:39 /dev/sdctl
vx32% bind '#Z' /n/unix
vx32% ls -l /n/unix/dev/sda
--rw-rw---- Z 2 root rsc 250059350016 May 17 16:12 /n/unix/dev/sda
vx32% echo loop rw /n/unix/dev/sda >/dev/sdctl
vx32% ls -l /dev/sd*
--rw-r----- S 0 rsc rsc            0 Jun 27 15:39 /dev/sd00/ctl
--rw-r----- S 0 rsc rsc 250059350016 Jun 27 15:39 /dev/sd00/data
-lrw------- S 0 rsc rsc            0 Jun 27 15:39 /dev/sd00/raw
--rw-r----- S 0 rsc rsc            0 Jun 27 15:39 /dev/sdctl
vx32% disk/fdisk -p /dev/sd00/data >/dev/sd00/ctl
vx32% ls -l /dev/sd*
--rw-r----- S 0 rsc rsc            0 Jun 27 15:39 /dev/sd00/ctl
--rw-r----- S 0 rsc rsc 243830168064 Jun 27 15:39 /dev/sd00/linux
--rw-r----- S 0 rsc rsc   6226504704 Jun 27 15:39 /dev/sd00/linuxswap
-lrw------- S 0 rsc rsc            0 Jun 27 15:39 /dev/sd00/raw
--rw-r----- S 0 rsc rsc            0 Jun 27 15:39 /dev/sdctl
vx32%


----------
> Wow. This is cool! I can now test my ports locally.  It should be possible
> for two 9vx instance to communicate with each other right?

Sure.  They all share the host's IP stack.

Also, I should add that #Z knows how to open
Unix domain sockets, you can mount p9p servers:

vx32% bind '#Z' /n/unix
vx32% aux/stub -d /mnt/factotum
vx32% mount /n/unix/tmp/ns.rsc.:0/factotum /mnt/factotum
vx32% ls -l /mnt/factotum
-lrw------- M 15 rsc rsc 0 Jun 28 11:11 /mnt/factotum/confirm
--r-------- M 15 rsc rsc 0 Jun 28 11:11 /mnt/factotum/conv
--rw------- M 15 rsc rsc 0 Jun 28 11:11 /mnt/factotum/ctl
-lrw------- M 15 rsc rsc 0 Jun 28 11:11 /mnt/factotum/log
-lrw------- M 15 rsc rsc 0 Jun 28 11:11 /mnt/factotum/needkey
--r--r--r-- M 15 rsc rsc 0 Jun 28 11:11 /mnt/factotum/proto
--rw-rw-rw- M 15 rsc rsc 0 Jun 28 11:11 /mnt/factotum/rpc
vx32%

(The aux/stub is needed because p9p factotum doesn't
present the top-level factotum directory that Plan 9's does,
unless you start it with the -x flag.  Could make that an
attach specifier instead.)


----------
>> libvx32/freebsd.c:20:2: warning: #warning "libvx32 and FreeBSD 5 and 6's libpthread are not compatible."
>>
>> I guess the priority of my "upgrade laptop's FreeBSD" thread has
>> just increased.
>
> Life is so boring when your OS doesn't break compatibility with
> existing APIs every other release... but my heart is torn between
> FreeBSD and OS X; ah I got the solution: whoever breaks backwards
> compatibility (again) first wins! I'm in a hurry to pick my next OS,

FreeBSD is *very* good about backward compatibility,
about as good as Plan 9 is.  I can still run decade old
FreeBSD binaries.  The problem here isn't backward
compatibility.  It's that FreeBSD, like Linux and the others,
took a while to figure out that threads really need to
be implemented by the kernel, and they didn't get around
to that until FreeBSD 7.


----------
My plan is to push out a new release once someone
finds and fixes the OS X cpu bug.  Anyone?



Russ