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

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

There are a couple of things I'd like to see changed if this is what we want to
go with:

- "if (protocol == 1) {} else {}" should be switches, failing (or even BUGing) 
for
  all protocol versions other than 1 and 2
- assuming the abstraction is meant to scale to future protocol versions, adding
  many such explicit version handling code paths seems undesirable, as seems
  adding extra version specific variables or (non-union) structure members
- using all error possible values returned from xenbus_gather to indicate an old
  frontend seems odd at least - one specific error value should be
  recognized here
- unconditionally using #pragma pack(), __attribute__(()), and __i386__ or
  __x86_64__ in public Xen headers is, in my opinion, a no-go (these header
  should all be suitable for building e.g. Windows drivers, too - I know this 
isn't
  generally the case at present, but I don't think anything else can be the 
goal,
  and hence the situation shouldn't be made worse)

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 ...

-- 
Gerd Hoffmann <kraxel@xxxxxxx>

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