WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: Interdomain comms

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Interdomain comms
From: Eric Van Hensbergen <ericvh@xxxxxxxxx>
Date: Sat, 7 May 2005 16:22:07 -0500
Cc: Eric Van Hensbergen <ericvh@xxxxxxxxxxxxxxxxxxxxx>, Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Ronald G. Minnich" <rminnich@xxxxxxxx>, Mike Wray <mike.wray@xxxxxx>
Delivery-date: Sat, 07 May 2005 21:21:57 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fSglwwUeEjwLkc2ok4isRHvgsHk50gMvwEAsfRSaBbdljL421g3/NIxJqDtnXvcOwMUigmLG7h6iem1HWDD5YpfSSySPdnOU4zCvc/HKUfKCidNEqtAbqGJnTtDqeRVRupwWaPNaAaGl4rlILiTr+IAmW91A51a1MpAd0KQWr4g=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <29812b75c444f0fdbbe2abb3a985b65e@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <0BAE938A1E68534E928747B9B46A759A6CF3AC@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1115325448.12082.79.camel@localhost> <427B20B9.1010101@xxxxxx> <1115381693.18929.159.camel@localhost> <Pine.LNX.4.58.0505060940420.10357@xxxxxxxxxxxxxxx> <1115421185.4141.18.camel@localhost> <a4e6962a0505061719165b32e4@xxxxxxxxxxxxxx> <1115472417.4082.46.camel@localhost> <Pine.LNX.4.58.0505071009150.13088@xxxxxxxxxxxxxxx> <29812b75c444f0fdbbe2abb3a985b65e@xxxxxxxxxxxx>
Reply-to: Eric Van Hensbergen <ericvh@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 5/7/05, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:
> 
> Isn't 9p a file transfer protocol, or is that just one aspect of it? 
>

Its an easy misconception, 9P is many things - at its core it is the
API to all resources (system, device, application, files) in the Plan
9 paradigm - on the local system the system calls translate directly
to function calls within the kernel - never being marshaled into a
message form.  It is also a protocol for remote resource sharing
(since 9P is used to more than just files, the network encapsulation
of 9P can be used to share all the different resources of the system).

>
> At the very lowest level it doesn't appear so different from what we have
> now (multiple oustanding request messages, each with a different tag
> that is echoed in the asynchronous response message); but the next
> level up seems to be defined in terms of walking a hierarchical file
> system, obtaining handles on files, and so on. To me that doesn't sound
> obviously applicable to our inter-driver communications.
> 

The dynamic, stackable, hierarchical organization of 9P resources
within Plan 9 may be one of the most important thing for
virtualization environments to leverage.  It creates a easily
understood and manipulated metaphor for organizing system, partition,
or cluster resources.  Within device implementation, it can create a
hierarchy of interfaces allow core resources as well as extensions
that not all clients can take advantage of.  One thing which might be
useful would be to look at the Plan 9 man page sections on devices:
      (http://plan9.bell-labs.com/sys/man/3/INDEX.html) 
and file servers:
      (http://plan9.bell-labs.com/sys/man/4/INDEX.html)

I hate talking about this stuff before we have some sort of prototype
within the Xen environment to demonstrate, a lot of the power of this
methodology is best experienced rather than pontificated about. 
Regardless, we will be working towards this over the next few months
and it should tie in nicely with our v9fs driver in Linux (which will
also be likely ported to K42 and naturally already exists within Plan
9).  There has been quite a bit of interest from certain sects within
the BSD community in implementing something similar to v9fs, so
perhaps we'll have something there by summer's end as well.

        -eric

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>