Dne 09. 03. 21 v 1:38 Takashi Sakamoto napsal(a):
On Mon, Mar 08, 2021 at 03:33:46PM +0100, Jaroslav Kysela wrote:
Dne 08. 03. 21 v 13:58 Takashi Sakamoto napsal(a):
My concerns are:
- evaluation of numid field is not covered.
This is not preferable since ALSA control core implementation covers two types of comparison; numid only, and the combination iface, device, subdevice, name, and index fields. If the API is produced for general use cases, it should correctly handle the numid-only case, in my opinion.
My motivation was to allow to use this function for qsort() for example. The numid and full-field comparisons are two very different things.
Yep. I easily associated sort implementation in hcontrol API or simple mixer API from your implementation
However, the new API is a part of control API and it just achieves things without any supplemental information given from userspace implementation.
It's not required, if documented. Nobody forces to use this function in the app code.
For the above comparison API, as I described, it's not appropriate. ID structure for control element is not comparable, thus it should be dropped or replaced with equality function such as 'snd_ctl_elem_id_equal()'.
I don't require the numid match at this point. The numid is not known or may change for the id entered by the user. So I need to forcefully ignore it.
If we need a function which follow numid + full id comparison, then we can introduce it. I agree that it should return only a boolean return value in this case.
When you need any sorting algorithms, it should be implemented in application side or alsa-lib API in the other layer such as hcontrol and simple mixer since control API should follow to specification of ALSA control written in kernel land.
I don't follow your arguments here. The numid and full field comparisons are two different things. The caller must know things behind the scene. The snd_ctl_elem_id_compare() function may be used as a quick backend for the full field comparisons with the optimized execution (reduce app -> library calls).
The enums conversion to integers: I think that we're safe here. The interface enum numbers cannot change and we know the range (and the order), so it's safe.
Lastly, the qsort() with snd_ctl_id_compare() as an argument will produce a consistent, understandable result, right?
Jaroslav