eeh@netbsd.org writes:
> 	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?
> 
> If it's old-style it gets `aux'.  If it's transitional or
> new-style it gets the new interface.  During the transition
> both `aux' and properties should contain the same information,
> after all.

A nice thought, but incorrect.

In the current implementation, children of indirect-config busses are
responsible for filling in members of their 'aux' structures to
indicate the actual location of the device if some locators weren't
completely specified.  (This is often used for I/O sizes, memory
sizes, IRQs, etc.)

When busses are converted, they'll pass old aux and new props to the
children.

And, depending on whether the children have been converted, they'll
fill in either aux (not converted) or property values (converted).

If the print function's going to print out the info, it needs to know
which it needs to print.  The two sets of information are _not_
interchangable.

(Other than printing, the parent bus code doing the attach typically
doesn't need this information.  but if it did, it could figure out
which type it was dealing with by looking at the child device.  The
print function as-is doesn't have that luxury.)


> 	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.
> 
> Well, if a locator has no value, then the parent should set
> a property with no data....

Storongly disagree.

since we're going into the whole 'search vs. no search' world,
locators should be looked for only directly on the device.  (other
data much be searched for, but not the locators.)

It's much more natural to say "no IRQ, no property".  it also makes a
lot more sense when thinking about e.g. what would be printed out when
dumping a device's properties.

(This kinda concerns me: you're not planning to go down the OFW-style
multi-value properties path, are you?  I could see some minor desire
for that, but it's not the path that we've taken with locators in the
config files up to this point... and you shouldn't start randomly
diverging from what the existing configuration code does.)


> 	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.
> 
> It may also make sense to combine all the locators as (name,
> value) pairs in a single property called `locators' so they
> can be easily extracted.

_easily_?  what would make that easy to extract?  8-)


> 	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-)
> 
> By extending the `flags' so you can have multiple flags with
> types more complicated than `int'.

I know where you're going...

the question is, how do you represent them?

There are a couple of ways you might try to do it.

One is a 'flags' mechanism, that's basically the same as the existing
properties mechnism but can't use the same code because you can't
easily associate properties with non-devices.

Another would be to, effectively, hang properties off of cfdata.

That way you could have your config-specified locators be properties
off your cfdata.  And flags as well.  You'd have to look for them
specially, but you'd only be doing it at match/attach time anyway.
(the notion being, you'd copy the flag properties to your device
node.)



chris