Re: RFC: new utility, kmodpatch

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