From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH - alsa-lib 1/1] Change card/pid get functions to return -ENOSYS if the kernel is too old Date: Mon, 04 Apr 2016 16:54:55 +0200 Message-ID: References: <1459532030-6387-1-git-send-email-agoode@google.com> <20160401211558.GA20661@mail.zuhause> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 601BB2608CF for ; Mon, 4 Apr 2016 16:54:56 +0200 (CEST) In-Reply-To: <20160401211558.GA20661@mail.zuhause> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Martin Koegler Cc: Adam Goode , alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org On Fri, 01 Apr 2016 23:15:58 +0200, Martin Koegler wrote: > > On Fri, Apr 01, 2016 at 01:33:50PM -0400, Adam Goode wrote: > > When trying to get the pid or card of a client, the get functions will > > return -1 if there is no pid or card for a client. Clients have zero or > > one of these, so -1 is correct for these cases. But we also need to detect > > the case where the kernel cannot tell us if there is a card or pid, so > > that userspace can fallback to probing this information in the old way. > > Its a pity, that alsa-lib 1.1.1 has just been released, which just returns -1. > If the time between releases is really about 2 kernel releases, you will very likely > have to cope with the old API for some time. Strictly speaking, for the function behavior change, we'd need a new API function and deprecated the old one eventually. But, this case is in a gray zone; the function definition doesn't prohibit to return an error value yet, but the change like this is incompatible with the current aconnect code, which is likely regarded as a template for other programs. OTOH, this is a pretty new API function, and it might be not too bad to fix the usage in the early stage, especially when it's a good improvement of the function behavior. So, for now, I'm inclined to take this change with a slight risk of breakage. But I'm open for more arguments, and would like to hear any objections. thanks, Takashi