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.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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?

>>   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?

Jan


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