Date: Sun, 6 May 2007 10:04:01 -0700 From: "Matthew Jacob" <lydianconcepts@gmail.com> To: "Scott Long" <scottl@samsco.org> Cc: Bernard Buri <berni@ask-us.at>, scsi@freebsd.org Subject: Re: Upcoming plans for CAM Message-ID: <7579f7fb0705061004p2c460887w227aad91795604cd@mail.gmail.com> In-Reply-To: <463DE4E7.1070506@samsco.org> References: <4628E0DE.2090103@samsco.org> <46290AC6.9020608@ask-us.at> <46292245.3030900@samsco.org> <463D9AAF.4070006@ask-us.at> <463DE4E7.1070506@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? 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). 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. 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. just a few random comments....
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7579f7fb0705061004p2c460887w227aad91795604cd>