[9fans] 9vx

[9fans] 9vx

[Ben Huntsman]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

Hi there
   Does anyone still use 9vx for anything?  Anyone ever look at adding a cocoa/metal GUI layer for more recent Mac OS X?  I'm looking at drawterm-cocoa as a starting point.

   This is a losing game for sure, since Apple dropped 32-bit binary support, but most of the project still compiles with XCode 9.4.1 under Mojave...  Another interesting project would be seeing if it could be modified to work as a 64-bit binary but still running a 32-bit environment on the inside...

   Thanks much, as always!

-Ben


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T13921a25ae477a65-M8261c3c4a52e717756b68e39
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2657 bytes --]

Re: [9fans] 9vx

[David du Colombier]

>    Does anyone still use 9vx for anything?  Anyone ever look at adding 
> a cocoa/metal GUI layer for more recent Mac OS X?  I'm looking at 
> drawterm-cocoa as a starting point.
>
>    This is a losing game for sure, since Apple dropped 32-bit binary 
> support, but most of the project still compiles with XCode 9.4.1 under 
> Mojave...  Another interesting project would be seeing if it could be 
> modified to work as a 64-bit binary but still running a 32-bit 
> environment on the inside...

I'm using 9vx daily, but on Linux only.

-- 
David du Colombier

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T13921a25ae477a65-M6dd9563dccda0b3a2930cdfd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9vx

[Stuart Morrow]

> Another interesting project would be seeing if it could be
> modified to work as a 64-bit binary but still running a 32-bit environment
> on the inside...


https://pdos.csail.mit.edu/papers/vx32:usenix08/#:~:text=The%20recent%2064,bit%20host%20application.

This needs to happen. I'd use it.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T13921a25ae477a65-M4468dd505f1dd37b95637658
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9vx

[hiro]

in case somebody else is wondering what Stuart is talking about, he's
referencing a specific text passage using one of these google chrome
specific features:

https://web.dev/text-fragments/

On 6/26/23, Stuart Morrow <morrow.stuart@gmail.com> wrote:
>> Another interesting project would be seeing if it could be
>> modified to work as a 64-bit binary but still running a 32-bit
>> environment
>> on the inside...
> 
> 
> https://pdos.csail.mit.edu/papers/vx32:usenix08/#:~:text=The%20recent%2064,bit%20host%20application.
> 
> This needs to happen. I'd use it.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T13921a25ae477a65-M88a880c0f59a83705d10b847
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9vx

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

I'm using it on a daily base for development and as a server plattform. 

9vx is my terminal, while I use geany editor from linux as an editor. 9p filesystems can easily be started for data transfer with native 9legacy. The only feature I miss in 9vx is the lack of some plan9 devices in my case the #g (segment) device which I use for shared memory on 9legacy forks to create my graphical framebuffer and font infrastructure. But there is a simple workaround for this problem so I don't mind it too much. 

9vx is extremly fast I can compile the kernel and userland in less than 2 minutes and the greatest advantage is the ability to use the underlying host filesystem directly from within linux. 

When I started kernel development with 9legacy after the licence changes I was looking for some way to exchange data between host and guest when someone pointed me to 9vx and afterwards it became my "thats it" solution.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T13921a25ae477a65-M2906ba611422c3ebd4e2fa7e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1772 bytes --]

Re: [9fans] 9vx

[Russ Cox]

the current 9vx tree builds and runs fine
using ubuntu on x86-64:

c2=; cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.10
DISTRIB_CODENAME=intrepid
DISTRIB_DESCRIPTION="Ubuntu 8.10"
c2=; uname -a
Linux c2 2.6.27-9-generic #1 SMP Thu Nov 20 22:15:32 UTC 2008 x86_64 GNU/Linux
c2=;

the tree has been broken for a few months.
i removed -fno-inline from the gcc command line
but apparently that was making gcc work!

if you have a partially built tree, you need to
make clean after pulling the updates.

russ

Re: [9fans] 9vx

[ron minnich]

On Fri, Jun 27, 2008 at 8:17 AM, Russ Cox <rsc@swtch.com> wrote:

> if you make clean
> and then edit the top-level src/Makefrag file to add -m32
> to the HOST_CFLAGS and then make 9vx/9vx
> you are likely to get a working binary.

I'm just trying this now. I was missing stubs-32.h on FC9.
I had to do this:

sudo yum install compat-gcc-34 compat-gcc-34-c++

It's a very important file; it has stuff like this in it :-)

#ifdef _LIBC
 #error Applications may not define the macro _LIBC
#endif

#define __stub___kernel_cosl
#define __stub___kernel_sinl
#define __stub___kernel_tanl
#define __stub_chflags
#define __stub_fattach
#define __stub_fchflags
#define __stub_fdetach
#define __stub_gtty
#define __stub_lchmod
#define __stub_revoke
#define __stub_setlogin
#define __stub_sigreturn
#define __stub_sstk
#define __stub_stty

Pretty!

I also had to do this:
diff -r a18e9872164b src/9vx/Makefrag
--- a/src/9vx/Makefrag	Wed Dec 10 03:29:15 2008 -0800
+++ b/src/9vx/Makefrag	Mon Apr 27 22:02:37 2009 -0700
@@ -124,7 +124,8 @@
 		x11-kernel.o \
 		x11-keysym2rune.o \
 	)
