On 14 Feb 2001 eeh@netbsd.org wrote:

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

It's already been suggested that we should add an int *dv_loc to struct
device, which would be a lighter-weight way of doing this.

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

Like the foocf_locnames arrays already built into ioconf.c?

>  Passing
> an array of locators is a specific fix which does not solve a full array
> of problems the way device properties does.

I'd like more examples of that array.

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

Hmm.  That kind of thing sounds like it might almost be worthwhile on
OFW-based systems.

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

Hmm.  That aspect of it seems interesting.  So would your hope be that for
most bus attachments, you could get away with the bus-specific attach code
disappearing entirely, because all the busses would effectively provide
the same attach_args?

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