PERFORCE change 36551 for review

[John Baldwin]

On 22-Aug-2003 Marcel Moolenaar wrote:
> On Fri, Aug 22, 2003 at 03:13:54PM -0400, John Baldwin wrote:
>> 
>> >> Yes.  For i386 definitely it would make sense to have a bus method
>> >> that bubbles back up to the nexus(4) and eventually calls the
>> >> MD interrupt code.  Maybe some kind of interrupt properties kobj
>> >> interface:
>> > 
>> > The impact of a seperate KOBJ interface is probably large. I can't
>> > think of a use of this object that's unrelated to the bus object.
>> > If we do have such an use, then it should probably be a seperate
>> > interface, otherwise I think we should just add new methods to the
>> > bus interface.
>> > 
>> 
>> My only concern is that I'm afraid this isn't a very MI interface,
>> but bus is probably an ok place for it for now.
> 
> Hmm.. Possibly.. I haven't given it that much thought. We could
> encapsulate this in a generic resource property method, which
> takes a pointer to an opaque type that's specific for the
> resource type. For irqs this is a struct with polarity, mode,
> CPU affinity, priority or maskability. Whatever we like.
> For memory I/O ranges this could be a struct which includes such
> things as coherence properties, cachability, speculatability or
> other features of hardware we're not likely going to use.
> For I/O port ranges this could be things like latencies or other
> chipset specific fodder for when I/O ports are emulated.
> The opaque types could be MI, MD or a mix like pcpu.
> 
> Thoughts?

If it's super abstract then it may become too obtuse to use.
I'd rather avoid a lockmgr() type interface.  An MD callout
in ACPI may be the best answer really.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/