In article <20010214175131.8658.qmail@mail.netbsd.org> you write:
>I propose adding properties and accessors to device nodes.  There are a number
>of cases where drivers need to pass information to other drivers or acquire
>information that is not available to them and accessible only through machine
>dependent code.  To solve these sorts of problems I propose adding a property
>framework to allow arbitrary data to be associated with particular device nodes.
>
>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
see, device locators work fine as they are (though they should perhaps be
passed in an array, like in a struct cfdata, rather than mixed into the
attach args).  There are only a few machines where MAC addresses aren't
directly extractable from Ethernet cards, and I don't think all this
infrastructure is necessary for just those cases.

>The most useful aspects of device properties occur when the parent driver is
>able to add properties which a child device uses during its attach routine.
>The current infrastructure makes this impossible since the child device
>structure is not available to the parent until after it has finished
>attaching.

Isn't this already handled by the aux pointer?

I'm still unconvinced that all this extra code (which has to be compiled
into the kernel even if nothing uses it) is worthwhile.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>