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

RE: [Xen-devel] xenbus message id's


  • To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, "List: Xen Developers" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
  • Date: Sun, 21 Dec 2008 19:56:28 +1100
  • Cc:
  • Delivery-date: Sun, 21 Dec 2008 00:56:54 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcljH0D6FXSgnxJQQr2YMorjxrj0fwAKgVTQAAAg9DA=
  • Thread-topic: [Xen-devel] xenbus message id's

> On 21/12/2008 03:50, "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
wrote:
> 
> > Unless there is a good reason to allow multiple outstanding
requests,
> > I'll change the xenbus code in GPLPV to be more like the linux
version
> > as it looks quite a bit simpler. xenbus is hardly a performance
> > sensitive interface...
> 
> Request/response pairs are serialised in the C xenstored. Further,
> multiple
> in-flight transactions are allowed (although the rather basic conflict
> detection means that all but the first to commit will be failed).
> 
> We might move to a smarter xenstored, but overall higher parallel
> performance of one domain's xenbus implementation is probably not a
very
> important thing to optimise?
> 

I agree. I will now proceed to stupefy my implementation to make it a
bit easier to work with :)

I only asked because the version in mini-os (which I based mine on) does
allow multiple outstanding requests but the version in linux doesn't.

James

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