RFC: new utility, kmodpatch

[Luigi Rizzo-5]

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

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Oliver Pinter (Pintér Olivér)]

Hi!

Do You think for this project: http://www.ksplice.com/ ?

On 1/1/09, Luigi Rizzo <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 [@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@...>.
>
> _______________________________________________
> freebsd-current@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."
>

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Alex Keda]

Luigi Rizzo ?????:
>      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.
It's very good idea!
Now I will be able to replace WiFi in my HP laptop with Broadcom -->
Intel, previously overwritten it identifier from Broadcom =)))
(In HP laptops work only devices whose ID's contains in BIOS.)
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Christoph Mallon]

Luigi Rizzo schrieb:
> 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 ?).

This looks useful for experimentation.

> Feedback welcome.

Attached is a slightly cleaned up version of your tool. I style(9)ified
it a bit, added const and static, removed unused stuff (asm("jmp
foo")?), added error checks in some places, which were missing, and
ensured that the table read in from file is NUL-terminated. I also
marked one place with XXX, where I think there is an off-by-one error.

> DESCRIPTION
> [...]
>      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.

I think, this should be moved into the EXAMPLES section.


Regards
        Christoph


PS: Hopefully you haven't forgotten my patch.

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Christoph Mallon]

Christoph Mallon schrieb:
> Attached is a slightly cleaned up version of your tool. [...]

The list ate my attachment. Here is a direct link:
http://tron.homeunix.org/kmodpatch.c
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Ben Kaduk]

On Thu, Jan 1, 2009 at 2:17 PM, Oliver Pinter <oliver.pntr@...> wrote:

> Hi!
>
> Do You think for this project: http://www.ksplice.com/ ?
>
> On 1/1/09, Luigi Rizzo <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 ?).
>>

Ksplice is not yet in the linux kernel tree, so it's probably not
what Luigi was referring to.  However, it is a pretty impressive
piece of software, intended to apply security updates to a running
kernel with a "hot-patch" approach.  They give their latest status
update here:
http://lkml.org/lkml/2008/12/5/330
I like that they have the goal of following the entire stable tree,
since it's not always clear which updates are security-related.

Their work is currently licensed under a GPLv2, and they haven't
thought very hard about whether they would be willing to relicense
with a BSD license.  (They're focusing their efforts on the Linux
kernel, for the moment.)

-Ben Kaduk

(disclaimer: the Ksplice developers are friends of mine, so
I heard most of this first-hand.)
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[M. Warner Losh]

In message: <20090101183026.GA15385@...>
            Luigi Rizzo <rizzo@...> 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
:
:     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.

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.

Warner

: 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@...>.
:
: _______________________________________________
: freebsd-current@... mailing list
: http://lists.freebsd.org/mailman/listinfo/freebsd-current
: To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."
:
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Luigi Rizzo-5]

On Fri, Jan 02, 2009 at 11:50:22AM -0700, M. Warner Losh wrote:

> In message: <20090101183026.GA15385@...>
>             Luigi Rizzo <rizzo@...> 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
> :
> :     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.
>
> 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.

true, this approach does not cover 100% of the cases, but I do believe
that it has a very high coverage, especially with removable devices
(more data below).

The usage model I expect is that people will be told something like this

    To support the BenQ T33 phone on FreeBSD/i386 6.x or 7.x do
        kmodpatch -t "umass.ko umass_devdescrs 4 4 4 2" - - @0 0x4050 0x4a5 0x0101 0x4200

    to support the Asus M2N-Vm DVI MCP67 ethernet on FreeBSD/i386 7.x do
        kmodpatch -t "if_nfe.ko nfe_devs 2 2 s" - - @0 0x10de 0x54c -
    and please note TX flow control does not work

This solves the immediate problem of users trying to talk to new hardware,
which hopefully in the next release will be fully supported.

I am more than happy if future FreeBSD version incorporate a different
mechanism such as the one you proposed to 'alias' the device IDs
(even though the alias approach does not cover all cases either;
but it has a complementary coverage area so it will be nice to have
both). The problem in using the "alias" approach in the short term
is that, I believe, it cannot be enabled without changing the kernel.

