[alsa-devel] RFC: snd_card_create() function

[Takashi Iwai]

At Wed, 14 Jan 2009 15:14:54 +0000,
James Courtier-Dutton wrote:
> 
> Takashi Iwai wrote:
> > At Mon, 12 Jan 2009 15:06:51 +0000,
> > James Courtier-Dutton wrote:
> >> 2009/1/12 Takashi Iwai <tiwai at suse.de>:
> >>> At Mon, 12 Jan 2009 14:42:06 +0000,
> >>> James Courtier-Dutton wrote:
> >>>> Sounds good to me.
> >>>> One can keep the wrapper outside of the kernel, and only available in
> >>>> alsa-driver for those out of tree people.
> >>> Yes, that's good.
> >>> I think it'd be better to do that after one kernel-cycle later for a
> >>> softer landing, though.
> >>>
> >> How soft do we need this?
> > 
> > One kernel cycle is enough.
> > 
> >> The change is probably max of 3 lines of code per sound card that has
> >> an out of tree driver.
> >> The only one I am aware of is the xfi one. With the wrapper being more
> >> than 3 lines of code being put into the kernel only to be removed
> >> again seems a little un-necessary to me.
> >> For internal kernel changes, I don't think we should care about out of
> >> kernel drivers. None of the rest of the kernel developers go out of
> >> their way for anything out-of-mainline.
> > 
> > Well, my main concern isn't about out-of-kernel drivers like xfi, but
> > the drivers that will come from other trees.  The codes outside ALSA
> > tree, for example, V4L, can't be always controlled by us (suppose a
> > new V4L driver comes in for the next kernel).  And these are more or
> > less "mainline" development.
> > 
> > If you see the linux-next development, you'll find how the internal
> > API can be a pain among several tree merges.  A typical API change
> > (that has been often seen in driver-core area) introduces first a
> > wrapper while converting all in the present kernel, then kill it at
> > the next cycle.
> > 
> 
> Ah! I did not think of V4L. Once cycle seems OK to me. I hope it creates
> a warning message to the V4L developers, although, I don't see why you
> cannot include a patch to V4L together with all the other alsa cards
> drivers that would get into linux-next.

It's possible, but often not too easy if a new V4L driver is
introduced in their tree.  In that case, either we or they import
their/out patch.  This can be a mess once if the tree gets rebased or
a similar thing happens.

Of course,  I already patched the existing drivers (also found in usb 
gadget).  But any upcoming stuff can be hard to expect...


thanks,

Takashi