From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 10:19:28 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 873EA106569C for ; Sun, 28 Sep 2008 10:19:28 +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 10EF78FC0A for ; Sun, 28 Sep 2008 10:19:27 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 18598730A8; Sun, 28 Sep 2008 12:07:31 +0200 (CEST) Date: Sun, 28 Sep 2008 12:07:31 +0200 From: Luigi Rizzo To: freebsd-arch@freebsd.org Message-ID: <20080928100731.GA49323@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: dynamic update of usb/pci/quirks tables X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2008 10:19:28 -0000 For some time I have been thinking of a way to solve the problem in the subject., which is hitting me almost every time i try to connect a newly bought device (scanner, phone, camera, mp3 player, even some flash keys) to FreeBSD. I was wondering what you people think about the following approach, which can be implemented by a trivial userland program (kldpatch) and probably be used with little effort or code bloat also in the loader. PROBLEM DESCRIPTION: A common problem with newer USB (but also other) peripheral is that often the kernel does not have the correct product and vendor numbers in its internal tables used for device matching or for applying quirks to certain devices. The problem arises quite often with e.g. uscanner (where the matching must be done through the table because there is no specific device class), or with various umass devices (flash keys, cameras, phones, etc.) which tend to require quirks because they do not implement all the default features used by the umass driver. APPROACH: The following approach can be used to patch the in-kernel structures used to store the match/quirks tables: + use kldfind and kldsym to locate the module, address and size for the desired data structure; + use kvm_open/kvm_read/kvm_write to read and possibly update the table. Of course patching the live kernel is dangerous, so one way to make the process a little less risky is to put some additional controls in the frontend program which implements the above. In particular, the frontend will contain a table of the form module symbol record_size record_format... which defines which modules/symbols can be patched and how each record is supposed to be structured. As an example: uscanner.ko uscanner_devs 8 2 2 4 umass.ko umass_devdescrs 16 4 4 4 2 2 if_sis.ko sis_devs 8 2 2 %s tells that uscanner has 8-byte records made of 3 numeric fields of size 2 2 4, umass.ko has 16-byte records with 5 numeric fields, if_sis has 8-byte records whose last one is a string pointer, (I could not find an instance with a fixed-size string). The frontend will accept commands of the form kldpatch if_sis.ko sis_devs write @3 0x1234 0x5678 "temporary entry" which means 'patch record 3 with the values specified". The frontend will make sure that operands are of the required size, that the table entry is within the table, and that (in case of patching constant strings) the replacement does not exceed the original length of the string. DISCUSSION: This approach does not address one case which is the "translation" of one PCI/USB/bus id into another one to make a driver believe that device X is instead device Y. It does address, however, the relatively common case where recognised IDs are in an explicit device or quirks table. I believe the same functionality can be added to the loader/kernel itself, e.g. by telling /boot/loader to load a text file with all the patches (i.e. the arguments to kldpatch) to be applied, and hooking into the kernel so that right after boot, and right after a module has been kldloaded, the patches are applied. In terms of preventing the user from doing mistakes, there are a few safety checks implemented by the internal table, which should at least prevent the user from writing outside the allowed areas. Clearly there is the issue of a possible mismatch between the record structure as known to kldpatch, and the actual record structure as defined in the .ko files -- but i don't know of a reasonably simple method to extract the structure info from the C source and pass them to kldpatch -- one way could be, perhaps, to add a special symbol to the module itself so perhaps at least the structure info can be declared within the module, and it is easier to be kept in sync. ---- comments ? cheers luigi From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 11:55:24 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7EA510656C2 for ; Sun, 28 Sep 2008 11:55:24 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 612078FC2A for ; Sun, 28 Sep 2008 11:55:24 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=R1wMmuKHYjIA:10 a=6lIswPyQL5gA:10 a=uUmtgKHQwvA07F2yBopI6A==:17 a=fGEZHhlHCNKiM2qep1sA:9 a=X9Uy50w_mSvlSv1NTV-iMCvwihUA:4 a=LY0hPdMaydYA:10 Received: from [62.113.135.118] (account mc467741@c2i.net [62.113.135.118] verified) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1093105826; Sun, 28 Sep 2008 12:55:21 +0200 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Sun, 28 Sep 2008 12:57:17 +0200 User-Agent: KMail/1.9.7 References: <20080928100731.GA49323@onelab2.iet.unipi.it> In-Reply-To: <20080928100731.GA49323@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809281257.18248.hselasky@c2i.net> Cc: Subject: Re: dynamic update of usb/pci/quirks tables X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2008 11:55:24 -0000 On Sunday 28 September 2008, Luigi Rizzo wrote: > Of course patching the live kernel is dangerous Why can't you put all the quirks in a loadable module like in USB2, that can be unloaded and loaded at any time ? --HPS From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 13:02:58 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DCBF1065690 for ; Sun, 28 Sep 2008 13:02:58 +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 C4B168FC13 for ; Sun, 28 Sep 2008 13:02:57 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D793A730A8; Sun, 28 Sep 2008 15:06:29 +0200 (CEST) Date: Sun, 28 Sep 2008 15:06:29 +0200 From: Luigi Rizzo To: Hans Petter Selasky Message-ID: <20080928130629.GA50928@onelab2.iet.unipi.it> References: <20080928100731.GA49323@onelab2.iet.unipi.it> <200809281257.18248.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809281257.18248.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: dynamic update of usb/pci/quirks tables X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2008 13:02:58 -0000 On Sun, Sep 28, 2008 at 12:57:17PM +0200, Hans Petter Selasky wrote: > On Sunday 28 September 2008, Luigi Rizzo wrote: > > Of course patching the live kernel is dangerous > > Why can't you put all the quirks in a loadable module like in USB2, that can > be unloaded and loaded at any time ? This would be a valid approach if we were writing the system from scratch, but we aren't, so this would require changing all source modules to adapt to the new mechanism. BTW - in the base system there is a handful of users of kvm_write: /usr/src/usr.sbin/dconschat/dconschat.c /usr/src/usr.sbin/kgmon/kgmon.c /usr/src/gnu/usr.bin/binutils/gdb/kvm-fbsd.c /usr/src/gnu/usr.bin/gdb/kgdb/trgt.c users of kvm_read are many more: 8 /usr/src/gnu/usr.bin/gdb/kgdb/trgt_i386.c 8 /usr/src/gnu/usr.bin/gdb/kgdb/kthr.c 7 /usr/src/usr.sbin/pstat/pstat.c 7 /usr/src/usr.sbin/kernbb/kernbb.c 7 /usr/src/usr.bin/ktrdump/ktrdump.c 6 /usr/src/usr.sbin/kgmon/kgmon.c 6 /usr/src/sbin/dmesg/dmesg.c 6 /usr/src/gnu/usr.bin/gdb/kgdb/trgt_arm.c 5 /usr/src/tools/diag/dumpvfscache/dumpvfscache.c 4 /usr/src/usr.bin/ipcs/ipcs.c 4 /usr/src/contrib/ipfilter/lib/kmem.c 3 /usr/src/usr.sbin/iostat/iostat.c 3 /usr/src/usr.sbin/dconschat/dconschat.c 3 /usr/src/usr.sbin/asf/asf_kvm.c 3 /usr/src/usr.bin/nfsstat/nfsstat.c 3 /usr/src/usr.bin/fstat/fstat.c 3 /usr/src/tools/tools/umastat/umastat.c 3 /usr/src/lib/libmemstat/memstat_uma.c 3 /usr/src/lib/libmemstat/memstat_malloc.c 2 /usr/src/usr.sbin/ifmcstat/ifmcstat.c 2 /usr/src/usr.bin/vmstat/vmstat.c 2 /usr/src/usr.bin/fstat/fstat.h 2 /usr/src/usr.bin/bluetooth/btsockstat/btsockstat.c 2 /usr/src/libexec/rpc.rstatd/rstat_proc.c 2 /usr/src/lib/libdevstat/devstat.c 2 /usr/src/gnu/usr.bin/gdb/kgdb/trgt_sparc64.c 2 /usr/src/gnu/usr.bin/gdb/kgdb/trgt_powerpc.c 2 /usr/src/gnu/usr.bin/gdb/kgdb/trgt_ia64.c 2 /usr/src/gnu/usr.bin/gdb/kgdb/trgt_amd64.c 2 /usr/src/contrib/ipfilter/ipsend/sock.c 1 /usr/src/usr.bin/systat/main.c 1 /usr/src/usr.bin/systat/fetch.c 1 /usr/src/usr.bin/netstat/main.c 1 /usr/src/gnu/usr.bin/gdb/kgdb/trgt.c 1 /usr/src/gnu/usr.bin/binutils/gdb/kvm-fbsd.c cheers luigi From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 20:00:55 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63CB5106569D for ; Sun, 28 Sep 2008 20:00:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 40D788FC17 for ; Sun, 28 Sep 2008 20:00:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m8SJw3e1089581; Sun, 28 Sep 2008 13:58:06 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 28 Sep 2008 13:58:55 -0600 (MDT) Message-Id: <20080928.135855.1708680935.imp@bsdimp.com> To: rizzo@iet.unipi.it From: "M. Warner Losh" In-Reply-To: <20080928100731.GA49323@onelab2.iet.unipi.it> References: <20080928100731.GA49323@onelab2.iet.unipi.it> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: dynamic update of usb/pci/quirks tables X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2008 20:00:55 -0000 uscanner_devs and sis_devs aren't quirks. They are device tables. You've repeated ignored the mapping idea that I've posted. You can't just add stuff to tables randomly and expect that to work (says someone who has actually done this to lots of drivers in the tree in the pccard era). the driver has to know what kind of device to treat it as. Putting a translation table into the kernel is much easier and you don't have to worry about hokey kludges like what you describe with 'patch'. Maybe it will work out for the other tables you want to update, but it won't work well for device tables. Warner From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 20:19:48 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9200D1065687 for ; Sun, 28 Sep 2008 20:19:48 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 814D28FC0C for ; Sun, 28 Sep 2008 20:19:48 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 531121A3C37; Sun, 28 Sep 2008 13:19:48 -0700 (PDT) Date: Sun, 28 Sep 2008 13:19:48 -0700 From: Alfred Perlstein To: "M. Warner Losh" Message-ID: <20080928201948.GE36572@elvis.mu.org> References: <20080928100731.GA49323@onelab2.iet.unipi.it> <20080928.135855.1708680935.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080928.135855.1708680935.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@FreeBSD.org Subject: Re: dynamic update of usb/pci/quirks tables X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2008 20:19:48 -0000 * M. Warner Losh [080928 13:01] wrote: > uscanner_devs and sis_devs aren't quirks. They are device tables. > > You've repeated ignored the mapping idea that I've posted. You can't > just add stuff to tables randomly and expect that to work (says > someone who has actually done this to lots of drivers in the tree in > the pccard era). the driver has to know what kind of device to treat > it as. > > Putting a translation table into the kernel is much easier and you > don't have to worry about hokey kludges like what you describe with > 'patch'. > > Maybe it will work out for the other tables you want to update, but it > won't work well for device tables. I really like the idea of using a kmod to just add the new device strings.. (some form of what Hans did). -Alfred From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 21:33:07 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97D311065690 for ; Sun, 28 Sep 2008 21:33:07 +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 5A71B8FC19 for ; Sun, 28 Sep 2008 21:33:07 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 45FAA730A8; Sun, 28 Sep 2008 23:36:40 +0200 (CEST) Date: Sun, 28 Sep 2008 23:36:40 +0200 From: Luigi Rizzo To: "M. Warner Losh" Message-ID: <20080928213640.GA55310@onelab2.iet.unipi.it> References: <20080928100731.GA49323@onelab2.iet.unipi.it> <20080928.135855.1708680935.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080928.135855.1708680935.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: dynamic update of usb/pci/quirks tables X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2008 21:33:07 -0000 Hi Warner, On Sun, Sep 28, 2008 at 01:58:55PM -0600, M. Warner Losh wrote: > uscanner_devs and sis_devs aren't quirks. They are device tables. i actually also mentioned umass which is definitely a quirks table (and to tell the truth, uscanner_devs has a flags field as well, even though it only supports 2 values). > You've repeated ignored the mapping idea that I've posted. You can't I have not ignored the mapping idea -- i explicitly mentioned it in my email, saying that my suggestion does not handle device mapping. I do like the device mapping idea, i think it is a useful one, but it is not sufficient, because it doesn't cover the case of quirks tables (i wouldn't know how to actually implement the mapping thing, but that's just my ignorance in that area of the kernel - i am sure i can figure out with some studying). This said, the kldsym/kmem based approach has the advantage that it can be implemented as a port (if you forget the /boot/loader support) and be used on a pre-existing system without having to rebuild kernels or modules. Some times this can be useful. > just add stuff to tables randomly and expect that to work (says > someone who has actually done this to lots of drivers in the tree in > the pccard era). the driver has to know what kind of device to treat > it as. i don't understand why you believe that i am suggesting to "randomly adding stuff" to the tables. I know (and I wrote it in my email) that playing with tables is dangerous and one should know what he is doing before trying. Certainly, if i have a device with unknown specs, the only way to tell what it can do is by trial and error, looking at a similar devices, and playing with mapping or quirks tables. Sure, if the code itself outside the table makes use of the actual IDs, then adding entries to the tables may not work. But, if and when someone has determined that the patching is safe (e.g. because it is a quirks table, as in the umass case, or because the actual IDs are not used anywhere else in the code, as in the case of uscanner or if_rl or probably many other places), I don't understand why we should artificially make life harder to FreeBSD users asking them to "upgrade to next release" or "patch and rebuild the kernel". Sometimes you just can't do that -- take e.g. the case of embedded platforms where you don't have a compiler available or possibly not even full kernel sources -- after all it's BSD licensed! > Putting a translation table into the kernel is much easier and you > don't have to worry about hokey kludges like what you describe with > 'patch'. > > Maybe it will work out for the other tables you want to update, but it > won't work well for device tables. I am open to all solutions that can make FreeBSD more compatible with external hardware. It will be great if we can implement your mapping idea. It will be great if there is a better way of handling quirks tables. cheers luigi From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 22:09:37 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E62071065694; Sun, 28 Sep 2008 22:09:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A48128FC17; Sun, 28 Sep 2008 22:09:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m8SM9KnT090913; Sun, 28 Sep 2008 16:09:20 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 28 Sep 2008 16:10:10 -0600 (MDT) Message-Id: <20080928.161010.1649769915.imp@bsdimp.com> To: alfred@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20080928201948.GE36572@elvis.mu.org> References: <20080928100731.GA49323@onelab2.iet.unipi.it> <20080928.135855.1708680935.imp@bsdimp.com> <20080928201948.GE36572@elvis.mu.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: dynamic update of usb/pci/quirks tables X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2008 22:09:38 -0000 In message: <20080928201948.GE36572@elvis.mu.org> Alfred Perlstein writes: : * M. Warner Losh [080928 13:01] wrote: : > uscanner_devs and sis_devs aren't quirks. They are device tables. : > : > You've repeated ignored the mapping idea that I've posted. You can't : > just add stuff to tables randomly and expect that to work (says : > someone who has actually done this to lots of drivers in the tree in : > the pccard era). the driver has to know what kind of device to treat : > it as. : > : > Putting a translation table into the kernel is much easier and you : > don't have to worry about hokey kludges like what you describe with : > 'patch'. : > : > Maybe it will work out for the other tables you want to update, but it : > won't work well for device tables. : : I really like the idea of using a kmod to just add the new device : strings.. (some form of what Hans did). The problem is that except for the most trivial driver, that doesn't work. Most of the NIC drivers in the tree do special things based on what chip they thing they are talking to. An unknown chip may work, but it would work a lot better if the unknown chip is compatible with a specific chip, as opposed to being compatible with the driver. I'm cool with having the overriden ids also override the device description too... Warner From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 22:18:58 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E574106568C for ; Sun, 28 Sep 2008 22:18:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id CD63E8FC20 for ; Sun, 28 Sep 2008 22:18:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m8SMIEU5090991; Sun, 28 Sep 2008 16:18:14 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 28 Sep 2008 16:19:05 -0600 (MDT) Message-Id: <20080928.161905.-1350498240.imp@bsdimp.com> To: rizzo@iet.unipi.it From: "M. Warner Losh" In-Reply-To: <20080928213640.GA55310@onelab2.iet.unipi.it> References: <20080928100731.GA49323@onelab2.iet.unipi.it> <20080928.135855.1708680935.imp@bsdimp.com> <20080928213640.GA55310@onelab2.iet.unipi.it> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: dynamic update of usb/pci/quirks tables X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2008 22:18:58 -0000 In message: <20080928213640.GA55310@onelab2.iet.unipi.it> Luigi Rizzo writes: : Hi Warner, : : On Sun, Sep 28, 2008 at 01:58:55PM -0600, M. Warner Losh wrote: : > uscanner_devs and sis_devs aren't quirks. They are device tables. : : i actually also mentioned umass which is definitely a quirks table : (and to tell the truth, uscanner_devs has a flags : field as well, even though it only supports 2 values). True. The umass stuff is definitely quirk table expansion. : > You've repeated ignored the mapping idea that I've posted. You can't : : I have not ignored the mapping idea -- i explicitly mentioned it : in my email, saying that my suggestion does not handle device : mapping. : I do like the device mapping idea, i think it is a useful one, but : it is not sufficient, because it doesn't cover the case of quirks tables : (i wouldn't know how to actually implement the mapping thing, : but that's just my ignorance in that area of the kernel - i am : sure i can figure out with some studying). I posted diffs that did everything except the maintaining the table in like 15-20 lines of code for PCI. The hard part is the interface to /boot/loader and any desire to tweak the table and rescan devices... : This said, the kldsym/kmem based approach has the advantage that : it can be implemented as a port (if you forget the /boot/loader support) : and be used on a pre-existing system without having to rebuild kernels : or modules. Some times this can be useful. I doubt that this is a good selling point. It is rare that you add new hardware to a system that's already running that's compatible with the old hardware, but needs updated driver support. I'm skeptical that the kld solution would be robust enough for people who have such situations to trust more than a source rebuild to pickup the new mapping table. : > just add stuff to tables randomly and expect that to work (says : > someone who has actually done this to lots of drivers in the tree in : > the pccard era). the driver has to know what kind of device to treat : > it as. : : i don't understand why you believe that i am suggesting to : "randomly adding stuff" to the tables. : : I know (and I wrote it in my email) that playing with tables is : dangerous and one should know what he is doing before trying. I guess we're saying the same thing: This is a large caliber gun that can be useful, but also has an unusually high foot-shooting potential. : Certainly, if i have a device with unknown specs, the only way to : tell what it can do is by trial and error, looking at a similar : devices, and playing with mapping or quirks tables. : Sure, if the code itself outside the table makes use of : the actual IDs, then adding entries to the tables may not work. Correct. This is what I do with PC Card and PCI drivers when I find hardware at garage sales that I can find no other data on. Usually a model number and version will get me enough data to know. But wireless cards seem to have busted that :-(. : But, if and when someone has determined that the patching is safe : (e.g. because it is a quirks table, as in the umass case, or because : the actual IDs are not used anywhere else in the code, as in the : case of uscanner or if_rl or probably many other places), I don't : understand why we should artificially make life harder to FreeBSD : users asking them to "upgrade to next release" or "patch and rebuild : the kernel". Sometimes you just can't do that -- take e.g. the : case of embedded platforms where you don't have a compiler available : or possibly not even full kernel sources -- after all it's BSD licensed! I think the embedded argument oversells the capability here. It assumes the embedded systems let you get to the boot loader prompt, or that it even uses /boot/loader. : > Putting a translation table into the kernel is much easier and you : > don't have to worry about hokey kludges like what you describe with : > 'patch'. : > : > Maybe it will work out for the other tables you want to update, but it : > won't work well for device tables. : : I am open to all solutions that can make FreeBSD more compatible : with external hardware. It will be great if we can implement your : mapping idea. It will be great if there is a better way of handling : quirks tables. Let's pursue both ideas. I'll implement it for usb, pci, pc card and cardbus and we'll see where it goes. Warner From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 22:23:44 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF685106569F; Sun, 28 Sep 2008 22:23: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 697FC8FC14; Sun, 28 Sep 2008 22:23:44 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 60659730AE; Mon, 29 Sep 2008 00:27:18 +0200 (CEST) Date: Mon, 29 Sep 2008 00:27:18 +0200 From: Luigi Rizzo To: "M. Warner Losh" Message-ID: <20080928222718.GA56058@onelab2.iet.unipi.it> References: <20080928100731.GA49323@onelab2.iet.unipi.it> <20080928.135855.1708680935.imp@bsdimp.com> <20080928201948.GE36572@elvis.mu.org> <20080928.161010.1649769915.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080928.161010.1649769915.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: alfred@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: dynamic update of usb/pci/quirks tables X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2008 22:23:44 -0000 On Sun, Sep 28, 2008 at 04:10:10PM -0600, M. Warner Losh wrote: > In message: <20080928201948.GE36572@elvis.mu.org> > Alfred Perlstein writes: > : * M. Warner Losh [080928 13:01] wrote: ... > : > Maybe it will work out for the other tables you want to update, but it > : > won't work well for device tables. > : > : I really like the idea of using a kmod to just add the new device > : strings.. (some form of what Hans did). > > The problem is that except for the most trivial driver, that doesn't > work. Most of the NIC drivers in the tree do special things based on > what chip they thing they are talking to. An unknown chip may work, it really depends on what you are looking at -- in some drivers the "special things" are called inline in the code looking at the device IDs; in other drivers, they are implemented as functions that are called depending on the content of the quirks info, so the behaviour is (or aims to be) entirely table driven. In this respect I believe USB stuff tends to be more table-driven (probably because there is also a huge variety of devices, and the inline approach wouldn't scale well). NIC drivers are different as most of them are derived one from another by copying and modifications, and there wasn't always a lot of design involved in making them generic and configurable -- nor was it worth the effort once they are working (and i don't mean to blame anyone -- there is no point to optimize a driver for a broken piece of hardware if you can get better hw). cheers luigi From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 22:31:27 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80E041065691 for ; Sun, 28 Sep 2008 22:31:27 +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 411AA8FC21 for ; Sun, 28 Sep 2008 22:31:27 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 2DBDF730A8; Mon, 29 Sep 2008 00:35:01 +0200 (CEST) Date: Mon, 29 Sep 2008 00:35:01 +0200 From: Luigi Rizzo To: "M. Warner Losh" Message-ID: <20080928223501.GB56058@onelab2.iet.unipi.it> References: <20080928100731.GA49323@onelab2.iet.unipi.it> <20080928.135855.1708680935.imp@bsdimp.com> <20080928213640.GA55310@onelab2.iet.unipi.it> <20080928.161905.-1350498240.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080928.161905.-1350498240.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@FreeBSD.org Subject: Re: dynamic update of usb/pci/quirks tables X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2008 22:31:27 -0000 On Sun, Sep 28, 2008 at 04:19:05PM -0600, M. Warner Losh wrote: > In message: <20080928213640.GA55310@onelab2.iet.unipi.it> > Luigi Rizzo writes: ... > : This said, the kldsym/kmem based approach has the advantage that > : it can be implemented as a port (if you forget the /boot/loader support) > : and be used on a pre-existing system without having to rebuild kernels > : or modules. Some times this can be useful. > > I doubt that this is a good selling point. It is rare that you add > new hardware to a system that's already running that's compatible with with umass devices (including cameras phones and mp3 players) it happens all the time, and those you can connect to many single board computers these days. Same with several scanners and usb-serial adapters. > : I am open to all solutions that can make FreeBSD more compatible > : with external hardware. It will be great if we can implement your > : mapping idea. It will be great if there is a better way of handling > : quirks tables. > > Let's pursue both ideas. I'll implement it for usb, pci, pc card and > cardbus and we'll see where it goes. ok good -- no rush, i was just trying to figure out how to address the problem, after being hit two more times last week! cheers luigi From owner-freebsd-arch@FreeBSD.ORG Mon Sep 29 11:06:47 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B59EA106568F for ; Mon, 29 Sep 2008 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7D4318FC15 for ; Mon, 29 Sep 2008 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m8TB6ldX040733 for ; Mon, 29 Sep 2008 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m8TB6k5K040729 for freebsd-arch@FreeBSD.org; Mon, 29 Sep 2008 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 29 Sep 2008 11:06:46 GMT Message-Id: <200809291106.m8TB6k5K040729@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2008 11:06:47 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 19:07:32 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 883A4106568A; Wed, 1 Oct 2008 19:07:32 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:3fb::211]) by mx1.freebsd.org (Postfix) with ESMTP id 3346A8FC13; Wed, 1 Oct 2008 19:07:29 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 52FAC1CD1C; Wed, 1 Oct 2008 21:07:28 +0200 (CEST) Date: Wed, 1 Oct 2008 21:07:28 +0200 From: Ed Schouten To: FreeBSD FS , FreeBSD Arch Message-ID: <20081001190728.GL16837@hoeg.nl> References: <20080912182722.GK1191@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="egxrhndXibJAPJ54" Content-Disposition: inline In-Reply-To: <20080912182722.GK1191@hoeg.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Jille Timmermans , Mark van Cuijk Subject: Re: Expanding vops in vop_vectors during startup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 19:07:32 -0000 --egxrhndXibJAPJ54 Content-Type: multipart/mixed; boundary="vTUhhhdwRI43FzeR" Content-Disposition: inline --vTUhhhdwRI43FzeR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, * Ed Schouten wrote: > Yesterday I was talking with some friends of mine about the FreeBSD VFS > layer. As an exercise, Jille was trying to patch nullfs to hide .svn > directories (see hackers@), so that's how we got to the subject. >=20 > After talking about the way our vop_vector works (vop_bypass and > vop_default), we were wondering why we don't propagate all pointers in > the vop_vector to its children to save the unneeded function pointer > resolving inside the VOP_* calls. >=20 > The reason I'm sending this message, is because based on discussions I had with several people on IRC we've basically got two different opinions on this patch: - One group of people liked the idea of the patch. Some people even said the patch looks good enough to be committed. - Another group of people also liked the idea, but thought it would make no sense to commit it, because it's not like it's a bottleneck right now. It should only be committed if an increase in performance is notable. I did some tests with the patch set, by running tens of millions of fstat(), fchown(), etc. calls to see how performance was affected. It turns out on a kernel without any debugging options enabled, the performance gain is only 1-2%, which sounds pretty valid to me. It's not much, so because there are objections I've decided not to commit it. This doesn't make a lot of sense to me, because the patch is already there. It's just a matter of punching in `svn commit'. I'm attaching the latest version of the patch to this email message, so if someone else would like to pick this up: be my guest. Be sure to buy a bucket of paint before doing so. --=20 Ed Schouten WWW: http://80386.nl/ --vTUhhhdwRI43FzeR Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="vnode-vop-expand.diff" Content-Transfer-Encoding: quoted-printable Index: sys/nfsclient/nfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/nfsclient/nfs_vnops.c (revision 182995) +++ sys/nfsclient/nfs_vnops.c (working copy) @@ -134,7 +134,6 @@ * Global vfs data structures for nfs */ struct vop_vector nfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, .vop_access =3D nfs_access, .vop_advlock =3D nfs_advlock, .vop_advlockasync =3D nfs_advlockasync, @@ -164,6 +163,7 @@ .vop_symlink =3D nfs_symlink, .vop_write =3D nfs_write, }; +DECLARE_VOP_VECTOR(nfs_vnodeops); =20 struct vop_vector nfs_fifoops =3D { .vop_default =3D &fifo_specops, @@ -178,6 +178,7 @@ .vop_setattr =3D nfs_setattr, .vop_write =3D nfsfifo_write, }; +DECLARE_VOP_VECTOR(nfs_fifoops); =20 static int nfs_mknodrpc(struct vnode *dvp, struct vnode **vpp, struct componentname *cnp, struct vattr *vap); Index: sys/gnu/fs/xfs/FreeBSD/xfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/gnu/fs/xfs/FreeBSD/xfs_vnops.c (revision 182995) +++ sys/gnu/fs/xfs/FreeBSD/xfs_vnops.c (working copy) @@ -118,7 +118,6 @@ static vop_vptofh_t _xfs_vptofh; =20 struct vop_vector xfs_vnops =3D { - .vop_default =3D &default_vnodeops, .vop_access =3D _xfs_access, .vop_advlock =3D _xfs_advlock, .vop_bmap =3D _xfs_bmap, @@ -151,6 +150,7 @@ .vop_write =3D _xfs_write, .vop_vptofh =3D _xfs_vptofh, }; +DECLARE_VOP_VECTOR(xfs_vnops); =20 /* * FIFO's specific operations. Index: sys/gnu/fs/reiserfs/reiserfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/gnu/fs/reiserfs/reiserfs_vnops.c (revision 182995) +++ sys/gnu/fs/reiserfs/reiserfs_vnops.c (working copy) @@ -20,8 +20,6 @@ =20 /* Global vfs data structures for ReiserFS */ struct vop_vector reiserfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D reiserfs_access, .vop_bmap =3D reiserfs_bmap, .vop_cachedlookup =3D reiserfs_lookup, @@ -37,15 +35,15 @@ .vop_strategy =3D reiserfs_strategy, .vop_vptofh =3D reiserfs_vptofh, }; +DECLARE_VOP_VECTOR(reiserfs_vnodeops); =20 struct vop_vector reiserfs_specops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D reiserfs_access, .vop_getattr =3D reiserfs_getattr, .vop_inactive =3D reiserfs_inactive, .vop_reclaim =3D reiserfs_reclaim, }; +DECLARE_VOP_VECTOR(reiserfs_specops); =20 /* ------------------------------------------------------------------- * vnode operations Index: sys/gnu/fs/ext2fs/ext2_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/gnu/fs/ext2fs/ext2_vnops.c (revision 182995) +++ sys/gnu/fs/ext2fs/ext2_vnops.c (working copy) @@ -116,7 +116,6 @@ =20 /* Global vfs data structures for ext2. */ struct vop_vector ext2_vnodeops =3D { - .vop_default =3D &default_vnodeops, .vop_access =3D ext2_access, .vop_bmap =3D ext2_bmap, .vop_cachedlookup =3D ext2_lookup, @@ -148,9 +147,9 @@ .vop_write =3D ext2_write, .vop_vptofh =3D ext2_vptofh, }; +DECLARE_VOP_VECTOR(ext2_vnodeops); =20 struct vop_vector ext2_fifoops =3D { - .vop_default =3D &fifo_specops, .vop_access =3D ext2_access, .vop_close =3D ext2fifo_close, .vop_fsync =3D ext2_fsync, @@ -164,6 +163,7 @@ .vop_write =3D VOP_PANIC, .vop_vptofh =3D ext2_vptofh, }; +DECLARE_VOP_VECTOR(ext2_fifoops); =20 #include =20 Index: sys/ufs/ufs/ufs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/ufs/ufs/ufs_vnops.c (revision 182995) +++ sys/ufs/ufs/ufs_vnops.c (working copy) @@ -2446,7 +2446,6 @@ =20 /* Global vfs data structures for ufs. */ struct vop_vector ufs_vnodeops =3D { - .vop_default =3D &default_vnodeops, .vop_fsync =3D VOP_PANIC, .vop_read =3D VOP_PANIC, .vop_reallocblks =3D VOP_PANIC, @@ -2490,6 +2489,7 @@ .vop_aclcheck =3D ufs_aclcheck, #endif }; +DECLARE_VOP_VECTOR(ufs_vnodeops); =20 struct vop_vector ufs_fifoops =3D { .vop_default =3D &fifo_specops, @@ -2518,3 +2518,4 @@ .vop_aclcheck =3D ufs_aclcheck, #endif }; +DECLARE_VOP_VECTOR(ufs_fifoops); Index: sys/ufs/ffs/ffs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/ufs/ffs/ffs_vnops.c (revision 182995) +++ sys/ufs/ffs/ffs_vnops.c (working copy) @@ -132,6 +132,7 @@ .vop_write =3D ffs_write, .vop_vptofh =3D ffs_vptofh, }; +DECLARE_VOP_VECTOR(ffs_vnodeops1); =20 struct vop_vector ffs_fifoops1 =3D { .vop_default =3D &ufs_fifoops, @@ -139,6 +140,7 @@ .vop_reallocblks =3D ffs_reallocblks, /* XXX: really ??? */ .vop_vptofh =3D ffs_vptofh, }; +DECLARE_VOP_VECTOR(ffs_fifoops1); =20 /* Global vfs data structures for ufs. */ struct vop_vector ffs_vnodeops2 =3D { @@ -157,6 +159,7 @@ .vop_setextattr =3D ffs_setextattr, .vop_vptofh =3D ffs_vptofh, }; +DECLARE_VOP_VECTOR(ffs_vnodeops2); =20 struct vop_vector ffs_fifoops2 =3D { .vop_default =3D &ufs_fifoops, @@ -172,6 +175,7 @@ .vop_setextattr =3D ffs_setextattr, .vop_vptofh =3D ffs_vptofh, }; +DECLARE_VOP_VECTOR(ffs_fifoops2); =20 /* * Synch an open file. Index: sys/kern/uipc_mqueue.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/uipc_mqueue.c (revision 182995) +++ sys/kern/uipc_mqueue.c (working copy) @@ -2477,7 +2477,6 @@ }; =20 static struct vop_vector mqfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, .vop_access =3D mqfs_access, .vop_cachedlookup =3D mqfs_lookup, .vop_lookup =3D vfs_cache_lookup, @@ -2495,6 +2494,7 @@ .vop_mkdir =3D VOP_EOPNOTSUPP, .vop_rmdir =3D VOP_EOPNOTSUPP }; +DECLARE_VOP_VECTOR(mqfs_vnodeops); =20 static struct vfsops mqfs_vfsops =3D { .vfs_init =3D mqfs_init, Index: sys/kern/vfs_default.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/vfs_default.c (revision 182995) +++ sys/kern/vfs_default.c (working copy) @@ -72,10 +72,7 @@ * */ =20 -struct vop_vector default_vnodeops =3D { - .vop_default =3D NULL, - .vop_bypass =3D VOP_EOPNOTSUPP, - +static struct vop_vector default_vnodeops =3D { .vop_advlock =3D vop_stdadvlock, .vop_advlockasync =3D vop_stdadvlockasync, .vop_bmap =3D vop_stdbmap, @@ -102,6 +99,50 @@ }; =20 /* + * A generic routine to inherit missing routines in vop_vectors from + * their vop_default or vop_bypass routines. This routine shall be + * called on all vop_vectors on startup, which means we can always + * assume existing routines are referenced. + */ + +void +vop_vector_init(void *arg) +{ + struct vop_vector *vop =3D arg, *dvop; + vop_bypass_t **vlist, **dvlist; + unsigned int i; + + /* + * Set vop->vop_default to &default_vnodeops to indicate that + * the vop_vector has already been processed. This saves some + * unneeded traversing of the vectors. + */ + dvop =3D vop->vop_default; + if (dvop =3D=3D &default_vnodeops) + return; + vop->vop_default =3D &default_vnodeops; + + if (dvop !=3D NULL) + vop_vector_init(dvop); + else + dvop =3D &default_vnodeops; + + vlist =3D _VOP_VECTOR_ARRAY(vop); + dvlist =3D _VOP_VECTOR_ARRAY(dvop); + + for (i =3D 0; i < _VOP_VECTOR_COUNT; i++) { + if (vlist[i] =3D=3D NULL) { + if (vop->vop_bypass !=3D NULL) + vlist[i] =3D vop->vop_bypass; + else if (dvlist[i] !=3D NULL) + vlist[i] =3D dvlist[i]; + else + vlist[i] =3D VOP_EOPNOTSUPP; + } + } +} + +/* * Series of placeholder functions for various error returns for * VOPs. */ Index: sys/kern/vfs_subr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/vfs_subr.c (revision 182995) +++ sys/kern/vfs_subr.c (working copy) @@ -3262,7 +3262,6 @@ static int sync_reclaim(struct vop_reclaim_args *); =20 static struct vop_vector sync_vnodeops =3D { - .vop_bypass =3D VOP_EOPNOTSUPP, .vop_close =3D sync_close, /* close */ .vop_fsync =3D sync_fsync, /* fsync */ .vop_inactive =3D sync_inactive, /* inactive */ @@ -3271,6 +3270,7 @@ .vop_unlock =3D vop_stdunlock, /* unlock */ .vop_islocked =3D vop_stdislocked, /* islocked */ }; +DECLARE_VOP_VECTOR(sync_vnodeops); =20 /* * Create a new filesystem syncer vnode for the specified mount point. Index: sys/tools/vnode_if.awk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/tools/vnode_if.awk (revision 182995) +++ sys/tools/vnode_if.awk (working copy) @@ -290,6 +290,10 @@ ctrstr =3D ctrstr ", a->a_" args[i]; ctrstr =3D ctrstr ");"; =20 + numvops++; + if (!firstvop) + firstvop =3D name; + if (pfile) { printp("\t"name"_t\t*"name";") } @@ -366,17 +370,11 @@ printc(""); printc("\tVNASSERT(a->a_gen.a_desc =3D=3D &" name "_desc, a->a_" args[0]= ","); printc("\t (\"Wrong a_desc in " name "(%p, %p)\", a->a_" args[0]", a)= );"); - printc("\twhile(vop !=3D NULL && \\"); - printc("\t vop->"name" =3D=3D NULL && vop->vop_bypass =3D=3D NULL)") - printc("\t\tvop =3D vop->vop_default;") - printc("\tVNASSERT(vop !=3D NULL, a->a_" args[0]", (\"No "name"(%p, %p)\= ", a->a_" args[0]", a));") + printc("\tVNASSERT(vop->"name" !=3D NULL, a->a_" args[0]", (\"No "name"(= %p, %p)\", a->a_" args[0]", a));") for (i =3D 0; i < numargs; ++i) add_debug_code(name, args[i], "Entry", "\t"); add_pre(name); - printc("\tif (vop->"name" !=3D NULL)") - printc("\t\trc =3D vop->"name"(a);") - printc("\telse") - printc("\t\trc =3D vop->vop_bypass(&a->a_gen);") + printc("\trc =3D vop->"name"(a);") printc(ctrstr); printc("\tif (rc =3D=3D 0) {"); for (i =3D 0; i < numargs; ++i) @@ -424,7 +422,11 @@ } =20 if (pfile) - printp("};") + printp("};\n" \ + "\n" \ + "#define\t_VOP_VECTOR_COUNT\t"numvops"\n" \ + "#define\t_VOP_VECTOR_ARRAY(vop) \\\n" \ + "\t(vop_bypass_t **)((void *)&(vop)->"firstvop")") =20 if (hfile) close(hfile); Index: sys/fs/unionfs/union_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/unionfs/union_vnops.c (revision 182995) +++ sys/fs/unionfs/union_vnops.c (working copy) @@ -2278,8 +2278,6 @@ } =20 struct vop_vector unionfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D unionfs_access, .vop_aclcheck =3D unionfs_aclcheck, .vop_advlock =3D unionfs_advlock, @@ -2326,3 +2324,4 @@ .vop_write =3D unionfs_write, .vop_vptofh =3D unionfs_vptofh, }; +DECLARE_VOP_VECTOR(unionfs_vnodeops); Index: sys/fs/deadfs/dead_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/deadfs/dead_vnops.c (revision 182995) +++ sys/fs/deadfs/dead_vnops.c (working copy) @@ -52,8 +52,6 @@ static vop_rename_t dead_rename; =20 struct vop_vector dead_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D VOP_EBADF, .vop_advlock =3D VOP_EBADF, .vop_bmap =3D dead_bmap, @@ -80,6 +78,7 @@ .vop_symlink =3D VOP_PANIC, .vop_write =3D dead_write, }; +DECLARE_VOP_VECTOR(dead_vnodeops); =20 /* ARGSUSED */ static int Index: sys/fs/pseudofs/pseudofs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/pseudofs/pseudofs_vnops.c (revision 182995) +++ sys/fs/pseudofs/pseudofs_vnops.c (working copy) @@ -864,8 +864,6 @@ * Vnode operations */ struct vop_vector pfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D pfs_access, .vop_cachedlookup =3D pfs_lookup, .vop_close =3D pfs_close, @@ -890,3 +888,4 @@ .vop_write =3D pfs_write, /* XXX I've probably forgotten a few that need VOP_EOPNOTSUPP */ }; +DECLARE_VOP_VECTOR(pfs_vnodeops); Index: sys/fs/tmpfs/tmpfs_fifoops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/tmpfs/tmpfs_fifoops.c (revision 182995) +++ sys/fs/tmpfs/tmpfs_fifoops.c (working copy) @@ -37,6 +37,7 @@ __FBSDID("$FreeBSD$"); =20 #include +#include #include #include #include @@ -88,7 +89,6 @@ * vnode operations vector used for fifos stored in a tmpfs file system. */ struct vop_vector tmpfs_fifoop_entries =3D { - .vop_default =3D &fifo_specops, .vop_close =3D tmpfs_fifo_close, .vop_reclaim =3D tmpfs_reclaim, .vop_access =3D tmpfs_access, @@ -96,4 +96,4 @@ .vop_setattr =3D tmpfs_setattr, .vop_kqfilter =3D tmpfs_fifo_kqfilter, }; - +DECLARE_VOP_VECTOR(tmpfs_fifoop_entries); Index: sys/fs/tmpfs/tmpfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/tmpfs/tmpfs_vnops.c (revision 182995) +++ sys/fs/tmpfs/tmpfs_vnops.c (working copy) @@ -38,6 +38,7 @@ =20 #include #include +#include #include #include #include @@ -1443,7 +1444,6 @@ * vnode operations vector used for files stored in a tmpfs file system. */ struct vop_vector tmpfs_vnodeop_entries =3D { - .vop_default =3D &default_vnodeops, .vop_lookup =3D vfs_cache_lookup, .vop_cachedlookup =3D tmpfs_lookup, .vop_create =3D tmpfs_create, @@ -1471,4 +1471,4 @@ .vop_vptofh =3D tmpfs_vptofh, .vop_bmap =3D VOP_EOPNOTSUPP, }; - +DECLARE_VOP_VECTOR(tmpfs_vnodeop_entries); Index: sys/fs/portalfs/portal_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/portalfs/portal_vnops.c (revision 182995) +++ sys/fs/portalfs/portal_vnops.c (working copy) @@ -551,8 +551,6 @@ } =20 struct vop_vector portal_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D VOP_NULL, .vop_getattr =3D portal_getattr, .vop_lookup =3D portal_lookup, @@ -562,3 +560,4 @@ .vop_reclaim =3D portal_reclaim, .vop_setattr =3D portal_setattr, }; +DECLARE_VOP_VECTOR(portal_vnodeops); Index: sys/fs/hpfs/hpfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/hpfs/hpfs_vnops.c (revision 182995) +++ sys/fs/hpfs/hpfs_vnops.c (working copy) @@ -1230,8 +1230,6 @@ * Global vfs data structures */ struct vop_vector hpfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D hpfs_access, .vop_bmap =3D hpfs_bmap, .vop_cachedlookup =3D hpfs_lookup, @@ -1254,3 +1252,4 @@ .vop_write =3D hpfs_write, .vop_vptofh =3D hpfs_vptofh, }; +DECLARE_VOP_VECTOR(hpfs_vnodeops); Index: sys/fs/nullfs/null_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/nullfs/null_vnops.c (revision 182995) +++ sys/fs/nullfs/null_vnops.c (working copy) @@ -747,3 +747,4 @@ .vop_unlock =3D null_unlock, .vop_vptofh =3D null_vptofh, }; +DECLARE_VOP_VECTOR(null_vnodeops); Index: sys/fs/coda/coda_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/coda/coda_vnops.c (revision 182995) +++ sys/fs/coda/coda_vnops.c (working copy) @@ -110,7 +110,6 @@ * Definition of the vnode operation vector. */ struct vop_vector coda_vnodeops =3D { - .vop_default =3D &default_vnodeops, .vop_cachedlookup =3D coda_lookup, /* uncached lookup */ .vop_lookup =3D vfs_cache_lookup, /* namecache lookup */ .vop_create =3D coda_create, /* create */ @@ -150,6 +149,7 @@ #endif =20 }; +DECLARE_VOP_VECTOR(coda_vnodeops); =20 static void coda_print_vattr(struct vattr *attr); =20 Index: sys/fs/devfs/devfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/devfs/devfs_vnops.c (revision 182995) +++ sys/fs/devfs/devfs_vnops.c (working copy) @@ -1432,8 +1432,6 @@ }; =20 static struct vop_vector devfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D devfs_access, .vop_getattr =3D devfs_getattr, .vop_ioctl =3D devfs_rioctl, @@ -1452,10 +1450,9 @@ #endif .vop_symlink =3D devfs_symlink, }; +DECLARE_VOP_VECTOR(devfs_vnodeops); =20 static struct vop_vector devfs_specops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D devfs_access, .vop_advlock =3D devfs_advlock, .vop_bmap =3D VOP_PANIC, @@ -1487,6 +1484,7 @@ .vop_symlink =3D VOP_PANIC, .vop_write =3D VOP_PANIC, }; +DECLARE_VOP_VECTOR(devfs_specops); =20 /* * Our calling convention to the device drivers used to be that we passed Index: sys/fs/smbfs/smbfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/smbfs/smbfs_vnops.c (revision 182995) +++ sys/fs/smbfs/smbfs_vnops.c (working copy) @@ -86,8 +86,6 @@ static vop_getextattr_t smbfs_getextattr; =20 struct vop_vector smbfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D smbfs_access, .vop_advlock =3D smbfs_advlock, .vop_close =3D smbfs_close, @@ -118,6 +116,7 @@ .vop_symlink =3D smbfs_symlink, .vop_write =3D smbfs_write, }; +DECLARE_VOP_VECTOR(smbfs_vnodeops); =20 static int smbfs_access(ap) Index: sys/fs/ntfs/ntfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/ntfs/ntfs_vnops.c (revision 182995) +++ sys/fs/ntfs/ntfs_vnops.c (working copy) @@ -756,8 +756,6 @@ * Global vfs data structures */ struct vop_vector ntfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D ntfs_access, .vop_bmap =3D ntfs_bmap, .vop_cachedlookup =3D ntfs_lookup, @@ -775,3 +773,4 @@ .vop_write =3D ntfs_write, .vop_vptofh =3D ntfs_vptofh, }; +DECLARE_VOP_VECTOR(ntfs_vnodeops); Index: sys/fs/cd9660/cd9660_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/cd9660/cd9660_vnops.c (revision 182995) +++ sys/fs/cd9660/cd9660_vnops.c (working copy) @@ -827,7 +827,6 @@ * Global vfs data structures for cd9660 */ struct vop_vector cd9660_vnodeops =3D { - .vop_default =3D &default_vnodeops, .vop_open =3D cd9660_open, .vop_access =3D cd9660_access, .vop_bmap =3D cd9660_bmap, @@ -845,6 +844,7 @@ .vop_strategy =3D cd9660_strategy, .vop_vptofh =3D cd9660_vptofh, }; +DECLARE_VOP_VECTOR(cd9660_vnodeops); =20 /* * Special device vnode ops @@ -859,3 +859,4 @@ .vop_setattr =3D cd9660_setattr, .vop_vptofh =3D cd9660_vptofh, }; +DECLARE_VOP_VECTOR(cd9660_fifoops); Index: sys/fs/fifofs/fifo_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/fifofs/fifo_vnops.c (revision 182995) +++ sys/fs/fifofs/fifo_vnops.c (working copy) @@ -109,8 +109,6 @@ { 1, NULL, filt_fifodetach_notsup, filt_fifo_notsup }; =20 struct vop_vector fifo_specops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D VOP_EBADF, .vop_advlock =3D fifo_advlock, .vop_close =3D fifo_close, @@ -137,6 +135,7 @@ .vop_symlink =3D VOP_PANIC, .vop_write =3D VOP_PANIC, }; +DECLARE_VOP_VECTOR(fifo_specops); =20 struct mtx fifo_mtx; MTX_SYSINIT(fifo, &fifo_mtx, "fifo mutex", MTX_DEF); Index: sys/fs/fdescfs/fdesc_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/fdescfs/fdesc_vnops.c (revision 182995) +++ sys/fs/fdescfs/fdesc_vnops.c (working copy) @@ -72,8 +72,6 @@ static vop_setattr_t fdesc_setattr; =20 static struct vop_vector fdesc_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D VOP_NULL, .vop_getattr =3D fdesc_getattr, .vop_lookup =3D fdesc_lookup, @@ -83,6 +81,7 @@ .vop_reclaim =3D fdesc_reclaim, .vop_setattr =3D fdesc_setattr, }; +DECLARE_VOP_VECTOR(fdesc_vnodeops); =20 static void fdesc_insmntque_dtr(struct vnode *, void *); static void fdesc_remove_entry(struct fdescnode *); Index: sys/fs/nwfs/nwfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/nwfs/nwfs_vnops.c (revision 182995) +++ sys/fs/nwfs/nwfs_vnops.c (working copy) @@ -84,8 +84,6 @@ =20 /* Global vfs data structures for nwfs */ struct vop_vector nwfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D nwfs_access, .vop_close =3D nwfs_close, .vop_create =3D nwfs_create, @@ -113,6 +111,7 @@ .vop_symlink =3D nwfs_symlink, .vop_write =3D nwfs_write, }; +DECLARE_VOP_VECTOR(nwfs_vnodeops); =20 /* * nwfs_access vnode op Index: sys/fs/msdosfs/msdosfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/msdosfs/msdosfs_vnops.c (revision 182995) +++ sys/fs/msdosfs/msdosfs_vnops.c (working copy) @@ -54,6 +54,7 @@ #include #include #include +#include #include #include #include @@ -1965,8 +1966,6 @@ =20 /* Global vfs data structures for msdosfs */ struct vop_vector msdosfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D msdosfs_access, .vop_bmap =3D msdosfs_bmap, .vop_cachedlookup =3D msdosfs_lookup, @@ -1994,3 +1993,4 @@ .vop_write =3D msdosfs_write, .vop_vptofh =3D msdosfs_vptofh, }; +DECLARE_VOP_VECTOR(msdosfs_vnodeops); Index: sys/fs/udf/udf_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/udf/udf_vnops.c (revision 182995) +++ sys/fs/udf/udf_vnops.c (working copy) @@ -74,8 +74,6 @@ daddr_t *sector, uint32_t *max_size); =20 static struct vop_vector udf_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D udf_access, .vop_bmap =3D udf_bmap, .vop_cachedlookup =3D udf_lookup, @@ -91,6 +89,7 @@ .vop_strategy =3D udf_strategy, .vop_vptofh =3D udf_vptofh, }; +DECLARE_VOP_VECTOR(udf_vnodeops); =20 MALLOC_DEFINE(M_UDFFID, "udf_fid", "UDF FileId structure"); MALLOC_DEFINE(M_UDFDS, "udf_ds", "UDF Dirstream structure"); Index: sys/nfs4client/nfs4_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/nfs4client/nfs4_vnops.c (revision 182995) +++ sys/nfs4client/nfs4_vnops.c (working copy) @@ -162,7 +162,6 @@ * Global vfs data structures for nfs */ struct vop_vector nfs4_vnodeops =3D { - .vop_default =3D &default_vnodeops, .vop_access =3D nfs4_access, .vop_advlock =3D nfs4_advlock, .vop_advlockasync =3D nfs4_advlockasync, @@ -192,6 +191,7 @@ .vop_symlink =3D nfs4_symlink, .vop_write =3D nfs_write, }; +DECLARE_VOP_VECTOR(nfs4_vnodeops); =20 static int nfs4_removerpc(struct vnode *dvp, const char *name, int namelen, struct ucred *cred, struct thread *td); Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 18= 2995) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working cop= y) @@ -3526,7 +3526,6 @@ struct vop_vector zfs_fifoops; =20 struct vop_vector zfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, .vop_inactive =3D zfs_freebsd_inactive, .vop_reclaim =3D zfs_freebsd_reclaim, .vop_access =3D zfs_freebsd_access, @@ -3558,6 +3557,7 @@ .vop_bmap =3D VOP_EOPNOTSUPP, .vop_fid =3D zfs_freebsd_fid, }; +DECLARE_VOP_VECTOR(zfs_vnodeops); =20 struct vop_vector zfs_fifoops =3D { .vop_default =3D &fifo_specops, @@ -3571,3 +3571,4 @@ .vop_write =3D VOP_PANIC, .vop_fid =3D zfs_freebsd_fid, }; +DECLARE_VOP_VECTOR(zfs_fifoops); Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c (revision 1= 82995) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c (working co= py) @@ -436,7 +436,6 @@ } =20 static struct vop_vector zfsctl_ops_root =3D { - .vop_default =3D &default_vnodeops, .vop_open =3D zfsctl_common_open, .vop_close =3D zfsctl_common_close, .vop_ioctl =3D VOP_EINVAL, @@ -448,6 +447,7 @@ .vop_reclaim =3D zfsctl_common_reclaim, .vop_fid =3D zfsctl_common_fid, }; +DECLARE_VOP_VECTOR(zfsctl_ops_root); =20 static int zfsctl_snapshot_zname(vnode_t *vp, const char *name, int len, char *zname) @@ -840,7 +840,6 @@ } =20 static struct vop_vector zfsctl_ops_snapdir =3D { - .vop_default =3D &default_vnodeops, .vop_open =3D zfsctl_common_open, .vop_close =3D zfsctl_common_close, .vop_ioctl =3D VOP_EINVAL, @@ -852,6 +851,7 @@ .vop_reclaim =3D zfsctl_common_reclaim, .vop_fid =3D zfsctl_common_fid, }; +DECLARE_VOP_VECTOR(zfsctl_ops_snapdir); =20 static vnode_t * zfsctl_snapshot_mknode(vnode_t *pvp, uint64_t objset) @@ -987,12 +987,12 @@ * be covered. */ static struct vop_vector zfsctl_ops_snapshot =3D { - .vop_default =3D &default_vnodeops, .vop_inactive =3D zfsctl_snapshot_inactive, .vop_reclaim =3D zfsctl_common_reclaim, .vop_getattr =3D zfsctl_snapshot_getattr, .vop_fid =3D zfsctl_snapshot_fid, }; +DECLARE_VOP_VECTOR(zfsctl_ops_snapshot); =20 int zfsctl_lookup_objset(vfs_t *vfsp, uint64_t objsetid, zfsvfs_t **zfsvfsp) Index: sys/sys/vnode.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/sys/vnode.h (revision 182995) +++ sys/sys/vnode.h (working copy) @@ -718,8 +718,11 @@ =20 extern struct vop_vector fifo_specops; extern struct vop_vector dead_vnodeops; -extern struct vop_vector default_vnodeops; =20 +void vop_vector_init(void *arg); +#define DECLARE_VOP_VECTOR(name) \ + SYSINIT(name, SI_SUB_VFS, SI_ORDER_ANY, vop_vector_init, &name) + #define VOP_PANIC ((void*)(uintptr_t)vop_panic) #define VOP_NULL ((void*)(uintptr_t)vop_null) #define VOP_EBADF ((void*)(uintptr_t)vop_ebadf) --vTUhhhdwRI43FzeR-- --egxrhndXibJAPJ54 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjjynAACgkQ52SDGA2eCwXSCwCeOQlljPRORRZ7th46uy0ZPB7N u0oAnjYVG7zx0v6S4WZxB+CXI+GgUB9x =Cd+S -----END PGP SIGNATURE----- --egxrhndXibJAPJ54-- From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 20:11:21 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81EDE106568C for ; Wed, 1 Oct 2008 20:11:21 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 438908FC15 for ; Wed, 1 Oct 2008 20:11:21 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id B80F3170E4; Wed, 1 Oct 2008 19:46:57 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id m91JktR5069187; Wed, 1 Oct 2008 19:46:55 GMT (envelope-from phk@critter.freebsd.dk) To: Ed Schouten From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 01 Oct 2008 21:07:28 +0200." <20081001190728.GL16837@hoeg.nl> Date: Wed, 01 Oct 2008 19:46:55 +0000 Message-ID: <69186.1222890415@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD FS , Mark van Cuijk , Jille Timmermans , FreeBSD Arch Subject: Re: Expanding vops in vop_vectors during startup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 20:11:21 -0000 In message <20081001190728.GL16837@hoeg.nl>, Ed Schouten writes: >The reason I'm sending this message, is because based on discussions I >had with several people on IRC we've basically got two different >opinions on this patch: > >- One group of people liked the idea of the patch. Some people even said > the patch looks good enough to be committed. > >- Another group of people also liked the idea, but thought it would make > no sense to commit it, because it's not like it's a bottleneck right > now. It should only be committed if an increase in performance is > notable. > >I did some tests with the patch set, by running tens of millions of >fstat(), fchown(), etc. calls to see how performance was affected. It >turns out on a kernel without any debugging options enabled, the >performance gain is only 1-2%, which sounds pretty valid to me. My resistance to this patch is not quite what you describe above: By factoring the vop vectors out, you remove the ability to let default vectors pick up new functionality later. I will admit that I have no knowledge of this level of generality, dating back from Heidemans Phd. dissertation, being used for anything sensible. Furthermore, if I am not mistaken, your patch increases the kernel size. Absent a plausible performance improvement, I don't see any point of your change. And that brings me to your "1-2%" measurement quoted in IRC and above. I have earlier ranted about the difference between benchmarking and random number generators, and you may have joined the project after the latest of these. Please search the mail-archives for that topic, and then use the handy ministat(1) program, to see if you have actually show any net speed benefit. Once and if you cross that threshold, I am going to raise my next objection: Benchmarking "tens of millions of fstat(), fchown(), etc. calls" and showing a 1-2% difference is patently bogus, and certainly no reason for the change you propose. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 20:21:10 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FC38106568B; Wed, 1 Oct 2008 20:21:10 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:3fb::211]) by mx1.freebsd.org (Postfix) with ESMTP id B5AC28FC08; Wed, 1 Oct 2008 20:21:09 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id DB3FA1CD1C; Wed, 1 Oct 2008 22:21:08 +0200 (CEST) Date: Wed, 1 Oct 2008 22:21:08 +0200 From: Ed Schouten To: Poul-Henning Kamp Message-ID: <20081001202108.GO16837@hoeg.nl> References: <69186.1222890415@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ccJhwVfaC+fHwTsl" Content-Disposition: inline In-Reply-To: <69186.1222890415@critter.freebsd.dk> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD FS , Mark van Cuijk , Jille Timmermans , FreeBSD Arch Subject: Re: Expanding vops in vop_vectors during startup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 20:21:10 -0000 --ccJhwVfaC+fHwTsl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Poul-Henning, * Poul-Henning Kamp wrote: > In message <20081001190728.GL16837@hoeg.nl>, Ed Schouten writes: >=20 > >The reason I'm sending this message, is because based on discussions I > >had with several people on IRC we've basically got two different > >opinions on this patch: > > > >- One group of people liked the idea of the patch. Some people even said > > the patch looks good enough to be committed. > > > >- Another group of people also liked the idea, but thought it would make > > no sense to commit it, because it's not like it's a bottleneck right > > now. It should only be committed if an increase in performance is > > notable. > > > >I did some tests with the patch set, by running tens of millions of > >fstat(), fchown(), etc. calls to see how performance was affected. It > >turns out on a kernel without any debugging options enabled, the > >performance gain is only 1-2%, which sounds pretty valid to me. >=20 >=20 > My resistance to this patch is not quite what you describe above: >=20 > By factoring the vop vectors out, you remove the ability to let > default vectors pick up new functionality later. Could you give me an example of such functionality? You mean extending a vop_vector? That shouldn't be a problem, right? If such functionality really seems to be in conflict with this modification, it's not like we're carving things in stone here. > I will admit that I have no knowledge of this level of generality, > dating back from Heidemans Phd. dissertation, being used for anything > sensible. >=20 > Furthermore, if I am not mistaken, your patch increases the kernel > size. Even though I admit I don't have that many file system types compiled into my kernel, binary size is 2203 bytes smaller with my patch applied. If you have a whole bunch of filesystems compiled into your kernel, these numbers might be a little different. We now need an extra SYSINIT per struct vop_vector. > Absent a plausible performance improvement, I don't see any point > of your change. >=20 > And that brings me to your "1-2%" measurement quoted in IRC and > above. >=20 > I have earlier ranted about the difference between benchmarking=20 > and random number generators, and you may have joined the project > after the latest of these. >=20 > Please search the mail-archives for that topic, and then use > the handy ministat(1) program, to see if you have actually=20 > show any net speed benefit. >=20 > Once and if you cross that threshold, I am going to raise my next > objection: >=20 > Benchmarking "tens of millions of fstat(), fchown(), etc. calls" > and showing a 1-2% difference is patently bogus, and certainly > no reason for the change you propose. ministat(1) also mentions a 2% improvement with 95.0% confidence. Quite a nifty tool. Thanks for pointing me to it. About the benchmarks: the reason why I decided to test these things, was because I didn't want to measure disk I/O performance. I just wanted to see how performance was different with respect to VOP_*() calls. This means most of the cases I tested scenario's when data would already be available from cache or on pseudo-filesystems, where real disk I/O would not occur. But as I said: I am not going to commit it. End of discussion. --=20 Ed Schouten WWW: http://80386.nl/ --ccJhwVfaC+fHwTsl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjj27QACgkQ52SDGA2eCwWqPgCfUKBUYLojYXtQdUm3/h71Z/gf lzMAnjGwVodxtPVsvJ700h73MPZ7Xylk =/2f/ -----END PGP SIGNATURE----- --ccJhwVfaC+fHwTsl-- From owner-freebsd-arch@FreeBSD.ORG Sat Oct 4 02:41:23 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D79551065694; Sat, 4 Oct 2008 02:41:23 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from core.tav.kiev.ua (tavex.colocall.com [62.149.10.42]) by mx1.freebsd.org (Postfix) with ESMTP id 709458FC08; Sat, 4 Oct 2008 02:41:23 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from s01060021299bf294.vc.shawcable.net ([24.87.45.120] helo=jeeves.bluezbox.com) by core.tav.kiev.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Klwhn-000OfP-5y; Sat, 04 Oct 2008 05:17:16 +0300 Message-ID: <48E6D21E.8040808@bluezbox.com> Date: Fri, 03 Oct 2008 19:17:02 -0700 From: Oleksandr Tymoshenko User-Agent: Thunderbird 2.0.0.16 (X11/20080831) MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Core-Spam-Level: ---- X-Core-Spam-Report: Spam detection software, running on the system "core.tav.kiev.ua", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hello -arch, I was playing with p4 mips2 branch catching up with recent developments and trying to reduce kernel size for MALTA configuration. At some point I ran into ata-chipset.c. This file contains all ATA chipsets supported by FreeBSD so it was a natural candidate for axing. I hacked small proof-of-concept framework for pluggable ATA chipsets. The idea is to move all vendor-related code to separated modules (.c, not .ko), register each during compile/link-time using ATA_CHIPSET macros (utilizes DATA_SET for this purpose) and provide each chipset with kernel config option. Something like this Warner did to miibus/*phy about two years ago. [...] Content analysis details: (-4.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list Cc: sos@freebsd.org Subject: Modular ata chipsets data X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2008 02:41:23 -0000 Hello -arch, I was playing with p4 mips2 branch catching up with recent developments and trying to reduce kernel size for MALTA configuration. At some point I ran into ata-chipset.c. This file contains all ATA chipsets supported by FreeBSD so it was a natural candidate for axing. I hacked small proof-of-concept framework for pluggable ATA chipsets. The idea is to move all vendor-related code to separated modules (.c, not .ko), register each during compile/link-time using ATA_CHIPSET macros (utilizes DATA_SET for this purpose) and provide each chipset with kernel config option. Something like this Warner did to miibus/*phy about two years ago. So far I got only Intel vendor working (tested with Gxemul) and would like to know if it's worth to keep moving in this direction and what possible pitfalls may appear. 90Kb is not that dramatical improvement :), but it's better then nothing and code readability should be better after splitting 180K file into several, IMHO. Patch: http://people.freebsd.org/~gonzo/embedded/modular-ata.diff don't mind copyrights, they're automatically inserted by vim. -- gonzo From owner-freebsd-arch@FreeBSD.ORG Sat Oct 4 10:51:19 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 456C0106568C for ; Sat, 4 Oct 2008 10:51:19 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from deepcore.dk (adsl.deepcore.dk [87.63.29.106]) by mx1.freebsd.org (Postfix) with ESMTP id AB0398FC17 for ; Sat, 4 Oct 2008 10:51:18 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from [192.168.0.138] ([192.168.0.138]) by deepcore.dk (8.14.3/8.14.2) with ESMTP id m94AJUPY026377; Sat, 4 Oct 2008 12:19:30 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) Message-Id: <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= To: Oleksandr Tymoshenko In-Reply-To: <48E6D21E.8040808@bluezbox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 4 Oct 2008 12:19:30 +0200 References: <48E6D21E.8040808@bluezbox.com> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (deepcore.dk [87.63.29.106]); Sat, 04 Oct 2008 12:19:30 +0200 (CEST) Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Modular ata chipsets data X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2008 10:51:19 -0000 Hi (Please keep me CC'd as I do not normally read the list) Anyhow, what I would like to see is that the chipset support get moved =20= into kernel modules, preferably auto-loadable when a given vendor is =20 detected, but for starters that could be left out. This is the way to =20= go for vendor supplied modules as well. I have a least 2 vendors that =20= are looking into that way of providing support for new chipsets. For a =20= small kernel you just load the module(s) you need and voila. I have VIP in that direction, but its not finished yet, but spiitting =20= up things is pretty trivial for the most part, except a few gotchas =20 here and there that will make at least autoloading a wee bit tricky. I guess the tedious part is to get all the code moved around into =20 seperate files, how the actual compile/link/load should be done is a =20 minor part that can be added when the seperaion is done. However, I do have most of that in place in a tree here, so thats more =20= or less done already, I just need to pull out the right tree here and =20= that part should be dealt with more or less. PS: in your patch you suddenly got exclusive Copyright on the Intel =20 and AHCI code, that will get you bad karma :) -S=F8ren On 4Oct, 2008, at 4:17 , Oleksandr Tymoshenko wrote: > Hello -arch, > > I was playing with p4 mips2 branch catching up with recent =20 > developments > and trying to reduce kernel size for MALTA configuration. At some =20 > point > I ran into ata-chipset.c. This file contains all ATA chipsets =20 > supported > by FreeBSD so it was a natural candidate for axing. I hacked small > proof-of-concept framework for pluggable ATA chipsets. The idea is to > move all vendor-related code to separated modules (.c, not .ko), > register each during compile/link-time using ATA_CHIPSET macros > (utilizes DATA_SET for this purpose) and provide each chipset with > kernel config option. Something like this Warner did to miibus/*phy > about two years ago. > > So far I got only Intel vendor working (tested with Gxemul) and would > like to know if it's worth to keep moving in this direction and what > possible pitfalls may appear. > > 90Kb is not that dramatical improvement :), but it's better then =20 > nothing > and code readability should be better after splitting 180K file into > several, IMHO. > > Patch: http://people.freebsd.org/~gonzo/embedded/modular-ata.diff > don't mind copyrights, they're automatically inserted by vim. > > --=20 > gonzo > -S=F8ren From owner-freebsd-arch@FreeBSD.ORG Sat Oct 4 17:57:36 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B75731065699; Sat, 4 Oct 2008 17:57:36 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from core.tav.kiev.ua (tavex.colocall.com [62.149.10.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1E88FC1D; Sat, 4 Oct 2008 17:57:34 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from s01060021299bf294.vc.shawcable.net ([24.87.45.120] helo=jeeves.bluezbox.com) by core.tav.kiev.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1KmBNo-000AlL-81; Sat, 04 Oct 2008 20:57:38 +0300 Message-ID: <48E7AE7D.6020709@bluezbox.com> Date: Sat, 04 Oct 2008 10:57:17 -0700 From: Oleksandr Tymoshenko User-Agent: Thunderbird 2.0.0.16 (X11/20080831) MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <48E6D21E.8040808@bluezbox.com> <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> In-Reply-To: <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Core-Spam-Level: ---- X-Core-Spam-Report: Spam detection software, running on the system "core.tav.kiev.ua", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Søren Schmidt wrote: > Hi > > (Please keep me CC'd as I do not normally read the list) > > Anyhow, what I would like to see is that the chipset support get moved > into kernel modules, preferably auto-loadable when a given vendor is > detected, but for starters that could be left out. This is the way to go > for vendor supplied modules as well. I have a least 2 vendors that are > looking into that way of providing support for new chipsets. For a small > kernel you just load the module(s) you need and voila. > > I have VIP in that direction, but its not finished yet, but spiitting up > things is pretty trivial for the most part, except a few gotchas here > and there that will make at least autoloading a wee bit tricky. > > I guess the tedious part is to get all the code moved around into > seperate files, how the actual compile/link/load should be done is a > minor part that can be added when the seperaion is done. > However, I do have most of that in place in a tree here, so thats more > or less done already, I just need to pull out the right tree here and > that part should be dealt with more or less. Great, I'll wait for results of your work to hit svn. [...] Content analysis details: (-4.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Modular ata chipsets data X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2008 17:57:36 -0000 Søren Schmidt wrote: > Hi > > (Please keep me CC'd as I do not normally read the list) > > Anyhow, what I would like to see is that the chipset support get moved > into kernel modules, preferably auto-loadable when a given vendor is > detected, but for starters that could be left out. This is the way to go > for vendor supplied modules as well. I have a least 2 vendors that are > looking into that way of providing support for new chipsets. For a small > kernel you just load the module(s) you need and voila. > > I have VIP in that direction, but its not finished yet, but spiitting up > things is pretty trivial for the most part, except a few gotchas here > and there that will make at least autoloading a wee bit tricky. > > I guess the tedious part is to get all the code moved around into > seperate files, how the actual compile/link/load should be done is a > minor part that can be added when the seperaion is done. > However, I do have most of that in place in a tree here, so thats more > or less done already, I just need to pull out the right tree here and > that part should be dealt with more or less. Great, I'll wait for results of your work to hit svn. > PS: in your patch you suddenly got exclusive Copyright on the Intel and > AHCI code, that will get you bad karma :) Ha! I cheated by helping old ladies across the street and got some extra karma to burn:) As I told - my vim is the one to be blamed, these copyrights wasn't going to make it into svn commit anyway :) > -Søren > > > On 4Oct, 2008, at 4:17 , Oleksandr Tymoshenko wrote: > >> Hello -arch, >> >> I was playing with p4 mips2 branch catching up with recent developments >> and trying to reduce kernel size for MALTA configuration. At some point >> I ran into ata-chipset.c. This file contains all ATA chipsets supported >> by FreeBSD so it was a natural candidate for axing. I hacked small >> proof-of-concept framework for pluggable ATA chipsets. The idea is to >> move all vendor-related code to separated modules (.c, not .ko), >> register each during compile/link-time using ATA_CHIPSET macros >> (utilizes DATA_SET for this purpose) and provide each chipset with >> kernel config option. Something like this Warner did to miibus/*phy >> about two years ago. >> >> So far I got only Intel vendor working (tested with Gxemul) and would >> like to know if it's worth to keep moving in this direction and what >> possible pitfalls may appear. >> >> 90Kb is not that dramatical improvement :), but it's better then nothing >> and code readability should be better after splitting 180K file into >> several, IMHO. >> >> Patch: http://people.freebsd.org/~gonzo/embedded/modular-ata.diff >> don't mind copyrights, they're automatically inserted by vim. >> >> -- >> gonzo >> From owner-freebsd-arch@FreeBSD.ORG Sat Oct 4 18:31:44 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AF2E106568D for ; Sat, 4 Oct 2008 18:31:44 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from deepcore.dk (adsl.deepcore.dk [87.63.29.106]) by mx1.freebsd.org (Postfix) with ESMTP id DFE308FC13 for ; Sat, 4 Oct 2008 18:31:43 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from [192.168.0.138] ([192.168.0.138]) by deepcore.dk (8.14.3/8.14.2) with ESMTP id m94IVZbd033251; Sat, 4 Oct 2008 20:31:35 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) Message-Id: <8C0B1202-5DF8-45CF-82EA-03367BFABAE7@FreeBSD.ORG> From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= To: Oleksandr Tymoshenko In-Reply-To: <48E7AE7D.6020709@bluezbox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 4 Oct 2008 20:31:35 +0200 References: <48E6D21E.8040808@bluezbox.com> <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> <48E7AE7D.6020709@bluezbox.com> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (deepcore.dk [87.63.29.106]); Sat, 04 Oct 2008 20:31:35 +0200 (CEST) Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Modular ata chipsets data X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2008 18:31:44 -0000 I found the devel tree with a modulerized ATA subsystem in it, and =20 just upgraded it to the latest greatest from -current. It can be found on http://deepcore.dk/pub/ATA as two files, ata-=20 modules-diff that contains a diff for /sys/conf/files and ata-=20 modules.tgz that is a replacement for /sys/dev/ata. This turns the chipset parts into a module for each vendor, and they =20 are all compiled in as is, however they can be left out on a pr vendor =20= basis (there are a few interdependencies though). I havn't written all the /sys/modules/ata/*/Makefiles that it would =20 take to make it into loadable modules, but thats trivial todo. Now what I'd like to find good generic solutions to is: How to select the proper modules at config/compile time without =20 drowning in "option ATA_BLA_BLA" in the config. How to automagically load the right modules when device probing takes =20= place. It could be loading them all in turn and unloading those that =20 didnt catch anything. I'm not aware of any ways to do this in the =20 kernel, but I've been unattentive for the last many months, so it =20 might have crept in :) Let me know how this works for you, I could very well be tempted to =20 commit it to -current soonish as it makes some things easier to play =20 with. PS: please keep me CC'd still, I dont read arch currently -S=F8ren On 4Oct, 2008, at 19:57 , Oleksandr Tymoshenko wrote: > S=F8ren Schmidt wrote: >> Hi >> (Please keep me CC'd as I do not normally read the list) >> Anyhow, what I would like to see is that the chipset support get =20 >> moved into kernel modules, preferably auto-loadable when a given =20 >> vendor is detected, but for starters that could be left out. This =20 >> is the way to go for vendor supplied modules as well. I have a =20 >> least 2 vendors that are looking into that way of providing support =20= >> for new chipsets. For a small kernel you just load the module(s) =20 >> you need and voila. >> I have VIP in that direction, but its not finished yet, but =20 >> spiitting up things is pretty trivial for the most part, except a =20 >> few gotchas here and there that will make at least autoloading a =20 >> wee bit tricky. >> I guess the tedious part is to get all the code moved around into =20 >> seperate files, how the actual compile/link/load should be done is =20= >> a minor part that can be added when the seperaion is done. >> However, I do have most of that in place in a tree here, so thats =20 >> more or less done already, I just need to pull out the right tree =20 >> here and that part should be dealt with more or less. > Great, I'll wait for results of your work to hit svn. > >> PS: in your patch you suddenly got exclusive Copyright on the Intel =20= >> and AHCI code, that will get you bad karma :) > Ha! I cheated by helping old ladies across the street and got > some extra karma to burn:) As I told - my vim is the one to be blamed, > these copyrights wasn't going to make it into svn commit anyway :) > > >> -S=F8ren >> On 4Oct, 2008, at 4:17 , Oleksandr Tymoshenko wrote: >>> Hello -arch, >>> >>> I was playing with p4 mips2 branch catching up with recent =20 >>> developments >>> and trying to reduce kernel size for MALTA configuration. At some =20= >>> point >>> I ran into ata-chipset.c. This file contains all ATA chipsets =20 >>> supported >>> by FreeBSD so it was a natural candidate for axing. I hacked small >>> proof-of-concept framework for pluggable ATA chipsets. The idea is =20= >>> to >>> move all vendor-related code to separated modules (.c, not .ko), >>> register each during compile/link-time using ATA_CHIPSET macros >>> (utilizes DATA_SET for this purpose) and provide each chipset with >>> kernel config option. Something like this Warner did to miibus/*phy >>> about two years ago. >>> >>> So far I got only Intel vendor working (tested with Gxemul) and =20 >>> would >>> like to know if it's worth to keep moving in this direction and what >>> possible pitfalls may appear. >>> >>> 90Kb is not that dramatical improvement :), but it's better then =20 >>> nothing >>> and code readability should be better after splitting 180K file into >>> several, IMHO. >>> >>> Patch: http://people.freebsd.org/~gonzo/embedded/modular-ata.diff >>> don't mind copyrights, they're automatically inserted by vim. >>> >>> --=20 >>> gonzo >>> > -S=F8ren From owner-freebsd-arch@FreeBSD.ORG Sat Oct 4 19:00:31 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 854BB1065686; Sat, 4 Oct 2008 19:00:31 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id 4ACDC8FC24; Sat, 4 Oct 2008 19:00:26 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id m94IZiRn006208; Sat, 4 Oct 2008 12:36:00 -0600 Message-ID: <48E7B73A.2030507@semihalf.com> Date: Sat, 04 Oct 2008 20:34:34 +0200 From: Rafal Jaworowski Organization: Semihalf MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <48E6D21E.8040808@bluezbox.com> <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> In-Reply-To: <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Oleksandr Tymoshenko , freebsd-arch@FreeBSD.ORG Subject: Re: Modular ata chipsets data X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2008 19:00:31 -0000 Søren Schmidt wrote: > (Please keep me CC'd as I do not normally read the list) > > Anyhow, what I would like to see is that the chipset support get moved > into kernel modules, preferably auto-loadable when a given vendor is > detected, but for starters that could be left out. This is the way to go > for vendor supplied modules as well. I have a least 2 vendors that are > looking into that way of providing support for new chipsets. For a small > kernel you just load the module(s) you need and voila. > > I have VIP in that direction, but its not finished yet, but spiitting up > things is pretty trivial for the most part, except a few gotchas here > and there that will make at least autoloading a wee bit tricky. > > I guess the tedious part is to get all the code moved around into > seperate files, how the actual compile/link/load should be done is a > minor part that can be added when the seperaion is done. > However, I do have most of that in place in a tree here, so thats more > or less done already, I just need to pull out the right tree here and > that part should be dealt with more or less. Apart from the above, have you got any plans towards refactoring the ATA driver so there is a generic ATA logic layer, clearly separate from controller specific parts and bus attachments like PCI etc.? Such a well structured approach would greatly benefit embedded systems at least, which very often have an ATA/SATA controller hanging directly on some local bus; in environments like this using our current ATA code is difficult as there needs to be some fake PCI glue provided and other hacks. Rafal From owner-freebsd-arch@FreeBSD.ORG Sat Oct 4 21:05:58 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4B721065698 for ; Sat, 4 Oct 2008 21:05:58 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from deepcore.dk (adsl.deepcore.dk [87.63.29.106]) by mx1.freebsd.org (Postfix) with ESMTP id 4662A8FC15 for ; Sat, 4 Oct 2008 21:05:58 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from [192.168.0.138] ([192.168.0.138]) by deepcore.dk (8.14.3/8.14.2) with ESMTP id m94L5pa3035363; Sat, 4 Oct 2008 23:05:52 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) Message-Id: <06D9EA2E-3EB2-4F77-8AE8-CD70E6D46444@FreeBSD.ORG> From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= To: Rafal Jaworowski In-Reply-To: <48E7B73A.2030507@semihalf.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 4 Oct 2008 23:05:51 +0200 References: <48E6D21E.8040808@bluezbox.com> <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> <48E7B73A.2030507@semihalf.com> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (deepcore.dk [87.63.29.106]); Sat, 04 Oct 2008 23:05:52 +0200 (CEST) Cc: Oleksandr Tymoshenko , freebsd-arch@FreeBSD.ORG Subject: Re: Modular ata chipsets data X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2008 21:05:58 -0000 On 4Oct, 2008, at 20:34 , Rafal Jaworowski wrote: > S=F8ren Schmidt wrote: >> (Please keep me CC'd as I do not normally read the list) >> >> Anyhow, what I would like to see is that the chipset support get =20 >> moved >> into kernel modules, preferably auto-loadable when a given vendor is >> detected, but for starters that could be left out. This is the way =20= >> to go >> for vendor supplied modules as well. I have a least 2 vendors that =20= >> are >> looking into that way of providing support for new chipsets. For a =20= >> small >> kernel you just load the module(s) you need and voila. >> >> I have VIP in that direction, but its not finished yet, but =20 >> spiitting up >> things is pretty trivial for the most part, except a few gotchas here >> and there that will make at least autoloading a wee bit tricky. >> >> I guess the tedious part is to get all the code moved around into >> seperate files, how the actual compile/link/load should be done is a >> minor part that can be added when the seperaion is done. >> However, I do have most of that in place in a tree here, so thats =20 >> more >> or less done already, I just need to pull out the right tree here and >> that part should be dealt with more or less. > > Apart from the above, have you got any plans towards refactoring the =20= > ATA > driver so there is a generic ATA logic layer, clearly separate from =20= > controller > specific parts and bus attachments like PCI etc.? Actually it is allready done that way, at least to the extent that the =20= device in question has to look like or be able to be modelled like an =20= ATA device. ata-isa.c ata-card.c ata-cbus.c ata-pci,c are all different bus =20 "adaptors" that just interact with different connection methods for =20 generic ATA devices, and presents them in a generic way to the ATA =20 "core" below. ata-all.c ata.-queue.c ata-lowlevel,c ata-dma.c are the "core" of the =20= ATA functionality, machinery that knows the ATA/ATAPI protocol and how =20= to deal with it. ata-disk.c atapi-cd.c atapi-fd.c atapi-tape.c are device drivers for =20 the different types of ATA/ATAPI devices. They know how to talk to the =20= device, using the "core" routines from above to do transfers etc. ata-chipset.c is the collection of code that knows how to deal with =20 specific controller related things, ie how to set a given transfer mode. ata-usb.c is somewhat special, as it lets certain USB devices show up =20= as if they where connected to an ATA bus, utilizing ATA's flexibility =20= to cope with just about anything that smells of ATA. > Such a well structured approach would greatly benefit embedded =20 > systems at > least, which very often have an ATA/SATA controller hanging directly =20= > on some > local bus; in environments like this using our current ATA code is =20 > difficult > as there needs to be some fake PCI glue provided and other hacks. That should be very easy to setup, you just need to write an "ata-=20 yourbus.c" ala the others mentioned above to tie you given HW setup =20 into ATA, and you're golden. Let me know a little more about you given HW, and I'll help you out =20 doing this. BTW, I have one of these WD MyBook World lying around in pieces, any =20 chances someone has played with getting FreeBSD onto one of those (it =20= runs linsux from factory). Would make a nice platform to play with =20 ARM, and I'm sure it needs ATA support to work :) -S=F8ren