WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-tools

[Xen-tools] Re: xenbus block device support

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:
> > 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.

I was thinking of "read-only" on the backends: if xend write "read-only"
last without transactions, the backend could think the device is
read-write, because it reads the directory before the read-only node
exists.  Sure, an ideal driver will pick up the change when the
read-only node is created, but the frontend can map the device
read-write in the meantime.  It's fragile, and was exactly why we wanted
some atomicity in the store...

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

OK, if you prefer that, or even "xenbus_register_device_driver" vs.
"xenbus_register_backend_driver" maybe.  Your call.

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


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