-PLAN9_x11_LIBS = -L/usr/X11R6/lib -L/usr/local/lib -lX11
+#PLAN9_x11_LIBS = -L/usr/X11R6/lib -L/usr/local/lib -L/usr/lib -lX11
+PLAN9_x11_LIBS =  /usr/lib/libX11.so.6

 PLAN9_osx_OBJS =\
 	$(addprefix 9vx/osx/, \
@@ -148,7 +149,7 @@
 	libvx32/libvx32.a \

 9vx/9vx: $(PLAN9_DEPS)
-	$(HOST_CC) -o $@ $(PLAN9_DEPS) $(PLAN9_GUI_LIBS) -lpthread
+	$(HOST_CC) $(HOST_LDFLAGS) -o $@ $(PLAN9_DEPS) $(PLAN9_GUI_LIBS) -lpthread

 9vx/a/%.o: 9vx/a/%.c
 	$(HOST_CC) $(HOST_CFLAGS) -I. -I9vx -I9vx/a -Wall
-Wno-missing-braces -c -o $@ $<
diff -r a18e9872164b src/Makefrag
--- a/src/Makefrag	Wed Dec 10 03:29:15 2008 -0800
+++ b/src/Makefrag	Mon Apr 27 22:02:37 2009 -0700
@@ -1,9 +1,9 @@
 # Main top-level makefile fragment for the vx32 virtual machine.

 # Compiler flags common to both host and VX32 environment files.
-COMMON_CFLAGS = -g -O3 -MD -std=gnu99 -I. $(CFLAGS)
+COMMON_CFLAGS = -g -O3 -MD -std=gnu99 -I. $(CFLAGS) -m32
 #COMMON_CFLAGS = -g -MD -std=gnu99 -I. $(CFLAGS)
-COMMON_LDFLAGS = -g -L. $(LDFLAGS)
+COMMON_LDFLAGS = -g -L. $(LDFLAGS) -m32

 # Host environment compiler options
 HOST_CC		:= $(CC)

Comments:
1. No, it can't find -lX11 even with a little hand-holding -L/usr/lib
to help it. Don't know, don't care...
2. It really seems to need HOST_LDFLAGS to work correctly on the
9vx/9vx link step.
3. It didn't work well for me unless I put -m32 on the COMMON_CFLAGS
4. I think what I'm doing with LDFLAGS is wrong wrong wrong

And, well, it builds. But it dies.

 9vx panic: user fault: signo=11 addr=0 [useraddr=28054000] read=1
eip=80c222a esp=d724cd5c
aborting, to dump core.

which is:
0x080c2228 <vxrun+24>:	mov    %eax,%es
0x080c222a <vxrun+26>:	mov    %eax,%ss

which makes sense I guess.

Anyway, I figure I'll go back and look some more. Probably reset my
changes first.

ron

Re: [9fans] 9vx

[Russ Cox]

run gdb on the 9vx binary and type

list *0x80123123

russ

[9fans] 9vx

[erik quanstrom]

suppose i have a typical kernel complaint giving a
address of a lock or some such.  what's the easiest way
to figure out what's at that address?  the equivalent
of src($address) or just $address in acid with the normal
kernel.

- erik

Re: [9fans] 9vx

[erik quanstrom]

rc bug.  it appears something is going wrong
with rc's local assignments.  ifs has the usual
value.

; font=/lib/font/bit/cyberbit/mod*.font rio
rio: can't access /lib/font/bit/cyberbit/mod\x01*.font: bad character in file name: '/lib/font/bit/cyberbit/mod\x01*.font'
; unicode \x01
0001
; echo /lib/font/bit/cyberbit/mod*.font
/lib/font/bit/cyberbit/mod14.font
; x=/lib/font/bit/cyberbit/mod*.font
; whatis x
x=/lib/font/bit/cyberbit/mod14.font

- erik

Re: [9fans] 9vx

[Russ Cox]

> yup.  9vx creates ctl files without a "geometry line".
> libdisk/disk.c:/^opensd demands it.

thanks.

> also, it would be nice if 9vx devsd created an entry
> in sdctl for each loopback controller.

i intended it to, though perhaps i messed that up.

> i apologize for not sending a patch.  i haven't yet
> gotten the vx32 compilers working on my machine.
> i'm sure this is operator error.

you don't need them to build 9vx.
just "make 9vx/9vx" instead of make.

looking forward to a patch.  ;-)

russ

Re: [9fans] 9vx

[erik quanstrom]

> The bug is in devsd, though you'll probably have to
> add prints to fdisk to find it.
>

yup.  9vx creates ctl files without a "geometry line".
libdisk/disk.c:/^opensd demands it.

also, it would be nice if 9vx devsd created an entry
in sdctl for each loopback controller.

i apologize for not sending a patch.  i haven't yet
gotten the vx32 compilers working on my machine.
i'm sure this is operator error.

- erik

Re: [9fans] 9vx

[Russ Cox]

> this must be a quirk of the interaction between
> devsd and fdisk.  by hand data does disappear:
>
> 	; lc
> 	9fat	ctl	data	nvram	plan9	raw
> 	; for(i in 9fat data nvram plan9 data)echo delpart $i>ctl
> 	; lc
> 	ctl	raw

You are allowed to delete the data partition.
The problem is that fdisk should not be trying to.
Since it doesn't do that on native Plan 9, there
must be some aspect of devsd that is not behaving
the same way under 9vx that it does under Plan 9.
The bug is in devsd, though you'll probably have to
add prints to fdisk to find it.

Plan 9:

glenda# disk/fdisk -p /dev/sdC0/data
part linux 63 58589055
part plan9 58589055 241248105
glenda#

9vx:

% bind '#Z' /n/unix
% echo loop rw /n/unix/dev/sda >/dev/sdctl
% disk/fdisk -p /dev/sd00/data
delpart data
part linux 63 476230860
part linuxswap 476230923 488392065
%

That's running on a different disk but the same
fdisk binary (the one from sources as of today,
dated May 10).

Russ

Re: [9fans] 9vx

[erik quanstrom]

