CAM_NEW_TRAN changes-next set of changes ready for review

[mjacob at freebsd.org]

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 at 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