root/trunk/freewrt/Docs/new_kmod_creation.txt

New kmod IPKG creation style
============================

The KMOD_template is a PITA. Having an automated algorithm to create the IPKG
files from the built kernel modules is a lot better way of doing it. Following
the KISS principle, let's simply create one IPKG per module, extracting all
necessary information right out of the module itself.

PKGNAME="kmod-${FILENAME%%.ko}"
FILENAME="${PKGNAME}.ipk"
DESCR="`modinfo ${FILENAME} | grep description | sed 's/description: //'`"
DEPENDS="kernel (${BOARD}-${KERNEL}-${LINUX_VERSION}) \
        `modinfo ${FILENAME} | grep depends | sed 's/depends: //'`"

There is one major problem left: the ADK never enables modular kernel features
for being built into the kernel binary, they always end up as modules. The
decision of the user of whether a certain kernel feature is "m" or "y" just
decides whether the module is being shipped with the generated image or not.

This is where the problems start: since for every built module the decision
has to be made of whether it has to be built into the image or not, there has
to be knowledge about the corresponding kernel config symbol's value. But it's
not the value, it's the symbol: Actually, it's non-trivial to find out which
kernel config symbol triggered the creation of a certain kernel module. This
information is kept inside the kernel's Makefile tree, and stays in there.
Until there is a better way of finding this out, we'll have to stick with
another PITA in return for the initial one.

The following shell function tries to find the kernel module name for a given
kernel symbol:

| func sym2kmod() {     # ("<kernel symbol name>")
|       find . -name Makefile -print0 | \
|       xargs -0 grep "obj-\$(CONFIG_$1).*\.o" | \
|       sed -n 's/.*= \(.*\)\.o/\1/p'
| }

Trying to prove it's correctness:

| grep FWRT_KPACKAGE_KMOD_ Config.in.kernelopts | \
|       sed s/FWRT_KPACKAGE_KMOD_// > temp_kernel_module_symbols
| for i in $(<temp_kernel_module_symbols); do
|       echo -n "$i: "
|       sym2kmod $i
| done | grep -v :

The output shows "fails". Interesting problems are:

| sym2kmod IPX
| sym2kmod ATALK
| sym2kmod OPROFILE

Doing a reverse lookup seems to be more successful. The following code
searches the kernel path at $CWD for the corresponding symbol name to a given
module name:

| kmod2ksym() { # ("module basename")
|       find . -name Makefile -print0 | \
|       xargs -0 grep "obj-\$(CONFIG_.*).*=.* $1.o" | \
|       sed -n 's/.*obj-\$(CONFIG_\(.*\)).*=.*/\1/p' | \
|       tr '\n' ' '
|       echo ""
| }

The function prints a list of kernel symbols triggering the creation of the
given module. If one of them is set to "y" via the ADK's menuconfig, the
module has to be shipped within the rootfs image.

The following function is a sample implementation of how the information
gathered above could be formatted into a syntax understood by make:

| kmoddeps() { # ("module basename")
|       for sym in `kmod2ksym $1`; do
|               printf 'obj-$(FWRT_KPACKAGE_KMOD_%s) += %s.ko\n' $sym $1
|       done
| }

The Kmod_template in mk/kernel.mk adds the given kernel ipkg name to the make
variable INSTALL_TARGETS. The install target in mk/kernel-build.mk then
installs the mentioned names into the rootfs.