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

This is fairly ... "magical" from the perspective of the caller.

It really seems best to me to not magically re-use the containers
they're providing, and punt on the whole 'is it used' question.  if
they make it it's fake, if it's fake it stays fake, and if they try to
destroy something non-fake, they die.

If you're going to make a create-and-hand-off interface, go all the
way: make config_found() or config_search() actually consume the
device container provided for them.  (I.e. it's used for a device, or
it's destroyed.)  If you get a ptr back, something was attached.  If
you get NULL back, nothing was and for that device you're done.

Personally, though, i prefer to avoid create-and-hand-off interfaces
except where there's some overriding reason to use them.

What you've proposed in the last draft and/or your followup messages
seems to be 'create and kind-of hand off but still require effort to
be done' thing, which will cause more problems than either a
create-and-hand-off or create-loan-destroy interface...


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

I guess this fits in with the notion that inheritance is ~never to be
used.

(I find that kind of unfortunate, since it means that a _lot_ of
memory will be wasted for inheritable things...  *sigh*)


> 	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.
> [ ... ]
> 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, right now, bus speed is something passed down via aux on at
least some busses, because it's "important enough."

believe it or not, I think that in fact you might want 'speed' to be
set closer to the device, in terms of the inheritance chain, than bus
chipset info.  consider a (taken from real life) example like:

	rfpchb
	pci @ rfpchb		# really fast pci-like bus; not exactly PCI,
				# but OS software can't tell the diff.
	ppb @ rfpci		# really fast -> 64x66 bridge
	dev @ ppb

the bus chipset info should be provided by rfpchb.  The clock speed
could be provided by rfpchb and by ppb.

This use of inheritance seems inconsistent.  If you're going to get
bus speed via inheritance, why wouldn't you also get other bus chipset
information of various varieties?  It's absolutely unchanging, and you
may not know the distance between you and the bus bridge...  I don't
understand how it's different than 'speed,' except that it happens to
be used more often.

It's not like lookup speed matters; you do the lookup once at match
time & once at attach time, then you're done...

If you think about a hypothetical utility to dump properties
associated with a device... why would the bus chipset info be
associated with a device, any more than the bus speed is?

Do you have another example?  I'm thinking, if you don't want to use
inheritance for obvious stuff like bus chipset info, why in fact would
you want to use it at all?



Also, it seems that several of your suggestions so far have assumed a
set of expected properties that would be used.  Can you provide a
list?  (such a list should come with the documentation for a change
like this anyway... 8-)




cgd