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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 2 Nov 2017 11:55:14 +0200
From:   Oleksandr Andrushchenko <Oleksandr_Andrushchenko@...m.com>
To:     Takashi Sakamoto <o-takashi@...amocchi.jp>, tiwai@...e.com,
        alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
        xen-devel@...ts.xen.org,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:     Oleksandr Andrushchenko <andr2000@...il.com>,
        Oleksandr Grytsov <al1img@...il.com>,
        Clemens Ladisch <clemens@...isch.de>
Subject: Re: [RFC] ALSA: vsnd: Add Xen para-virtualized frontend driver


On 11/02/2017 11:44 AM, Takashi Sakamoto wrote:
> 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@...il.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?
of course, sorry about that
>
> 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.
>
will do
> [1] https://www.ietf.org/rfc/rfc0822.txt
>
> Regards
>
> Takashi Sakamoto
Thank you,
Oleksandr