From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 1/2] xen/kbdif: update protocol documentation Date: Wed, 11 Jan 2017 23:50:04 +0100 Message-ID: <1484175004.32021.153.camel@citrix.com> References: <1483695173-7600-1-git-send-email-andr2000@gmail.com> <1483695173-7600-2-git-send-email-andr2000@gmail.com> <527e8987-481b-4df0-b329-1f133b260fa4@gmail.com> <1484156127.32021.143.camel@citrix.com> <259345c1-04a9-0a3d-3b67-b71b4941804e@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0162378652571682049==" Return-path: Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cRRiy-0001NY-FT for xen-devel@lists.xenproject.org; Wed, 11 Jan 2017 22:50:32 +0000 In-Reply-To: <259345c1-04a9-0a3d-3b67-b71b4941804e@gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Oleksandr Andrushchenko , Stefano Stabellini Cc: lars.kurth@citrix.com, vlad.babchuk@gmail.com, julien.grall@arm.com, andrii.anisov@gmail.com, olekstysh@gmail.com, al1img@gmail.com, JBeulich@suse.com, xen-devel@lists.xenproject.org, joculator@gmail.com List-Id: xen-devel@lists.xenproject.org --===============0162378652571682049== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-ROeWbF8SSuOJy8oUufRK" --=-ROeWbF8SSuOJy8oUufRK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2017-01-11 at 20:40 +0200, Oleksandr Andrushchenko wrote: > On 01/11/2017 07:35 PM, Dario Faggioli wrote: > >=C2=A0 > > It's indeed a repetition, but a good one, IMO: it helps the reader, > > as > > she won't have to go back to figure out how big the struct was, how > > the > > macro was call and to what value it was defined). > I am still not convinced that we should put it. > Probably we can go the way other RFCs do, like TCP [1], 802.11 [2] > etc: > those do not define any reserved fields at the bottom of structures, > (which are effectively padding?) but are limited to only those fields > which are defined. > In principle, I like the idea of following the example of those RFCs. However, I'd say that what we should value most is consistency within our own source tree. But, TBH, there aren't many binary diagram already committed in include/public/io, so it's hard to tell. FWIW, I still think that providing a clue to the reader about the size --even if already specified somewhere else-- would be beneficial, but it's a rather minor thing, and I certainly can leave with whatever you and the maintainer(s) agree upon. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-ROeWbF8SSuOJy8oUufRK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJYdradAAoJEBZCeImluHPuiEAQAOm7upq1V9TwXd/JyyfH5gXW ciWI/iHHPqH4vuaFElc6pANEp1nspelnbSKRdngDQ7NNmujET+d5SdKE77xa7+Ku FM7pYLGLEIHcMnWBrvam9X+j86dbDgiZRkcaH86Y/oEkLuzFMgyL4O3x6PHmwgwj OiuVic21FA72Nziv9DnW9rC+xDcYphDw3P6ORS3121e61MlDjwe0Snspjc2Dp4Ym m5ezfVgeFI8m2v5JLS7z8wYG4BxgMq1nEuIe6p0uSam7qKP8QkVds9uJ8qUJeFc9 PKqX64Lfd/Wdo1rWRGrT7QUW1Yw5pXQIs1szGpx1cz0o/5/Z//Zd4VwhUaL74KLj mqslmHnNNe0YeNWjlQLe9cEgGJnW8/qreS6IzrNjo4bzYhH8Fn66M76zNLQEhiZ7 VwNQBtGib+ZTD8qkvJmOY1AVhtSHqFi2YUwI2qhyEKTAZS9Idkt8YqdUWfJxWiV+ g8Au8qT+6sGzPuq7JQl947OvcmTojkZHsLQwfWj1RERO5WrGB+Ld1IrW1ZpDzoLN pdHKyDbYgpqpr92m07crdW2PXJN+QAPmJ1xIgLODqtzBRupZ1C7POMvHt8nmB1iG d7AGJn3pv+J9T3sF9JIrWJMxj+EAAY1K0CBwGIuhktAiMxYonJ++AAsBPChnVIpx Knk2V3W5+4nrOHYfmm9D =UBvZ -----END PGP SIGNATURE----- --=-ROeWbF8SSuOJy8oUufRK-- --===============0162378652571682049== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============0162378652571682049==--