Re: [Xen-devel] Block device configuration

[Ian Brown <ianbrn@xxxxxxxxx>]

is anyone lixening here?
Ian B.

On 10/21/05, Mark Ryden <markryde@xxxxxxxxx> 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@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
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel