From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <78990e76df2dd31dfb79c920aef55750@swtch.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] p9p on win32?
From: "Russ Cox" <rsc@swtch.com>
Date: Tue, 14 Mar 2006 08:04:29 -0500
In-Reply-To: <1e9d65c3485c20086ab31b43abc7f35c@quintile.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 13cfb1e6-ead1-11e9-9d60-3106f5b1d025

> I assume the best compiler to use is mingw as knows about at least some plan9-isms

Doesn't matter.  There are no Plan 9 isms in the p9p
code base.  At least not supposed to be.

> The big issue is I would also like to get a cpu server going.

That's harder than it sounds.

> Currently I use rsh which doesn't pass keyboard interrupt to the remote host.
> I could run openssh under cygwin which would give that functionality and
> on-the-wire encryption which is nice these days.

I would do this for the short term.  Installing cygwin is
super-easy.

> My favorite solution is to use the plan9 cpu protocol. This would allow
> me to access files on the local plan9 system, pass interrupts (by reading
> /mnt/term/dev/cpunote), and pass the win32 current directory back to plan9
> (rc writes to /mnt/term/dev/wdir) so plumbed error messages will open the
> correct file in sam/acme.

If you use the cygwin ssh and set your profile to emit
xterm window change codes every time you switch
directories, you can use "ssh windows | aux/conswdir"
on the Plan 9 side.  See rwd(1).

> I would need a 9p client written against stdio, and a port of openssl to provide
> the equivilent of pushssl(2), or alternatively if most of p9p is comming acrross
> easily I could just use the plan9 code (except that ssl/tls is in the plan9 kernel).

Actually I've pulled out a standalone ssl that you can
invoke on a pipe.  The main part left for cpu to Plan 9
is writing the /dev/draw file server.

> Windows filesystem drivers seem to live in the kernel, which would make debugging them
> tiresome, however I have found two frameworks for creating user space synthetic
> filesystems on Win32, one creates a local cifs server [1] the other uses a proxy
> device driver to allow a psudo filesystem to live in user space [2]. This still
> leaves the problem of mounting/unmounting a filesystem on each cpu(1)
> connect/disconnect.

p9p doesn't do kernel mounts, so this isn't an issue.
If someone wants to explore kernel 9P mounts later,
that's a separate issue.  I strongly suggest doing a
first cut without them.  Especially since you don't have
per-process name spaces.

You do need some equivalent to Unix domain sockets
for posting services.  I think you should be able to use
a service-posting program and then find it by name
and use IPC to talk to it.  Kind of a user-level /srv.

Russ