RFC: new utility, kmodpatch
rizzo at iet.unipi.it
Thu Jan 1 18:25:38 UTC 2009
I mentioned this utility a couple of months ago, and it's now working
so i would like to receive feedback on whether this is good to have
as part of the system, or just keep it as a port (which is what
i plan to do by default).
In a nutshell, the kmodpatch utility can print or alter the content
of device/quirk tables in kernel modules (I think Linux has some
similar tool, though i don't remember the name -- or perhaps it is
a feature of insmod ?).
Full manpage is attached at the end, full sources are at
What is missing is some extra code to let it patch an on-disk file
(elfdump returns the info we need, so in the worst case we just
need to write a wrapper around elfdump).
------- manpage content --------
KMODPATCH(8) FreeBSD System Manager's Manual KMODPATCH(8)
kmodpatch -- print/modify device/quirk tables in kernel modules
kmodpatch [-v] [-t file | format] module_name table_name [@offset [args
The kmodpatch utility can print or alter the content of device/quirk
tables in kernel modules. These tables are generally used to identify
devices, and possibly apply specific quirks to enable/disable certain
features. kmodpatch is especially useful to let the kernel recognise a
new device without rebooting and rebuilding/reinstalling kernel or mod-
In read mode (when no args are specified), kmodpatch only list one or
more entries in the matching module and table.
In write mode, kmodpatch overwrites a user's specified entry in a table
with the values passed on the command line. kmodpatch does some amount
of checking to make sure that the arguments (module and table name, off-
set, parameters formats) are compatible with the currently loaded mod-
A couple of real life examples:
kmodpatch umass.ko - @0 0x4050 0x4a5 0x0101 0x4200
set the kernel to use flags UMASS_PROTO_SCSI | UMASS_PROTO_BBB and
quirks WRONG_CSWSIG | NO_SYNCHRONIZE_CACHE for a certain GSM phone
that implements the umass interface;
kmodpatch uscanner.ko - @0 0x04b8 0x084a 0
let uscanner.ko recognise a newly introduced MFP scanner device.
kmodpatch relies on a list of which modules and tables (associated to
kernel symbols) it can work on, and the format of the records in each ta-
ble. By default kmodpatch uses an internal list, which can be overridden
from the command line using the -t option followed by either a file name,
or by immediate text describing the kernel table. The format of the file
is described in Section MODULE DESCRIPTION
The following options are available:
-v Verbose mode, print some debugging info
-t file | format
Specify a file containing the name and format of descriptor
tables, or a line with the actual format of the table.
The file (or text) describing modules, tables and record structure has a
simple text format with one line per table. The `#' character is a com-
ment delimiter, and can appear anywhere in the text. Each valid line
must contain the following fields:
module_name symbol_name entry_format [entry_format ...]
Each entry_format describes one field in the table, and it is made of a
number and/or a character specifying the field size and format, followed
by an optional ':' and a word describing the field itself.
Supported formats are:
2 | 2l | 2b
16-bit unsigned in host, little-endian or big-endian format;
4 | 4l | 4b
32-bit unsigned in host, little-endian or big-endian format;
8 | 8l | 8b
64-bit unsigned in host, little-endian or big-endian format;
p a pointer;
s a null-terminated string;
The optional description is used as a header when listing the content of
EXAMPLE MODULE DESCRIPTION
The following is an example of a file containing module descriptions.
umass.ko umass_devdescrs 4:vendor 4:product 4:rev 2:proto 2:quirks
uscanner.ko uscanner_devs 2:vendor 2:device 4:flags # comment
if_nfe.ko nfe_devs 2:vendor 2:device s:name
if_re.ko re_devs 2:vendor 2:device 4:type s:name
In addition to the two examples given at the beginning, one can use
kmodpatch to explore the content of kernel tables, as follows.
To list entries in module if_re:
kmodpatch if_re -
To list entry 10 in module umass:
kmodpatch umass - @10
To set the last entry in module uscanner.ko
kmodpatch uscanner.ko - @-1 0x04b8 0x0839 0
kmodpatch requires root privileges even to just read the content of the
In write mode, the use of kmodpatch is as dangerous as accessing
/dev/kmem in write mode, even though kmodpatch does some amount of check-
ing to make sure that the arguments passed are reasonable. To this pur-
pose, it is fundamental that the table descriptions used by kmodpatch
match the actual structure of the kernel tables. There is no automatic
way to extract this info.
Right now, kmodpatch only writes to in-memory modules (or kernel). As a
consequence the approach is not suitable to devices that are persistently
connected to the system and for which the system cannot do a "reprobe".
kldconfig(8), kldload(8), kldstat(8), kldunload(8)
The kmodpatch utility first appeared in FreeBSD 8.0 inspired by a similar
feature present on Linux.
The kmodpatch utility was designed and implemented by Luigi Rizzo
<luigi at FreeBSD.org>.
More information about the freebsd-current