Date: Mon, 11 Oct 1999 20:21:51 -0400 (EDT) From: "Matthew N. Dodd" <winter@jurai.net> To: Gerard Roudier <groudier@club-internet.fr> Cc: Randell Jesup <rjesup@wgate.com>, scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller Message-ID: <Pine.BSF.4.10.9910112005450.480-100000@sasami.jurai.net> In-Reply-To: <Pine.LNX.3.95.991011211622.403A-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Oct 1999, Gerard Roudier wrote: > In my opinion, a driver (and driver writers) must be aware of the > actual BUS used by devices, since ordering rules and optimization > concerns depend on the actual BUS being used. A driver that works for > ISA/EISA and PCI without any code difference is likely either > sub-optimal or just broken for some of these BUSes. This let me think > that too much abstraction-mania for BUSes may lead to bad drivers in > the first place. In cases where one driver offers a number of bus attachments, the driver is usually constrained by a suboptimal design in the first place. Take the if_ep driver; ISA, EISA, MCA, and PCCARD (and we could probably make it work with 3c59X boards too, and a few of the early 3c9xx boards in compat mode.) Granted this is just a stupid PIO driven chip but the glue logic presents the hardware to us in such a manner that the physical bus isn't really relevant outside of the probe/attach phase. Most performance oriented SCSI devices are going to use a scatter/gather list chain type of interface for reading/writing blocks of data and this is something that bus_dma does well for any physical bus. While it would be nice to use a function pointer or something faster to avoid the per call test of bus_space I somehow doubt that 2 or 3 instructions per port access are going to kill you given that port or memory accesses are so much slower than processor instructions. > Some BUS abstraction allows to deal with machines that does not implement > the flat memory model as suggested by PCI. For these ones you have to > ensure that memory you want to DMA is DMAable and allow the system to > handle the corresponding resources that are obviously limited. > Abstractions for these sort of hacked hardware (generally due to the > history of that hardware) lead to useless overhead and code complexity on > simple machines that implement the flat memory model for PCI. I think your complaint is directed at the opaqueness of bus_dma, not any flaws in its concept. Why not ask for pointers or bitch about the doc instead of taking pot-shots at a code base that exists to help driver writers arrive at code that is easier to maintain and more portable. Remember, we're not just using bus_space/bus_dma to work around ancient hardware; we have to consider the Alpha, the PPC, the MIPS, the ARM, and whatever hacked up busses happen to be hanging off of those systems. > Having to ask a kernel abstraction for providing me a scatter list and > then having to rewalk it for it to conform with the expectations of > the hardware (sometimes modulo device errata) is something that makes > me pain in the ass to run on my Intel machine. So, even if I ever go > with some BUS abstractions for this kind of stuff, I will keep with > the legacy _simple_ way to do the same thing, conditionnally > compilable for my personnal use (as long as this legacy way will be > available, obviously). > > Same pain in the ass if, when doing MMIO I have to call something > that will not only do the memory access, but each time will test for > having to do IO or MMIO. This situation may get just ridiculous for > example for a device that only allows one of the IO methods (only MMIO > for example on PCI). Feel free to keep on avoiding kernel APIs and standardization and bodies of code which lend themselves to multiple consumers. Do it on the Linux side of the fence though; they seem to appreciate that sort of nonsense. (you did say 'for your personal use' though, so maybe Linux isn't as fond of this sort of thing as they used to be.) I would welcome discussion on how to avoid redundant testing in the bus_space/bus_dma code though. I'm sure everyone has a few items on their wishlist that should be added before the code is declared 'mature'. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9910112005450.480-100000>