[alsa-devel] RFC: snd_card_create() function
tiwai at suse.de
Wed Jan 14 16:31:41 CET 2009
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...
More information about the Alsa-devel