On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote:
> Hi,
>
> On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe <lacombar@gmai...> wrote:
> > That's neither correct nor robust in a couple of way:
> >  1) you have no guarantee a device unit will always give you the same resource.
> this raises the following question: how can a device, today, figure
> out which parent in a given devclass would give it access to resources
> it needs.
>
> Say, you have gpiobus0 provided by a superio and gpiobus1 provided by
> the chipset and a LED on the chipset's GPIO. Now, say gpiobus0
> attachment is conditional to some BIOS setting. How can you tell
> gpioled(4) to attach on the chipset provided GPIO without hardcoding
> unit number either way ?
>
> AFAIK, you can not.
>
> Even hints provided layout description is defeated. Each device in a
> given devclass need to have a set of unique attribute to allow a child
> to distinguish it from other potential parent in the same devclass...
>
>  - Arnaud

Talking about a child being unable to choose the correct parent seems to
indicate that this whole problem is turned upside-down somehow; children
don't choose their parents.

Just blue-sky dreaming here on the fly... what we really have is a
resource-management problem.  A device comes along that needs a GPIO
resource, how does it find and use that resource?  

Well, we have a resource manager, could that help somehow?  Could a
driver that provides access to GPIO somehow register its availability so
that another driver can find and access it?  The "resource" may be a
callable interface, it doesn't really matter, I'm just wondering if the
current rman stuff could be leveraged to help make the connection
between unrelated devices.   I think that implies that there would have
to be something near the root of the hiearchy willing to be the
owner/manager of dynamic resources.

-- Ian


_______________________________________________
freebsd-hackers@free... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@free..."