[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cf52537811c2958dda4510b50792278d04fe9f39.camel@opensource.cirrus.com>
Date: Fri, 23 Jan 2026 14:42:13 +0000
From: Maciej Strozek <mstrozek@...nsource.cirrus.com>
To: Takashi Iwai <tiwai@...e.de>, Jaroslav Kysela <perex@...ex.cz>
Cc: Takashi Iwai <tiwai@...e.com>, linux-kernel@...r.kernel.org,
linux-sound@...r.kernel.org, patches@...nsource.cirrus.com,
alsa-devel@...a-project.org
Subject: Re: [PATCH v2] ALSA: control: add ioctl to retrieve full card
components
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?
--
Regards,
Maciej
Powered by blists - more mailing lists