eeh@netbsd.org writes:
> I was planning to extract the locator information from ioconf.c
> and attach them as properties to the dev node inside dev_config_found().
> Now, are they needed for both probe and attach or just attach?

In fact, primarily they're needed for match/probe, and typically not
at all for attach, but they're needed in wildly different two ways.

(1) indirect config (ISA, etc.):

	Bus provides cfdata locators to child, to look for device
	at that location.  If there's one there, great.  If not,
	no device there.

	i.e. right now, if you have an ISA device with io addr foo
	specified in the cfdata locators, the isa bus code construct
	a isa_attach_args specifying foo, and tries to attach it.

	it basically does "foreach cfdata, construct isa_attach_args
	from locators and try to attach."

	it seems fairly obvious that you want this to translate to
	"foreach cfdata, copy properties into a temporary container,
	add any other device-specific properties you know about, and
	try to use that to match/attach."

(2) direct config (PCI, SBUS, TC, etc.):

	Bus and/or devices compare the actual locators to the locators
	specified by the config files, and if they are 'compatible'
	then the match routine may succeed.  For many busses, this
	comparison is done by the bus-provided 'submatch' function.


There are problems with doing the conversion inside
dev_config_found(), i think.

Right now, all locators are 'int'.  That's broken.  If you want to
address a >32 bit address, you lose.  if you want to talk about a
string, you lose.

If you try to do the conversion in dev_config_found(), all you can
know to get, at this point, are 'int's.

To do this right, I think you need to do one of two things:

(1) provide type information in the config file for each locator.
I.e., the locators for a given bus are known to be of specific types
(and those are what they're compiled into when generating them).  This
doesn't necessarily mean exposing those types into the properties
system, btw.  The only real problem with this is figuring out what
headers you need, to compile the various types.

or

(2) do minimal type setup at compile time (i.e. handle string and
64-bit integer, but that's it), but allow runtime type conversion of
the integral types so that each driver doesn't have to know to do it
for itself.  That would require exposing the runtime properties stuff
to types, which, for the most part, I think we've decided to avoid.


I suppose you could do it wrong by making the bus code do the
conversion, but then you still need to figure out what to do about
strings, etc., in the config files.  And, it seems to me that there
are other benefits to doing it as real properties.  (e.g.: actual sane
generation of runtime-loadable config data.  no longer do you have
these insane little arrays of numbers, you can have real name,value
pairs...)



cgd