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

[Takashi Iwai <tiwai@suse.de>]

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