%     Registration       Block Devices and Transport Classes: Where are we    
%                                             going?                          
%  Proposal           James Bottomley (jejb@steeleye.com)                     
                                                        
A transport class is quite simply a device driver       
helper library with an associated sysfs component.      
Although this sounds deceptively simple, in practise it 
allows fairly large simplifications in device driver    
code. Up until recently, transport classes were         
restricted to be SCSI only, but now they can be made to 
apply to any device driver at all (including ones with  
no actual transports).                                  
                                                        
The need for a transport class comes into most device   
driver subsystems that drive a class of devices. SCSI   
is a really good example of this: We have a core set of 
APIs which are needed by every SCSI driver (whether     
Parallel SCSI, Fibre Channel or something even more     
exotic) to do with queueing commands and interpreting   
status codes. However, there were a large number of     
ancillary services which don't apply to the whole of    
SCSI, like Domain Validation for Parallel SCSI or       
target disconnection/reconnection for Fibre Channel.    
The sysfs exposure gives the user a well known way to   
control device parameters (like period and offset, for  
parallel SCSI) without having to develop a core SCSI    
API. Since a transport class has only a sysfs interface 
and a driver API, it is completely independent of the   
SCSI core. This makes the classes arbitrarily           
extensible and imposes no limit on how many may be      
simultaneously present.                                 
                                                        
This talk will examine the evolution of the transport   
class in SCSI, covering its current uses in Parallel   
SCSI (SPI), Fibre Channel (FC) and other transports     
(iSCSI and SAS), contrasting it with previous           
approaches, like CAM, and follow with a description of  
how the concept was freed from the SCSI subsystem and   
how it could be applied in other aspects of kernel      
development, particularly block devices.