eeh@netbsd.org writes:
>>Examples of data that are currently problematical but could easily be passed
>>as properties are device locators, which require and arbitrary bus-specific
>>structure to pass betwen the parent bus node and the child device node, and
>>MAC addresses for ethernet devices, which on some machines are available by a
>>simple firmware call, but on others require the driver to dig bits out of an
>>EPROM.
>
>How would using properties help in either of these cases?  As far as I can

>The driver attempts to retrieve a property, and the MD code
>intercepts the request and provides the desired property 
>which was generated in som MD manner.

Right, but, _how_?  I.e., 'get property' fails, then 'get md property'
is invoked to try to get the result?

Just trying to understand how this thing is supposed to work.


Is interhitance of properties done by copying them, or by traversing
up-chain?  (If the latter, you'll need to expand my suggestion of
'property container' slightly to point to the up-stream container...
No biggie.)


> It's not just MAC addresses.  OpenFirmware allows lots of arbitrary
> properties to be associated with device nodes.  Right now there is
> no MI way for devices to even attempt to retrieve this information.  One
> example is associating an OFW node with a PCI device.  Current PCI
> bus code does not provide any means of doing this because the attach
> args are quite limited.  This could be solved by adding MD fields to
> the PCI attach args, or it could be done by passing this information
> as additional properties associated with the device node.

Of course, in fact, it can't be done as either unless the MD PCI code
is enhanced to pass down this information, correct?  (see other
discussion about why the MD PCI code shouldn't be changed to do this.)

It gives you a better way of getting the bus node than looking in the
PCI chipset tag, maybe...


> 	I'm still unconvinced that all this extra code (which has to be compiled
> 	into the kernel even if nothing uses it) is worthwhile.
> 
> This actually provides for potential reduction in code.  The current MI
> device scheme requires different bus-specific glue code to handle different
> bus-specific attach arg encodings.  Device properties are standard, and do
> not require special decoding.  By switching to Device properties, the 
> bus-specific attach routines could be generalized and reduced to a single
> attach routine.  This could result in substancial savings in kernel space.

I think that, in fact, this is fairly unlikely to happen as you
suggest.  But, anything's possible.  8-)



cgd