From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: Guidelines for new PV protocol submission Date: Tue, 20 Jan 2015 13:20:43 +0000 Message-ID: <54BE562B.40601@citrix.com> References: <54BE4E6A.8010102@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YDYjg-0004xZ-QG for xen-devel@lists.xenproject.org; Tue, 20 Jan 2015 13:20:48 +0000 In-Reply-To: <54BE4E6A.8010102@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: =?windows-1252?Q?Roger_Pau_Monn=E9?= , xen-devel Cc: oleksandr.dmytryshyn@globallogic.com, Ian Jackson , Ian Campbell , Jan Beulich , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 20/01/15 12:47, Roger Pau Monn=E9 wrote: > Hello, > = > I should probably have done this earlier because I've been aware of this > issue for a long time (since I've started dealing with the PV blk protoco= l). > = > The current way to describe PV protocols in Xen is very inefficient > IMHO. Using C structs as "the description" of a binary protocol seems > very wrong, specially taking into account that different ABIs can > generate different layouts for the same C struct. This is for example a > problem in the PV blk protocol, since the binary layout of the > structures change depending on the bitness. > = > In order to avoid this, I would like to request that any new PV protocol > that's added to Xen be described in binary terms, just like it's > normally done with other protocols. As a reference see for example the > following section from the TCP RFC: > = > http://tools.ietf.org/html/rfc793#page-15 > = > I think this is both more easy to understand and removes the bitness > problem of using C structs. > = > Then each user of this protocol could define it's own set of structures > that would map to the binary layout, which should be almost trivial. > There would be no problem with using __packed or similar gcc'isms as > each implementation could choose the more convenient way to represent > this layout internally. +1 We did this for migration v2 protocol[1] and I agree that this is a much better way of specifying binary protocols. David [1] http://xenbits.xen.org/people/andrewcoop/domain-save-format-F.pdf