Date: Sat, 03 Feb 2007 08:29:41 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: rizzo@icir.org Cc: rwatson@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: configurable device (and other) tables in the kernel ? Message-ID: <20070203.082941.1649771040.imp@bsdimp.com> In-Reply-To: <20070203043250.A8294@xorpc.icir.org> References: <20070201104506.B82313@xorpc.icir.org> <20070203115235.W91177@fledge.watson.org> <20070203043250.A8294@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20070203043250.A8294@xorpc.icir.org>
Luigi Rizzo <rizzo@icir.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070203.082941.1649771040.imp>