From owner-freebsd-arch@FreeBSD.ORG Thu Feb 1 18:03:52 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 1399B16A400; Thu, 1 Feb 2007 18:03:52 +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 B347813C4A6; Thu, 1 Feb 2007 18:03:51 +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 l11I1ZAU062378; Thu, 1 Feb 2007 11:01:35 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 01 Feb 2007 11:02:06 -0700 (MST) Message-Id: <20070201.110206.1102529050.imp@bsdimp.com> To: rizzo@icir.org From: "M. Warner Losh" In-Reply-To: <20070201091605.A82313@xorpc.icir.org> References: <20070131115148.A60420@xorpc.icir.org> <200702011109.12821.jhb@freebsd.org> <20070201091605.A82313@xorpc.icir.org> 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]); Thu, 01 Feb 2007 11:01:36 -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: Thu, 01 Feb 2007 18:03:52 -0000 In message: <20070201091605.A82313@xorpc.icir.org> Luigi Rizzo writes: : 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 ? Look at the firmware routines. However, they won't work until / is mounted, which is after all the device probing happens. : > 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 ? 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. However, only pccard and miibus drivers seem to religiously use tables to do their configuration. No other busses do that currently, although many have support for doing so. usb and pci are the big offenders whereby the probe is handled in many ad-hoc hackish ways. usb is bad in another way: it doesn't grok reprobing and has a 'vacuum' device that attaches to everything (ugen). The other issue is that there's many different parts of the PnP information that are used to bind devices to drivers. In pccard, for example, sio doesn't have a list of all modems, but instead attaches to all serial cards based on function id rather than the typcial vendor/model identifiers that other drivers use. This multiplicity of selection methods complicates any solution. On the other hand, the reason that we have the device driver tables compiled into the kernel is because when the kernel is doing its initial probe/attach of devices, it can't touch the root file system. This is the classic chicken and egg problem. The loader would have to assist the kernel in loading these tables, but there's complications for situations where one is booting over the network, or one is booting from flash. In these situations, it can be impossible to load another module until more of the infrastructure is in place (either disk drivers + busses + cam/ata or nfs + network interface). I've long wanted to have the ability to tell a bus to 'pretend' that the device ID for a given device is XXXX rather than the YYYY read from the device's enumeration mechanism. This would allow us to 'quirk' drivers for new hardware, as well as allow for users to get their devices up and running more quickly than having to rebuild the kernel. While this is the safest solution, it doesn't solve the 'which module to load' issue. It also doesn't force users to report these device IDs back to us, which may make fewer devices work out of the box in the long run. There's also only so much one can do with this mechanism if the driver is smart and has workarounds for different models and such that aren't needed/are harmful to newer silicon. Warner