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

[Jaroslav Kysela]

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. 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
};

struct snd_ctl_card_bytes {
	unsigned int card;		// this is duplication with info ioctl
					// to be removed?
	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.

				Jaroslav

--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.