Subject: Re: More Device Properties
To: None <firstname.lastname@example.org, email@example.com>
From: Ben Harris <firstname.lastname@example.org>
Date: 02/14/2001 18:50:57
In article <email@example.com> 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
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
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 <firstname.lastname@example.org>
Portmaster, NetBSD/arm26 <URL:http://www.netbsd.org/Ports/arm26/>