Page MenuHomeFreeBSD

A skeleton kernel module suitable for creating new such modules.
ClosedPublic

Authored by gnn on Oct 5 2023, 8:08 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Apr 30, 4:17 PM
Unknown Object (File)
Tue, Apr 30, 4:09 PM
Unknown Object (File)
Tue, Apr 30, 4:08 PM
Unknown Object (File)
Tue, Apr 30, 9:08 AM
Unknown Object (File)
Fri, Apr 26, 9:13 PM
Unknown Object (File)
Fri, Apr 26, 2:46 AM
Unknown Object (File)
Fri, Apr 26, 1:58 AM
Unknown Object (File)
Fri, Apr 26, 12:21 AM
Subscribers

Details

Reviewers
jhb

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 54373
Build 51263: arc lint + arc unit

Event Timeline

gnn requested review of this revision.Oct 5 2023, 8:08 PM

The one caveat is that many kernel modules don't actually have an explicit module event handler. In particular, "modules" is an overloaded term unfortunately that gets used both for foo.ko and moduledata_t. Most of the time people use modules to mean foo.ko, and a single foo.ko can contain multiple (or even zero) moduledata_t instances.

In truth what all modules really have is at least one SYSINIT and possibly a SYSUNINIT. I would be tempted to use those directly for the simplest form of a foo.ko. We have many abstractions that build on top of SYSINITs including things like sysctl nodes as well as DECLARE_MODULE. And we have wrappers on top of DECLARE_MODULE including DEV_MODULE (for standalone /dev/foo) and DRIVER_MODULE (for new-bus). Most foo.ko modules do not use an explicit moduledata_t handler, and many modules use a a mix of various SYSINITs. For example, a driver might use SX_SYSINIT to manage the construction/destruction of a global lock along with DRIVER_MODULE to register/deregister a new-bus driver.

For teaching purposes I would probably describe SYSINIT and SYSUNINIT as global constructor and destructor methods (respectively) and then build up the abstraction stack from there. In particular, many times when I write a quick and dirty foo.ko to test something, I most often use one or more sysctls and don't generally use a moduledata_t handler.

share/examples/modules/skel.c
48
87

I would probably use SI_SUB_LAST instead of SI_SUB_DRIVERS for a generic module.

  • Update the minor issues found by jhb@, other discussion continues.

I have to say I prefer the version with the module_data, even though it is admittedly longer, because it shows the reader how to explicitly add module data. A much simpler verison with SYSINIT and SYSUNINIT doesn't easily show someone how to not only make a module but how to create their private module data. I could create a version with both using a #define #if setup, so we can show both styles. Let me know is that would be preferred or if what we have here is acceptable.

gbe added inline comments.
share/examples/modules/skel.c
62

s/unloadin/unloading/

gnn marked 3 inline comments as done.Nov 13 2023, 9:22 PM

I do think it would be nice to add several modules here, one with just a SYSCTL_PROC for example. Some with SYSINITS, a simple character device perhaps. I have some character device ones I could "donate".

This revision is now accepted and ready to land.Nov 14 2023, 5:37 PM

@jhb Just sent a private email asking for more of these and I'll organize and commit, thanks!

commit 029848334f85e03895234db8b89f5544ffb6e720 (HEAD -> main, freebsd/main, fr>
Author: George V. Neville-Neil <gnn@FreeBSD.org>
Date: Tue Nov 14 16:09:18 2023 -0500

Address review feedback on a typo.

Reviewed by:    jhb, gbe
Differential Revision:  <https://reviews.freebsd.org/D42096>