[Xen-tools] Re: xenbus block device support

[Rusty Russell <rusty@xxxxxxxxxxxxxxx>]

On Thu, 2005-08-11 at 09:02 +0100, Christian Limpach wrote:
> On Thu, Aug 11, 2005 at 02:15:36PM +1000, Rusty Russell wrote:
> > This is really irritating.  It's so easy to use the C API, and yet the
> > Python bindings seem to make a mess of it.  I wonder if a
> > straight-through API would serve xend better?
> 
> Well, I've been begging for a better interface between xend and the store
> for a while, but nobody has picked up on it.  I like how the store is
> mapped to dictionaries, but I don't think the implementation is how we
> want it to be.

OK, I've looked at this now.  The python xenstore interface in
tools/python/xen/xend/xenstore/ is 1220 lines, vs the C interface at 704
lines.  That's just *wrong*, and doesn't count the Python bindings to
that C interface (another 788 lines).

I suggest the following:

(1) Two python classes XenstoreTransaction and XenstoreReadable.  The
former is initialized a path (indicating the root of the transaction),
the latter is for read-only uses which don't need one.  All store
operations go through one or the other, and you can't have more than one
XenstoreTransaction on a thread at a time.  Each Python thread will need
its own connection to the store, BTW, because doing otherwise doesn't
really make sense (you don't want to do ops in the middle of my
transaction).

(2) xs.c needs to be enhanced to have retry logic, so the xenstored can
restart.  This should not be in the python implementation, since all
clients will need it.  I will do this, as part of the "xenstored
restart" work.

(3) In future, xs transactions should probably be enhanced to have more
than one non-intersecting root.  Transactions have an explicit root
argument because we can implement transactions reasonably efficiently
without needing EAGAIN on commit.  They only have one root because that
was simple, but that means that the tools have to use "/domain" if they
want to set up front and backends simultaneously 8(

> I'd be happy with xenbus_register_driver and xenbus_register_backend,
> I think the combination of xenbus_register_driver and
> xenbus_register_backend_driver is confusing.

If a "device" has a "driver", the equivalent for a backend is clear: 
xenbus_register_biver!

Just kidding,
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman


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