[alsa-devel] [alsa-lib][PATCH 0/5] ctl: support extra information for user-defined element set

[Takashi Iwai]

On Thu, 30 Jun 2016 16:22:35 +0200,
Takashi Sakamoto wrote:
> 
> Hi,
> 
> On Jun 30 2016 15:54, Takashi Iwai wrote:
> > On Wed, 29 Jun 2016 15:42:58 +0200,
> > Takashi Sakamoto wrote:
> >>
> >> Hi,
> >>
> >> This patchset adds support extra information to the type-specific for
> >> user-defined element set. Currently, 'dimension' is such an extra
> >> information.
> >>
> >> In ALSA kernel/userspace interface, information to an element is described
> >> in this structure.
> >>
> >> struct snd_ctl_elem_info {
> >>     struct snd_ctl_elem_id id;
> >>     unsigned int access;
> >>     unsigned int count;
> >>     pid_t owner;
> >>     union value;
> >>
> >>     union dimen;
> >>     unsigned char reserved[64 - 4 * sizeof(unsigned short)];
> >> };
> >>
> >> This structure includes reserved fields, thus it's possible to add
> >> more fields for future extension.
> >>
> >> Currently, APIs to add user-defined element set don't support such extra
> >> fields. Meanwhile, supporting just the dimension field is not good as
> >> stable library APIs.
> >>
> >> This patchset changes prototype of the APIs with 'snd_ctl_elem_info_t'
> >> instead of adding more parameters. Callers are expected to fill the parameter
> >> with identification information and the extra information.
> > 
> > Applied, thanks.
> > 
> > But at the next time, try to avoid changing the API functions you
> > added.  They must not be changed once when published, in general.
> 
> In general, it's true.

Yes, and the story is basically over at this point...

> But it's in development cycle now. We don't
> publish the APIs yet. I think it better to permit to change APIs just
> included in the same development period, till releasing. Unless, the
> cost to develop this userspace library becomes quite expensive, at least
> to me.
>
> In this time, I realized the probability of extension of information
> structure, after committing previous patchset, several days after
> reading a thread about extension of data structure which Intel
> developers proposed[1]. I'm not so clever developer, and you're not so,
> too. We should have enough rest to assure the changes.

As I already pulled, it wasn't a big problem in this case.  Otherwise
I didn't pull it.

However, the fact that we had to change the API function means that
the previous design was bad.  Let's accept this truth.  We should be
careful enough not to make such a change happening again.
This is what my previous comment implies.  Nothing more than that.


thanks,

Takashi