Re: RFC: packaging kernel modules
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 <ydirson@mygale.org> | Stop making M$-Bill richer & richer,
isp-email: <ydirson@a2points.com> | support Debian GNU/Linux:
debian-email: <dirson@debian.org> | more powerful, more stable !
http://www.mygale.org/~ydirson/ | Check <http://www.debian.org/>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: