Date: Mon, 11 Oct 1999 22:22:03 +0200 (MET DST) From: Gerard Roudier <groudier@club-internet.fr> To: Randell Jesup <rjesup@wgate.com> Cc: "Matthew N. Dodd" <winter@jurai.net>, scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller Message-ID: <Pine.LNX.3.95.991011211622.403A-100000@localhost> In-Reply-To: <ybuu2ny15su.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11 Oct 1999, Randell Jesup wrote: > "Matthew N. Dodd" <winter@jurai.net> writes: > >On 9 Oct 1999, Randell Jesup wrote: > >> Sure. In this case, if someone had docs on the bus interface for a > >> 710-based card, and people had some real use for a driver for them (I > >> don't know if that's true), it probably wouldn't be hard to modify an > >> '810 driver to support it. I didn't have any real plans to do so when >=20 > >I've taken a look at the NCR driver and my conclusion, outside of any SI= M > >issues is that 2 things need to happen. > > > >1. The NCR driver needs to be converted to bus_space. > [snip] > >2. The NCR driver needs be converted to use newbus, not the legacy shims > > it is currently using. > [snip] > >If someone wants to start working on this I will make myself available f= or > >newbus related questions and will also provide EISA bus front ends for t= he > >various onboard and expansion 53c7xx based boards I've got laying around= =2E > > > >Since the 53c[78]xx chips either have onboad PCI interfacing logic, or > >make use of fairly standard bus interface logic I don't think that the > >actual bus specific bits will be anything more than bus_space and > >attention to proper alignment. >=20 > =09So, it sounds like it's certainly doable with some (but not major) > effort. >=20 > =09Here's the question then (Gerard's question): is it worth doing? > Would anyone have a use for this? While of limited utility, it would > help me understand how a FreeBSD driver/SIM is put together. 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.=20 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. 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).=20 =20 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). > =09The other possible thing I'm considering doing (since a couple of > the SIM's do have support for target-mode) is to build an IP transport You must distinguish between phase cognizant target mode and host target mode. What I intend to implement in the future is something that avoids stalling the phase engine as possible, thus host target mode. Note that if you just read the messages after selection, accept the command and disconnect prior to signaling the upper layer, then this host target mode will never stall the phase engine in normal situations when implemented with 53c8xx chips. This will allow to use both initiator and target mode on an HBA without wasting uselessly SCSI BUS bandwitch for the target mode part. As seen from SIM the handling of the target mode is in fact much simpler tham initiator mode, since the part that acts as a target has the baton in SCSI. So, a SIM that will only implement target mode should be significantly simpler than common ones that only implement initiator mode= =20 (given appropriate hardware).=20 What is not simple is to provide both modes from a SIM, without the support for the target mode adding too much complexity (making driver less reliable) and wasting too much resources. > on top of CAM2/3 target mode. I suspect this is more useful, especially > for people building high-reliability servers (that was why DEC was so > interested in target mode; several of the other people on the target-mode > subcommittee were from DEC, and implemented target-mode for this purpose)= =2E > Very high speed (short-distance) networking. Probably. G=E9rard. 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.LNX.3.95.991011211622.403A-100000>