|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] sndif: add ABI for Para-virtual sound
El 20/01/15 a les 11.22, Oleksandr Dmytryshyn ha escrit:
> Frontend driver registers an virtual sound card
> and sends an PCM streams to the backend driver.
> Backend driver is an user-space application.
>
> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx>
> Signed-off-by: Iurii Konovalenko <iurii.konovalenko@xxxxxxxxxxxxxxx>
> ---
> Changes since v1:
> * removed __attribute__((__packed__)) from all structures definitions
>
> xen/include/public/io/sndif.h | 205
> ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 205 insertions(+)
> create mode 100644 xen/include/public/io/sndif.h
>
> diff --git a/xen/include/public/io/sndif.h b/xen/include/public/io/sndif.h
> new file mode 100644
> index 0000000..1b93520
> --- /dev/null
> +++ b/xen/include/public/io/sndif.h
> @@ -0,0 +1,205 @@
> +/******************************************************************************
> + * sndif.h
> + *
> + * Unified sound-device I/O interface for Xen guest OSes.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense,
> and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright (C) 2013-2015 GlobalLogic Inc.
> + */
> +
> +#ifndef __XEN_PUBLIC_IO_SNDIF_H__
> +#define __XEN_PUBLIC_IO_SNDIF_H__
> +
> +/*
> + * Feature and Parameter Negotiation
> + * =================================
> + * The two halves of a Xen vsnd driver utilize nodes within the XenStore to
> + * communicate capabilities and to negotiate operating parameters. This
> + * section enumerates these nodes which reside in the respective front and
> + * backend portions of the XenStore, following the XenBus convention.
> + *
> + * All data in the XenStore is stored as strings. Nodes specifying numeric
> + * values are encoded in decimal. Integer value ranges listed below are
> + * expressed as fixed sized integer types capable of storing the conversion
> + * of a properly formated node string, without loss of information.
> + *
> + * Any specified default value is in effect if the corresponding XenBus node
> + * is not present in the XenStore.
> + *
> + * XenStore nodes in sections marked "PRIVATE" are solely for use by the
> + * driver side whose XenBus tree contains them.
> + *
> +
> *****************************************************************************
> + * Backend XenBus Nodes
> +
> *****************************************************************************
> + *
> + *------------------ Backend Device Identification (PRIVATE)
> ------------------
> + *
> + * stream_id
> + * Values: <uint32_t>
> + *
> + * Virtuelized stream number
> + *
> +
> *****************************************************************************
> + * Frontend XenBus Nodes
> +
> *****************************************************************************
> + *
> + *----------------------- Request Transport Parameters
> -----------------------
> + *
> + * event-channel
> + * Values: <uint32_t>
> + *
> + * The identifier of the Xen event channel used to signal activity
> + * in the ring buffer.
> + *
> + * ring-ref
> + * Values: <uint32_t>
> + * Notes: 6
> + *
> + * The Xen grant reference granting permission for the backend to map
> + * the sole page in a single page sized ring buffer.
> + */
> +
> +/*
> + * PCM FORMATS.
> + */
> +#define SNDIF_PCM_FORMAT_S8 (0)
> +#define SNDIF_PCM_FORMAT_U8 (1)
> +#define SNDIF_PCM_FORMAT_S16_LE (2)
> +#define SNDIF_PCM_FORMAT_S16_BE (3)
> +#define SNDIF_PCM_FORMAT_U16_LE (4)
> +#define SNDIF_PCM_FORMAT_U16_BE (5)
> +
> +/* low three bytes */
> +#define SNDIF_PCM_FORMAT_S24_LE (6)
> +
> +/* low three bytes */
> +#define SNDIF_PCM_FORMAT_S24_BE (7)
> +
> +/* low three bytes */
> +#define SNDIF_PCM_FORMAT_U24_LE (8)
> +
> +/* low three bytes */
> +#define SNDIF_PCM_FORMAT_U24_BE (9)
> +
> +#define SNDIF_PCM_FORMAT_S32_LE (10)
> +#define SNDIF_PCM_FORMAT_S32_BE (11)
> +#define SNDIF_PCM_FORMAT_U32_LE (12)
> +#define SNDIF_PCM_FORMAT_U32_BE (13)
> +
> +/* 4-byte float, IEEE-754 32-bit, range -1.0 to 1.0 */
> +#define SNDIF_PCM_FORMAT_FLOAT_LE (14)
> +
> +/* 4-byte float, IEEE-754 32-bit, range -1.0 to 1.0 */
> +#define SNDIF_PCM_FORMAT_FLOAT_BE (15)
> +
> +/* 8-byte float, IEEE-754 64-bit, range -1.0 to 1.0 */
> +#define SNDIF_PCM_FORMAT_FLOAT64_LE (16)
> +
> +/* 8-byte float, IEEE-754 64-bit, range -1.0 to 1.0 */
> +#define SNDIF_PCM_FORMAT_FLOAT64_BE (17)
> +
> +/* IEC-958 subframe, Little Endian */
> +#define SNDIF_PCM_FORMAT_IEC958_SUBFRAME_LE (18)
> +
> +/* IEC-958 subframe, Big Endian */
> +#define SNDIF_PCM_FORMAT_IEC958_SUBFRAME_BE (19)
> +
> +#define SNDIF_PCM_FORMAT_MU_LAW (20)
> +#define SNDIF_PCM_FORMAT_A_LAW (21)
> +#define SNDIF_PCM_FORMAT_IMA_ADPCM (22)
> +#define SNDIF_PCM_FORMAT_MPEG (23)
> +#define SNDIF_PCM_FORMAT_GSM (24)
> +#define SNDIF_PCM_FORMAT_SPECIAL (31)
> +
> +/*
> + * REQUEST CODES.
> + */
> +#define SNDIF_OP_OPEN 0
> +#define SNDIF_OP_CLOSE 1
> +#define SNDIF_OP_READ 2
> +#define SNDIF_OP_WRITE 3
> +#define SNDIF_SET_VOLUME 4
> +#define SNDIF_GET_VOLUME 5
> +
> +#define SNDIF_MAX_PAGES_PER_REQUEST 10
> +
> +/*
> + * STATUS RETURN CODES.
> + */
> + /* Operation failed for some unspecified reason (-EIO). */
> +#define SNDIF_RSP_ERROR -1
> + /* Operation completed successfully. */
> +#define SNDIF_RSP_OKAY 0
> +
> +struct snd_params {
> + uint32_t format; /* SNDIF_PCM_FORMAT_??? */
> + uint32_t channels; /* Channels count */
> + uint32_t rate; /* Data rate */
> +};
> +
> +struct sndif_request_common {
> + uint64_t id; /* private guest value, echoed in resp */
> + struct snd_params _pad1;
> + uint32_t _pad2;
> + uint32_t _pad3;
> +};
> +
> +struct sndif_request_open {
> + uint64_t id; /* private guest value, echoed in resp */
> + struct snd_params snd_params;
> + uint32_t stream;
> + uint32_t _pad2;
> +};
> +
> +struct sndif_request_rw {
> + uint64_t id; /* private guest value, echoed in resp */
> + struct snd_params _pad1;
> + uint32_t len;
> + uint32_t _pad2;
> + grant_ref_t gref[SNDIF_MAX_PAGES_PER_REQUEST];
> +};
> +
> +struct sndif_request_volume {
> + uint64_t id; /* private guest value, echoed in resp */
> + struct snd_params _pad1;
> + uint32_t left;
> + uint32_t right;
> +};
> +
> +struct sndif_request {
> + uint8_t operation; /* SNDIF_OP_??? */
> + union {
> + struct sndif_request_common common;
> + struct sndif_request_open open;
> + struct sndif_request_rw rw;
> + struct sndif_request_volume vol;
> + } u;
> +};
Describing protocols in terms of structs has given us problems in the
past (like the blk protocol, that has two different layouts depending on
the bitness).
In general I would prefer any new protocol that's added to Xen to be
described with plain binary layouts, just like protocols are usually
written. For example like it's done in:
http://tools.ietf.org/html/rfc793#page-15.
Providing suitable structs would be a bonus, but not a way to describe it.
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |