From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v14] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other. Date: Tue, 29 Nov 2016 19:30:17 +0100 Message-ID: <1480444217.3178.94.camel@citrix.com> References: <1480433095-25292-1-git-send-email-andr2000@gmail.com> <1480433095-25292-2-git-send-email-andr2000@gmail.com> <583DB63E02000078001235D3@prv-mh.provo.novell.com> <284d0731-6540-f4c8-3ce3-5cc44e30a411@gmail.com> <583DC35B020000780012368D@prv-mh.provo.novell.com> <54a7f3ae-2909-d33d-7042-822927dcf215@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5428990308462222385==" Return-path: In-Reply-To: <54a7f3ae-2909-d33d-7042-822927dcf215@gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Oleksandr Andrushchenko , Jan Beulich Cc: lars.kurth@citrix.com, iurii.konovalenko@globallogic.com, vlad.babchuk@gmail.com, tim@xen.org, oleksandr.dmytryshyn@globallogic.com, ian.jackson@eu.citrix.com, al1img@gmail.com, andrii.anisov@gmail.com, olekstysh@gmail.com, embedded-pv-devel@lists.xenproject.org, julien.grall@arm.com, david.vrabel@citrix.com, xen-devel@lists.xenproject.org, joculator@gmail.com List-Id: xen-devel@lists.xenproject.org --===============5428990308462222385== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-tzbFHJL5EimwajU9XGML" --=-tzbFHJL5EimwajU9XGML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-11-29 at 19:27 +0200, Oleksandr Andrushchenko wrote: > On 11/29/2016 07:05 PM, Jan Beulich wrote: > > If you document it as padding, you can't easily use it later on for > > some extension. > Why not? I would be more careful about reserved, rather than padding. > Reserved means that it might be used for something, but padding at > the > end of the structure (clearly?) says it was added just to align the > size of > this structure and most probably is not used > I think that's exactly the point. Padding must be zeroed and can (should?) be checked to be zero. That means that if, say in 2 years time, we want to support a new fancy feature being introduced in sound cards, and that requires adding a new field in the struct, we can't use these 27 bytes, because we can't set them to anything else than a bunch of 0s. In fact, if you use them in frontend, and happen to speak with a backend that does not support the extension and enforces the padding to be 0, you're doomed. :-/ OTOH, if you say reserved, neither of the endpoints is authorized to assume anything about the content of that area. Therefore: 1) you can (with some care) use it for extensions 2) if you do that in a frontend, even when speaking with a backend that does not support the extension, it will just ignore the new content (which is still just reserved space for him), and won't crash the communication Hope this is both correct and clear. :-) > > =C2=A0 But you know possible extension routes of this > > protocol better than me... > Well, after implementing PV sound back and front with this kind of > response I can confirm we didn't face any problem. > So, I would say it is sufficient > Eheh, how did it sound? Ah, yes: <<640K ought to be enough for anybody.>> :-D Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-tzbFHJL5EimwajU9XGML 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 iQIcBAABCAAGBQJYPck5AAoJEBZCeImluHPuZUYQAMttWuyXKDCEx1CD0YjwuGfN fLml1V9ErUTPT/GmnEu3lNvmlRfibg9yw7Uht+0nHgVNate66autHUyVXLQuX3JJ 21W7mdUsbWsPYb8i+oKyyF7v8z4jI3EtnC5fCxLwmlPZC5mU+jb6S7ZTWNScfxt3 /YwzrbpKbXnadOUVWEVdZ+QqTMw6Xn8EzH1gJrgsFWqJmV7SiHW4zyN9aFuQE53g z149c7SiluhMUYYgFv1BszL/y7CGx50AWoDn7+3ouvDna4kWBzkw8XLGdl1j8vf/ 5ILsA9TB1cUv7RqGYreBa69iSyJZlM3w+YHj/oskxrLzxnHGEs6smfqUlaXfA/9d uxIdgBvLalQSHyKTPjVMlUZADiRroE7XZXFzvZF1uNHNeguyWmSKn8QDsaqlF96l T09SJUENDaFUDK9uX++1hL259W8TH7shrAwbdVAtbJlbJMrsth7TxZORAOyvO9ac YMoj1d0HQV7C7rwY+GQOZ3nyNCTCgxpt2qUTHAmWGBGVAPPO+vLhkNsxtWMHPy6P 4zGrad+TEL8BHlWSErVvZwHVWM7TQ0C+qrhxo1c8qtYDIVb79U1qFkivGexCAIjo fdtKrfxw0/+k+l/yHqsn8/FmfrSOykRhGWBOcUNlibeodnmV6f6XlCHcxRfVFHkH H52wuynt81F0IdNLPlrM =EVkk -----END PGP SIGNATURE----- --=-tzbFHJL5EimwajU9XGML-- --===============5428990308462222385== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============5428990308462222385==--