In message <20060220014745.BB9E93C0296@berkshire.machshav.com>, "Steven M. Bell
ovin" writes:
>In message <200602200112.k1K1CYHF029586@guild.plethora.net>, Peter Seebach writ
>es:
>>If this were generalized, it could allow people to do all sorts of neat
>>things.  BSD/OS had a somewhat similar feature; /etc/boot.default could be
>>used to set parameters, ranging anywhere from specifying a forced size for
>>maximum memory, to driver-specific flags, or forcing a given driver not to
>>probe.  (Generically, xx0 port=-1 suppressed probes of the xx driver.)

>I miss that feature....

Me too.  And it seems to me that all the pieces are in place now.  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.

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!

-s