WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Block device configuration

To: Mark Ryden <markryde@xxxxxxxxx>
Subject: Re: [Xen-devel] Block device configuration
From: Ian Brown <ianbrn@xxxxxxxxx>
Date: Sat, 22 Oct 2005 21:01:22 +0200
Cc: Rusty Russell <rusty@xxxxxxxxxxxxxxx>, Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sat, 22 Oct 2005 18:58:35 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MZn719YDk9/GQn4nW302DDCEJHUgA9sH932xRK7zy30Vs7s7SaIdIAk9OuM1d5K1dVXHGXGqrozb+Nc+aBivh9VZrIHxg/TuvBO/S811XVOzY/kVNqV72qy7ycxX8Cs19RQo5JGLhvqD+/CvbOU40x9yRaBQaH2RKwysJDYo5g0=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <dac45060510202355x192e0c5byb664a54583c4824b@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1129868947.28563.22.camel@xxxxxxxxxxxxxxxxxxxxx> <dac45060510202355x192e0c5byb664a54583c4824b@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

<Prev in Thread] Current Thread [Next in Thread>