Date: Fri, 22 Aug 2003 12:55:32 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: John Baldwin <jhb@FreeBSD.org> Cc: Perforce Change Reviews <perforce@FreeBSD.org> Subject: Re: PERFORCE change 36551 for review Message-ID: <20030822195532.GA32939@ns1.xcllnt.net> In-Reply-To: <XFMail.20030822151354.jhb@FreeBSD.org> References: <20030822180604.GB849@dhcp42.pn.xcllnt.net> <XFMail.20030822151354.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030822195532.GA32939>