In any case, i should repeat that my goal is
1) to provide users with a tool that does not require them to rebuild
   kernel/module or reinstall the OS;
2) to figure out if "kmodpatch" (or whatever we want to call it)
   deserves to be part of the base system or we just keep it as a port
   (which is perfectly fine in practice, and also a must for those
   who have an older OS version that they don't want to upgrade).


On coverage of the kmodpatch approach: out of 29 (or 30) usb drivers:
 +  19 are compatible with this approach out of the box
 +   2 could/should be changed to replace a long 'if' statement
       with a table-based approach;
 +   3 (uhid, ulpt, ugen) match on the device class so there is no issue;
 +   2 (urio and ufm) only recognise a single device so it is unclear
       how generic they are, anyways
and the remaining 3-4 are ehci, uhci and ohci drivers.

I am sure things go worse for PCI and PCMCIA devices, but not by a large
degree (and no, i did not do a full count because there are 160 entries
in /sys/dev and this is far beyond the point i want to make).

        cheers
        luigi
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Luigi Rizzo-5]

On Thu, Jan 01, 2009 at 07:19:12PM -0500, Ben Kaduk wrote:

> On Thu, Jan 1, 2009 at 2:17 PM, Oliver Pinter <oliver.pntr@...> wrote:
> > Hi!
> >
> > Do You think for this project: http://www.ksplice.com/ ?
> >
> > On 1/1/09, Luigi Rizzo <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 ?).
> >>
>
>
> Ksplice is not yet in the linux kernel tree, so it's probably not
> what Luigi was referring to.  However, it is a pretty impressive

correct, i think there is some feature (in insmod or whatever the
utility to load a module is) to configure the module so it uses
certain variables (perhaps including recognising a given USB vendor-id pair?)

        cheers
        luigi
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[M. Warner Losh]

In message: <20090102210133.GA57653@...>
            Luigi Rizzo <rizzo@...> writes:
: On Fri, Jan 02, 2009 at 11:50:22AM -0700, M. Warner Losh wrote:
: > In message: <20090101183026.GA15385@...>
: >             Luigi Rizzo <rizzo@...> 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
: > :
: > :     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.
: >
: > 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.
:
: true, this approach does not cover 100% of the cases, but I do believe
: that it has a very high coverage, especially with removable devices
: (more data below).
:
: The usage model I expect is that people will be told something like this
:
:     To support the BenQ T33 phone on FreeBSD/i386 6.x or 7.x do
: kmodpatch -t "umass.ko umass_devdescrs 4 4 4 2" - - @0 0x4050 0x4a5 0x0101 0x4200
:
:     to support the Asus M2N-Vm DVI MCP67 ethernet on FreeBSD/i386 7.x do
: kmodpatch -t "if_nfe.ko nfe_devs 2 2 s" - - @0 0x10de 0x54c -
:     and please note TX flow control does not work

This is a good interface for our users?

