From owner-freebsd-arch@FreeBSD.ORG Sat Feb 3 23:16:02 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D509616A406 for ; Sat, 3 Feb 2007 23:16:02 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9308B13C441 for ; Sat, 3 Feb 2007 23:16:02 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id l13NDxaw001243; Sat, 3 Feb 2007 16:13:59 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 03 Feb 2007 16:14:31 -0700 (MST) Message-Id: <20070203.161431.-2001112364.imp@bsdimp.com> To: gurney_j@resnet.uoregon.edu From: "M. Warner Losh" In-Reply-To: <20070203195759.GG779@funkthat.com> References: <20070201091605.A82313@xorpc.icir.org> <20070201.110206.1102529050.imp@bsdimp.com> <20070203195759.GG779@funkthat.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 03 Feb 2007 16:14:00 -0700 (MST) Cc: freebsd-arch@freebsd.org Subject: Re: configurable device (and other) tables in the kernel ? 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, 03 Feb 2007 23:16:02 -0000 In message: <20070203195759.GG779@funkthat.com> John-Mark Gurney writes: : Warner Losh wrote this message on Thu, Feb 01, 2007 at 11:02 -0700: : > On the one hand, I like the flexibility of having the ability to look : > at a device and know what driver(s) may attach to it w/o having the : > drivers in memory, since that allows us to move to a demand load : > model for those people that want it. Right now, there's no way to : > smartly extract the plug and play info used by the device probe : > routines to bid on a device from the drivers to try to smartly load, : > say, the atheros driver when an atheros cardbus card is inserted. : : Hmmm.. couldn't we do something like dedicate a section to a simple : table that contains the PCI id's and related data to match.. Then : we could have a tool that embeds the PCI id data from a plain text : file and recreates the plain text file from the section... : : This doesn't solve the cases where the driver needs to handle a device : specially, but w/ the text file, and the driver using the table, it'd : be easy to do an on demand load pass... (and for new devices, users : would be able to test drivers w/o having to recompile the module).. : : And as part of installation, it lists the modules that are necessary : to boot in loader.conf... You could do all these things... However, somebody has to take it upon themselves to spearhead fixing all the drivers to use the new infrastructure. The higher level 'how to pass the table' in is the interesting problem. Until we have more drivers using tables, however, the uninteresting problem of driver conversion remains a show stopper. Warner