[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 youthese 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 sizeThis 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 bufferSo 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |