Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 19fcae3d authored by Christoph Hellwig's avatar Christoph Hellwig Committed by Martin K. Petersen
Browse files

scsi: remove the SCSI OSD library 



Now that all the users are gone the SCSI OSD library can be removed as
well.

Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
Reviewed-by: default avatarJens Axboe <axboe@kernel.dk>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
parent 80f21213

Documentation/scsi/osd.txt

deleted100644 → 0
+0 −192
Original line number Diff line number Diff line 
The OSD Standard

================

OSD (Object-Based Storage Device) is a T10 SCSI command set that is designed

to provide efficient operation of input/output logical units that manage the

allocation, placement, and accessing of variable-size data-storage containers,

called objects. Objects are intended to contain operating system and application

constructs. Each object has associated attributes attached to it, which are

integral part of the object and provide metadata about the object. The standard

defines some common obligatory attributes, but user attributes can be added as

needed.



See: http://www.t10.org/ftp/t10/drafts/osd2/ for the latest draft for OSD 2

or search the web for "OSD SCSI"



OSD in the Linux Kernel

=======================

osd-initiator:

  The main component of OSD in Kernel is the osd-initiator library. Its main

user is intended to be the pNFS-over-objects layout driver, which uses objects

as its back-end data storage. Other clients are the other osd parts listed below.



osd-uld:

  This is a SCSI ULD that registers for OSD type devices and provides a testing

platform, both for the in-kernel initiator as well as connected targets. It

currently has no useful user-mode API, though it could have if need be.



osd target:

  There are no current plans for an OSD target implementation in kernel. For all

needs, a user-mode target that is based on the scsi tgt target framework is

available from Ohio Supercomputer Center (OSC) at:

http://www.open-osd.org/bin/view/Main/OscOsdProject

There are several other target implementations. See http://open-osd.org for more

links.



Files and Folders

=================

This is the complete list of files included in this work:

include/scsi/

	osd_initiator.h   Main API for the initiator library

	osd_types.h	  Common OSD types

	osd_sec.h	  Security Manager API

	osd_protocol.h	  Wire definitions of the OSD standard protocol

	osd_attributes.h  Wire definitions of OSD attributes



drivers/scsi/osd/

	osd_initiator.c   OSD-Initiator library implementation

	osd_uld.c	  The OSD scsi ULD

	osd_ktest.{h,c}	  In-kernel test suite (called by osd_uld)

	osd_debug.h	  Some printk macros

	Makefile	  For both in-tree and out-of-tree compilation

	Kconfig		  Enables inclusion of the different pieces

	osd_test.c	  User-mode application to call the kernel tests



The OSD-Initiator Library

=========================

osd_initiator is a low level implementation of an osd initiator encoder.

But even though, it should be intuitive and easy to use. Perhaps over time an

higher lever will form that automates some of the more common recipes.



init/fini:

- osd_dev_init() associates a scsi_device with an osd_dev structure

  and initializes some global pools. This should be done once per scsi_device

  (OSD LUN). The osd_dev structure is needed for calling osd_start_request().



- osd_dev_fini() cleans up before a osd_dev/scsi_device destruction.



OSD commands encoding, execution, and decoding of results:



struct osd_request's is used to iteratively encode an OSD command and carry

its state throughout execution. Each request goes through these stages:



a. osd_start_request() allocates the request.



b. Any of the osd_req_* methods is used to encode a request of the specified

   type.



c. osd_req_add_{get,set}_attr_* may be called to add get/set attributes to the

   CDB. "List" or "Page" mode can be used exclusively. The attribute-list API

   can be called multiple times on the same request. However, only one

   attribute-page can be read, as mandated by the OSD standard.



d. osd_finalize_request() computes offsets into the data-in and data-out buffers

   and signs the request using the provided capability key and integrity-

   check parameters.



e. osd_execute_request() may be called to execute the request via the block

   layer and wait for its completion.  The request can be executed

   asynchronously by calling the block layer API directly.



f. After execution, osd_req_decode_sense() can be called to decode the request's

   sense information.



g. osd_req_decode_get_attr() may be called to retrieve osd_add_get_attr_list()

   values.



h. osd_end_request() must be called to deallocate the request and any resource

   associated with it. Note that osd_end_request cleans up the request at any

   stage and it must always be called after a successful osd_start_request().



osd_request's structure:



The OSD standard defines a complex structure of IO segments pointed to by

members in the CDB. Up to 3 segments can be deployed in the IN-Buffer and up to

4 in the OUT-Buffer. The ASCII illustration below depicts a secure-read with

associated get+set of attributes-lists. Other combinations very on the same

basic theme. From no-segments-used up to all-segments-used.



|________OSD-CDB__________|

|                         |

|read_len (offset=0)     -|---------\

|                         |         |

|get_attrs_list_length    |         |

|get_attrs_list_offset   -|----\    |

|                         |    |    |

|retrieved_attrs_alloc_len|    |    |

|retrieved_attrs_offset  -|----|----|-\

|                         |    |    | |

|set_attrs_list_length    |    |    | |

|set_attrs_list_offset   -|-\  |    | |

|                         | |  |    | |

|in_data_integ_offset    -|-|--|----|-|-\

|out_data_integ_offset   -|-|--|--\ | | |

\_________________________/ |  |  | | | |

                            |  |  | | | |

|_______OUT-BUFFER________| |  |  | | | |

|      Set attr list      |</  |  | | | |

|                         |    |  | | | |

|-------------------------|    |  | | | |

|   Get attr descriptors  |<---/  | | | |

|                         |       | | | |

|-------------------------|       | | | |

|    Out-data integrity   |<------/ | | |

|                         |         | | |

\_________________________/         | | |

                                    | | |

|________IN-BUFFER________|         | | |

|      In-Data read       |<--------/ | |

|                         |           | |

|-------------------------|           | |

|      Get attr list      |<----------/ |

|                         |             |

|-------------------------|             |

|    In-data integrity    |<------------/

|                         |

\_________________________/



A block device request can carry bidirectional payload by means of associating

a bidi_read request with a main write-request. Each in/out request is described

by a chain of BIOs associated with each request.

The CDB is of a SCSI VARLEN CDB format, as described by OSD standard.

The OSD standard also mandates alignment restrictions at start of each segment.



In the code, in struct osd_request, there are two _osd_io_info structures to

describe the IN/OUT buffers above, two BIOs for the data payload and up to five

_osd_req_data_segment structures to hold the different segments allocation and

information.



Important: We have chosen to disregard the assumption that a BIO-chain (and

the resulting sg-list) describes a linear memory buffer. Meaning only first and

last scatter chain can be incomplete and all the middle chains are of PAGE_SIZE.

For us, a scatter-gather-list, as its name implies and as used by the Networking

layer, is to describe a vector of buffers that will be transferred to/from the

wire. It works very well with current iSCSI transport. iSCSI is currently the

only deployed OSD transport. In the future we anticipate SAS and FC attached OSD

devices as well.



The OSD Testing ULD

===================

TODO: More user-mode control on tests.



Authors, Mailing list

=====================

Please communicate with us on any deployment of osd, whether using this code

or not.



Any problems, questions, bug reports, lonely OSD nights, please email:

   OSD Dev List <osd-dev@open-osd.org>



More up-to-date information can be found on:

http://open-osd.org



Boaz Harrosh <ooo@electrozaur.com>



References

==========

Weber, R., "SCSI Object-Based Storage Device Commands",

T10/1355-D ANSI/INCITS 400-2004,

http://www.t10.org/ftp/t10/drafts/osd/osd-r10.pdf



Weber, R., "SCSI Object-Based Storage Device Commands -2 (OSD-2)"

T10/1729-D, Working Draft, rev. 3

http://www.t10.org/ftp/t10/drafts/osd2/osd2r03.pdf

MAINTAINERS

+0 −6
Original line number Diff line number Diff line
@@ -11385,12 +11385,6 @@ W: http://www.nongnu.org/orinoco/ 
S:	Orphan

F:	drivers/net/wireless/intersil/orinoco/



OSD LIBRARY and FILESYSTEM

M:	Boaz Harrosh <ooo@electrozaur.com>

S:	Maintained

F:	drivers/scsi/osd/

F:	include/scsi/osd_*



OV2659 OMNIVISION SENSOR DRIVER

M:	"Lad, Prabhakar" <prabhakar.csengg@gmail.com>

L:	linux-media@vger.kernel.org

drivers/scsi/Kconfig

+0 −2
Original line number Diff line number Diff line
@@ -1515,6 +1515,4 @@ source "drivers/scsi/pcmcia/Kconfig" 


source "drivers/scsi/device_handler/Kconfig"



source "drivers/scsi/osd/Kconfig"



endmenu

drivers/scsi/Makefile

+0 −1
Original line number Diff line number Diff line
@@ -150,7 +150,6 @@ obj-$(CONFIG_CHR_DEV_SG) += sg.o 
obj-$(CONFIG_CHR_DEV_SCH)	+= ch.o

obj-$(CONFIG_SCSI_ENCLOSURE)	+= ses.o



obj-$(CONFIG_SCSI_OSD_INITIATOR) += osd/

obj-$(CONFIG_SCSI_HISI_SAS) += hisi_sas/



# This goes last, so that "real" scsi devices probe earlier

drivers/scsi/osd/Kbuild

deleted100644 → 0
+0 −20
Original line number Diff line number Diff line 
#

# Kbuild for the OSD modules

#

# Copyright (C) 2008 Panasas Inc.  All rights reserved.

#

# Authors:

#   Boaz Harrosh <ooo@electrozaur.com>

#   Benny Halevy <bhalevy@panasas.com>

#

# This program is free software; you can redistribute it and/or modify

# it under the terms of the GNU General Public License version 2

#



# libosd.ko - osd-initiator library

libosd-y := osd_initiator.o

obj-$(CONFIG_SCSI_OSD_INITIATOR) += libosd.o



# osd.ko - SCSI ULD and char-device

osd-y := osd_uld.o

obj-$(CONFIG_SCSI_OSD_ULD) += osd.o