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

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.

	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

Device locators are specified in config files and are completely
dependent on the that config file.  With the current scheme locators
are used during attach, but not passed to the driver and not kept after
the attach.  That information is required when trying to extract a device
tree for a config file from a running kernel.  If the locators were then
associated to the device nodes as properties during attach that information
would be available later.

Also, if you use an array for locators, there is the issue of associating
the locator value with the locator type.  You would need to provide two
arrays, one of the locator values and another of locator names.  Passing
an array of locators is a specific fix which does not solve a full array
of problems the way device properties does.

	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.

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.

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

The aux pointer is extremely bus dependent, non-extensible, and destroyed
after attach.  Properties are not.

	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.

Eduardo