[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.



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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.