From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 20:56:44 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A185106564A for ; Fri, 2 Jan 2009 20:56:44 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 915FE8FC26 for ; Fri, 2 Jan 2009 20:56:43 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9BEA973098; Fri, 2 Jan 2009 22:01:33 +0100 (CET) Date: Fri, 2 Jan 2009 22:01:33 +0100 From: Luigi Rizzo To: "M. Warner Losh" Message-ID: <20090102210133.GA57653@onelab2.iet.unipi.it> References: <20090101183026.GA15385@onelab2.iet.unipi.it> <20090102.115022.1102529931.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090102.115022.1102529931.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 20:56:44 -0000 On Fri, Jan 02, 2009 at 11:50:22AM -0700, M. Warner Losh wrote: > In message: <20090101183026.GA15385@onelab2.iet.unipi.it> > Luigi 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