Date: Tue, 31 Oct 2006 14:06:14 -0800 (PST) From: mjacob@freebsd.org To: "Matthew D. Fuller" <fullermd@over-yonder.net> Cc: freebsd-scsi@freebsd.org Subject: Re: CAM_NEW_TRAN changes-next set of changes ready for review Message-ID: <20061031135750.B21918@ns1.feral.com> In-Reply-To: <20061031214930.GZ17019@over-yonder.net> References: <7579f7fb0610281854l3ec600d7kf0a2cdf20fdcb838@mail.gmail.com> <7579f7fb0610282210p59de2123g379f0d4069bd1e42@mail.gmail.com> <45443C7F.5040508@samsco.org> <7579f7fb0610300801x4650cb3fgb93f662fbf7b4213@mail.gmail.com> <20061031115204.Y21918@ns1.feral.com> <20061031214930.GZ17019@over-yonder.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 31 Oct 2006, Matthew D. Fuller wrote: > On Tue, Oct 31, 2006 at 11:57:29AM -0800 I heard the voice of > mjacob@freebsd.org, and lo! it spake thus: >> >> This is the complete set of changes that remove the non-NEW_TRAN >> code from the kernel [...] > > For those of us following along at home, can you handwave a sentence > or two about what the difference is and how/if it will affect me? Hopefully not much at all (at present). The intent of this change is to make the CAM transport layer in the kernel a bit more flexible by splitting some of the internal pieces into protocol (e.g. "SCSI") and transport (e.g. "SAS" or "SPI" or "Fibre Channel") specific chunks. This allows for finer grained control and information depending upon the actual underlying device. For example, Fibre Channel devices are part of the XPORT_FC transport, thus have things like World Wide Names and Port IDs and what not. There is no mechanism at present to get that information programmatically to a user application. This change that is being put into place will enable that to occur, which will make less of a hack the multipath stuff I'm now working on. The user visible changes shouldn't be much unless there are user agents that issue XPT_PATH_INQ and XPT_GET_TRAN_SETTINGS/XPT_SET_TRAN_SETTINGS cam codes. In the base source tree only camlib and camcontrol do either. Some ports use them as well, but I don't believe that this will specifically break them at present. These changes, btw, have been around for years under the kernel option 'CAM_NEW_TRAN_CODE'. All I'm doing right now is making this the default and making sure that things don't fall over. -matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061031135750.B21918>