: This solves the immediate problem of users trying to talk to new hardware,
: which hopefully in the next release will be fully supported.
:
: I am more than happy if future FreeBSD version incorporate a different
: mechanism such as the one you proposed to 'alias' the device IDs
: (even though the alias approach does not cover all cases either;
: but it has a complementary coverage area so it will be nice to have
: both). The problem in using the "alias" approach in the short term
: is that, I believe, it cannot be enabled without changing the kernel.
:
: In any case, i should repeat that my goal is
: 1) to provide users with a tool that does not require them to rebuild
:    kernel/module or reinstall the OS;
: 2) to figure out if "kmodpatch" (or whatever we want to call it)
:    deserves to be part of the base system or we just keep it as a port
:    (which is perfectly fine in practice, and also a must for those
:    who have an older OS version that they don't want to upgrade).

It is interesting technology, I'm not sure it is the right tool for
the device aliasing...

: On coverage of the kmodpatch approach: out of 29 (or 30) usb drivers:
:  +  19 are compatible with this approach out of the box
:  +   2 could/should be changed to replace a long 'if' statement
:        with a table-based approach;
:  +   3 (uhid, ulpt, ugen) match on the device class so there is no issue;
:  +   2 (urio and ufm) only recognise a single device so it is unclear
:        how generic they are, anyways
: and the remaining 3-4 are ehci, uhci and ohci drivers.

It does require some extra care to introduce duplicate entries into
the table, or reserve space.  With proper aliasing, we could publish
one big file that has all the new aliases since the last release and
there'd be no need to modify the leaf drivers.  With these
modifications, you are inherently limited as to the number of extra
entries you can add.  OK for the one-off patching, but not so good as
an update mechanism.

: I am sure things go worse for PCI and PCMCIA devices, but not by a large
: degree (and no, i did not do a full count because there are 160 entries
: in /sys/dev and this is far beyond the point i want to make).

PC Card drivers are in good shape.  The PCI drivers, by and large,
tend to be a very mixed bag.  Some are good, and have tables, others
aren't so good.  ISA is even worse, but those are much less relevant
today than when I was starting this...

Warner
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Luigi Rizzo-5]

On Fri, Jan 02, 2009 at 04:33:08PM -0700, M. Warner Losh wrote:
> In message: <20090102210133.GA57653@...>
>             Luigi Rizzo <rizzo@...> writes:
...

> : The usage model I expect is that people will be told something like this
> :
> :     To support the BenQ T33 phone on FreeBSD/i386 6.x or 7.x do
> : kmodpatch -t "umass.ko umass_devdescrs 4 4 4 2" - - @0 0x4050 0x4a5 0x0101 0x4200
> :
> :     to support the Asus M2N-Vm DVI MCP67 ethernet on FreeBSD/i386 7.x do
> : kmodpatch -t "if_nfe.ko nfe_devs 2 2 s" - - @0 0x10de 0x54c -
> :     and please note TX flow control does not work
>
> This is a good interface for our users?

i don't know -- in the end it is
    "if you trust me, cut&paste this line into a root shell"
which I believe is simpler than
    "if you trust me, apply this patch, rebuild the kernel and reinstall"

> It is interesting technology, I'm not sure it is the right tool for
> the device aliasing...

> It does require some extra care to introduce duplicate entries into
> the table, or reserve space.

or just overwrite some entry that is unused in your setting,
which again does not work in 100% of the cases but it is very
close to that.

>                               With proper aliasing, we could publish
> one big file that has all the new aliases since the last release and
> there'd be no need to modify the leaf drivers.  With these

in principle yes, though that i expect that the source of info is not
freebsd.org (which often does not have a chance to check/try
whether an alias is correct), but rather mailing lists or other users
which happen to have the same device and tried it.

        cheers
        luigi
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[M. Warner Losh]

In message: <20090103005040.GA64606@...>
            Luigi Rizzo <rizzo@...> writes:
: On Fri, Jan 02, 2009 at 04:33:08PM -0700, M. Warner Losh wrote:
: > In message: <20090102210133.GA57653@...>
: >             Luigi Rizzo <rizzo@...> writes:
: ...
: > : The usage model I expect is that people will be told something like this
: > :
: > :     To support the BenQ T33 phone on FreeBSD/i386 6.x or 7.x do
: > : kmodpatch -t "umass.ko umass_devdescrs 4 4 4 2" - - @0 0x4050 0x4a5 0x0101 0x4200
: > :
: > :     to support the Asus M2N-Vm DVI MCP67 ethernet on FreeBSD/i386 7.x do
: > : kmodpatch -t "if_nfe.ko nfe_devs 2 2 s" - - @0 0x10de 0x54c -
: > :     and please note TX flow control does not work
: >
: > This is a good interface for our users?
:
: i don't know -- in the end it is
:     "if you trust me, cut&paste this line into a root shell"
: which I believe is simpler than
:     "if you trust me, apply this patch, rebuild the kernel and reinstall"

That's debatable :).  Let's trade this hard to do thing for this thing
that's hard to verify...  It might be progress, but it is only tiny,
incremental progress...

: > It is interesting technology, I'm not sure it is the right tool for
: > the device aliasing...
:
: > It does require some extra care to introduce duplicate entries into
: > the table, or reserve space.
:
: or just overwrite some entry that is unused in your setting,
: which again does not work in 100% of the cases but it is very
: close to that.

Yea, it is a kludge that works...

: >                               With proper aliasing, we could publish
: > one big file that has all the new aliases since the last release and
: > there'd be no need to modify the leaf drivers.  With these
:
: in principle yes, though that i expect that the source of info is not
: freebsd.org (which often does not have a chance to check/try
: whether an alias is correct), but rather mailing lists or other users
: which happen to have the same device and tried it.

I'd suspect it is freebsd.org, with inputs from the mailing lists...

Warner
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Gary Jennejohn-3]

On Fri, 2 Jan 2009 23:17:19 +0100
Luigi Rizzo <rizzo@...> wrote:

> On Thu, Jan 01, 2009 at 07:19:12PM -0500, Ben Kaduk wrote:
> > On Thu, Jan 1, 2009 at 2:17 PM, Oliver Pinter <oliver.pntr@...> wrote:
> > > Hi!
> > >
> > > Do You think for this project: http://www.ksplice.com/ ?
> > >
> > > On 1/1/09, Luigi Rizzo <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 ?).
> > >>
> >
> >
> > Ksplice is not yet in the linux kernel tree, so it's probably not
> > what Luigi was referring to.  However, it is a pretty impressive
>
> correct, i think there is some feature (in insmod or whatever the
> utility to load a module is) to configure the module so it uses
> certain variables (perhaps including recognising a given USB vendor-id pair?)
>

These are called moduler parameters in Linux parlance and must be built
into the drivers themselves.  insmod merely provides a mehcanism for
passing them to the drivers.

---
Gary Jennejohn
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Alex Keda]

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

cannot build
HP$ gunzip  --stdout 20090101-kmodpatch.tgz | tar --extract --file=-
HP$ cd kmodpatch
HP$ ll
total 32
-rw-r--r--  1 lissyara  wheel   132B  1 янв 23:08 Makefile
-rw-r--r--  1 lissyara  wheel   6,1K  1 янв 23:07 kmodpatch.8
-rw-r--r--  1 lissyara  wheel    16K  1 янв 22:48 kmodpatch.c
HP$ make
cc -O2 -pipe  -O1 -Wall -Werror -Wunused -g -I/usr/local/include
-L/usr/local/lib -lkvm  kmodpatch.c  -o kmodpatch
cc1: warnings being treated as errors
kmodpatch.c: In function 'dump':
kmodpatch.c:234: warning: format '%d' expects type 'int', but argument 3
has type 'size_t'
kmodpatch.c:291: warning: format '%016llx' expects type 'long long
unsigned int', but argument 3 has type 'uint64_t'
kmodpatch.c: In function 'do_rw':
kmodpatch.c:535: warning: format '%d' expects type 'int', but argument 5
has type 'size_t'
*** Error code 1

Stop in /tmp/kmodpatch.
HP$
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Vyacheslav Druzhinin]

Hi,

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 ?).

Can't make it on CURRENT (31.12.2008) amd64

dvg-nb# make
cc -O2 -pipe  -O1 -Wall -Werror -Wunused -g -I/usr/local/include -L/usr/local/lib -lkvm  kmodpatch.c  -o kmodpatch
cc1: warnings being treated as errors
kmodpatch.c: In function 'dump':
kmodpatch.c:234: warning: format '%d' expects type 'int', but argument 3 has type 'size_t'
kmodpatch.c:291: warning: format '%016llx' expects type 'long long unsigned int', but argument 3 has type 'uint64_t'
kmodpatch.c: In function 'do_rw':
kmodpatch.c:535: warning: format '%d' expects type 'int', but argument 5 has type 'size_t'
*** Error code 1

Stop in /home/dvg/downloads/kmodpatch.

WBR,
Vyacheslav Druzhinin

[Luigi Rizzo-5]

On Sat, Jan 03, 2009 at 09:44:58PM +0300, Alex Keda wrote:

> 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
>
> cannot build
> HP$ gunzip  --stdout 20090101-kmodpatch.tgz | tar --extract --file=-

is this on amd64 ?
in any case, as a temporary workaround just cast the arguments as
suggested by the warnings.

        cheers
        luigi

> HP$ cd kmodpatch
> HP$ ll
> total 32
> -rw-r--r--  1 lissyara  wheel   132B  1 ?????? 23:08 Makefile
> -rw-r--r--  1 lissyara  wheel   6,1K  1 ?????? 23:07 kmodpatch.8
> -rw-r--r--  1 lissyara  wheel    16K  1 ?????? 22:48 kmodpatch.c
> HP$ make
> cc -O2 -pipe  -O1 -Wall -Werror -Wunused -g -I/usr/local/include
> -L/usr/local/lib -lkvm  kmodpatch.c  -o kmodpatch
> cc1: warnings being treated as errors
> kmodpatch.c: In function 'dump':
> kmodpatch.c:234: warning: format '%d' expects type 'int', but argument 3
> has type 'size_t'
> kmodpatch.c:291: warning: format '%016llx' expects type 'long long
> unsigned int', but argument 3 has type 'uint64_t'
> kmodpatch.c: In function 'do_rw':
> kmodpatch.c:535: warning: format '%d' expects type 'int', but argument 5
> has type 'size_t'
> *** Error code 1
>
> Stop in /tmp/kmodpatch.
> HP$

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Max Laier]

On Saturday 03 January 2009 19:47:29 dvg_lab wrote:

> Hi,
>
> 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 ?).
>
> Can't make it on CURRENT (31.12.2008) amd64
>
> dvg-nb# make
> cc -O2 -pipe  -O1 -Wall -Werror -Wunused -g -I/usr/local/include
> -L/usr/local/lib -lkvm  kmodpatch.c  -o kmodpatch
> cc1: warnings being treated as errors
> kmodpatch.c: In function 'dump':
> kmodpatch.c:234: warning: format '%d' expects type 'int', but argument 3
> has type 'size_t'

change %d to %zu

> kmodpatch.c:291: warning: format '%016llx' expects type 'long long unsigned
> int', but argument 3 has type 'uint64_t'

change %016llx to %016jx and cast argument three to uintmax_t

> kmodpatch.c: In function 'do_rw':
> kmodpatch.c:535: warning: format '%d' expects type 'int', but argument 5
> has type 'size_t'

See above %zu

> *** Error code 1
>
> Stop in /home/dvg/downloads/kmodpatch.
>
> WBR,
> Vyacheslav Druzhinin

--
/"\  Best regards,                      | mlaier@...
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Vyacheslav Druzhinin]

Max Laier wrote:

On Saturday 03 January 2009 19:47:29 dvg_lab wrote:
> Hi,
>
> 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 ?).
>
> Can't make it on CURRENT (31.12.2008) amd64
>
> dvg-nb# make
> cc -O2 -pipe  -O1 -Wall -Werror -Wunused -g -I/usr/local/include
> -L/usr/local/lib -lkvm  kmodpatch.c  -o kmodpatch
> cc1: warnings being treated as errors
> kmodpatch.c: In function 'dump':
> kmodpatch.c:234: warning: format '%d' expects type 'int', but argument 3
> has type 'size_t'

change %d to %zu

> kmodpatch.c:291: warning: format '%016llx' expects type 'long long unsigned
> int', but argument 3 has type 'uint64_t'

change %016llx to %016jx and cast argument three to uintmax_t

> kmodpatch.c: In function 'do_rw':
> kmodpatch.c:535: warning: format '%d' expects type 'int', but argument 5
> has type 'size_t'

See above %zu

> *** Error code 1
>
> Stop in /home/dvg/downloads/kmodpatch.

Thanks a lot, Max, it works for me.

WBR,
dvg_lab

[Luigi Rizzo-5]

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 [@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@...>.

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."