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

In this instance, locator info would be attached as
properties by *config_found().  Any other information
needed would need to be provided by the bus driver.

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

SBus does not use a `submatch' function.  The *probe()
routine does a `strcmp' of the OFW device name with
the set of names the driver accepts.  (I suppose this
could be generalized to a `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.

I was hoping to put this issue off for for a bit
and stick to 32-bit integers until other types are
required.  This would require changes to configure,
and if you plan to add different types to locators,
you should replace `flags' with multiple, typed
properties, that way you don't need to provide
bitmasks to SCSI controllers telling them to disable
sync, tags, etc. for individual devices.

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

We should definitely do the former: add to the config(8) 
syntax so types can be specified when locators are 
defined so you can do:

	define	scsi {[string name = ""] [channel = -1]} property [string disable-sync-id0 = "no"]

where types default to `int' and there can be multiple 
properties with default values.

config(8) would then generate the required data to 
instantiate the locators and properties, which consist 
of the name, length, and the address of (pointer to) 
the data itself.

Once again, this could, and should be done as a 
future enhancement.

Eduardo