RFC: new utility, kmodpatch
M. Warner Losh
imp at bsdimp.com
Fri Jan 2 18:53:27 UTC 2009
In message: <20090101183026.GA15385 at onelab2.iet.unipi.it>
Luigi Rizzo <rizzo at iet.unipi.it> writes:
: 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).
: Feedback welcome.
Again the feedback I always give here: You really need to have a
compatibility table so that all drivers work. This approach is
inherently limited to those drivers that have tables, and those
drivers that treat any match in that table as the same. Many drivers
don't fall into this category.
: ------- 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.
: MODULE DESCRIPTION
: 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
: a table.
: 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
: kernel tables.
: 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".
: SEE ALSO
: 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>.
: freebsd-current at freebsd.org mailing list
: To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
More information about the freebsd-current