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

[Xen-devel] Block device configuration

To: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Block device configuration
From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Date: Fri, 21 Oct 2005 14:29:07 +1000
Delivery-date: Fri, 21 Oct 2005 04:26:43 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

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