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: >>> >>> 1. 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 -- Jaroslav Kysela <perex@xxxxxxxx> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
