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@xxxxxxx>: > >>> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
