[ sorry for the resend on this, local MTA seemed to suffer a bit of
  lossage ]

eeh@netbsd.org writes:
> Yes, the print functions will need to change somehow.  It should be
> possible for config_attach() and config_found() to determine whether
> to pass in `aux' or `struct device *' based on the bus device is 
> calling an old-style or new-style config_{found,attach} function.
> Or we could add new parameter, but that won't end up looking as
> nice when `aux' goes away.

The problem is, for the transitional case, how does the print function
know what kind of arg it has?


> The same thing could be done with the submatch functions.

submatch is easy, because you get cfdata, which includes ptr to
cfattach, which you can consult.

Of course, that's kinda grotty.



> 	(3) the whole "properties being automatically added from locators"
> 	needs a _lot_ more thought.
> 
> 	For instance, for direct-config devices where you have to call lots of
> 	match functions, trying to automatically set properties from locators
> 	means you may end up setting properties a bunch, or even dozens of
> 	times.  This seems ... quite excessive.
> 
> The simple solution is to make adding locator properties a
> rsponsibility of the parent driver, and only add locators from
> ioconf.c if in config_attach*() if that property has not already
> been set by the parent.

Actually, i'd say "only the first half of that sentence".


> 	It also raises the issue of 'default value' vs. 'no value'.  For
> 	instance, if you've got a potential vector of i/o addresses/sizes, you
> 	really don't want to include properties for the case where 'no value'
> 	is specified.
> 
> Huh?  How do you have a locator with `no value'?  

So, in general, if you have something like "ioaddr1 iosize1 ioaddr2
iosize2", it's "the right thing" to be able to say:

	ioaddr1 ? iosize1 ?

which means whatever ioaddr1 and iosize1, but there is no ioaddr2 and
iosize2.



> 	Finally, things which actually look at properties "later" don't really
> 	care what the config-file-specified locators are, just the ones that
> 	were actually used to attach the device.
> 
> I don't know if that's completely true.  If you are trying to build
> a config file from a running kernel you may care what's wildcarded.

If you're trying to build a config file from a running kernel, then
what you need to know is what locators are actually in use...

wildcards might be useful if you're trying to do something more
abstract... but you can do that by turning known values into
wildcards.


> 	To be honest, this gets me thinking about separate property
> 	containers, so that when it's time to make properties automatically
> 	generated from config info, there's a good place to attach them.
> 	("AIEEEE!")
> 
> Properties do not exist unless they are associated with a particular
> device.

Then, how do you plan to do 'random' properties specified in the
config file, associated with specific device lines?

They don't fit into the existing locator machinery nicely...

I don't think the answer is to add another property-like mechanism by
which property-like things can be associated with cfdata...  8-)


chris