>> Here's the fix for the fdisk problem:
>>
>> /sys/src/cmd/disk/prep/edit.c:503,508 - edit.c:503,509
>>   	 */
>>   	for(i=0; i<edit->nctlpart; i++) {
>>   		p = edit->ctlpart[i];
>> + 		if(strncmp(p->ctlname, "data", 5) != 0)
>>   		if(p->changed)
>>   		if(fprint(ctlfd, "delpart %s\n", p->ctlname)<0) {
>>   			fprint(2, "delpart failed: %s: %r\n", p->ctlname);

on second read, with this approach, i would think that strcmp() not
strncmp should be used.

>
> That would work, but one wonders why
> the normal kernel doesn't have this problem.

this must be a quirk of the interaction between
devsd and fdisk.  by hand data does disappear:

	; lc
	9fat	ctl	data	nvram	plan9	raw
	; for(i in 9fat data nvram plan9 data)echo delpart $i>ctl
	; lc
	ctl	raw

by the way, be very careful with this before
applying this patch:

; diff -c /sys/src/9/port/devsd.c /n/dump/2008/0701/sys/src/9/port/devsd.c
/sys/src/9/port/devsd.c:147,153 - /n/dump/2008/0701/sys/src/9/port/devsd.c:147,152
  	 */
  	pp = unit->part;
  	for(i = 0; i < unit->npart; i++){
- 		if(pp->name)
  		if(strcmp(name, pp->name) == 0)
  			break;
  		pp++;

this is required because npart is set to the number
of partitions allocated.  the names never-set partitions
might be 0.  otherwise "delpart missingpart>/dev/sdXX/ctl"
will be a noisy and somewhat gratituous synonym for
"echo reboot>/dev/reboot".

- erik

Re: [9fans] 9vx

[Russ Cox]

> Here's the fix for the fdisk problem:
>
> /sys/src/cmd/disk/prep/edit.c:503,508 - edit.c:503,509
>   	 */
>   	for(i=0; i<edit->nctlpart; i++) {
>   		p = edit->ctlpart[i];
> + 		if(strncmp(p->ctlname, "data", 5) != 0)
>   		if(p->changed)
>   		if(fprint(ctlfd, "delpart %s\n", p->ctlname)<0) {
>   			fprint(2, "delpart failed: %s: %r\n", p->ctlname);

That would work, but one wonders why
the normal kernel doesn't have this problem.

Russ

Re: [9fans] 9vx

[erik quanstrom]

>> 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.
>
> Here's the fix for the fdisk problem:
>
> /sys/src/cmd/disk/prep/edit.c:503,508 - edit.c:503,509
>   	 */
>   	for(i=0; i<edit->nctlpart; i++) {
>   		p = edit->ctlpart[i];
> + 		if(strncmp(p->ctlname, "data", 5) != 0)
>   		if(p->changed)
>   		if(fprint(ctlfd, "delpart %s\n", p->ctlname)<0) {
>   			fprint(2, "delpart failed: %s: %r\n", p->ctlname);


i don't think this is the right solution.

as geoff pointed out, fdisk shouldn't be deleteing the parent
partition or any partitions that lie outside its parent partition.

obviously prep has a similar problem.

- erik

Re: [9fans] 9vx

[Anthony Martin]

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

Here's the fix for the fdisk problem:

/sys/src/cmd/disk/prep/edit.c:503,508 - edit.c:503,509
  	 */
  	for(i=0; i<edit->nctlpart; i++) {
  		p = edit->ctlpart[i];
+ 		if(strncmp(p->ctlname, "data", 5) != 0)
  		if(p->changed)
  		if(fprint(ctlfd, "delpart %s\n", p->ctlname)<0) {
  			fprint(2, "delpart failed: %s: %r\n", p->ctlname);

     Anthony

Re: [9fans] 9vx

[Russ Cox]

>> Does it work to set csremoved=1 in src/9vx/devip.c instead?
>
> I can confirm that this works, with the benefit of using secstore
> instead of prompting for my password.

Okay, done.  Thanks.

Russ

Re: [9fans] 9vx

[andrey mirtchovski]

> Does it work to set csremoved=1 in src/9vx/devip.c instead?

I can confirm that this works, with the benefit of using secstore
instead of prompting for my password.

Re: [9fans] 9vx

[Russ Cox]

> 9grid% yesterday -d util.c
> diff /n/dump/2008/0630/sys/src/cmd/auth/factotum/util.c
> /sys/src/cmd/auth/factotum/util.c
> 33c33
> < 		return authdial(net, authdom);
> ---
>> 		;//return authdial(net, authdom);
> 9grid%

Does it work to set csremoved=1 in src/9vx/devip.c instead?

> unfortunately with a terminal booted thusly i no longer have /mnt/term :)

bind '#Z' /mnt/term

Russ

Re: [9fans] 9vx

[andrey mirtchovski]

> now compile 8.factotum and copy it as 9vx/src/9vx/factotum.9 and recompile 9vx.

err, make that vx32/src/9vx/factotum.9. i'm compiling against the
latest mercurial, but there's not reason why it shouldn't just work
with .11 and .10

Re: [9fans] 9vx

[andrey mirtchovski]

now that you've explained the cs issue things are much clearer. i can
confirm that I have successfully booted a 9vx terminal off a remote
plan9 server using a small modification to factotum.

the original boot process failed with:

password:
!
authentication failed (auth_proxy rpc write: bootes: Connection
refused), trying mount anyways
boot: mount /: fossil authCheck: auth protocol not finished
9vx panic: boot process died: unknown

and the change simply sidesteps factotum using cs to figure out
who/what to dial, instead just using IP addresses.

here's the hack:

9grid% yesterday -d util.c
diff /n/dump/2008/0630/sys/src/cmd/auth/factotum/util.c
/sys/src/cmd/auth/factotum/util.c
33c33
< 		return authdial(net, authdom);
---
> 		;//return authdial(net, authdom);
9grid%

now compile 8.factotum and copy it as 9vx/src/9vx/factotum.9 and recompile 9vx.

unfortunately with a terminal booted thusly i no longer have /mnt/term :)

Re: [9fans] 9vx

[Russ Cox]

> Same recipe works here. But I've no idea why the rm /net/cs is
> necessary - can anyone put me out of my misery?

There are a bunch of rough edges that need to be fixed.
This is one of them.  9vx provides a #I/cs so that you
can do things like hget without starting cs.  But it can't
translate auth domains via /lib/ndb, which factotum
needs it to do.  So you have to start the more full-featured
ndb/cs, but that mounts itself on /net using MAFTER
(a bug, if you ask me).  Because I knew I couldn't get
a fix to ndb/cs into the distribution in time, I made the
#I/cs file removable.

Originally, the reason for providing #I/cs was to provide
access to host DNS lookups, just like it does in drawterm.
Now that there is a separate #I/dns (that ndb/cs will use),
it might be that the right thing to do is just toss away #I/cs
so that termrc will start a real one.

Another rough edge, if anyone wants a challenge, is that
gs goes into an I/O-free loop after reading the first 4k of
/sys/lib/ghostscript/gs_init.ps.  (I deleted gs from the 9vx
tar file to save space, so you'll have to run against a
distribution tree instead.)

Russ

Re: [9fans] 9vx

[sqweek]

On Fri, Jun 27, 2008 at 10:12 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> there's not access to the network device per ce, but the network works
> fine for me.  this is what i needed to do to connect to plan 9
> networks
>
>        1. edit /lib/ndb/auth and /lib/ndb/local as appropriate.
>        2. rm /net/cs; ndb/cs
>        3. auth/factotum
>        4. cpu -h $host

 Same recipe works here. But I've no idea why the rm /net/cs is
necessary - can anyone put me out of my misery?
-sqweek

Re: [9fans] 9vx

[Pietro Gagliardi]

scratch that - no newns. (what is it's name?)

On Jun 28, 2008, at 1:28 PM, Pietro Gagliardi wrote:

> Yes. It's a single line of code:
>
> 	exec rc -c '{ newns; rio }'
>
> On Jun 28, 2008, at 1:03 AM, lucio@proxima.alt.za wrote:
>
>>> i've not had a chance to look through the sources.  is a windows
>>> port
>>> feasible?
>>
>> 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?
>>
>> ++L
>>
>>
>
>

Re: [9fans] 9vx

[Pietro Gagliardi]

On Jun 28, 2008, at 11:23 AM, Russ Cox wrote:

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

Interesting. I'll try that and find out how it goes. (I was starting
to use Interface Builder and Xcode!) There is one bug, though, in the
drawterm code:

1) Copy something in OS X
2) Paste in Plan 9
3) Copy something smaller
4) Paste in Plan 9

Apparently, drawterm doesn't truncate. I'll see why.

Re: [9fans] 9vx

[lucio]

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

I'm sure I risk making a total fool of myself here, seeing as I don't
know anything about VX, nevermind 9vx.  But I am of the opinion that
Plan 9 is still preferable as a platform on which to do virtualisation
and the ability to run a VX port on Plan 9 may be the trigger for
other OSes to follow.  And if that is totally off the mark, don't
bother reading the rest of my post, just put me out of your misery :-)

There are two possible errors in my speculations: firstly that having
VX capabilities over Plan 9 isn't sufficient to provide a
virtualisation environment for, say Linux (as I say, I'm really
shooting in the dark here, feel free to educate me) and secondly that
Plan 9's elegance will not have the appeal I would expect.  Russ'
technical reservations are real enough, but not unsurmountable.

++L

Re: [9fans] 9vx

[Pietro Gagliardi]

Yes. It's a single line of code:

	exec rc -c '{ newns; rio }'

On Jun 28, 2008, at 1:03 AM, lucio@proxima.alt.za wrote:

>> i've not had a chance to look through the sources.  is a windows port
>> feasible?
>
> 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?
>
> ++L
>
>

Re: [9fans] 9vx

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

So I guess that rules out linux :-)

On Fri, Jun 27, 2008 at 5:23 PM, Uriel <uriel99@gmail.com> wrote:

> 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,
> but this shouldn't take more than a week or two...
>
> uriel
>
> On Sat, Jun 28, 2008 at 1:41 AM, Dave Eckhardt <davide+p9@cs.cmu.edu<davide%2Bp9@cs.cmu.edu>>
> wrote:
> > 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.
> >
> > Dave Eckhardt
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 1211 bytes --]

