ocpbus(4)

[M. Warner Losh]

In message: <200712281500.55155.jhb at freebsd.org>
            John Baldwin <jhb at freebsd.org> writes:
: On Friday 28 December 2007 02:16:43 pm Marcel Moolenaar wrote:
: > > : Q1: Do people think it's worthwhile to pursue a generic
: > > :      ocpbus(4) definition?
: > >
: > > Generally, yes.  In fact, I've done a bunch of things with what I've
: > > called obio (On Board I/O) that does similar things, but relies
: > > entirely on hints to do the job.  Since that's how we do things
: > > elsewhere, this seems like a reasonable approach.  If we move to doing
: > > things differently, then we can talk about that.
: > 
: > Hints can be used to implement the device tree or
: > device list, but is rather limited. I'd like us to
: > implement something richer in the future. For that
: > reason I don't want to expose hints to the driver,
: > but rather abstract the implementation of the device
: > tree or the device list behind IVARs. That makes it
: > possible to implement the "bus" in many different
: > ways without having to change the device drivers that
: > attach to the bus.
: 
: So to jump in here.  I've been thinking more since the last hints debacle and 
: am thinking of replacing hints with the generic device metadata we'd 
: discussed some at the end of the last thread:
: 
: device.FOO.<property>=<value>
: 
: where any driver or unit wiring is a new property rather than encoded into 
: FOO's name.  Thus:
: 
: device.COM1.at=isa0
: device.COM1.irq=4
: device.COM1.port=0x3f8
: device.COM1.driver=sio
: device.COM1.unit=0
: 
: or some such.

How does one separate the topological information from the
proscriptive information?  Eg, is the irq=4 an instruction to the
driver to use IRQ 4 for the device (proscriptive), or is it an
instruction to the bus to help locate COM1 (topological).

: There would be a new-bus level framework to enumerate the various devices that 
: have properties and bus drivers would "claim" a device and bind it to a child 
: device_t.  Each bus could then expose the properties as it saw fit.  For 
: example, if you had this:
: 
: device.FOO.at=pci4.5.0
: device.FOO.vendor=0x5555
: device.FOO.device=0x1212

Same question here.  If the first one was 'device.FOO.at=pci' then
what would the other two things mean, especially if there was a
driver/unit forced for this device?

: then the PCI bus could use that to override what gets returned via the vendor, 
: device, and devid IVARs used in probing.
: 
: You could still implement the bus_enumerate_hinted_children() API using this 
: alternate backend.

Assuming one could clear up the ambiguity, yes.

: Also, fwiw I'm thinking of having a 'device' command in the loader that is a 
: bit of a frontend so you can do things like:
: 
: 'device COM1 at isa0 irq 4 console'
: 
: that might translate into setting 'at=isa0', 'irq=4', 'console=1'.

Again, the same questions: what parts of this are topological and what
parts proscriptive?

: I also think there might be a generic way to get at any properties associated 
: with a device_t by doing:
: 
: int	property_get_str(device_t dev, const char *name, char *buf,
: 	    size_t buflen);
: int	property_get_bool(device_t dev, const char *name, int *val);
: int	property_get_int(device_t dev, const char *name, int *val);
: 
: etc.
: 
: Maybe devprop_* instead, but you get the idea.

We already have similar interfaces to get the hinted properties...
What would the translation be.

Also, I think that even though this is mildly relevant for the ocpbus
discussion, we shouldn't let ourselves get sidetracked by it.

Warner