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