From owner-cvs-all@FreeBSD.ORG Tue Jun 17 20:14:55 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A8C937B401; Tue, 17 Jun 2003 20:14:55 -0700 (PDT) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2596B43FDD; Tue, 17 Jun 2003 20:14:54 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by aslan.scsiguy.com (8.12.9/8.12.8) with ESMTP id h5I3ErVR000374; Tue, 17 Jun 2003 21:14:53 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Date: Tue, 17 Jun 2003 21:14:53 -0600 From: "Justin T. Gibbs" To: Frank Durda IV , mdodd@FreeBSD.org Message-ID: <9820000.1055906093@aslan.scsiguy.com> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: nyan@jp.FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/matcd creativeif.h matcd.c matcd_data.h matcd_isa.c matcddrv.h options.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2003 03:14:55 -0000 > [1]mdodd@FreeBSD.ORG writes: > [1]inb()/outb() are not portable. > > Their use here doesn't need to be, for hardware like this that only exists > in the Intel PC world, and as far as I know, only in the ISA world. The idea behind bus_space is to provide an interface that will work on other systems that could use a given driver. The ISA bus happens to have (shamefully in my opinion) been replicated on other architectures including the Alpha and the PC98. Neither of these two platforms will function correctly in all cases if you use inb() or outb(). I understand that you are concerned about timing and such. Rest assured that, with the appropriate use of bus space, there will be no additional overhead for the i386. I encourage you to verify this for yourself by reviewing i386/include/bus_at386.h which includes the inline expansions of the bus_space methods. In your case, you will only be including "bus_pio.h" for your driver, so all of the memory mapped I/O support will magically vanish behind #ifdefs leaving just inb() and outb(). If the above doesn't seem a compelling argument, consider other developers that are in the same situation as yourself - looking through the source tree to determine the "sanctioned" methods for writing a device driver. The more drivers we have that follow the rules, the fewer examples we have left of "less than optimal" API conformance for people to trip over. -- Justin