From owner-freebsd-arch@FreeBSD.ORG Sat Feb 3 12:32: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 B9C0116A407; Sat, 3 Feb 2007 12:32:52 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 8BBAE13C428; Sat, 3 Feb 2007 12:32:52 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l13CWowg008697; Sat, 3 Feb 2007 04:32:50 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l13CWoEI008696; Sat, 3 Feb 2007 04:32:50 -0800 (PST) (envelope-from rizzo) Date: Sat, 3 Feb 2007 04:32:50 -0800 From: Luigi Rizzo To: Robert Watson Message-ID: <20070203043250.A8294@xorpc.icir.org> References: <20070131115148.A60420@xorpc.icir.org> <200702011109.12821.jhb@freebsd.org> <20070201.110206.1102529050.imp@bsdimp.com> <20070201104506.B82313@xorpc.icir.org> <20070203115235.W91177@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20070203115235.W91177@fledge.watson.org>; from rwatson@FreeBSD.org on Sat, Feb 03, 2007 at 11:55:03AM +0000 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: Sat, 03 Feb 2007 12:32:52 -0000 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... cheers luigi