Re: [9fans] 9vx

[Russ Cox]

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

Re: [9fans] 9vx

[erik quanstrom]

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

i think that would be enough for disk/partfs.

- erik

Re: [9fans] 9vx

[lucio]

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

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?

++L

Re: [9fans] 9vx

[Brian L. Stuart]

> I haven't tried this yet, but is there any reason you
> couldn't put block special files for disk partitions
> in the 9vx directory and put the arenas, etc there,
> assuming of course all the permissions were set right?
> I'll probably give it a try later tonight unless someone
> yells "Stop! You'll poke out your eye^W partition table."

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.

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.

BLS

Re: [9fans] 9vx

[Fernan Bolando]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

On 6/27/08, Russ Cox <rsc@swtch.com> wrote:
>
> a quick announcement:
>
>         http://swtch.com/9vx/
>
> i'll have time to say more later.
>
>
> russ
>
>
>

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?

Bryan and Russ thanks a lot

fernan
--
http://www.fernski.com

[-- Attachment #2: Type: text/html, Size: 794 bytes --]

Re: [9fans] 9vx

[ron minnich]

On Fri, Jun 27, 2008 at 4:29 PM, Brian L. Stuart <blstuart@bellsouth.net> wrote:

> I haven't tried this yet, but is there any reason you
> couldn't put block special files for disk partitions
> in the 9vx directory and put the arenas, etc there,
> assuming of course all the permissions were set right?

I see no reason that should not work. Tonight I'm going to try to move
my venti/fossil from lguest universe to vx universe if I get time.

ron

Re: [9fans] 9vx

[Uriel]

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,
but this shouldn't take more than a week or two...

uriel

On Sat, Jun 28, 2008 at 1:41 AM, Dave Eckhardt <davide+p9@cs.cmu.edu> wrote:
> 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.
>
> Dave Eckhardt
>
>

Re: [9fans] 9vx

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

On Fri, Jun 27, 2008 at 4:41 PM, Dave Eckhardt
<davide+p9@cs.cmu.edu<davide%2Bp9@cs.cmu.edu>>
wrote:

> 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.
>
> Dave Eckhardt
>
> FreeBSD 7 has been for me quite good... I pretty much stopped using it
around FreeBSD 5, and 7 has made me think that over again.

[-- Attachment #2: Type: text/html, Size: 713 bytes --]

Re: [9fans] 9vx

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

On Fri, Jun 27, 2008 at 4:34 PM, Pietro Gagliardi <pietro10@mac.com> wrote:

> On Jun 27, 2008, at 7:13 PM, Skip Tavakkolian wrote:
>
>> i've not had a chance to look through the sources.  is a windows port
>> feasible?
>>
> 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.


I'm no expert in Cocoa-ification, but am more than willing to test and help
where and when I can (I have new father syndrome)


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

[-- Attachment #2: Type: text/html, Size: 1165 bytes --]

Re: [9fans] 9vx

[Dave Eckhardt]

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.

Dave Eckhardt

Re: [9fans] 9vx

[Pietro Gagliardi]

On Jun 27, 2008, at 7:13 PM, Skip Tavakkolian wrote:
> i've not had a chance to look through the sources.  is a windows port
> feasible?
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.

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

Re: [9fans] 9vx

[Brian L. Stuart]

> So i realized I'm being foolish w.r.t my comments on "i want my venti"
>
> in the 9vx directory
> dd if=/dev/zero of=arenas bs=1048576 count=whatever
>
> do for index and bloom
> follow venti instructions.
>
> voila. Venti. Rinse and repeat for fossil.

I haven't tried this yet, but is there any reason you
couldn't put block special files for disk partitions
in the 9vx directory and put the arenas, etc there,
assuming of course all the permissions were set right?
I'll probably give it a try later tonight unless someone
yells "Stop! You'll poke out your eye^W partition table."

> oh man I love this 9vx.
>
> Time for tvx -- tiny vx -- no need for the H any more, as that stood
> for horrible :-)

This is seriously cool.  I'm enough of a geezer that not
too much excites me anymore.  But today, I had fun reading
the USENIX paper and thinking about how to use this.

BLS

Re: [9fans] 9vx

[Skip Tavakkolian]

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

i mean, any updates beyond what's on page 3 of the paper.

Re: [9fans] 9vx

[Skip Tavakkolian]

this is fantastic. thank you Bryan and Russ.

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

> a quick announcement:
>
> 	http://swtch.com/9vx/
>
> i'll have time to say more later.
>
> russ

Re: [9fans] 9vx

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 71 bytes --]

>
>
> oh man I love this 9vx.


Indeed, this is truly excellent.

[-- Attachment #2: Type: text/html, Size: 242 bytes --]

Re: [9fans] 9vx

[ron minnich]

So i realized I'm being foolish w.r.t my comments on "i want my venti"

in the 9vx directory
dd if=/dev/zero of=arenas bs=1048576 count=whatever

do for index and bloom
follow venti instructions.

voila. Venti. Rinse and repeat for fossil.

oh man I love this 9vx.

Time for tvx -- tiny vx -- no need for the H any more, as that stood
for horrible :-)
ron

Re: [9fans] 9vx

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

On Fri, Jun 27, 2008 at 10:39 AM, ron minnich <rminnich@gmail.com> wrote:

> I'm on this 32 bit machine using vx32. Wow, nice. Boots like a bat.
>
> now all I want is my fossil and venti :-)
>
> This is really sweet. I think we've got an easy way to show people Plan 9
> now.
>
> thanks Russ!
>
> ron
>
> And uriel should be able to stop complaining about drawterm being redundant
:-)
Dave

