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

[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.