Re: Merging alsa-kernel-1.0.7 into kernel 2.6.9

[Takashi Iwai <tiwai@suse.de>]

At Thu, 18 Nov 2004 20:41:13 -0800,
Stephen Warren wrote:
> 
> I'm working on a project where we don't use modules for the kernel at
> all - for various reasons such as target environment simplicity - very
> hard-coded boot scripts, no huge sysvinit based interactive 'desktop'
> system etc.
> 
> We need ALSA support, and specifically, alsa-driver 1.0.7 release fixes
> some problems for the target hardware we're using.
> 
> So, I'm attempting to merge the content of alsa-driver 1.0.7 into the
> kernel source tree, and to build ALSA support as non-modules.
> 
> I found a few resources that *basically* say you just copy the
> alsa-kernel directory into the kernel tree and that's it. So, here's
> what I started doing:
> 
> # linux-kernel.org is a virgin kernel.org 2.6.9 tree
> rm -rf linux-kernel.org-2
> cp -rp linux-kernel.org linux-kernel.org-2
> chmod -R +w linux-kernel.org-2
> rm -rf alsa-driver-1.0.7
> tar jxvf patches-src/alsa-driver-1.0.7.tar.bz2
> cd alsa-driver-1.0.7/alsa-kernel/
> rm -rf oss
> cp -a * ../../linux-kernel.org-2/sound
> rm -rf ../../linux-kernel.org-2/sound/include
> rm -rf ../../linux-kernel.org-2/sound/Documentation
> cd include
> cp -a * ../../../linux-kernel.org-2/include/sound
> cd ../Documentation
> cp -a * ../../../linux-kernel.org-2/Documentation/sound/alsa
> cd ../../..
> diff -urN linux-kernel.org linux-kernel.org-2 >
> patches-src/nvidia-2.6.9-alsa-1.0.7-1.diff
> 
> This gets me a pretty fair way. I found from that point, that all I
> needed to do was apply acore/init.patch, then manually fix all the calls
> to module_param_array() to take a dummy count argument to back-port the
> code to the 2.6.9 API.
> 
> Having done this, the kernel does compile and I can get sound working.
> However, I'm wondering if this is a totally 100% correct approach. For
> example, if I watch the result of a regular "./configure;make" build of
> alsa-driver, I notice a lot of patches being applied to the source
> before the build, most to enable the code to compile on a wide range of
> kernels. If I manually apply to my tree every *.patch that the regular
> build process applies, then I'm left with a few sets of errors:
> 
> * memalloc failures, due to missing header files (config.h/adriver.h if
> I recall)
> * KERNEL_VERSION isn't define everywhere, due to missing
> <linux/version.h> includes
> * still have the module_param_array problems
> 
> So, should I just ignore all the patches except init.path, do the manual
> fixup of the module_param_array stuff and be done?

Yes.  The only changes are module_param_array() and
pci_save/restore_config() stuff, IIRC.
I don't remember whether usb has a change (which is one of the most
frequently changed thing).

> Any pointers on the 'correct' way to do this would be greatly
> appreciated. If there's an accurate doc somewhere, my googling hasn't
> found it.

The backporting is the only way, I think.
It's a generic problem of kernel drivers, continuously changing API :)


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8