[alsa-devel] [PATCH - alsa-lib 1/1] Change card/pid get functions to return -ENOSYS if the kernel is too old

[Adam Goode]

On Fri, Apr 8, 2016 at 3:53 PM, Adam Goode <agoode at google.com> wrote:

> On Fri, Apr 8, 2016 at 1:56 PM, Martin Koegler <martin.koegler at chello.at>
> wrote:
>
>> On Fri, Apr 08, 2016 at 11:21:57AM -0400, Adam Goode wrote:
>> > So there are 2 alternatives I can think of:
>> >
>> > option 1: introduce snd_seq_client_info_get_pid_2() and leave the
>> existing
>> > function alone. This new function can return a new constant,
>> > SND_SEQ_CLIENT_INFO_PID_UNKNOWN for missing kernel support. Same for
>> card.
>> > option 2: introduce snd_seq_client_info_pid_known() that returns a bool
>> if
>> > there is kernel support. Same for card.
>>
>> I wouldn't implement option 1. Using that methode for API changes will
>> result in lots of rarely used functions.
>>
>> Chrome will probable need that information to enable a fallback-code - if
>> a application has no fallback code,
>> it has no need for different returncodes. In a few years, most
>> distributions will likely ship kernel including that functions,
>> so there is no need to for fallback-code and the kernel support check any
>> more.
>>
>> Why not a snd_seq_client_info_get_capatibilites() returing bit flags:
>> .._CAP_CARD_NUMBER | .._CAP_PID ?
>>
>>
> This approach is fine by me as well, though it does introduce more
> constants and bitwise logic.
>
>
Since returning to this problem after a while, I've realized that we don't
need any changes at all to alsa-lib. This test is equivalent to what is
needed:

snd_seq_get_client_info(seq, info); // get our client's info
bool client_pid_supported = snd_seq_client_info_get_pid(info) != -1; // do
we know our own PID?

It might be helpful to put this into the documentation, but otherwise I
think this is fine.


Thanks,

Adam