Wichert Akkerman writes: > Previously Yann Dirson wrote: > > It does not seem that we have currently any conventions regarding the > > packaging of kernel modules. I just tried the new alsadriver from > > slink, and, for the same reason I could not use the packaged joystick > > driver, this one too is useless to me. > > Can you try recompiling the source package and use that? And what > kernel version are you using? (own compile, kernel version, etc.)
I use my own compile of (upstream) 2.0.33, on an i486, which, guess what, has no PCI bus - so I did not compile with PCI support. The problem is that "insmod snd" reports that it looks for some pci_* symbols. But I didn't try to compile alsa myself, so it may be that alsa requires PCI support - I remember kgi snapshots pre-0.0.9 required PCI too. > > 2) These packages only provide compiled modules for some special > > kernel version. Eg, alsa install its modules for 2.0.33; joystick > > used to do it for 1 version I don't remember, and after a bug report, > > finally included the driver for 2 kernel versions, which even did not > > solve my problem, for the above-mentionned reason. > > This is always a horny problem, which is inherrent to changing kernel > interface. I've compiled the ALSA-packages on my own 2.0.33 kernel (somewhat > patched), but it should work on other 2.0.33 kernels AFAIK. Not only. As I understand it, the kernel defines some symbol names that include a checksum on something (functions ? see <kernel-top>/include/linux/modules/*.ver). If the involved part of the kernel has changed, the modules that were compiled against the old version won't link against the new one. At least that's what I understood last time I checked. This seems to mean that when you use a kernel that is compiled with different patches, you can expect that some precompiled modules won't link correctly - just try this between 2 sufficiently different kernel versions (you'll need to "insmod -f" because a the version-string change), like 2.0.33 and .34, and see how many modules of one you can cause the other one to accept... > > kernel-package, which seem to be the tool to build a kernel the Right > > Way on a Debian system, provides a framework to also build the > > relevant modules from /usr/src/modules/, which can IMHO be used to > > solve these problems. > > I have no idea how flexibable kernel-package is with respect to other > modules, or how the interface works. If there is a general interface I > would be happy to incorporate it in the alsa-packages. IIRC, put your modules into /usr/src/modules/, cd to the kernel tree you want to compile modules for, and ask eg. "make-kpkg modules_image" > > I think the various modules should be primarily packaged in source > > form, just as the kernel is, and installed under /usr/src/modules/. > > And packaged compiled for the standard kernel-image packages, so we > can use them on the bootdisks if wanted. Er, yes, did I really forget to write that ? ;) -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, isp-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
