Re: [Xen-devel] Block device configuration

[Mark Ryden <markryde@xxxxxxxxx>]

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