Re: [RFC] ALSA: vsnd: Add Xen para-virtualized frontend driver

From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>,
	tiwai@suse.com, alsa-devel@alsa-project.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Oleksandr Andrushchenko <andr2000@gmail.com>,
	Oleksandr Grytsov <al1img@gmail.com>,
	Clemens Ladisch <clemens@ladisch.de>
Subject: Re: [RFC] ALSA: vsnd: Add Xen para-virtualized frontend driver
Date: Thu, 2 Nov 2017 18:44:05 +0900	[thread overview]
Message-ID: <b229c2d1-7628-d6dd-73f1-94a4a4106f52@sakamocchi.jp> (raw)
In-Reply-To: <77dc886e-f3e6-ecef-ed73-c92e966d02f9@epam.com>

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: <e56a09e9-da66-b748-4e82-4b96a18cef32@gmail.com>

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