Kernel module extensions

[Jason W]

One of our goals is the installing of extensions under /usr/local as completely as possible to support PPI method of use and RAM savings of tclocal.  There are times when files just have to be placed above /usr/local, but kernel modules have not been left out in the cold.  TC's depmod utility supports the installing of kernel modules under /usr/local and a symlink has been placed in the base system to accomodate that.  The path that kernel modules need to be installed to is /usr/local/lib/modules/`uname -r`/kernel.  In the base system, the symlink '/lib/modules/`uname -r`/kernel.tclocal' points to '/usr/local/lib/modules/`uname -r`/kernel'.  To move modules into /usr/local, it is easy as inserting /usr/local/ in front of the standard module path (/lib/modules/etc/etc). 

There may be a rare exception where a setup utility uses a hard coded module path and will not work with modules installed under /usr/local.  Alsa is one of these. But that is the only one so far that does not work with this approach, or with the tcz format. 

With the next kernel update, all modules will be moved to /usr/local.  And for all new extensions please install the kernel modules under /usr/local/lib/modules/`uname -r`/kernel.

Don't hesitate to ask if there are any questions.

[Onyarian]

Jason W,

To make a .tcem I was following the wiki clear point "Creating Extensions", perhaps it need to be actualized with the new recommendations in the case of modules with also a clear guideline.

I'm not an expert and when I have to modify a new .tcem with the new recommendation I don't know how, when and where to make changes, perhaps with a lot of time and error-success it can be, but I am an amateur with a little time every day., so a clear guide is very helpful and encourages us to move forward.

I'm very happy with the progress made in the AAO-tc and many can benefit.
Greetings.

[Jason W]

Hi Onyarian,
This is the first formal mention of installing modules in /usr/local, and there does need to be more documentation about it.  Basically our depmod follows symlinks under the /lib/modules/`uname -r` directory. That allows the kernel modules to be installed into /usr/local/lib/modules/`uname -r`/kernel.  Basically, to change an existing kernel module extension it would be something like this:

mkdir pkg
tar xzvf extension.tcem -C pkg
cd pkg
mkdir usr/local/lib  # if it does not exist
mv lib/modules usr/local/lib/
cd ..

For a new extension simply move the lib/moduels directory to /usr/local/lib/modules.

Then create the extension out of the pkg directory as normal. We will add more docs on this in the near future.

[Onyarian]

Thank you, sometimes we can be impatient.

[mikshaw]

And for all new extensions please install the kernel modules under /usr/local/lib/modules/`uname -r`/kernel.

Would that work for a proprietary (but redistributable?) driver such as nvidia graphics?  I said redistributable because although I never checked the license it was made available as an extension for DSL, so I assume it is.

From my experience, the nvidia driver simply builds and installs where it wants to be.

[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.

[Juanito]

Before broadcom released a native driver, I was using the b43 module and firmware for my wireless card - as you describe below, I copied the firmware to /lib and then made a tce extension of it.

Making your own tce firmware extension is probably the way to go as the licence is unlikely to allow us to post an extension of this sort on-line. You could also package up your module in the same extension and call it tcem to be loaded on boot..

[combo3]

Like MikeLockmoore above, I would like to submit a USB wifi firmware package that loads into /lib/firmware, but I'm not sure how to make it PPI compatable.

The firmware package is GPL v2 compliant.

[^thehatsrule^]

If it needs to be in /lib ... it may be a bit obscure, such as:
- copy files somewhere to /usr/local  such as /usr/local/lib/...
- create symlinks in a script, to be called during extension loading and/or system start (could use manual instructions here)

[Jason W]

Storing files under /usr/local and using the startup script to copy them to /lib, /etc, or wherever is a good idea.  As well as installing into a directory under /usr/local and symlinking that directory to /usr or wherever by the script if apps must have them in /usr.  Any extension, whether kernel related or not, could be PPI compatible using that practice.

[bmarkus]

Storing files under /usr/local and using the startup script to copy them to /lib, /etc, or wherever is a good idea.  As well as installing into a directory under /usr/local and symlinking that directory to /usr or wherever by the script if apps must have them in /usr.  Any extension, whether kernel related or not, could be PPI compatible using that practice.

While copy works, it is using additional RAM. I would prefer symlinks.