All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Koegler <martin.koegler@chello.at>
To: Adam Goode <agoode@google.com>
Cc: Takashi Iwai <tiwai@suse.de>,
	alsa-devel@alsa-project.org,
	Martin Koegler <martin.koegler@chello.at>
Subject: Re: [PATCH - alsa-lib 1/1] Change card/pid get functions to return -ENOSYS if the kernel is too old
Date: Fri, 8 Apr 2016 19:56:33 +0200	[thread overview]
Message-ID: <20160408175633.GA14123@mail.zuhause> (raw)
In-Reply-To: <CAOf41N=vdhUu+y08JZLs7c=DL_LYx4wQgxxnMkWw-eQCUT-etw@mail.gmail.com>

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 ?

Regards,
Martin

  reply	other threads:[~2016-04-08 17:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-01 17:33 [PATCH - alsa-lib 1/1] Change card/pid get functions to return -ENOSYS if the kernel is too old Adam Goode
2016-04-01 17:45 ` Adam Goode
2016-04-01 21:15 ` Martin Koegler
2016-04-04 14:54   ` Takashi Iwai
2016-04-05 15:21     ` Adam Goode
2016-04-07 19:23     ` Adam Goode
2016-04-07 20:10       ` Martin Koegler
2016-04-07 23:00         ` Takashi Sakamoto
2016-04-08 10:24         ` Takashi Iwai
2016-04-08 12:56           ` Jaroslav Kysela
2016-04-08 13:10             ` Takashi Iwai
2016-04-08 15:21               ` Adam Goode
2016-04-08 17:56                 ` Martin Koegler [this message]
2016-04-08 19:53                   ` Adam Goode
2016-06-06 13:57                     ` Adam Goode
2016-06-06 14:01                       ` Takashi Iwai
2017-01-03 13:34                         ` Adam Goode

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160408175633.GA14123@mail.zuhause \
    --to=martin.koegler@chello.at \
    --cc=agoode@google.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.