Tiny Core Extensions > TCE News

Kernel module extensions

<< < (2/4) > >>

Jason W:
As for the module in the nvidia extension, JLS had installed the module in /usr/local/lib/modules/`uname -r` with the original submission.  And depmod does map it properly so modprobe will load the module.

The nvidia license does allow redistribution.

Kernel modules, whether native to the kernel tree or not, tend to get installed into /lib/modules/`uname -r`.  Manually moving them to /usr/local/lib/modules/`uname -r` when making an extension does not affect the ability for the modules to be located by depmod and loaded by modprobe.  Setup scripts that use hardcoded paths to locate kernel modules are the main enemy of this approach.

^thehatsrule^:
It doesn't really matter where the module is located though.  Depending on the version of module-init-tools, modprobe may follow symlinks... but there's always insmod. [There is a 'grey' area concerning the module being linked to the kernel though]

Jason W:
Depmod is the tool at hand in terms of finding and mapping kernel modules so they can be loaded, and that is the tool that was patched to follow symlinks in /lib/modules/`uname -r` except for "build" and "source".  Modprobe and insmod have not been changed.  Modprobe simply refers to the mapping that depmod gathers when it loads modules.  Standard current depmod will not make use of tclocal installed modules as it does not follow symlinks in /lib/modules as it can hang if it enters the build or source symlinked directories. 

The modules must be installed under /lib/modules/`uname -r` or /usr/local/lib/modules/`uname -r` or they will not be found.  If at all possible, install under /usr/local/lib/modules/`uname -r` as mentioned for PPI and tclocal compatibility using modprobe.

EDIT: I may have misunderstood Hats' post above as to where the modules could be installed and modprobe.

^thehatsrule^:
No problem - your post makes it clearer :)

MikeLockmoore:
I built a kernel module for my TI-acx based WiFi adapter.  I see from this thread that I should put my acx.ko file into /usr/local/lib/modules/`uname -r`/kernel, if I understand it correctly.  (Or maybe in a subdir of that?)

My acx.ko file needs to load firmware into the chipset of the WiFi adapter card.  The source code uses the request_firmware( ) API call defined in <linux/firmware.h> to do this, which is part of the "hotplug" system.  However, I'm not sure TC has this hotplug system running.  I could only get my acx.ko module to work by creating a /lib/firmware directory and copying my WiFi chipset firmware there, which I suppose is some kind of "fallback" location for firmware.  But adding /lib/firmware makes my environment less TC-standard, correct? 

If I want to package up this acx as a .tecm package, how should I handle this issue?  Can /lib/firmware be a symlink to something under /usr/local/lib/firmware?  EDIT: no, a symlink does not seem to work.  The wireless start script called from bootlocal.sh does not succeed if the /lib/firmware is a symlink to /usr/local/lib/modules/firmware (where I had stored by firmware file).  Funny thing, though, if I run the same wireless start script later on in a terminal, it works fine.  ???

As a second consideration, the firware included with the WiFi card is most likely not GPL or LGPL, so it would probably necessary for the user to approve or explicitly request the firmware to be installed.  The acx source code includes a bash script to fetch driver packages including the chipset firmware from various sources and extract it into the format (and location?) acx.ko expects to find.  Can a .tcem installation automatically start such an installation script and query the user whether to proceed to find and install the chipset firmware?

Maybe there are not enough TI acx WiFi users out there to justify a .tcem?  Thanks for any guidance.

Navigation

[0] Message Index

[#] Next page

[*] Previous page