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