eeh@netbsd.org writes:
> 	(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.

In the indirect config case, config_found() is _never called_.



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

This is a bit off topic, but...

You may recall an old 'aux' member of cfdriver, that went away at some
point (when we split out to cfattach).

BSDI used it, for instance, to check things like that, as I recall.

If we wanted to resurrect it, we could, but it should be a pointer off
of cfattach rather than cfdriver.

There's some merit to that, but in my opinion it's not worthwhile,
because:

(1) match routines often have to look up other id-based metadata, and
so would probably have to do a lookup to check simple IDs anyway.

(2) match routines have a lot of other stuff to do, e.g. checking that
resource allocation will work out.

I prefer to provide common-to-bus structure definitions and functions
that can factor out common lookup code that'd otherwise be duplicated.


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

Yes, sure.  My goal with bringing it up is to make sure that whatever
interface comes out of this can handle it, without having to seriously
modify the interface again.



cgd