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

The children are filling out the `aux'?  Well, that's certainly
not the way it's described in Torek's config paper.

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

That means we'll have to change the signature of the print
function to handle both an `aux' and a child device.  I was
hoping that would not be necessary.

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

There's nothing to preclude multi-valued properties.  A few
multi-values properties are faster and easier to handle than
lots of single-values properties.  But I was not planning
to use multi-valued properties for locators. 

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

How do you distingush a locator property from a non-locator 
property when trying to dump a device tree to a kernel config
file?

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

My plan was to attach the properties to the cfdata the same
way locators are, only from different fields of the cfdata
structure so you can distinguish locators from other properites.  
Then they can be easily attached to the device node inside 
config_attach().  (Can't think of any reasonn the *match() 
routines would need access to properties.)

Eduardo