From owner-freebsd-arch@FreeBSD.ORG Sat Feb 3 17:41:01 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 BBFB916A403 for ; Sat, 3 Feb 2007 17:41:01 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5592A13C4C5 for ; Sat, 3 Feb 2007 17:41:01 +0000 (UTC) (envelope-from sam@errno.com) Received: from [10.212.129.70] ([10.0.0.221]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l13HEfFG014709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Feb 2007 09:14:41 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <45C4C301.3040603@errno.com> Date: Sat, 03 Feb 2007 09:14:41 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Luigi Rizzo 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> <20070203043250.A8294@xorpc.icir.org> In-Reply-To: <20070203043250.A8294@xorpc.icir.org> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Robert Watson , 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 17:41:01 -0000 Luigi Rizzo wrote: > 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... As I said to you privately, another motivation for firmware was to allow code in the firmware module to do interesting things like decode/decompress/etc. firmware data before handing it to the caller. Otherwise firmware data tends to have slightly different needs because it can be large. Sam