From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755325AbdKBJoN (ORCPT ); Thu, 2 Nov 2017 05:44:13 -0400 Received: from smtp-proxy003.phy.lolipop.jp ([157.7.104.44]:48393 "EHLO smtp-proxy003.phy.lolipop.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751782AbdKBJoL (ORCPT ); Thu, 2 Nov 2017 05:44:11 -0400 Subject: Re: [RFC] ALSA: vsnd: Add Xen para-virtualized frontend driver To: Oleksandr Andrushchenko , tiwai@suse.com, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, xen-devel@lists.xen.org, Konrad Rzeszutek Wilk Cc: Oleksandr Andrushchenko , Oleksandr Grytsov , Clemens Ladisch References: <1502108577-8099-1-git-send-email-andr2000@gmail.com> <2a2fd222-fc54-1709-bfc8-a530efc3f307@gmail.com> <3f8e535b-8607-6b15-6e17-da755a06cc1e@sakamocchi.jp> <3fde10f8-4727-e37b-8001-ce2356fffb2b@sakamocchi.jp> <162b7251-4040-c61f-1fcd-c32f65bd3c67@gmail.com> <8542f293-f2d0-9ba3-7082-967b32fcec17@ladisch.de> <5421f97e-cd7a-dd22-7557-b0fc25899c1b@gmail.com> <232329e2-893f-d40a-3543-062098338bc2@gmail.com> <77dc886e-f3e6-ecef-ed73-c92e966d02f9@epam.com> From: Takashi Sakamoto Message-ID: Date: Thu, 2 Nov 2017 18:44:05 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <77dc886e-f3e6-ecef-ed73-c92e966d02f9@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Oct 30 2017 15:33, Oleksandr Andrushchenko wrote: > This is an attempt to summarize previous discussions on Xen para-virtual > sound driver. > > A first attempt has been made to upstream the driver [1] which brought > number > of fundamental questions, one of the biggest ones was that the frontend > driver > has no means to synchronize its period elapsed event with the host driver, > but uses software emulation on the guest side [2] with a timer. > In order to address this a change to the existing Xen para-virtual sound > protocol [3] was proposed to fill this gap [4] and remove emulation: > 1. Introduced a new event channel from back to front > 2. New event with number of bytes played/captured (XENSND_EVT_CUR_POS, > to be used for sending snd_pcm_period_elapsed at frontend > (in Linux implementation, sent in bytes, not frames to make the protocol > generic and consistent) > 3. New request for playback/capture control (XENSND_OP_TRIGGER) with > start/pause/stop/resume sub-ops. > > Along with these changes other comments on the driver were addressed, > e.g. split into smaller chunks, moved the driver from misc to xen etc. [5]. > > Hope, this helps to get the full picture of what was discussed and makes it > possible to move forward: if the approach seems ok, then I'll start > upstreaming the changes to the sndif protocol and then will send the > updated > version of the driver for the further review. This message has below line in its header. > In-Reply-To: This field is defined in RFC822[1], and recent mail clients use this header field to associate the message to a message which the field indicates. This results in a series of messages, so-called 'message thread'. Iwai-san would like you to start a new message thread for your topic. Would you please post this message again without the header field? Generally, receiving no reactions means that readers/reviewers don't get enough information for your idea yet. (Of course, there's a probability that your work attracts no one...) In this case, submitting more resources is better, rather than requesting comments to them. For instance, you can point links to backend/frontend implementation as para-virtualization drivers which use the new feature of interface, if you did work for it. Indicating procedure to use a series of your work is better for test, if possible. [1] https://www.ietf.org/rfc/rfc0822.txt Regards Takashi Sakamoto