eeh@netbsd.org writes:
	[ IMMUTABLE properties ]

I suppose we could do the immutable thing and see
how well it works....

	> Hence I added dev_copyprops(9),
	> so you can keep a private property container that nobody 
	> else has access to.
	> 
	> Also, dev_destroy(9) checks to see if the perperty container
	> is unused before deleting it.  That way you can do:

	I didn't get anything from your latest message that said "checks to
	see if it's unused" or similar...

	(how do you propose to do this?)

Simple: a device is not used if it's not linked in to
the device tree (dv_parent is NULL and dv_list.tqe_next
is NULL).

	> 	create properties container
	> 	config_search(... properties container ...)
	> 	destroy properties container
	> 
	> or:
	> 
	> 	create static properties container
	> 	set up properties that will never change
	> 	loop {
	> 		create dynamic properties container
	> 		copy properties from static properties container
	> 			to dynamic properties container
	> 		set up properties that change from dev to dev on
	> 			dynamic properties container

	BTW, this example makes me ask whether your fake static properties
	containers need to to specify inheritance.  I'd think they do.

	does copyprops copy the inheritance (parent) pointer?  8-)

No.  A device does not have parents until it's linked into
the device tree.  If an attach routine wants to query its
parent's properties it is passed in the pointer to its
parent and can query it directly.

	> 	There definitely needs to be a way to 'reset' the inheritance, though,
	> 	i.e. terminate the inheritance chain.  Probably DVF_PROP_NOINHERIT,
	> 	which says that this node doesn't inherit from its parents.
	> 
	> 	That way, to clear a device's slate, you might do:
	> 
	> 		(1) set NOINHERIT,
	> 		(2) delete all.
	> 
	> 	Actually makes me wonder if you want to have the equivalent of a
	> 	'whiteout'.  (it might be useful to see how often that'd be used in
	> 	practice, and leave the door open to implementing it later...)  If
	> 	that type of thing isn't supported, it might be useful to say
	> 	something like:
	> 
	> 		(1) copy all inherited values down from parent,
	> 		(2) set NOINHERIT.
	> 
	> Since you specifically select whether you want to PROP_INHERIT
	> or not when you do the query, none of that is really needed.
	> To clear a device's node all you need is:
	> 
	> 	dev_delprop(dev, NULL, 0);

	Right, so, that raises some issues...

	you've gotta be very careful about whether or not you use
	PROP_INHERIT.  (I'd expect that, in general, you'd always say "yes, do
	inherit."  What are you expecting the default usage to be?  Or do you
	think it'll really depend on which attribute you're asking about?)

It really depends on the attribute.  This is mostly useful when
a device doesn't really know how many nodes are between it and
the node that contains the values it needs, such as when there 
are several bridges between a card and the bus controller.

	It also means that if you want your _child_ to see none (or some
	subset) of the parent's properties, if that child has to use
	inheritance, you're kinda out of luck.  e.g.:

		pchb
		pci at pchb
		dev at pci

	I think you'd actually _want_ to have the 'dev' get its
	pci_chipset_tag_t via inheritance from the PCHB.  otherwise, the pci
	would just be doing property additions left and right for no reason.
	(In that case, what's the point of inheritance?)

		pchb
		pci at pchb
		pcib at pci
		isa at pcib
		dev at pci

	well, all of a sudden now, if you're looking for a PCHB by
	inheritance, you're going to find the one inherited from pchb...

	Not necessarily desirable.  Interrupt routing information might even
	be more confusing.

	One answer to this is keeping bus-dependent match/attach routines
	(like I said before, I think you've gotta do that anyway 8-), and be
	_very_ careful about what properties they look at...

	I dunno, it's just an obvious feature that I expected to see, but
	didn't.  I expect that when you start trying to combine attachments,
	you'll run into problems here (esp. for ISA-ish devices that are
	effectively living behind other ISA-ish devices, e.g. multiport cards,
	sound cards, etc.)

In general, the parent should attach properties a device should
use to the device node.  That way the device would query itself
to find what properties it should use.  Inheritence should be
used for obscure things such as when a driver needs to know the
frequency of the bus it's attached to.

	> Actually, we could get rid of this `aux' vs. `propdev' distinction in
	> the function signitures by basing it on a property associated with the
	> parent (bus) node.  If the property "device-properties" is set it casts
	> `aux' to a `struct device *' and uses it to pass propreties.  If that
	> property is not set it uses it at an opaque `aux' structure the way
	> it works now.
	>
	> But that would preclude mixing old and new attachment schemes.  So
	> macros are probably a better way to go.  Unless there were some way
	> to provide this information in the cfattach strucure....

	you might be able to stuff a special value at the end of cfattach --
	if non-zero, then it'd be new style.

	but that makes it harder to flip the switch after everything's been
	converted, and I dunno how you'd tell before hand if everything's been
	converted...

Probably better to just change the function signatures.

Eduardo