[alsa-devel] [PATCH] topology: Include <linux/types.h> in API header file

Takashi Iwai tiwai at suse.de
Fri Nov 6 14:33:19 CET 2015


On Fri, 06 Nov 2015 14:31:18 +0100,
Vinod Koul wrote:
> 
> On Fri, Nov 06, 2015 at 01:59:41PM +0100, Takashi Iwai wrote:
> > On Fri, 06 Nov 2015 13:39:36 +0100,
> > mengdong.lin at linux.intel.com wrote:
> > > 
> > > From: Mengdong Lin <mengdong.lin at linux.intel.com>
> > > 
> > > Include <linux/types.h> in the API header file topology.h
> > > 
> > > The struct snd_tplg_stream_caps_template has a member "formats"
> > > of type __le64. So <linux/types.h> is needed.
> > 
> > We shouldn't use __le64 for user-space API.  I couldn't find it in
> > include/topology.h.  Where is it used?
> > 
> > Of course, it's fine to use it for kernel ABI.  But then linux/types.h
> > is already included in local.h, so it shouldn't be a problem.
> 
> Our tool threw this error
> 
> ./local-alsa/include/alsa/topology.h:668:2: error: â__le64â does not name a
> type
>   __le64 formats; /*!< supported formats SNDRV_PCM_FMTBIT_* */
> 
> 
> It is coming from new ABI update
> 
> /*
>  * Stream Capabilities
>  */
> struct snd_soc_tplg_stream_caps {
>         __le32 size;            /* in bytes of this structure */
>         char name[SNDRV_CTL_ELEM_ID_NAME_MAXLEN];
>         __le64 formats; /* supported formats SNDRV_PCM_FMTBIT_* */
> ^^^^^^^^^^^^^^^^^^^^^
> 
>         __le32 rates;           /* supported rates SNDRV_PCM_RATE_* */
>         __le32 rate_min;        /* min rate */
>         __le32 rate_max;        /* max rate */
>         __le32 channels_min;    /* min channels */
>         __le32 channels_max;    /* max channels */
>         __le32 periods_min;     /* min number of periods */
>         __le32 periods_max;     /* max number of periods */
>         __le32 period_size_min; /* min period size bytes */
>         __le32 period_size_max; /* max period size bytes */
>         __le32 buffer_size_min; /* min buffer size bytes */
>         __le32 buffer_size_max; /* max buffer size bytes */
> } __attribute__((packed));
> 
> The problem is the users of alsa-lib and not the alsa-lib compile itself..

The structure above shouldn't be exposed to user-space as is.
If it's a part of alsa-lib API, it must be generic.


Takashi


More information about the Alsa-devel mailing list