Re: [PATCH v3 2/2] ALSA: control: add ioctl to retrieve full card components

Takashi Iwai
2026-03-06T10:44:40Z

On Fri, 06 Mar 2026 10:39:46 +0100,
Jaroslav Kysela wrote:
>
> On 3/5/26 11:18, Takashi Iwai wrote:
> > On Thu, 05 Mar 2026 11:11:40 +0100,
> > Maciej Strozek wrote:
> >>
> >> W dniu czw, 05.03.2026 o godzinie 11∶04 +0100, użytkownik Takashi Iwai
> >> napisał:
> >>> On Thu, 05 Mar 2026 10:54:35 +0100,
> >>> Maciej Strozek wrote:
> >>>>
> >>>> W dniu wto, 03.03.2026 o godzinie 16∶47 +0100, użytkownik Takashi
> >>>> Iwai
> >>>> napisał:
> >>>>>>
> >>>>>> + */
> >>>>>> +struct snd_ctl_card_components {
> >>>>>> + int card;
> >>>>>> + unsigned int length;
> >>>>>> + unsigned char *components;
> >>>>>> +};
> >>>>>
> >>>>> And the ioctl can serve for two purposes:
> >>>>>
> >>>>> - When length=0 is set, the kernel stores the current number of
> >>>>> bytes
> >>>>>   and returns without copying.  User-space can use this mode for
> >>>>>   allocating the buffer.
> >>>>>
> >>>> In alsa-lib all data must be allocated beforehand, so this
> >>>> length==0
> >>>> query is not very useful there, it will just go into a [512] array
> >>>> anyway. Are there any other users that may benefit from this?
> >>>
> >>> My suggested API can work even with the fixed size 512, too, if 512
> >>> is
> >>> hight enough.  It's just more flexible.  And there is no restriction
> >>> about alsa-lib data allocation; the function can query the size then
> >>> allocate, too.
> >>>
> >>>
> >>> Takashi
> >>
> >> OK, will prepare v4 with this, thanks
> >
> > Well, let's see how others think, too. The API design needs more
> > considerations because we can't change it any longer once after
> > defined.
>
> I think that the indirect pointer in ioctl structure is the best at
> the moment unless we decide to use the fixed char array.

OK, it might be indeed better if the user-space API is something like:

int snd_ctl_card_components(snd_ctl_t *ctl, unsigned char *buf, size_t len);

Then it's simpler to pass the pointer as is without copying.

> But (for
> discussion) we may try to be a bit clever and define universal bytes
> ioctl which may carry also other things in future like:
>
> enum {
> SND_CTL_CARD_BTYPE_COMPONENTS = 1
> };

So this is for future extensions?

> struct snd_ctl_card_bytes {
> unsigned int card; // this is duplication with info ioctl
> // to be removed?

Right, it sounds like superfluous. I thought we were to allow
extracting a card info for a different card number, but it doesn't
look so.

> unsigned int type; // e.g. SND_CTL_CARD_BTYPE_COMPONENTS
> unsigned int data_allocated; // overall size of data
> unsigned int data_len; // actual data len
> unsigned char *data; // pointer to data array
> };
>
> Scenarios:
>
> data_allocated = 0 or data == NULL -> driver just returns data_len
> data_allocated < data_len -> driver returns -ENOMEM
> data_allocated >= data_len -> driver will copy data
>
> Note that data_len will be zero from the user space for read
> operations (driver knows it). But we can eventually use this ioctl to
> set some data in future, so data_len/data will be used for the write
> operation.

In all cases, data_len is filled with the expected data size in
return, right?

thanks,

Takashi