From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Guidelines for new PV protocol submission Date: Tue, 20 Jan 2015 13:39:59 +0000 Message-ID: <54BE5AAF.6020709@citrix.com> References: <54BE4E6A.8010102@citrix.com> <54BE562B.40601@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YDZ3c-0006rv-Nd for xen-devel@lists.xenproject.org; Tue, 20 Jan 2015 13:41:24 +0000 In-Reply-To: <54BE562B.40601@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: David Vrabel , =?windows-1252?Q?Roger_Pau_?= =?windows-1252?Q?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 13:20, David Vrabel wrote: > 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 protoc= ol). >> >> 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. +1 It is far nicer to work from a document than to worry how another compiler might change the structure. ~Andrew