[-- Attachment #2: Type: text/html, Size: 689 bytes --]

Re: [9fans] 9vx

[Pietro Gagliardi]

On Jun 27, 2008, at 1:39 PM, ron minnich wrote:

> This is really sweet. I think we've got an easy way to show people
> Plan 9 now.

I agree: a self-contained 9 could really solve all my QEMU worries and
boot CD nonsense! (No mouse detection, "kbd init failed" x infinity,
inverse video - sorry) Now if only it could work without X11. I might
try that.

Re: [9fans] 9vx

[ron minnich]

I'm on this 32 bit machine using vx32. Wow, nice. Boots like a bat.

now all I want is my fossil and venti :-)

This is really sweet. I think we've got an easy way to show people Plan 9 now.

thanks Russ!

ron

Re: [9fans] 9vx

[ron minnich]

On Fri, Jun 27, 2008 at 8:41 AM, Uriel <uriel99@gmail.com> wrote:
> What broke in lguest? seemed quite nice from what I have seen so far,
> just wondering because I was pondering using it for some projects.

some things changed on the plan 9 side, and then on the lguest side,
and I can no longer build a working kernel. I've kind of run out of
patience with the linux kernel churn, so if vx32 works for me, I'm
moving on :-)

thanks
ron

Re: [9fans] 9vx

[ron minnich]

This with a new untar, HOSTCFLAGS I added -m32


[rminnich@amd64 src]$ make 9vx/9vx
make: vx32-gcc: Command not found
make: vx32-gcc: Command not found
make: *** No rule to make target `9vx/9vx'.  Stop.


OK, I can see that 9vx/9vx target in 9vx/Makefrag, but the alarm just
went off and I gotta go pretend to work. More later. It would be nice
to have this work on x86 64 :-)

I do enjoy make sometimes.

thanks

ron

Re: [9fans] 9vx

[Uriel]

What broke in lguest? seemed quite nice from what I have seen so far,
just wondering because I was pondering using it for some projects.

Not to mean anything against vx32/9vx which is quite damned awesome as
far as I can see.

uriel

> But lguest just broke big time so if I can get this to work, I'm moving!
>
> thanks
>
> ron
>
>

Re: [9fans] 9vx

[andrey mirtchovski]

Try running with -F (and no -t). It seems to work fine on my machine.

andrey

On Fri, Jun 27, 2008 at 8:32 AM, Francisco J Ballesteros <nemo@lsub.org> wrote:
> MacOSX 10.5,
>
> running it with -t works fine here, including GUI.
>

Re: [9fans] 9vx

[Russ Cox]

> building on x86 64 bit.
>
> first issue is that I get this:make: vx32-gcc: Command not found
>
> second is that I get this:
> gcc -Ilibvx32 -c -g -O3 -MD -std=gnu99 -I.  -o libvx32/linux.o libvx32/linux.c
> libvx32/linux.c: In function `vx32_sighandler':
> libvx32/linux.c:254: error: structure has no member named `rip'
> libvx32/linux.c:303: error: structure has no member named `rip'
> make: *** [libvx32/linux.o] Error 1
>
> which makes sense I guess as we're not 64 bit and IIRC it has a different name.
>
> Did you want -m32 on those files? I don't understand this well enough
> yet to know.
>
> But lguest just broke big time so if I can get this to work, I'm moving!

make 9vx/9vx
will build only 9vx and will not need vx32-gcc.

if you make clean
and then edit the top-level src/Makefrag file to add -m32
to the HOST_CFLAGS and then make 9vx/9vx
you are likely to get a working binary.

compiling in 64-bit mode is almost certainly
not going to work; the plan 9 kernel code is
very 32-bit here.  and it would be very confused
if its own pointers were 64-bit but the user
code pointers were 32-bit.

russ

Re: [9fans] 9vx

[ron minnich]

On Fri, Jun 27, 2008 at 7:57 AM, ron minnich <rminnich@gmail.com> wrote:
> building on x86 64 bit.
>
> first issue is that I get this:make: vx32-gcc: Command not found
>
> second is that I get this:
> gcc -Ilibvx32 -c -g -O3 -MD -std=gnu99 -I.  -o libvx32/linux.o libvx32/linux.c
> libvx32/linux.c: In function `vx32_sighandler':
> libvx32/linux.c:254: error: structure has no member named `rip'
> libvx32/linux.c:303: error: structure has no member named `rip'
> make: *** [libvx32/linux.o] Error 1

yeah. The rip thing is fixed for sigcontext in linux.c, but not in this:
// VX32 CPU state
struct vxcpu {
	uint32_t	reg[8];
	uint32_t	eip;
	uint32_t	eflags;

	uint32_t	traperr;
	uint32_t	trapva;  // cr2
};


So the #defines in libvx32/linux.c fix things for sigcontext and break
things for vxcpu struct.

Hmm.

It's rather sleazy but I put
#undef eip
at linux.c line 252 and it builds. Now I get a link error:
libvx32/libvx32.a(rts.o)(.text+0x99): In function `vxrun_lookup_backpatch':
libvx32/rts.S:127: undefined reference to `VXEMU_RETPTR'
libvx32/libvx32.a(rts.o)(.text+0x10d): In function `vxrun_lookup_indirect':
libvx32/rts.S:214: undefined reference to `VXEMU_RETPTR'
libvx32/libvx32.a(rts.o)(.text+0x13e): In function `vxrun_gentrap':
libvx32/rts.S:232: undefined reference to `VXEMU_RETPTR'
libvx32/libvx32.a(run64.o)(.text+0x2e): In function `vxrun':
libvx32/run64.S:56: undefined reference to `VXEMU_RUNPTR'
libvx32/libvx32.a(run64.o)(.text+0x60):libvx32/run64.S:82: undefined
reference to `VXEMU_RUNPTR'
collect2: ld returned 1 exit status
make: exit 2

more as I hit it. This is a little bit easier than building lguest
modules. Ah, this is going to be fun!

I just shorted vmware. I'm gonna be rich, I tell you! Rich!
ron

Re: [9fans] 9vx

[ron minnich]

building on x86 64 bit.

first issue is that I get this:make: vx32-gcc: Command not found

second is that I get this:
gcc -Ilibvx32 -c -g -O3 -MD -std=gnu99 -I.  -o libvx32/linux.o libvx32/linux.c
libvx32/linux.c: In function `vx32_sighandler':
libvx32/linux.c:254: error: structure has no member named `rip'
libvx32/linux.c:303: error: structure has no member named `rip'
make: *** [libvx32/linux.o] Error 1

which makes sense I guess as we're not 64 bit and IIRC it has a different name.

Did you want -m32 on those files? I don't understand this well enough
yet to know.

But lguest just broke big time so if I can get this to work, I'm moving!

thanks

ron

Re: [9fans] 9vx

[andrey mirtchovski]

found something that crashes consistently: the xscr hacks that use threads.

this from the 9vx console:

783 substrate fault 0x9a1 no segment
segment 0xf000000 0x10000000
segment 0x1000 0x1e000
segment 0x1e000 0x27000
segment 0x27000 0x251000
783 substrate: unhandled fault va=9a1 [10009a1] eip=13f07
cpu0: registers for substrate 783
FLAGS=0 TRAP=0 ECODE=0 PC=13F07 USP=3730C
  AX 0000030F  BX 00000031  CX 00026B08  DX 0000030F
  SI 0000030F  DI 00037308  BP 00000000
785 strange: unhandled fault va=37424000 [38424000] eip=15014
cpu0: registers for strange 785
FLAGS=0 TRAP=0 ECODE=0 PC=15014 USP=28594
  AX 00000001  BX 83C33CC4  CX 0002061C  DX 00000311
  SI 00000311  DI 00028590  BP 00000000

inside 9vx:

% xscr/substrate
substrate 783: sxscruicide: sys: trap: page fault pc=0x00013f07
% xscr/strange
strange 785: suicide: sys: trap: page fault pc=0x00015014
% acid 785
/proc/785/text:386 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/386
acid: lstk()
threadexitsall(exitstr=0x1ee21)+0xc9 /sys/src/libthread/exit.c:49
	mypid=0x311
	npid=0x0
	pid=0x1c4ac
	i=0x91b1
threadmain(argv=0xfffffb0,argc=0x0)+0xee /usr/andrey/xscr/strange.c:404
	_argc=0xfefefefe
	_args=0xfefefefe
	m=0x0
mainlauncher(arg=0x25cc0)+0x18 /sys/src/libthread/main.c:58
launcher386(arg=0x25cc0,f=0x1495c)+0x10 /sys/src/libthread/386.c:10
0xfefefefe ?file?:0
acid: \x04
echo kill > /proc/785/ctl
% acid 783
/proc/783/text:386 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/386
acid: lstk()
threadexitsall(exitstr=0x1e7cd)+0xc9 /sys/src/libthread/exit.c:49
	mypid=0x30f
	npid=0x0
	pid=0x1e4fc
	i=0x81aa
screenhack()+0x15a /usr/andrey/xscr/substrate.c:381
	max_cycles=0x7d0
	tempx=0x63
threadmain(argv=0xfffffb0,argc=0x0)+0xce /usr/andrey/xscr/substrate.c:448
	_argc=0xfefefefe
	_args=0xfefefefe
mainlauncher(arg=0x34a60)+0x18 /sys/src/libthread/main.c:58
launcher386(arg=0x34a60,f=0x1384f)+0x10 /sys/src/libthread/386.c:10
0xfefefefe ?file?:0
acid:
% xscr/swirl
swirl 803: suicide: sys: trap: page fault pc=0x0001546a
% xscr/zoom
zoom 805: suicide: sys: trap: page fault pc=0x000108d2
%

Re: [9fans] 9vx

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

In fact, no capital letters work.

On Fri, Jun 27, 2008 at 7:45 AM, David Leimbach <leimy2k@gmail.com> wrote:

> I'm noticing I can't type a colon ":" but semicolon works :-)
>
>
>
> On Fri, Jun 27, 2008 at 7:39 AM, andrey mirtchovski <mirtchovski@gmail.com>
> wrote:
>
>> confirmed for 10.5.3.
>>
>> On Fri, Jun 27, 2008 at 8:32 AM, Francisco J Ballesteros <nemo@lsub.org>
>> wrote:
>> > MacOSX 10.5,
>> >
>> > running it with -t works fine here, including GUI.
>> >
>> >
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 1171 bytes --]

Re: [9fans] 9vx

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 363 bytes --]

I'm noticing I can't type a colon ":" but semicolon works :-)


On Fri, Jun 27, 2008 at 7:39 AM, andrey mirtchovski <mirtchovski@gmail.com>
wrote:

> confirmed for 10.5.3.
>
> On Fri, Jun 27, 2008 at 8:32 AM, Francisco J Ballesteros <nemo@lsub.org>
> wrote:
> > MacOSX 10.5,
> >
> > running it with -t works fine here, including GUI.
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 801 bytes --]

Re: [9fans] 9vx

[andrey mirtchovski]

confirmed for 10.5.3.

On Fri, Jun 27, 2008 at 8:32 AM, Francisco J Ballesteros <nemo@lsub.org> wrote:
> MacOSX 10.5,
>
> running it with -t works fine here, including GUI.
>
>

Re: [9fans] 9vx

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

Confirmed!  That works great!

On Fri, Jun 27, 2008 at 7:32 AM, Francisco J Ballesteros <nemo@lsub.org>
wrote:

> MacOSX 10.5,
>
> running it with -t works fine here, including GUI.
>
>
> On Fri, Jun 27, 2008 at 4:30 PM, Pat Hacker <pat@picoworks.com> wrote:
> > on OSX 10.5.3
> > % ./9vx.OSX -1g -u glenda
> >
> > init: starting /bin/rc
> > bind: #S: unknown device in # filename
> > upas/fs: '/bin/upas/fs' does not exist
> > #m/mousectl: rc: can't open: jmk added reentrancy for threads
> > init: rc exit status: rc 4: error
> >
> >
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 979 bytes --]

Re: [9fans] 9vx

[Francisco J Ballesteros]

MacOSX 10.5,

running it with -t works fine here, including GUI.


On Fri, Jun 27, 2008 at 4:30 PM, Pat Hacker <pat@picoworks.com> wrote:
> on OSX 10.5.3
> % ./9vx.OSX -1g -u glenda
>
> init: starting /bin/rc
> bind: #S: unknown device in # filename
> upas/fs: '/bin/upas/fs' does not exist
> #m/mousectl: rc: can't open: jmk added reentrancy for threads
> init: rc exit status: rc 4: error
>
>
>
>

Re: [9fans] 9vx

[Pat Hacker]

on OSX 10.5.3
% ./9vx.OSX -1g -u glenda

init: starting /bin/rc
bind: #S: unknown device in # filename
upas/fs: '/bin/upas/fs' does not exist
#m/mousectl: rc: can't open: jmk added reentrancy for threads
init: rc exit status: rc 4: error

Re: [9fans] 9vx

[Russ Cox]

> Without GUI I get a pretty good looking start :-)

That's good, although too bad it doesn't help with the X11 problem.
Rebuilding from source is the first thing I'd try.
After that, someone needs to learn how to get a
system call trace from a multithreaded program
on OS X.

Russ

Re: [9fans] 9vx

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 656 bytes --]

On Fri, Jun 27, 2008 at 6:52 AM, Russ Cox <rsc@swtch.com> wrote:

> > Currently getting:
> > 9vx panic: setsigsegv vx32 without alt stack
>
> Do you have strace installed (is there one?) on OS X?
> Can you run it with the -g (disable gui) flag
> under strace?


Without GUI I get a pretty good looking start :-)

[7:00] dave(mt64):..p/9vx-0.10 %> ./9vx.OSX -g -u glenda

init: starting /bin/rc
bind: #S: unknown device in # filename
upas/fs: '/bin/upas/fs' does not exist
#m/mousectl: rc: can't open: jmk added reentrancy for threads
init: rc exit status: rc 5: error

init: starting /bin/rc
%



>
>
> Thanks.
> Russ
>
>
>

[-- Attachment #2: Type: text/html, Size: 1250 bytes --]

Re: [9fans] 9vx

[Russ Cox]

> Seconded; everything works beautifully except that I'm not getting
> any network devices, it seems.

Perhaps

	bind -b '#I' /net

That should be happening automatically, but hey, you never know.
If files in /net exist, could you give more details?

> Did only the 9 kernel need modifications or did the applications
> binaries need to be recompiled as well?

The user binaries are unmodified native 386 binaries.

Russ

Re: [9fans] 9vx

[erik quanstrom]

> Seconded; everything works beautifully except that I'm not getting
> any network devices, it seems.

there's not access to the network device per ce, but the network works
fine for me.  this is what i needed to do to connect to plan 9
networks

	1. edit /lib/ndb/auth and /lib/ndb/local as appropriate.
	2. rm /net/cs; ndb/cs
	3. auth/factotum
	4. cpu -h $host

- erik

Re: [9fans] 9vx

[erik quanstrom]

>> Did only the 9 kernel need modifications or did the applications
>> binaries need to be recompiled as well?
>>
[...]
>
> 9vx requires no host kernel modifications or
> special privileges, and it runs unmodified
> plan9 386 binaries.

but that doesn't answer the question.  the plan 9
kernel was modified.  how else would it provide
access to the host's fs?

- erik

Re: [9fans] 9vx

[Gorka Guardiola]

On Fri, Jun 27, 2008 at 3:58 PM, Venkatesh Srinivas <me@acm.jhu.edu> wrote:
> Works impressively well here. Even snarf/paste between host and 9vx is
> working.
>
> Did only the 9 kernel need modifications or did the applications
> binaries need to be recompiled as well?
>
> --vs
>
>

9vx requires no host kernel modifications or
special privileges, and it runs unmodified
plan9 386 binaries.

--
- curiosity sKilled the cat

Re: [9fans] 9vx

[john]

> Works impressively well here. Even snarf/paste between host and 9vx is
> working.
>
> Did only the 9 kernel need modifications or did the applications
> binaries need to be recompiled as well?
>
> --vs

Seconded; everything works beautifully except that I'm not getting
any network devices, it seems.

John

Re: [9fans] 9vx

[Russ Cox]

> same error here. invoke with -t and it'll work. investigating.

I believe, though I can't see yet why that would matter
in this case.  I do suspect that the behavior of signal
handlers in threaded programs changed between 10.4 and 10.5.

You might try rebuilding from source (the binary was
built on 10.4.10) just to see if that fixes the problem.

Thanks for the reports.  I'm sure there will be more bugs,
especially in the OS X code, which is about a day old.

Even on OS X 10.4, 9vx seems to chew most of available cpu while
idling.  (On my 2-processor machine, it was using 130% cpu.)
Obviously it's not suposed to.  I suspect a pthreads issue,
but I haven't had time to look into it.  Perhaps there are
people out there more familiar with debugging on OS X
than I am.

Russ

Re: [9fans] 9vx

[a]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

I'm guessing here, but I think this was a reference to the fact
that in 10.5, Apple did some work to make X11 start automatically
when the first X11 app is run; maybe that's not working for pietro.

Is everyone having a problem on OS X on 10.5? I am.

OS X doesn't have strace; ≤10.4 has ktrace, 10.5 has dtrace.
Anthony

[-- Attachment #2: Type: message/rfc822, Size: 1706 bytes --]

From: "Russ Cox" <rsc@swtch.com>
To: 9fans@9fans.net
Subject: Re: [9fans] 9vx
Date: Fri, 27 Jun 2008 06:50:02 -0700
Message-ID: <20080627134806.3112F1E8C53@holo.morphisms.net>

> And for some reason I have to manually start X11.

Welcome to OS X.

Russ

Re: [9fans] 9vx

[Venkatesh Srinivas]

Works impressively well here. Even snarf/paste between host and 9vx is
working.

Did only the 9 kernel need modifications or did the applications
binaries need to be recompiled as well?

--vs

Re: [9fans] 9vx

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

On Fri, Jun 27, 2008 at 6:52 AM, Russ Cox <rsc@swtch.com> wrote:

> > Currently getting:
> > 9vx panic: setsigsegv vx32 without alt stack
>
> Do you have strace installed (is there one?) on OS X?
> Can you run it with the -g (disable gui) flag
> under strace?
>

No strace on Leopard.

Dave


>
> Thanks.
> Russ
>
>
>

[-- Attachment #2: Type: text/html, Size: 799 bytes --]

Re: [9fans] 9vx

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 937 bytes --]

I've got 10.5

On Fri, Jun 27, 2008 at 6:49 AM, Latchesar Ionkov <lucho@ionkov.net> wrote:

> Works fine on my laptop that runs MacOSX 10.4.
>
>    Lucho
>
> On Fri, Jun 27, 2008 at 4:40 PM, David Leimbach <leimy2k@gmail.com> wrote:
> > Currently getting:
> > 9vx panic: setsigsegv vx32 without alt stack
> > On Mac OS X.
> > On Fri, Jun 27, 2008 at 6:18 AM, David Leimbach <leimy2k@gmail.com>
> wrote:
> >>
> >> Russ,
> >> This looks really compelling...  I'll be trying it out for sure.  I've
> had
> >> my share of aggravation keeping things running on "real hardware", and
> this
> >> may be the "time saver" I needed to keep up with Plan 9.
> >> Dave
> >>
> >> On Fri, Jun 27, 2008 at 4:07 AM, Russ Cox <rsc@swtch.com> wrote:
> >>>
> >>> a quick announcement:
> >>>
> >>>        http://swtch.com/9vx/
> >>>
> >>> i'll have time to say more later.
> >>>
> >>> russ
> >>>
> >>>
> >>
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 1663 bytes --]

Re: [9fans] 9vx

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

On Fri, Jun 27, 2008 at 6:46 AM, Pietro Gagliardi <pietro10@mac.com> wrote:

> Same here. And for some reason I have to manually start X11.
>

X11 starts up for me ok.  But then my xterms don't have the ability to deal
with capital letters for some reason.




>
> On Jun 27, 2008, at 9:40 AM, David Leimbach wrote:
>
> Currently getting:
> 9vx panic: setsigsegv vx32 without alt stack
>
> On Mac OS X.
>
> On Fri, Jun 27, 2008 at 6:18 AM, David Leimbach <leimy2k@gmail.com> wrote:
>
>> Russ,
>> This looks really compelling...  I'll be trying it out for sure.  I've had
>> my share of aggravation keeping things running on "real hardware", and this
>> may be the "time saver" I needed to keep up with Plan 9.
>>
>> Dave
>>
>>
>> On Fri, Jun 27, 2008 at 4:07 AM, Russ Cox <rsc@swtch.com> wrote:
>>
>>> a quick announcement:
>>>
>>>        http://swtch.com/9vx/
>>>
>>> i'll have time to say more later.
>>>
>>> russ
>>>
>>>
>>>
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2240 bytes --]

Re: [9fans] 9vx

[Russ Cox]

> Currently getting:
> 9vx panic: setsigsegv vx32 without alt stack

Do you have strace installed (is there one?) on OS X?
Can you run it with the -g (disable gui) flag
under strace?

Thanks.
Russ

Re: [9fans] 9vx

[Russ Cox]

> And for some reason I have to manually start X11.

Welcome to OS X.

Russ

Re: [9fans] 9vx

[Latchesar Ionkov]

Works fine on my laptop that runs MacOSX 10.4.

    Lucho

On Fri, Jun 27, 2008 at 4:40 PM, David Leimbach <leimy2k@gmail.com> wrote:
> Currently getting:
> 9vx panic: setsigsegv vx32 without alt stack
> On Mac OS X.
> On Fri, Jun 27, 2008 at 6:18 AM, David Leimbach <leimy2k@gmail.com> wrote:
>>
>> Russ,
>> This looks really compelling...  I'll be trying it out for sure.  I've had
>> my share of aggravation keeping things running on "real hardware", and this
>> may be the "time saver" I needed to keep up with Plan 9.
>> Dave
>>
>> On Fri, Jun 27, 2008 at 4:07 AM, Russ Cox <rsc@swtch.com> wrote:
>>>
>>> a quick announcement:
>>>
>>>        http://swtch.com/9vx/
>>>
>>> i'll have time to say more later.
>>>
>>> russ
>>>
>>>
>>
>
>

Re: [9fans] 9vx

[a]

[-- Attachment #1: Type: text/plain, Size: 124 bytes --]

same error here. invoke with -t and it'll work. investigating.

lots of reading to do. this is pretty exciting.
anthony

[-- Attachment #2: Type: message/rfc822, Size: 4322 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 609 bytes --]

Currently getting:
9vx panic: setsigsegv vx32 without alt stack

On Mac OS X.

On Fri, Jun 27, 2008 at 6:18 AM, David Leimbach <leimy2k@gmail.com> wrote:

> Russ,
> This looks really compelling...  I'll be trying it out for sure.  I've had
> my share of aggravation keeping things running on "real hardware", and this
> may be the "time saver" I needed to keep up with Plan 9.
>
> Dave
>
>
> On Fri, Jun 27, 2008 at 4:07 AM, Russ Cox <rsc@swtch.com> wrote:
>
>> a quick announcement:
>>
>>        http://swtch.com/9vx/
>>
>> i'll have time to say more later.
>>
>> russ
>>
>>
>>
>

[-- Attachment #2.1.2: Type: text/html, Size: 1318 bytes --]

Re: [9fans] 9vx

[Pietro Gagliardi]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

Same here. And for some reason I have to manually start X11.

On Jun 27, 2008, at 9:40 AM, David Leimbach wrote:

> Currently getting:
>
> 9vx panic: setsigsegv vx32 without alt stack
>
> On Mac OS X.
>
> On Fri, Jun 27, 2008 at 6:18 AM, David Leimbach <leimy2k@gmail.com>
> wrote:
> Russ,
>
> This looks really compelling...  I'll be trying it out for sure.
> I've had my share of aggravation keeping things running on "real
> hardware", and this may be the "time saver" I needed to keep up with
> Plan 9.
>
> Dave
>
>
> On Fri, Jun 27, 2008 at 4:07 AM, Russ Cox <rsc@swtch.com> wrote:
> a quick announcement:
>
>        http://swtch.com/9vx/
>
> i'll have time to say more later.
>
> russ
>
>
>
>


[-- Attachment #2: Type: text/html, Size: 1609 bytes --]

Re: [9fans] 9vx

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

Currently getting:
9vx panic: setsigsegv vx32 without alt stack

On Mac OS X.

On Fri, Jun 27, 2008 at 6:18 AM, David Leimbach <leimy2k@gmail.com> wrote:

> Russ,
> This looks really compelling...  I'll be trying it out for sure.  I've had
> my share of aggravation keeping things running on "real hardware", and this
> may be the "time saver" I needed to keep up with Plan 9.
>
> Dave
>
>
> On Fri, Jun 27, 2008 at 4:07 AM, Russ Cox <rsc@swtch.com> wrote:
>
>> a quick announcement:
>>
>>        http://swtch.com/9vx/
>>
>> i'll have time to say more later.
>>
>> russ
>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 1318 bytes --]

Re: [9fans] 9vx

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

Russ,
This looks really compelling...  I'll be trying it out for sure.  I've had
my share of aggravation keeping things running on "real hardware", and this
may be the "time saver" I needed to keep up with Plan 9.

Dave

On Fri, Jun 27, 2008 at 4:07 AM, Russ Cox <rsc@swtch.com> wrote:

> a quick announcement:
>
>        http://swtch.com/9vx/
>
> i'll have time to say more later.
>
> russ
>
>
>

[-- Attachment #2: Type: text/html, Size: 832 bytes --]