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@lists.xensource.com
http://lists.xensource.com/xen-devel
Hi, In this occasion, I want to add one question which is also about this issue,if I may: Can anyone explain in a few sentences and show exactly where in the code and how the backend driver probe function and the frontend driver probe function are called ? (blkfront_probe() and blkback_probe() in the case of a block device). I could not find the code which triggers these functions. Is this have to do with udev/hotplug calling probe using generic linux probe methods? Or is it that merely setting values in XenStore triggers the probing functions, using some callback? I doubt this is the case. Regards, MR On 10/21/05, Rusty Russell <rusty@rustcorp.com.au> wrote:> 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@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
is anyone lixening here? Ian B. On 10/21/05, Mark Ryden <markryde@gmail.com> wrote:> Hi, > > In this occasion, I want to add one question which is also about > this issue,if I may: > > Can anyone explain in a few sentences and show exactly where in the code and > how the backend driver probe function and the frontend driver probe function > are called ? (blkfront_probe() and blkback_probe() in the case of a > block device). > > I could not find the code which triggers these functions. > > Is this have to do with udev/hotplug calling probe using generic linux > probe methods? > > Or is it that merely setting values in XenStore triggers the probing > functions, using some callback? I doubt this is the case. > > Regards, > MR > > > On 10/21/05, Rusty Russell <rusty@rustcorp.com.au> wrote: > > 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@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, 2005-10-21 at 08:55 +0200, Mark Ryden wrote:> Hi, > > In this occasion, I want to add one question which is also about > this issue,if I may: > > Can anyone explain in a few sentences and show exactly where in the code and > how the backend driver probe function and the frontend driver probe function > are called ? (blkfront_probe() and blkback_probe() in the case of a > block device).Look in drivers/xen/xenbus_probe.c. This code places watches on the "device" and "backend" directories: when a new directory appears, it calls xenbus_probe_node(), which calls the driver core''s device_register(). This calls xenbus_match to compare the device against each driver; if a driver is found, it calls xenbus_dev_probe, which calls blkfront_probe() or blkback_probe() in your two cases.> Is this have to do with udev/hotplug calling probe using generic linux > probe methods?No, udev/hotplug is orthogonal. That call gets fired off asynchronously by the Linux driver core> Or is it that merely setting values in XenStore triggers the probing > functions, using some callback? I doubt this is the case.It is the case. Hope that clarifies, Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel