Date: Tue, 17 Jun 2003 21:14:53 -0600 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Frank Durda IV <uhclem@FreeBSD.org>, mdodd@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 Message-ID: <9820000.1055906093@aslan.scsiguy.com> In-Reply-To: <m19ST6h-000MLTC@nemesis.lonestar.org> References: <m19ST6h-000MLTC@nemesis.lonestar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9820000.1055906093>