From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Merging alsa-kernel-1.0.7 into kernel 2.6.9 Date: Fri, 19 Nov 2004 19:33:21 +0100 Message-ID: References: Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: Sender: alsa-devel-admin@lists.sourceforge.net Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Stephen Warren Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org 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 > 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