Re: Best practices for kernel patches?
skaya <skaya@enix.org> writes:
skaya> by the way, what would be the canonical way to distribute a
skaya> iptables patch? I looked the kernel-patch-ulog package, but it
skaya> patches the kernel, and I don't need that : I just need to
skaya> build an independant kernel module ... such packages exist for,
skaya> e.g., nvidia kernel modules, but I would like to know if there
skaya> is some kind of debhelper to build such packages, or if I have
skaya> to start from scratch (or from another package). all the stuff
skaya> about kernel header detection and so on has to be quite
skaya> redundant between all, and I did not find information about
skaya> that in the policy manual. is there a better source of
skaya> information for that concern ?
I don't recall it being documented particularly well anywhere.
Probably the best source of information is
/usr/share/doc/kernel-package/README.modules, under "MODULE Packaging
hints". The kernel-package documentation also includes sample rules
and control files for building kernel modules.
A typical kernel-module package (e.g. lm-sensors, openafs) includes
both some user-space tools and the kernel modules. So the build
process tends to build the user-space tools, clean up, and then tar up
the package source and drop the tarball into debian/my-module-source.
ISTR some module packages (maybe ALSA's?) having completely separate
sets of rules/control/etc. files for the module package; lm-sensors
shares a rules file between the main package and lm-sensors-source.
But you essentially want to wind up with a binary package which, when
installed, has a tar file in /usr/src containing a modules/$PACKAGE
directory which is a Debian source tree for the kernel modules.
You also need to worry about things like having the tarball being
unpacked not-under /usr/src (specifically, into $MODULE_LOC), and
checking that any bizarre dependencies you have are satisfied.
(lm-sensors-source depends on either kernel 2.4.13 or newer, or
i2c-source. Blech. An upload of lm-sensors coming soon will have
logic to actually check for this in 'debian/rules sanity-check'.)
It's not clear what the right way to build modules for Debian-supplied
kernels is. I've mostly punted on the issue for lm-sensors (so
there's just an lm-sensors-source package, no prebuilt modules). Sam
Hartman was going to look at the issue, but from talking to him in
person it sounds like that's going to continue to not be a priority
bit of infrastructure for him for a while. :-/
skaya> additionally, my kernel module comes with a userland plugin for
skaya> iptables ; should it be packaged separately, or be built along
skaya> with the kernel module ? (the userland lib is
skaya> kernel-independant)
It makes sense to package them separately; this is the approach taken
by pretty much every other module package out there.
--
David Maze dmaze@debian.org http://people.debian.org/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
Reply to: