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