1 files changed, 41 insertions, 0 deletions
diff --git a/2005/flow-accounting-ols2005/OLS2005/bottomley/bottomley-abstract.tex b/2005/flow-accounting-ols2005/OLS2005/bottomley/bottomley-abstract.tex
new file mode 100644
index 0000000..2387025
--- /dev/null
+++ b/2005/flow-accounting-ols2005/OLS2005/bottomley/bottomley-abstract.tex
@@ -0,0 +1,41 @@
+
+%     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.