Date: Sat, 30 May 1998 06:51:37 -0400 From: Matt Thomas <matt@3am-software.com> To: Doug Rabson <dfr@nlsystems.com> Cc: current@FreeBSD.ORG Subject: Re: FreeBSD/alpha status report (2) Message-ID: <199805301053.GAA05668@tecumseh.altavista-software.com> In-Reply-To: <Pine.BSF.3.95q.980530080644.15699Y-100000@herring.nlsystem s.com> References: <199805300519.XAA02620@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 03:16 AM 5/30/98 , Doug Rabson wrote: >I am not saying that there won't be a <machine/bus.h>. I am saying that I >don't think that all the chipset implementations need to implement it. If >I do a bus_space interface, I expect that it will be something like >i386/include/bus.h. It is possible that TurboChannel and TurboLaser boxes >with multiple PCI busses might provide their own implementation rather >than the generic one. That's misguided. The point of the bus_space and bus_dma is to hide the mechanics of the underlying bus from the driver. Even if the bus is simple, the point is to abstract it (so you would have a simple abstraction). As an example, I recently moved the DEC FDDI driver to bus_dma (it already used in bus_space) which allowed me to get it running under NetBSD/pmax but only fixing coherency bugs. This means this drivers is known to work on 3 difference architectures and 3 different buses. This would be almost impossible without bus_space and bus_dma. In a week or two, I should be able to confirm it works under NetBSD/arm32. -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt/ Nashua, NH Disclaimer: I disavow all knowledge of this message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805301053.GAA05668>