configurable device (and other) tables in the kernel ?

[Sam Leffler]

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