[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [patch/rfc] multiprotocol blkback drivers (32-on-64)

  • To: Jan Beulich <jbeulich@xxxxxxxxxx>, Gerd Hoffmann <kraxel@xxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Mon, 18 Dec 2006 17:58:34 +0000
  • Cc: Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 18 Dec 2006 09:58:30 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcciziJ0YLv0Oo7BEduEawAX8io7RQ==
  • Thread-topic: [Xen-devel] Re: [patch/rfc] multiprotocol blkback drivers (32-on-64)

Gerd's description is along the lines of what I would implement myself. How
does your bi-modal approach work?

 -- Keir

On 18/12/06 17:09, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> I understand you favor this over the bi-modal approach I took? Any specific
> advantages? Jan
>>>> Gerd Hoffmann <kraxel@xxxxxxx> 18.12.06 17:39 >>>
> Hi,
> This is a patch for the block interface, frontend drivers, backend
> drivers and tools to support multiple ring protocols.  Right there are
> now just two: the 32bit and the 64bit one.  If needed it can be extended.
> Interface changes (io/blkif.h)
>  * Have both request structs there, with "v1" and "v2" added to the
>    name.  The old name is aliased to the native protocol of the
>    architecture.
>  * Add helper functions to convert v1/v2 requests to native.
> Frontend changes:
>  * Create a new node "protocol", add the protocol number it speaks
>    there.
> Backend changes:
>  * Look at the "protocol" number of the frontend and switch ring
>    handling accordingly.  If the protocol node isn't present it assumes
>    native protocol.
>  * As the request struct is copied anyway before being processed (for
>    security reasons) it is converted to native at that point so most
>    backend code doesn't need to know what the frontend speaks.
>  * In case of blktap this is completely transparent to userspace, the
>    kernel/userspace ring is always native no matter what the frontend
>    speaks.
> Tools changes:
>  * Add one more option to the disk configuration, so one can specify the
>    protocol the frontend speaks in the config file.  This is needed for
>    old frontends which don't advertise the protocol they are speaking
>    themself.
>    I'm not that happy with this approach, but it works for now and I'm
>    kida lost in the stack of python classes doing domain and device
>    handling ...
> Consider the code experimental, not all frontend/backend combinations
> are tested.
> Comments?  Questions?  Suggesions?
> cheers,
>   Gerd
> PS: Anyone working on blkback/blktap code sharing?  While walking
>     through the code I've noticed quite alot of it is cut&paste ...

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.