eeh@netbsd.org writes:
> O.K.  I will give you and explicit example of why you need to 
> be able to control this sort of searching when you do a query:
> 
> A cartain Solaris SCSI controller device driver wanted 
> to know the chip's clock frequency.  There were several
> versions of this chip at different clockrates, and the
> faster ones were capable of faster transfers.  So if
> it was running on a fast chip, the driver would enable
> the higher speed transfers.  To make this determination,
> it queried the `frequency' property.  However, some
> of the older devices did not have a `frequency' property
> in the FCode for that node.  Since the request had
> specified PROP_INHERIT, it would match the `frequency'
> for the bus on some machines, which was not the right
> value.  This caused the driver to use the wrong settings
> and caused problems.

This is a property-passing protocol violation.  The 'older devices'
didn't pass the frequency property.  For OFW or Solaris, that may be a
problem, I don't see why it's a problem for us.


> 	I disagree with this.  A device should _never_ have to look directly
> 	at another device's 'struct device' in order to function properly.
> 
> Then why are we passing a `parent' pointer into the driver *match()
> and *attach() functions?

You know, that's a good question.  I think the reason why we do it is
because that's they way the code was when it came into our hands, and
we never modified that part of it.

Certainly, now that I think about it, nuking that is something to
consider.  (it could be a difference encapsulated old-style
vs. new-style in the cfattach/fn wrapper macros that have been
discussed previously, to allow a smooth transition.)

> 	> If you use inheritance you never know who's property you're getting.
> 	> The parents are not the ones who care who's reading which property.
> 	> It's the children who can't trust the source of the property, whether
> 	> it comes from some parent node or some machine dependent repository.
> 
> 	Again, if this is true, what's a real-life example of a problem that
> 	_isn't_ a 'protocol violation' bug?
> 
> See above.  This is for much more than just attaching 
> devices to buses.

Sure.  But the point is, that example in the context of NetBSD is one
of a protocol violation and I think just about any similar one would
be.

The child was expecting to find a property from a predecessor in its
tree, that the predecessor erroneously did not provide.

In the OFW world, where you have to worry about backward compatibility
with old OFW, then maybe it was a problem.  But this properties scheme
is _not_ OFW.

If there's going to be a defined property-passing protocol between
parent, child, grandchild, etc., then it should be defined and stuck
to.  That means, for instance, consistently making sure that
e.g. "frequency" is there if children or grandchildren expect it.


> No.  Properties are for much more than just attaching
> child devices.  They are for controlling driver behavior.
> There will be many properties that will be used by device
> drivers that the bus drivers will know nothing about.  

Sure.  And those have to be defined by a system-wide protocol, rather
than a simple parent-child protocol.


> Anything that is accessed through dev_mdgetprop() for
> example, or properties attached to devices in config
> files.

Indeed, at least the latter _would_ be things that should be defined
by a system-wide or parent-child protocol.

The stuff that goes into dev_mdgetprop() _needs_ a translation layer
from the native NetBSD OS perspective (parent-child and global
protocols) to the firmware perspective.  For instance, consider
getting an ethernet address via dev_mdgetprop().

Some firmware will think of that as "ethernet-address" coupled with 6
byte values.  some will think "eaddr" and a "XX:XX..." string, or
maybe with a "XX-XX..." string.  Some will say "17" with who knows
what exact representation of the data.

When a NetBSD driver asks "give me the property for my ethernet
address", the MD getprop code has to:

	(1) translate the request for "ethernet address" into
	    something the native firmware understands.

	(2) translate the reply from the firmware back into something
	    that the NetBSD kernel understands.

Perhaps some of the property names or representations should be copied
from OFW.  But:

	(1) each case of doing that _should_ be examined.

	(2) it won't work straight off for some devices, even if you
	    have OFW.  (e.g. for the SCSI controller example, really,
	    the MD routine will have to invent something in the
	    appropriate places.)

	(3) that representation Just Won't Work for lots of systems.


> This is not just replacing locators and `aux'.  It also
> replaces `flags' amongst other things.

Right.  That seems fairly straightforward.

For flags, you need to enumerate up front (e.g. in the config file)
what the possible flag-replacement options are.  If an option is not
specified, the default value should be provided.


> 	I.e. I understand why you want PROP_INHERIT.  I don't understand why,
> 	assuming the protocol for passing properties is defined as well as it
> 	should be, you'd ever need to _not_ use it.
> 
> Properties cannot be taken care of at each level because
> there are potentially multiple protocols in operation on
> the same nodes at the same time.  One protocol would be 
> the bus driver/child protocol, which is used to pass 
> attachment information.  Another is the protocol to 
> set bus attributes, like SCSI SYNC and TAG QUEUEs.  
> Yet another could set speed, parity, and handshaking
> on a serial port.

This seems to indicate one of two things:

(1) you need to define protocols whose scope 'overlap' such that
they're compatible.  e.g. global has to be compatible with everything,
parent-child has to be compatible with parent-grandchild if you're
trying to do that type of thing, etc.  So, you don't really need to
worry about serial settings conflicting with SCSI settings, unless
you're providing global defaults for one or both of those.  If you
are, not matter what you do, you have to make sure they can coexist.

or

(2) you need some way to limit the scope of use of protocols.  And,
I'll again assert that, if you're going to do that, "0 and many"
aren't sufficient.  e.g. limiting scope to grandchildren is quite a
reasonable thing to want to do.  (scsi ctlr, scsi bus, scsi device...
or, if somebody ever fixes the SCSI code to attach targets rather than
target,luns, you'd need great-grandchild...)


> Also, some of the properties involved in a protocol
> may be set by the parent driver, but others may be
> set by firmware or inside the config file.  If we
> try to control inheritance when properties are added,
> we can only control the inheritance of properties that
> were added by drivers at run-time.  

That's true, yes.  Which, I think, speaks to the need for defining the
property communication protocol well and doing completely away with
any worries about the need to inheritance.


At this point, i've pretty much punted on the notion of limiting the
inheritance, at the creation or lookup side.  If you define your
properties well, and make sure they're passed at the right places, you
shouldn't need it.  (It was you, asserting that indeed that was what
removed the need for inheritance limitation, that got me thinking down
that path...  8-)


It's worth re-emphasizing that your proposal specifies the mechanism
for looking up properties, but doesn't actually say what properties
should be looked up, should be passed down from parents, should be
globally defined, etc.  Those things really should be subject to
another discussion entirely, but really come after the definition of
the interface, to my mind.


cgd