From owner-freebsd-arch@FreeBSD.ORG Sat Feb 3 15:31:41 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 C05DF16A403; Sat, 3 Feb 2007 15:31:41 +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 6210313C442; Sat, 3 Feb 2007 15:31:41 +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 l13FT9q0097115; Sat, 3 Feb 2007 08:29:14 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 03 Feb 2007 08:29:41 -0700 (MST) Message-Id: <20070203.082941.1649771040.imp@bsdimp.com> To: rizzo@icir.org From: "M. Warner Losh" In-Reply-To: <20070203043250.A8294@xorpc.icir.org> References: <20070201104506.B82313@xorpc.icir.org> <20070203115235.W91177@fledge.watson.org> <20070203043250.A8294@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 08:29:14 -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 15:31:41 -0000 In message: <20070203043250.A8294@xorpc.icir.org> Luigi Rizzo writes: : On Sat, Feb 03, 2007 at 11:55:03AM +0000, Robert Watson wrote: : ... : > The preferred way to make configuration frobs available during early boot is : > via the hints mechanism, which supports both loading data via the loader, : > compiling it into the kernel, and updating it using kenv(8). I'd really like : > us avoid adding yet more file access dependencies in the kernel. These tend : > to be fragile, can only run in certain contexts, run into issues with changing : > roots, etc. Could we add /boot/deviceids.hints to match /boot/device.hints? : : ok i was just asking for what the available options are. : : But in another private email i was mentioning that the bootloader : "load" mechanism also already support loading opaque files : and seems to pass the info to the kernel (preloaded_files ?), : and this would overcome what i think is a limitation of the hints/kenv : mechanism (more below). : : Following your principle (which i agree with) there would be no reason to : have a separate the firmware(9) mechanism except that: : : + the hints/kenv/loader variables/resource mechanism has too many : different names so people get confused on what it really is or can do; : : + documentation is also lacking a lot. E.g. "man -k hints" does not : mention kenv(2), which in turn does not mention any of the : resource_*(9) calls ("man -k resource" lists a few but not all : of them, but you have to know in the first place that 'resource' : and 'hint' are related, see previous point). : : + it seems to me that hints are only good at storing C strings i.e. : single lines of plain text. There is no support for opaque binary : data files. : : + the internal organization of hints is just a single list. Even if : one forgets about binary data and tries to store some large tables : (device ids, quirks etc) as multiple one-line name=value entries, : the mechanism doesn't scale. : : 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... Warner