configurable device (and other) tables in the kernel ?

[Luigi Rizzo]

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