From fca59bea770346cf1c1f9b0e00cb48a61b44a8f3 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Sun, 25 Oct 2015 21:00:20 +0100 Subject: import of old now defunct presentation slides svn repo --- .../OLS2005/bottomley/bottomley-abstract.tex | 41 ++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 2005/flow-accounting-ols2005/OLS2005/bottomley/bottomley-abstract.tex (limited to '2005/flow-accounting-ols2005/OLS2005/bottomley/bottomley-abstract.tex') 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. -- cgit v1.2.3