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

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

By adding abstraction to the ring macros and the affected headers, and then 
direct structure member accesses with appropriate macros. Reference patches
attached (not checked whether they would apply cleanly on -unstable). Jan

>>> Keir Fraser <keir@xxxxxxxxxxxxx> 18.12.06 18:58 >>>
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

Attachment: xen-bimodal-tpmback.patch
Description: Text document

Attachment: xen-bimodal-blkif.patch
Description: Text document

Attachment: xen-bimodal-blktap.patch
Description: Text document

Attachment: xen-bimodal-blkback.patch
Description: Text document

Xen-devel mailing list



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