From owner-freebsd-arch Sun Dec 16 9:28: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 8F77E37B416; Sun, 16 Dec 2001 09:27:57 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.5/8.11.5) with ESMTP id fBGHRug49634; Sun, 16 Dec 2001 10:27:56 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200112161727.fBGHRug49634@aslan.scsiguy.com> To: Mike Smith Cc: Thomas Moestl , arch@FreeBSD.ORG Subject: Re: Please review: changes to MI bus code for sparc64 In-Reply-To: Your message of "Thu, 13 Dec 2001 11:01:43 PST." <200112131901.fBDJ1hl02003@mass.dis.org> Date: Sun, 16 Dec 2001 10:27:56 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >> - make most functions in pci_pci.c non-static and add a new header >> (pcib.h) and an extension pointer to the softc to allow drivers for >> non-standard PCI-PCI bridges to use this code instead of duplicating >> most of it. > >I'm not sure that non-staticising this is the correct way to go; we need >a better way of subclassing things. Without knowing what you mean by >"non-standard", it's hard to see how calling these functions is useful. I have changes to new-bus in my tree that allow you to inherit and derive from opaque interfaces exported by other modules. I did this so that cardbus code could reuse the PCI code without having to know too much about the implementation details or PCI extern'ing every function. The unfortunate side effect of this is that every client of new-bus needs to be touched to understand the new method/interface declaration scheme. I've posted patches that allow me to use all the devices in my laptop here: http://people.FreeBSD.org/~gibbs/newbus_cardbus.diffs There is still lots of work to do (not as much code as could be reused is as of yet), but the patches will give you an idea of one possible way to address code reuse issues. It is also possible with this scheme to do an upcall to a parent interface's version of a method from an overridden one, but I haven't written the Perl glue (I have to pull out the book every time I write perl code) to generate the wrappers for this. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message