1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
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.
|
