Subject: Generic configuration requests outside of config files?
To: None <tech-kern@netbsd.org>
From: Peter Seebach <seebs@plethora.net>
List: tech-kern
Date: 02/19/2006 19:12:34
Background:  I'm working on a port of NetBSD to the TAMS 3011.  This board
has two ethernet devices, both of which have MAC addresses which must be
obtained from a special i2c EEPROM (not on board either chip, but a separate
part).  There are various ways to get similar configuration data on related
boards, mostly openbios and RedBoot configuration structures.

It seems to me that we have about 90% of what we need to migrate to a nicely
generic way to pass in configurable parameters to the kernel.  The various
openbios based ppc 405/405GP/405GPr boards are using a sort of hack built
on top of the propdb code, which is buried in arch/powerpc/ibm4xx/openbios.

My first-run theory is this:

The "board_info" feature should be promoted to be a kernel feature, not tied
so closely to openbios.

We should have code to populate it from openbios and from redboot, both of
which matter on at least some systems.

We should probably also have code to pass in parameters from the NetBSD native
bootstrap loader.

Some platforms (such as the TAMS 3011) will need special code to populate it,
say, from a custom EEPROM or other weird setup.

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

My big interest in this is simply that, as is, my options in getting this
board working all suck.  I could modify if_sip.c to have conditional code
to read a block of data from an eeprom, scan it for a particular string, and
copy data shortly after that into enaddr... But that's a really awful way
to implement this, and there's already a Linux port to this board.  My theory
is that a general interface for populating a propdb with useful things (such
as mac addresses) would make it possible to write nicely portable and generic
code to the effect of:
	if (board_info_get("%s-mac", sc->sc_dev->dv_xname)) {
		...
	}
and the sip driver would not need to have any idea whether I got that
information from an EEPROM or a file in /etc; it would just know that someone,
somewhere, had specified a MAC address for it.

BTW, if the answer is "we already have this, why aren't you using it", I'd
love to hear it.  :)

-s