[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: Interdomain comms


  • To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • 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=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.