Page MenuHomeFreeBSD

Permit local kernel modules to be built as part of a kernel.
ClosedPublic

Authored by jhb on Aug 30 2018, 11:19 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 22 2023, 10:56 PM
Unknown Object (File)
Dec 21 2023, 1:15 AM
Unknown Object (File)
Nov 8 2023, 2:47 AM
Unknown Object (File)
Oct 21 2023, 3:37 PM
Unknown Object (File)
Oct 13 2023, 6:00 PM
Unknown Object (File)
Oct 7 2023, 1:44 AM
Unknown Object (File)
Aug 22 2023, 10:14 AM
Unknown Object (File)
Aug 5 2023, 1:44 PM

Details

Summary

Add support for "local" modules. By default, these modules are located
in LOCALBASE/sys/modules (where LOCALBASE defaults to /usr/local).
Individual modules can be built along with a kernel by defining
LOCAL_MODULES to the list of modules. Each is assumed to be a subdirectory
containing a valid Makefile. If LOCAL_MODULES is not specified, all of
the modules present in LOCALBASE/sys/modules are built and installed along
with the kernel.

This means that a port that installs a kernel module can choose to install
its source along with a suitable Makefile to /usr/local/sys/modules/<foo>.
Future kernel builds will then include that kernel module using the
kernel configuration's opt_*.h headers and install it into /boot/kernel
along with other kernel-specific modules.

This is not trying to solve the issue of folks running GENERIC release
kernels, but is instead aimed at folks who build their own kernels.
For those folks this ensures that kernel modules from ports will always
be using the right KBI, etc. This includes folks running any KBI-breaking
kernel configs (such as PAE).

This is an initial strawman. I know there are other ideas kicking around,
but I think that /boot/modules is stuck with hosting "generic" modules
that are supposed to work with different possible kernels. I think if
we adopt this approach for any kernels that aren't GENERIC, we can
relegate /boot/modules to just holding pre-built objects that work with
GENERIC. We might also consider always compiling kernel modules as a
post-install step when possible even for GENERIC release kernels, but
that is outside the scope of this change. (One issue with always
recompiling is that not all systems have a kernel source tree installed.)

Test Plan
  • Created a little module in /usr/local/sys/modules/foo and verified buildkernel and installkernel built and installed it.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

sys/conf/kern.post.mk
42 ↗(On Diff #47508)

It would be nice if there were a parallel list for people that want to build modules that live outside of src/sys.

47 ↗(On Diff #47508)

yea, I don't like this much at all...

sys/conf/kern.post.mk
62 ↗(On Diff #47508)

It might make sense to have a .if exists ${LOCAL_MODULES_DIR}/${module}/Makefile
here for safety...

sys/conf/kern.post.mk
42 ↗(On Diff #47508)

You mean a way to have N directories that are checked? It's easy to have more directories if they all have some kind of top-level Makefile that recurses into subdirectories (e.g. some kind of 'EXTRA_MODULES_DIR' that is a list of directories to try to recurse into). If they don't have a top-level Makefile it gets messier.

47 ↗(On Diff #47508)

I'm just not sure how else to do it. Another route might be to have a special port that installs a /usr/local/sys/modules/Makefile and stick the equivalent of the 'ls' in that Makefile (and that Makefile would be the one that would honor LOCAL_MODULES similar to MODULES_OVERRIDE being honored by sys/modules/Makefile). However, all ports that install a module would have to depend on this special package, and it makes the build of local modules less self-contained. I also don't know that this really lets you do something better than 'ls' in that port's Makefile either. Maybe the special port could come with a couple of scripts that are used by kernel module ports to add and remove directories to a special Makefile.inc that defines the SUBDIR, but that seems more fragile than the 'ls' approach and a lot more lines of code.

62 ↗(On Diff #47508)

So I can't decide if that is a feature or not. It would only happen if you used an explicit 'LOCAL_MODULES' and one of the explicitly listed modules was missing. I kind of feel like that should probably fail to build. I should see what MODULES_OVERRIDE does if you give it the name of a module that doesn't exist (I feel like that case should fail to build as well)

jhb marked an inline comment as done.Oct 26 2018, 6:34 PM
jhb added inline comments.
sys/conf/kern.post.mk
62 ↗(On Diff #47508)

If you give a bad directory to MODULES_OVERRIDE you just get a build error rather than having it silently ignored, so I think the existing behavior is consistent with that.

I dislike the ls, but have no better suggestion,

This revision is now accepted and ready to land.Oct 29 2018, 10:51 PM
This revision was automatically updated to reflect the committed changes.