From owner-freebsd-arch@FreeBSD.ORG Thu Feb 1 22:54:28 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 290CB16A40D for ; Thu, 1 Feb 2007 22:54:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id AA3FA13C4B4 for ; Thu, 1 Feb 2007 22:54:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l11MsNRJ094270; Thu, 1 Feb 2007 17:54:25 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Luigi Rizzo Date: Thu, 1 Feb 2007 16:13:02 -0500 User-Agent: KMail/1.9.1 References: <20070131115148.A60420@xorpc.icir.org> <200702011109.12821.jhb@freebsd.org> <20070201091605.A82313@xorpc.icir.org> In-Reply-To: <20070201091605.A82313@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702011613.02809.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 01 Feb 2007 17:54:25 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2513/Thu Feb 1 11:48:53 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx 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: Thu, 01 Feb 2007 22:54:28 -0000 On Thursday 01 February 2007 12:16, Luigi Rizzo wrote: > On Thu, Feb 01, 2007 at 11:09:12AM -0500, John Baldwin wrote: > > On Wednesday 31 January 2007 14:51, Luigi Rizzo wrote: > ... > > > We have several tables in our kernel and modules, > > > containing at least device-id tables (pci, usb), > > > quirks for certain devices, and maybe more (i am excluding > ... > > Windows and MAC OS X both use plain text files to hold things like PCI device > > IDs to match drivers to devices. OS X uses an XML file format that lets you > > plain text files! > > too obvious to think of it :) > > but, where can i find an example of a piece of kernel code that can > read from a file "safely" (i.e. say in the modevent handler or maybe > at device probe time) ? > Something like > > char *load_file_into_kernel_memody(filename, max_size, &error); > > I have looked at the kernel side of execve and kldload, they are not > exactly straightforward (at least there are seveal indirections). > Maybe there are other simpler ones ? I think this would be a bad idea (kernel loading files). I think instead you should depend on userland to hand stuff to the kernel. For example, if you want to autoload drivers, you should have some sort of database devd consults to find a driver to kldload to see if it attaches to the device. > > list the PCI ID's a driver supports and the kernel auto-loads driver modules > > by matching on PCI IDs. Many drivers can't be helped by this though, as they > > use the device ID for for device-specific behavior (such as em(4) or > > brgpy(4)). > > well, that's a two-phase process, if you have the above table-based > mechanism, the kernel (actually the bus driver i would say) can > load the [device_id -> driver] table (or tables, assuming > each driver has its own file) to select and load the > correct driver, and then the driver itself could use the same > mechanism to load a [device_id -> quirks] table for internal use ? You missed the much more glaring problem. Suppose a new device comes out, and you want to add support to it to an existing driver, so you add the PCI ID of the card and load the driver. Only, since there's no _code_ to handle the quirk (think about the case of a quirk that didn't exist before), then it doesn't work, or worse, it sort of works until it hoses a bunch of data. I really don't think this is a good idea. -- John Baldwin