linux-kernel - Re: [PATCH RESEND1 00/12] 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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 4 Sep 2017 10:21:30 +0300
From:   Oleksandr Andrushchenko <andr2000@...il.com>
To:     Takashi Sakamoto <o-takashi@...amocchi.jp>,
        Oleksandr Grytsov <al1img@...il.com>
Cc:     clemens@...isch.de, alsa-devel@...a-project.org,
        xen-devel@...ts.xen.org, linux-kernel@...r.kernel.org,
        tiwai@...e.com,
        Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
Subject: Re: [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized
 frontend driver


On 08/24/2017 10:04 AM, Oleksandr Andrushchenko wrote:
> Hello,
>
> On 08/24/2017 07:38 AM, Takashi Sakamoto wrote:
>> On Aug 23 2017 23:51, Oleksandr Grytsov wrote:
>>> Hi,
>>>
>>> Thank you for detailed explanation.
>>>
>>> We understand that emulated interrupt on the frontend side is 
>>> completely not
>>> acceptable and definitely we need to provide some feedback mechanism 
>>> from
>>> Dom0 to DomU.
>>>
>>> In our case it is technically impossible to provide precise period 
>>> interrupt
>>> (mostly because our backend is a user space application).
>>> The best we can implement it is provide number of frames (time, 
>>> bytes etc.)
>>> consumed by real HW. This info will be outdated due to different 
>>> delays but
>>> we can provide precise timestamps when this info was acquired.
>>
>> Stuffs of ALSA PCM in kernel land is an abstraction layer for actual
>> hardware for data transmission. The stuffs get affects from a design of
>> actual hardware. Furthermore, sound subsystems on the other operating
>> systems such as Microsoft Windows are also designed with a consideration
>> about actual hardware. When you design any interfaces as an abstraction
>> for such software layer, it's better to understand actual hardware and
>> design of low-level software layer somehow.
>>
>> Actually the 'sndif' has no good abstraction for actual hardware,
>> therefore an idea to implement frontend driver as an ALSA driver is not
>> reasonable at all. 
> the reason for that is that you can use the same frontend driver for 
> various
> DomUs without the need to write yet another HAL/application, e.g. if 
> one of the
> DomUs has no PulseAudio (uses ALSA) and yet another DomU has PulseAudio,
> then using the same driver allows you to enable both out of the box 
> with the
> same codebase.
> If we can imagine something else running on top of ALSA (say some other
> mixing software other than PulseAudio) then we will have to support 
> that as well
>
>> It's better to implement it as an application in
>> the other software layer, e.g. sinks/sources of PulseAudio in DomU
> please see our reasoning above
>> via
>> Xenbus. This idea is nearer an original concept of Xen framework, I
>> guess. But I don't know we can write any applications of Xenbus in user
>> land of DomU or not.
>>
>> Anyway, it's not a good idea to have an ALSA driver for the present 
>> 'sndif', in my opinion.
>>
> ok, so the main concern here is that we cannot properly synchronize 
> Dom0-DomU.
> If we put this apart for a second are there any other concerns on 
> having ALSA
> frontend driver? If not, can we have the driver with timer 
> implementation upstreamed
> as experimental until we have some acceptable synchronization solution?
> This will allow broader audience to try and feel the solution and 
> probably contribute?
any thoughts on this?
>>
>> Regards
>>
>> Takashi Sakamoto
> Thank you very much for your time,
> Oleksandr Andrushchenko