From owner-freebsd-arch@FreeBSD.ORG Sat Feb 3 16:15:54 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 745DA16A400; Sat, 3 Feb 2007 16:15:54 +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 310C213C467; Sat, 3 Feb 2007 16:15:54 +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 l13GFV42097491; Sat, 3 Feb 2007 09:15:31 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 03 Feb 2007 09:16:03 -0700 (MST) Message-Id: <20070203.091603.1136083763.imp@bsdimp.com> To: rizzo@icir.org From: "M. Warner Losh" In-Reply-To: <20070203073709.B10325@xorpc.icir.org> References: <20070203043250.A8294@xorpc.icir.org> <20070203.082941.1649771040.imp@bsdimp.com> <20070203073709.B10325@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]); Sat, 03 Feb 2007 09:15:31 -0700 (MST) Cc: rwatson@FreeBSD.org, 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 16:15:54 -0000 In message: <20070203073709.B10325@xorpc.icir.org> Luigi Rizzo writes: : On Sat, Feb 03, 2007 at 08:29:41AM -0700, M. Warner Losh wrote: : ... : > : All of the above can be fixed - especially the documentation part, : > : but that doesn't mean that the hints mechanism can already do : > : what i was asking; there is still a bit of work to do... : > : > True. Things could be better documented. : > : > However, the more fundamental problems remain. It does no good to : > have a fancy binary loader with every kind of plug and play info if : > few of the drivers in the system use tables in a consistant way. : > That's a big problem to solve... : : well but that also can be fixed. e.g. many of the usb and quirks : tables, i think, are already reasonably structured so if : a mechanism is in place it won't take much work to adapt : them, maybe one at a time. Quirks, yes. Device tables, no. I guess it depends on how generic you want it, and how universal. Warner