Re: [Xen-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:56 PM, Jan Beulich wrote:
> > > > On 25.11.16 at 15:50, <andr2000@xxxxxxxxx> wrote:
> > 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)"
> Okay, in that case - what's the count for in the first place?
> Couldn't you simply fill all the rest of the page with grefs, as
> it would be clear from the specified buffer size how many there
> are?
yes, this can be done this way. I will remove num_grefs and put a comment
on how to determine when to stop
> > >    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
> So if read/write use that buffer, and the volume and muting
> controls use it too, how do I change the volume while listening
> without disturbing the read/write?
read/write do not happen continuously, e.g. sound card fills its
internal buffers (our buffer is busy) and then until next re-fill our
buffer is free. that means that there is almost no congestion and
always a good chance to set/get volume w/o problem
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel