RFC: new utility, kmodpatch

[Luigi Rizzo]

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

    http://info.iet.unipi.it/~luigi/FreeBSD/20090101-kmodpatch.tgz

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.

	cheers
	luigi

------- manpage content --------

KMODPATCH(8)            FreeBSD System Manager's Manual           KMODPATCH(8)

NAME
     kmodpatch -- print/modify device/quirk tables in kernel modules

SYNOPSIS
     kmodpatch [-v] [-t file | format] module_name table_name [@offset [args
               ...]]

DESCRIPTION
     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-
     ules.

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

     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

EXAMPLES
     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

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

BUGS
     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)

HISTORY
     The kmodpatch utility first appeared in FreeBSD 8.0 inspired by a similar
     feature present on Linux.

AUTHORS
     The kmodpatch utility was designed and implemented by Luigi Rizzo
     <luigi at FreeBSD.org>.