From owner-freebsd-arch@FreeBSD.ORG Thu Feb 1 16:21:13 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 D3BFB16A40B for ; Thu, 1 Feb 2007 16:21:13 +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 65F3713C4C9 for ; Thu, 1 Feb 2007 16:21:13 +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 l11GL73B091825; Thu, 1 Feb 2007 11:21:09 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 1 Feb 2007 11:09:12 -0500 User-Agent: KMail/1.9.1 References: <20070131115148.A60420@xorpc.icir.org> In-Reply-To: <20070131115148.A60420@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702011109.12821.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 11:21:10 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2511/Thu Feb 1 09:55:18 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: 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 16:21:14 -0000 On Wednesday 31 January 2007 14:51, Luigi Rizzo wrote: > I think there was some discussion on the topic some time ago > but cannot remember if there was any outcome so let me ask. > > 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 > firmware because it is not something where you may want > to change a few lines manually). > > Right now we compile them statically in the code. > However sometimes it is useful to update them 'on the fly' > without having to rebuild a kernel/module - e.g. because > an entry (e.g. a quirk for a specific device) cannot be > safely included in the distribution, etc.etc. > > What are the options to implement a mechanism that lets > userland update such tables, and maybe in a way that > is accessible to the boot loader ? > > The (obvious) requirements are: > + support for multiple tables with variable (maybe defined > at compile time) structure; > + initial values should be compiled in; > + the access mechanism should provide mechanism to read/modify/write/delete > entries; > + human-readable (i.e. textual) representation of entries in userland, > with hooks to translate them in a machine-friendly format on writes, > and back on reads; > > sysctl is the first method that comes to my mind, but > perhaps there is some better way ? 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 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)). -- John Baldwin