On Sun, Feb 19, 2006 at 08:04:29PM -0600, Peter Seebach wrote:
> The propdb code is flexible enough to be used; we have the bootloader
> pass us a structure in some trivial form, then we have code to read
> that, or redboot, or a board's local eeprom, and populate it.  All
> of this gets done after malloc is allowed but before autoconf, in
> principle, and you can populate it more later.

I'm not sure I quite understand the mechanics of what you're
proposing.  In at the least the evbppc case, there's a global
'dev_propdb.'  Are you thinking of something similar?

Personally, if it's a more generic resource, my first thought is
to add a pointer to struct device let autconf propagate it.  Perhaps
adding it as an argument to config_rootfound() to initialize it
(NULL means for autoconf to initialize an empty propdb for the
cases where it's not used).

> Actually, this raises the interesting question:  What is the
> right way to indicate a machine-specific use of an eeprom?  There's
> no real place to put a callback for "run this as soon as the eeprom
> is attached", but it'd be insane to have the eeprom driver contain
> code for every board that might use that particular chip!

If you can't read the information directly from the boot code, it
seems like it would be best to load it independently of the autoconf
framework.  If the eeprom is on i2c, then provide enough of the
iic framework to reuse that code.

If there's a better idea, I'd like to hear it.

I'm not sure about the suggestion to change config(8) to allow for
deferral there.  In some ways I like that a lot, but I am also a
little leery of putting too much machine-specific knowledge in
config files.

-allen

-- 
                  Use NetBSD!  http://www.NetBSD.org/