On Tue, 10 Oct 2006, Martin Husemann wrote:

> On Tue, Oct 10, 2006 at 04:11:16PM +0000, Eduardo Horvath wrote:
> > All other real device nodes should be handled the exact same way:
> > 
> > ihandle->phandle (if needed)
> 
> I fail to see one tiny thing:
> 
> Inside device_register(), how do I get the i- or phandle of the device
> currently attaching?
> 
> All the dance in device_register that is left there now only helps getting
> the phandle into the device properties. If there is an easier way, that
> would be cool.

Yes, that's a fundamental problem with the NetBSD device model.  Ideally, 
you would want some way of correlating a device node with port-private 
information like the device phandle.  This can be done easily after the 
device has been created and config_found() returns a pointer to the device 
node.  But if you need that information during the probe process, either 
inside the xxx_match(), xxx_attach(), or device_register() routines, you 
can't do that because config_found() both creates the device node and 
calls those routines.

Now the original idea I had behind device properties is that the locator 
and attach information provided in the aux vector, which is in a bus 
specific structure, could be passed in as properties associated with the 
device node, doing away with the aux vector entirely.  Thus the locator 
information would be stored in a manner that is persistent and accessible 
by anything without having to know the layout of a private structure.  
This, of course, would require re-structuring the device probing code in 
such a way as to allow the parent to associate the locator information 
with the device node before the xxx_match() and xxx_attach() routines were 
called, and met with significant resistance from a few rather vocal 
members.

Another way to achive a similar, although less optimal solution, would be 
to associate properties with specific aux vectors themselves.  With SBus 
it would be trivial to do, since we have MD code that runs the autoconfig 
engine.  For PCI it's more complicated, since there's no opaque value 
that's passed directly down the config code stack.  But it looks like a 
match routine could be supplied to pci_probe_device() that extracts the 
phandle from the pci_tag in the pci_attach_args structure and associates 
it with the pci_attach_args (aux vector) before config_found*() is called.

Then you could have a nice generic device_register() that extracts the 
phandle property from the aux vector without requiring all this 
bus dependent goo.

But then again, maybe it's not worth the bother.

Eduardo