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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home