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:   Thu, 24 Aug 2017 13:38:24 +0900
From:   Takashi Sakamoto <o-takashi@...amocchi.jp>
To:     Oleksandr Grytsov <al1img@...il.com>
Cc:     Oleksandr Andrushchenko <andr2000@...il.com>, 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 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. It's better to implement it as an application in
the other software layer, e.g. sinks/sources of PulseAudio in DomU 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.

Regards

Takashi Sakamoto