Re: [Embedded-pv-devel] [PATCH v12] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Oleksandr Andrushchenko <andr2000@xxxxxxxxx>]

On 11/25/2016 04:45 PM, Jan Beulich wrote:
> > > > On 25.11.16 at 15:27, <andr2000@xxxxxxxxx> wrote:
> > On 11/25/2016 04:12 PM, Jan Beulich wrote:
> > > > > > On 25.11.16 at 14:59, <andr2000@xxxxxxxxx> wrote:
> > > > On 11/25/2016 02:54 PM, Jan Beulich wrote:
> > > > > > > > On 25.11.16 at 12:57, <andr2000@xxxxxxxxx> wrote:
> > > > > > +struct xensnd_page_directory {
> > > > > > +    grant_ref_t gref_dir_next_page;
> > > > > > +    uint32_t num_grefs;
> > > > > You can't fit that many requests on one page anyway, so I think it
> > > > > would be better to limit this to 16 bits, and leave 16 bits reserved
> > > > > for future use (specified as must-be-zero).
got you
> > > > these are not for requests, but for buffers. you can imagine the size of
> > > > this
> > > > buffer if we play something like 8 channels 192kHz...
> > > I don't understand: You have one such entry per page, so how
> > > can it be larger than (or even equal to) PAGE_SIZE / sizeof(grant_ref_t)?
> > we employ the idea of a linked list here, e.g. gref_dir_next_page points
> > to the next page of the same structure.
> > if there are no more pages with grefs then num_grefs will not be equal to
> > (PAGE_SIZE - sizeof(gref_dir_next_page) - sizeof(num_grefs)) /
> > sizeof(grant_ref_t),
> > but will contain the remaining number of grefs in this page
> > this way we can flexibly allocate and reference buffers of any requested
> > size
> This in no way addresses my original or my subsequent replies.
sorry for that, got what you want
agree
> (Apart from that elsewhere you state that a zero gref indicates
> the end of the list.
"If shared
 *   buffer size exceeds what can be addressed by this single page, then
 *   reference to the next page must be supplied (gref_dir_next_page below
 *   is not 0)"
>   And the, am I reading this most recent reply
> of yours correctly that you mean for this list to be volatile? If
> so, how do frontend and backend synchronize accesses?)
this list is only passed from front to back on buffer allocation,
e.g. open command and destroyed on close.
so, read/write happens on already established buffer
> Jan

_______________________________________________
Embedded-pv-devel mailing list
Embedded-pv-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/embedded-pv-devel