Re: [PATCH v2] ALSA: control: add ioctl to retrieve full card components

[Takashi Iwai <tiwai@suse.de>]

On Fri, 23 Jan 2026 15:42:13 +0100,
Maciej Strozek wrote:
> 
> W dniu pią, 23.01.2026 o godzinie 13∶15 +0100, użytkownik Takashi Iwai
> napisał:
> > On Thu, 22 Jan 2026 14:30:04 +0100,
> > Jaroslav Kysela wrote:
> > > 
> > > On 1/22/26 12:12, Maciej Strozek wrote:
> > > > The fixed-size components field in SNDRV_CTL_IOCTL_CARD_INFO can
> > > > be too
> > > > small on systems with many audio devices.
> > > > 
> > > > Keep the existing struct snd_ctl_card_info ABI intact and add a
> > > > new ioctl
> > > > to retrieve the full components string.
> > > > 
> > > > When the legacy components field is truncated, append '>' to
> > > > indicate
> > > > that the full string is available via the new ioctl.
> > > 
> > > Thanks for the patch. Comments bellow.
> > > 
> > > > @@ -88,7 +89,8 @@ struct snd_card {
> > > >    char irq_descr[32]; /* Interrupt description */
> > > >    char mixername[80]; /* mixer name */
> > > >    char components[128]; /* card components delimited with
> > > > - space */
> > > > + space, truncated to 127 chars */
> > > > + char components_extended[SNDRV_CTL_COMPONENTS_LEN]; /* full
> > > > card components string */
> > > 
> > > I would remove the original components[128] string and replace it
> > > with dynamically allocated 'char *components_ptr' with 'unsigned
> > > int
> > > components_ptr_alloc' to store allocated size. Then the
> > > snd_component_add() function may allocate (and resize) dynamically
> > > the
> > > components_ptr on demand (using e.g. 32 byte step). This will also
> > > catch all drivers using the original struct member when compiled
> > > and
> > > make the memory usage a little bit happier.
> > 
> > Agreed that it'd be better to point to the dynamic allocated array.
> > 
> > And, we can basically drop the limit, too.
> > For example, the ioctl can store the size of the string in return
> > while filling up to the given length.  So, when user-space gives
> > snd_ctl_card_components.length = 0, it just stores the actual string
> > size to this length field.  Then user-space can allocate the needed
> > buffer and get the actual string.
> > 
> > Or, user-space allocates a large-enough size buffer, set to length,
> > and check the actually returned length, too.
> > 
> > Of course, we may (should) have some upper-limit internally for a
> > sanity check, but it doesn't have to be exposed as a part of ABI.
> > 
> > 
> > thanks,
> > 
> > Takashi
> 
> Thank you for your reviews, will prepare a v3 with dynamically
> allocated array soon.
> Do you suggest to simply error out if the internal upper-limit is
> exceeded?

I guess yes, but note that the upper limit check would be rather for
adding component strings, not for the ioctl.
Basically we don't need a temporary kmalloc for ioctl, but we can just
copy the contents since the buffer length is given.


thanks,

Takashi