kldpatch updated (Re: RFC: new utility, kmodpatch)

Hi,
I have updated and renamed the "kldpatch" utility
(formerly kmodpatch), so that now it can also
patch the disk copy of modules (or kernel).
You can find the updated version at the following URL

http://info.iet.unipi.it/~luigi/FreeBSD/20090108-kldpatch.tgz

A description of what it can do is below (old posting attached
for convenience). The manpage in the tarball is more up-to-date.

	cheers
	luigi

On Thu, Jan 01, 2009 at 07:30:26PM +0100, Luigi Rizzo wrote:
> 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 [_at_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 - _at_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 - _at_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 - _at_10
> 
>      To set the last entry in module uscanner.ko
> 
>            kmodpatch uscanner.ko - _at_-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>.