[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Block device configuration
Hi all, Am trying to write a skeleton driver, so I'm trying to understand the store interface for block devices. Is this correct, and what it's going to be in 3.0? Tool (eg. xend) creates two directories (with a single transaction ?): <backend>/backend/vbd/<per-frontend-dir>/<device-id>/ domain: name of frontend domain type: "phy" or "file" params: path of device (type=phy) or file (type=file)? dev: the device the frontend is going to see frontend: path of frontend device directory frontend-id: domain id of frontend directory. <frontend>/device/vbd/<device-id>/ virtual-device: same as "dev" in backend dir backend: path of backend device directory backend-id: domain id of backend Now, under Linux, the following happens on the backend: xenbus notices new backend device appear, calls vbd backend driver (which places a watch on itself), and invokes hotplug script (or udev) in userspace. hotplug script reads parameters from directory, and writes physical-device node. vbd backend notices creation of physical-device node. It then looks at frontend to "ring-ref" and "event-channel" values, then and writes "sectors", "info" and "sector-size". Under Linux, the following happens on the frontend: xenbus notices new device appear, calls vbd frontend driver, and invokes hotplug/udev. driver places watch on backend, reads "virtual-device" and creates writes "ring-ref" and "event-channel". Tries to read "sectors", "info" and "sector-size" from backend. Is this the model the skeleton driver should follow, or are more changes anticipated? Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |