Looking through the xenbus code in the linux kernel, it seems that only one outstanding request is allowed at a time (via a mutex), so there is no code that uses the ''id'' field in any way. Under mini-os though, it seems like we can have a number of requests on the fly at the same time (more complex code). This is the code I based gplpv on. Can anyone comment on why that is so? I''m trying to implement the xenbus kernel<->userspace interface and was wondering why the id of the request is accepted verbatim from userspace, but I guess if only one outstanding request at a time is allowed then it''s not a problem. 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... Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 21/12/2008 03:50, "James Harper" <james.harper@bendigoit.com.au> 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? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> On 21/12/2008 03:50, "James Harper" <james.harper@bendigoit.com.au>wrote:> > > Unless there is a good reason to allow multiple outstandingrequests,> > I''ll change the xenbus code in GPLPV to be more like the linuxversion> > 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 avery> 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@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper writes ("RE: [Xen-devel] xenbus message
id''s"):> I agree. I will now proceed to stupefy my implementation to make it a
> bit easier to work with :)
I agree with Keir that this is fine. The implications are just for
performance but that''s probably not important in your application. If
that turns out not to be true then souping up your implementation can
be done later.
docs/misc/xenstore.txt has this to say on this subject:
A caller who sends several requests may receive the replies in any
order and must use req_id (and tx_id, if applicable) to match up
replies to requests. (The current implementation always replies to
requests in the order received but this should not be relied on.)
Here a `caller'' is a counterparty communicating with xenstored via the
interdomain page/event channel mechanism or locally in dom0 via a
socket - ie your driver.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel