From owner-p4-projects@FreeBSD.ORG Fri Aug 22 12:55:35 2003 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 6C7F616A4C2; Fri, 22 Aug 2003 12:55:35 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE73316A4F1; Fri, 22 Aug 2003 12:55:33 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 894BE43FCB; Fri, 22 Aug 2003 12:55:32 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7MJtWwO033154; Fri, 22 Aug 2003 12:55:32 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.12.9/8.12.9/Submit) id h7MJtW1n033153; Fri, 22 Aug 2003 12:55:32 -0700 (PDT) (envelope-from marcel) Date: Fri, 22 Aug 2003 12:55:32 -0700 From: Marcel Moolenaar To: John Baldwin Message-ID: <20030822195532.GA32939@ns1.xcllnt.net> References: <20030822180604.GB849@dhcp42.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i cc: Perforce Change Reviews Subject: Re: PERFORCE change 36551 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2003 19:55:36 -0000 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