ocpbus(4)

[Marcel Moolenaar]

On Dec 28, 2007, at 12:00 PM, John Baldwin wrote:

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

Just a comment: there's a lot of value in taking a look at language
and DB theory. Both syntax and semantics can be very important
properties in the applicability and success of the new description.
Yes, we may want to be able to compile it into some binary form
for embedding it into the kernel...

For example: busses may nest and may need to be described. This
is especially true in the embedded space. The e500 has a local
bus within the CCSR, which may contain i2c busses for example.

Using the hints-way of describing hardware is just not going to
fly in that case, because you're still keying off of device names
and unit numbers. Let that be a consequence of the metadata, not
an integral part of... (device.COM1.* does exactly that).

FYI,

-- 
Marcel Moolenaar
marcelm at juniper.net