Date: Sat, 03 Feb 2007 09:14:41 -0800 From: Sam Leffler <sam@errno.com> To: Luigi Rizzo <rizzo@icir.org> Cc: Robert Watson <rwatson@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: configurable device (and other) tables in the kernel ? Message-ID: <45C4C301.3040603@errno.com> In-Reply-To: <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> <20070203043250.A8294@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45C4C301.3040603>