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
