[Xen-tools] Re: xenbus block device support

[Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>]

On Thu, Aug 11, 2005 at 02:15:36PM +1000, Rusty Russell wrote:
> On Wed, 2005-08-10 at 19:32 +0100, Christian Limpach wrote:
> > - store updates from xend don't use transactions and the code in the
> >   drivers to handle this short coming is complicated.  On the other
> >   hand it should make the drivers more robust.
> 
> 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.  I think there are issues on both the read and write side:
- read: I wouldn't be surprised if we didn't always fetch the values
  from the store but instead kept them cached in the dictionary?
- write: keys are first created with no data written to them and then
  only later on an exportToDB (or some flavour of that) the data is
  actually written to the store.

I'd like to see both reads and writes go straight to the store with
an option to create transactions.  As I said above, I like the mapping
to a dictionary but would definitely prefer a solution using a
straight-through API over the cumbersome to use current implementation.

> Kernel code can paper over this for the moment, but in general it will
> be unreliable: we will derive some information about the device from
> presence or lack of certain nodes.

I don't see a problem here.  Presence nodes are the only ones which
actually work with the current solution.

> Only one piece of feedback from reading the patches:
> > -int xenbus_register_driver(struct xenbus_driver *drv);
> > +int xenbus_register_frontend_driver(struct xenbus_driver *drv);
> 
> I left this as "xenbus_register_driver" in my tree, since not every
> xenbus driver (think shared LAN driver) is a frontend; a backend implies
> a frontend but not vice versa.  Minor nitpick.

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.

    christian


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