Date: Sun, 06 May 2007 19:17:38 -0600 From: Scott Long <scottl@samsco.org> To: Matthew Jacob <lydianconcepts@gmail.com> Cc: Bernard Buri <berni@ask-us.at>, scsi@freebsd.org Subject: Re: Upcoming plans for CAM Message-ID: <463E7E32.2030603@samsco.org> In-Reply-To: <7579f7fb0705061004p2c460887w227aad91795604cd@mail.gmail.com> References: <4628E0DE.2090103@samsco.org> <46290AC6.9020608@ask-us.at> <46292245.3030900@samsco.org> <463D9AAF.4070006@ask-us.at> <463DE4E7.1070506@samsco.org> <7579f7fb0705061004p2c460887w227aad91795604cd@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Jacob wrote: > A couple of comments here from me...... > > a) Other than architectural cleanliness, what advantages to FreeBSD > will accrue to replacing the ata driver with CAM access? SAS controllers that expose SATA devices through STP need the upper SCSI layers to understand ATA. MPT is a bit unique in that it hides the STP, SATA, and ATA details and pretends that all the world is SCSI/SAS (for normal operation, I know that there's a special passthrough mode), but many other controllers do not. Secondly, I have plans for more transport independence than just ATA/SATA. iSCSI, SAS, and FC can all benefit from not being treated like SPI. ATA/SATA just provides a quick and high-bang-for-buck demonstration of the merit splitting up the transport and protocol support in CAM. There are other reasons as well that are better discussed in private. > > b) The NEW_TRAN code stuff is a way (not necessarily the cleanest) to > try and be able to carry transport related metadata related to a > periph. By and large the periph driver doesn't need to know transport > related details. The exceptions to this are quirks which can only be > safely derived from transport types and transport related values and > identifiers that system management (or GEOM0 wants to know about (and > really can only ask the periph driver about). My intention is to continue to use and extend the NEW_TRAN code. Transport details that need to be worked out involve things like the GET_TRANS and SET_TRANS operations. I'm still thinking through that in terms of cleanliness in the periphs. > > c) All of #b is orthogonal to whether you have one periph driver or > multiple periph drivers for the same fundamental 'type'. Perhaps the > Win2K approach of allowing for selective binding (filter drivers) > might be appropriate and would extend the current 'main' periph driver > (e.g., "sa") plus the pass driver. Right now, just about any periph can attach to a device. The pass driver isn't really a special case, it just allows itself to attach to all devices, whereas the other periphs look at the INQ info and are selective. I plan to allow this to continue. I don't know a whole lot about how filter drivers work in Windows, though. Do the filters stack on top of each other, or are they all peers on top of the same device? It might be interesting to better encapsulate the periph API and allow periphs to be loaded as modules (something that is close to working already). If filters are peers in Windows, so Windows provide any arbitration or protection between peers? > > d) Don't expect that ATA specific commands will just automatically > tunnel, no matter what CAM changes are made. Different direct SATA > controllers may have different requirements for being able to do > arbitrary non-read/write commands. Tunneling HBAs (like mpt(4)) don't > support the ATA passthrough CDB at all and instead require a special > request structure. If you're talking about STP, then that's basically the kind of thing that SIMs will have to support on their own. The periph will send an XPT_SCSI_IO or XPT_SATA_IO (or whatever other protocols come along) CCB to the SIM, and it'll be up to the SIM to either accept the CCB or not. The encapsulation details will be left to the SIM. Helper functions might be developed for common schemes like STP, just like there are helper functions for SBP now. Specifically for SATA controllers, all I'm expecting the driver to support is the IDENTIFY command and the various basic read/write commands. I don't know of any standard way for an ATA controller to support ATAPI without supporting the PACKET command, but that might be a detail left to the SIM anyways, I don't know yet. These are just my random thoughts as well, so don't take any oversights or misunderstandings from me as deliberate =-) Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?463E7E32.2030603>