From: Dario Faggioli <dario.faggioli@citrix.com>
To: Oleksandr Andrushchenko <andr2000@gmail.com>,
Jan Beulich <JBeulich@suse.com>
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
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 [thread overview]
Message-ID: <1480444217.3178.94.camel@citrix.com> (raw)
In-Reply-To: <54a7f3ae-2909-d33d-7042-822927dcf215@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2083 bytes --]
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. :-)
> > 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
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-11-29 18:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-29 15:24 [PATCH v14] sndif: add ABI for para-virtual sound Oleksandr Andrushchenko
2016-11-29 15:24 ` [PATCH v14] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other Oleksandr Andrushchenko
2016-11-29 16:09 ` Jan Beulich
2016-11-29 16:55 ` Oleksandr Andrushchenko
2016-11-29 17:05 ` Jan Beulich
2016-11-29 17:27 ` Oleksandr Andrushchenko
2016-11-29 18:30 ` Dario Faggioli [this message]
2016-11-29 18:44 ` Oleksandr Andrushchenko
2016-11-30 8:45 ` Jan Beulich
2016-11-30 9:07 ` Oleksandr Andrushchenko
2016-11-29 16:06 ` [PATCH v14] sndif: add ABI for para-virtual sound Jan Beulich
2016-11-29 16:58 ` Oleksandr Andrushchenko
2016-11-29 17:10 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1480444217.3178.94.camel@citrix.com \
--to=dario.faggioli@citrix.com \
--cc=JBeulich@suse.com \
--cc=al1img@gmail.com \
--cc=andr2000@gmail.com \
--cc=andrii.anisov@gmail.com \
--cc=david.vrabel@citrix.com \
--cc=embedded-pv-devel@lists.xenproject.org \
--cc=ian.jackson@eu.citrix.com \
--cc=iurii.konovalenko@globallogic.com \
--cc=joculator@gmail.com \
--cc=julien.grall@arm.com \
--cc=lars.kurth@citrix.com \
--cc=oleksandr.dmytryshyn@globallogic.com \
--cc=olekstysh@gmail.com \
--cc=tim@xen.org \
--cc=vlad.babchuk@gmail.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).