On Wed, 12 Dec 2018 16:19:45 +0100,
Pierre-Louis Bossart wrote:
>
>
> >> diff --git a/include/sound/sof/control.h b/include/sound/sof/control.h
> >>
> >> +/* generic channel mapped value data */
> >> +struct sof_ipc_ctrl_value_chan {
> >> + uint32_t channel; /**< channel map - enum sof_ipc_chmap */
> >> + uint32_t value;
> > Any reason to avoid s32 and u32?
> > If this is supposed to be shared with user-space (or user-space may
> > use this as a reference of data struct), we should consider placing in
> > uapi directory, too.
>
> it's intentional
>
> The includes shared with userspace are in include/uapi/sound/sof.
>
> All the files in include/sound/sof, and this one in particular, are
> more for host-dsp IPC.
>
> In those two cases, uapi and IPC files, we don't use s32 and u32. we
> could move this directory under include/uapi/sound/sof-ipc if you
> prefer?
I don't mind so much but just wondered since it looks as if a part of
ABI definition. In anyway, u32/s32 are nicer for kernel codes in
general. When I read int32_t or such lengthy form, automatically my
alarm chimes as if an alien visiting. But it's also no big deal to
keep such types.
BTW, if a file is moved to uapi as a part of ABI, the types should be
__u32, not u32.
> >> +void snd_sof_ipc_free(struct snd_sof_dev *sdev)
> >> +{
> >> + cancel_work_sync(&sdev->ipc->tx_kwork);
> >> + cancel_work_sync(&sdev->ipc->rx_kwork);
> >> +}
> >> +EXPORT_SYMBOL(snd_sof_ipc_free);
> > Not specific to this function but a general question:
> > why not EXPORT_SYMBOL_GPL() in general in the whole SOF codes?
>
> We use a dual license (copied below)
>
> // SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> //
> // This file is provided under a dual BSD/GPLv2 license. When using or
> // redistributing this file, you may do so under either license.
Ah, that can of worms...
I don't know whether it makes so much sense to keep such a dual
license, but I know it's a hairy problem enough for keeping my fingers
away.
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
