ocpbus(4)

[Marcel Moolenaar]

On Jan 2, 2008, at 10:03 AM, John Baldwin wrote:

> Agreed, and device.FOO would create an unknownX device (much like  
> unprobed
> PNPBIOS or ACPI-enumerated devices) with a set of properties (if the  
> bus impl
> uses properties to create devices and doesn't use them purely as  
> additional
> metadata).  For example, I actually figured that the default  
> device.hints type
> stuff for COM1 would look like this:
>
> device.COM1.at="isa"
> device.COM1.port="0x3f8-0x3ff"
> device.COM1.irq=4
> device.COM1.pnpid="PNP0500"

BTW: I like the port range.

> which is what you get with ACPI/PnPBIOS.  On i386/amd64 users would  
> probably
> wish to bind it using something like:
>
> device.COM1.driver="sio"
> device.COM1.unit=0
>
> but it wouldn't be required.  Note that it would be nice to just
> say 'device.COM1.unit=0' and not specify a driver at all, but that  
> would not
> be easy to implement in new-bus.

It can also cause conflicts. With uart and sio, you can
wire both to the same unit, based on the fact that sio
attaches to legacy devices by default and uart attaches
to puc by default. If you remove the sio driver, then you
end up with 2 wiring directives for the same unit that
now apply to the same driver. Explicitly specifying the
driver+unit makes it clear what is meant: if there are
multiple directives for the same driver+unit, then it's
obvious that the directives are conflicting and thus that
it's pilot error.

Anyway, back to hints: your new approach is not disliked
by me. It fits my concept for the most part. However, in
order to support embedded hardware, we need to extend the
syntax (like using a range for the I/O port). Extending
the syntax may involve some significant work; even to the
extend that we can call it a rewrite, even if we keep
calling it hints.

More examples: the e500 core can have up to 4 MACs. Each
MAC has 3 interrupts. We need to support this. Also, some
devices have multiple I/O resource ranges. This too needs
to be supported. If we can modify the current hints
slightly to support it than I'm happy. It's just that I
have not seen any consideration for it and could only
assume it would fall through the cracks.

Also, A syntax like:
	FOO {
		sub1=a
		sub2=b
	}

... can be considered syntactic sugaring, because it
can mean exactly the same as:
	FOO.sub1=a
	FOO.sub2=b

This too is exactly like hints. So, even a discussion
about syntax does not mean we need to toss out everything
we have and start from scratch.

The bottomline: I'm not arguing that we cannot end up with
something that looks like hints. I'm arguing that if we
take hints *as they are* and apply your tweaks, that we don't
solve all the problems we're having or know we will have.

More examples: I think we need to make hints conditional
so that they can be included in case they're needed, but
can be disabled/masked in case they're not (and more
specifically when they're wrong and fry your SoC). Since
hints as we have them today are unconditional, I can only
object to using hints because of the fact they are unconditional
and there's no intention to make them conditional.

Anyway: I don't mind if you decide to step away from this,
but I do think you're making a mistake in that case. If
anything, it's important that people keep arguing to make
sure that we find the right balance...

-- 
Marcel Moolenaar
xcllnt at mac.com