[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |