Re: RFC: new utility, kmodpatch

In message: <20090102210133.GA57653_at_onelab2.iet.unipi.it>
            Luigi Rizzo <rizzo_at_iet.unipi.it> writes:
: On Fri, Jan 02, 2009 at 11:50:22AM -0700, M. Warner Losh wrote:
: > 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
: > : 
: > :     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" - - _at_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" - - _at_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