In message <20060220220149.GO29493@canolog.ninthwonder.com>, Allen Briggs write
s:
>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?

As similar as possible, really.  If it were generalized a bit, then instead of
having a lot of the code buried in openbios.c, openbios.c could just have the
code to populate this from openbios, and there'd be a similar file for redboot
boot info, and another to populate it from, say, a config file in /etc.

>> 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.

Well, we already sort of have that; there's a seeprom_bootstrap_read
function which takes a hand-rolled i2c_tag_t and fakes up all the stuff
the regular driver would do.

>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.

Hmm.  Well, the alternative is that we would have to modify the if_emac.c code
to defer a huge amount of processing JUST for this one board (out of maybe a
half-dozen 405GPr systems with the same ethernet hardware).

It seems to me that machine-specific knowledge belongs in config files for
embedded systems; maybe less so on platforms like i386, but on evbppc, every
config file describes essentially a single very specific hardware platform.
I mean, we don't even need memory or CPU speed probes; those are CONSTANTS
on these platforms.

The two features I'd ideally like are some sort of deferral, and some sort
of callback.  The idea of the callback is that your system's machdep.c (and
this really makes sense only for the embedded boards, probably; it's not like
i386, where machdep is "everything you need to do on any i386 from a laptop to
a Soekris board to a quad xeon server") can register a callback so that,
when a given device is attached, the callback can run on it immediately.  This
is relevant because devices like eeproms with boot information may need to
be processed before autoconfiguration can complete...

-s