Re: [PATCH] Provide card number / PID via sequencer client info

[Takashi Iwai <tiwai@suse.de>]

On Tue, 16 Feb 2016 09:59:37 +0100,
Clemens Ladisch wrote:
> 
> Takashi Iwai wrote:
> > Martin Koegler wrote:
> >> On Mon, Feb 15, 2016 at 11:34:09PM +0100, Takashi Iwai wrote:
> >>>> On Mon, Feb 15, 2016 at 08:08:12PM +0100, Takashi Iwai wrote:
> >>>>> Well, the question is whether only card number is enough.  What if
> >>>>> cards provide multiple rawmidi devices?
> >>>>
> >>>> Aren't they currently ports?
> >>>> seq_midi.c creates just one sequencer device per card number.
> >>>
> >>> Look at cards with synth support, e.g. emu10k1 or OPL3/OPL4.
> 
> Or snd-virmidi.
> 
> >> Should I export the client_index parameter of snd_seq_create_kernel_client too?
> >
> > Well, I'd rather ask what are the requirements -- in wide ranges.
> 
> The original requirement was just the ability to get the card name.

Yep.  And it's the assumption of only rawmidi, I suppose.  How would
it differentiate from synth?

> > As you already noticed, multiple rawmidi devices and rawmidi
> > subdevices are mapped into a single client with various ports.
> 
> Actually, multiple devices get multiple clients.

I thought of so, but reading back seq_midi.c, it looks different...

> > And, as mentioned, some cards provide indeed multiple clients.  How do
> > you identify which client is for what?  So far, it's identified only
> > from the name string and the type bits of each port.  Isn't it enough?
> > If not, what have to be provided?
> 
> This patch is about the card.  If we really need a method to identify
> the device, we can still add it later -- this patch does not obstruct
> such an extension.

Sure, it won't conflict.  But, the question is (back to square)
whether it's enough.

If we know that we shall change the API again, it's better to consider
the design well from the beginning.  A short-living API version bump
is the thing we should avoid as much as possible.  It's nothing but a
needless stress for maintainers :)

That said, I'm not particularly against the currently proposed change.
My only concern is whether we need any further change in (near)
future.


Takashi