Abstract:
A system includes an initiator device including an initiator interface. A target device includes a target interface that communicates with the initiator interface via a protocol. The protocol supports commands being sent from the initiator device to the target device. The protocol does not support commands being sent from the target device to the initiator device. The target interface is configured to send a command to the initiator device via the protocol. The initiator interface is configured to execute the command.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims the benefit of U.S. Provisional Application No. 61/540,157, filed on Sep. 28, 2011. The disclosure of the above application is incorporated herein by reference in its entirety. 
    
    
     FIELD 
     The present disclosure relates to block device interfaces, and more particularly to systems and methods for creating bidirectional communication channels using block device interfaces. 
     BACKGROUND 
     The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent the work is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure. 
     A block device typically operates as a uni-directional device using a block device protocol. More particularly, an initiator device sends a command to a target device and the target device simply responds to the command. The block device protocol assumes that only the initiator device initiates the commands. For example only, a host computer may operate as the initiator device and a hard disk drive or a solid state drive may operate as a target device using a block device protocol. In this example, the block device protocol may include a small computer serial interface (SCSI). In contrast, hard disk drives and solid state drives may also operate as bi-directional, client-server devices when more sophisticated interfaces are used, such as a Peripheral Component Interconnect Express (PCIe) interface. 
     In the foregoing example, the initiator device typically sends commands to the target device using the block device protocol to read data from or write data to the hard disk drive or the solid state drive associated with the target device. The target device is not capable of sending commands back to the initiator device. However, the target device may be able to send status responses to the initiator device in response to the commands. 
     SUMMARY 
     A system includes an initiator device including an initiator interface. target device including a target interface that communicates with the initiator interface via a protocol. The protocol supports commands being sent from the initiator device to the target device. The protocol does not support commands being sent from the target device to the initiator device. The target interface is configured to send a command to the initiator device via the protocol. The initiator interface is configured to execute the command. 
     An initiator interface for an initiator device that communicates using a protocol includes a dispatcher module configured to generate a thread. The first thread sends a read command to read data at a predetermined storage location of a target interface of a target device via the protocol. The protocol supports commands being sent from the initiator device to the target device, and the protocol does not support commands being sent from the target device to the initiator device. An executor module is configured to generate an executor thread. When the dispatcher module receives data associated with the predetermined storage location of the target device, the dispatcher module is configured to treat the data as a command and forward the command to the executor module. The executor module is configured to execute the command. 
     A target device includes a target interface configured to communicate with an initiator device using a protocol and including a predetermined storage location. The target interface comprises a control device that is associated with the predetermined storage location of the target interface. The protocol supports commands being sent from the initiator device to the target device. The protocol does not support commands being sent from the target device to the initiator device. After receiving a read command for the predetermined storage location from the initiator device, the control device is thereafter enabled to selectively send a command to the initiator device. When the target device is ready to send the command to the initiator device, the control device is configured to send first data and second data to the initiator device. The first data identifies the command and the second data identifies the predetermined storage location. 
     A method includes using an initiator interface of an initiator device, communicating with a target interface of a target device via a protocol. The protocol supports commands being sent from the initiator device to the target device. The protocol does not support commands being sent from the target device to the initiator device. The method includes configuring the target interface to send a command back to the initiator device via the protocol and configuring the initiator interface to execute the command. 
     Further areas of applicability of the present disclosure will become apparent from the detailed description, the claims and the drawings. The detailed description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the disclosure. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
       The present disclosure will become more fully understood from the detailed description and the accompanying drawings, wherein: 
         FIG. 1  is a functional block diagram of an example of an initiator device and one or more target devices communicating via a block device protocol according to the present disclosure; 
         FIG. 2  is a functional block diagram of an example of a host device and one or more storage devices communicating via a block device protocol according to the present disclosure; 
         FIG. 3  is a functional block diagram of an example of an initiator interface and a target interface according to the present disclosure; 
         FIG. 4  is a functional block diagram of an example illustrating operation of the initiator interface and the target interface during a data fetch according to the present disclosure; 
         FIG. 5  is a flowchart illustrating an example of a method illustrating operation of the initiator interface and the target interface during a data fetch according to the present disclosure; 
         FIG. 6  is a functional block diagram of an example illustrating operation of the initiator interface and the target interface during a data sync according to the present disclosure; and 
         FIG. 7  is a flowchart illustrating an example of a method operating the initiator interface and the target interface during a data sync according to the present disclosure. 
     
    
    
     DESCRIPTION 
     In some applications using legacy devices, it is not possible to connect devices using a bi-directional interface such as a Peripheral Component Interconnect Express (PCIe) interface. For these applications, it may be desirable to have a target device send commands to an initiator device using a standard block device protocol. For example only, the target device may need to send a command to the initiator device to fetch data from another target device or to synchronize data with another target device. 
     Referring now to  FIG. 1 , an Initiator device  10  includes an initiator interface  12 . A first target device  15  includes a first target interface  14  that communicates with the initiator interface  12  using a block device protocol. A second target device  17  includes a second target interface  16  that also communicates with the initiator interface  12  using the block device protocol. 
     Referring now to  FIG. 2 , an example of the initiator device and the target device is shown. A host computer  20  includes an interface  23 . A cache  24  includes an interface  25  that communicates with the interface  23  using the block device protocol. A storage device  26  such as a hard disk drive or solid state drive includes an interface  27  that communicates with the interface  23  using the block device protocol. 
     The cache  24  caches data stored on the storage device  26 . In this situation, the interface  23  of the host computer  20  sends read/write commands and the cache  24  returns cached data. When a cache miss occurs, the interface  25  sends a “command” to the interface  23  using the block device protocol to fetch and return cache miss data from the storage device  26 , as will be described further below. 
     The present disclosure describes systems and methods that enable commands to be sent from the first target device  15  to the initiator device  10  using the standard block device protocol. The mechanism employs one or more control devices that are created by the first target device. While the foregoing description describes systems and methods utilizing two control devices, a reverse communication of commands can be implemented with additional or fewer control devices. 
     Referring now to  FIG. 3 , a host interface  30  includes a dispatcher module  34 , an executor module  36  and an initiator module  38 . The target interface  32  includes a target module  40 , a first control device  42  and a second control device  44 . The dispatcher module  34  generates a dispatcher thread that initiates commands. When a first command associated with a first predetermined storage location (Identified by a first address or a first address offset) of the first control device  42  is received (an open read command), the first control device  42  responds at that time or later (to close the open read command) with data (corresponding to a reverse command). 
     The dispatcher module  34  forwards the data/reverse command that is returned from the target interface to the executor module  36 , which generates an executor thread to execute the command. The executor module  36  executes the command. In some examples, the executor module  36  may then send a second command and/or data to a second predetermined storage location (identified by a second address or second address offset) associated with the second control device  44 . In this example, the first control device  42  is used as a device for delivering commands and control information in either direction. The second control device  44  is used to deliver data for operations initiated from the target interface  32 . 
     More particularly, the dispatcher module  34  issues a read of a predetermined storage location (identified by the first address or the first address offset) of the first control device  42 . The target interface  32  stores reverse direction commands in the first predetermined storage location associated with the first control device  42 . The target interface  32  completes the read command when a read of the predetermined storage location occurs. When the read command completes, the dispatcher module  34  forwards the command to the executor module  36 . 
     The executor module  36  executes the command. In some examples, executing the command may require fetching data from one or more remote targets and sending the fetched data to the target interface  32  by writing the data to the second predetermined storage location associated with the second control device  44 . In some examples, the executor module  36  also writes a command completion status to the first control device  42  at a third predetermined storage location. 
     The target interface  32  does not need to have real storage media for the one or more control devices such as the first and second control devices. The first and second control devices  42  and  44  can be purely logical constructs or pseudo device structures implemented in firmware. For example only, suitable data structures for keeping track of commands and data passed back and forth using this communication mechanism include radix trees, B-trees or any data structure that efficiently keeps track of control or data pages read or written from/to different devices offsets. 
     Referring now to  FIG. 4 , an example is shown to illustrate operation during a cache read. A dispatcher thread  64  sends an open read command to a first predetermined storage location at  70  of a first control device  74 . Sometime later, the first control device  74  sends data/reverse command corresponding to a fetch miss data command. The dispatcher thread  64  receives the completed open read from the first predetermined storage location and therefore interprets the returned data as a reverse command. The dispatcher thread  64  forwards the reverse command to an executor thread  68 , which executes the command (for example only, by fetching the data from one or more other target devices). The executor thread  68  writes the fetched data to a second predetermined storage location at  76  of a second control device  78 . The executor thread  68  also updates a fetch status at a third predetermined storage location at  80  corresponding to the first control device  74 . 
     Referring now to  FIG. 5 , an example flowchart illustrating operation performed by a host interface, a cache target and a hard disk drive target during a cache read are shown. The host interface initiates an open read command from a first control device at  110 . At  112 , if there is a hard disk drive read request, a dispatcher module sends a read request to the cache at  114 . At  116 , the cache determines whether there is a cache miss. If not, the cache returns data at  118 . If  116  is true, the first control device completes the open read command with a fetch miss data command at  122 . At  126 , the dispatcher module forwards the command to the executor module, which fetches data from the hard disk drive. At  130 , the executor module stores the fetched data in the second control device and updates the fetch status in the first control device. At  134 , the cache interface moves the data from the first control device to the cache. At  138 , the cache completes the original read request. 
     Referring now to  FIG. 6 , an example of operation performed during a cache sync are shown. A dispatcher thread  64  sends an open read command to a first predetermined storage location at  90  corresponding to a first control device  74 . Sometime later, the first control device  74  sends data/reverse command corresponding to a sync data command. The dispatcher thread  64  receives the completed read from the first predetermined storage location and therefore interprets returned data as a reverse command. The dispatcher thread  64  forwards the reverse command to an executor thread  68 , which executes the command. The executor thread  68  reads the sync data from a second predetermined storage location at  92  corresponding to a second control device  78 . The executor thread  68  syncs the data with one or more other target devices. The executor thread  68  also updates a sync status at a third predetermined storage location at  94  corresponding to the first control device  74 . 
     Referring now to  FIG. 7 , an example flowchart illustrating operation performed by a host interface, a cache target and a hard disk drive target during a cache sync are shown. The host interface outputs an open read command to a first control device at  150 . At  152 , the first control device determines whether data in the cache changed. If true, the first control device completes the open read command with a sync data command at  156 . At  160 , a dispatcher module receives a completed read command (corresponding to the open read command) from the predetermined storage location and forwards the sync command to the executor module. At  162 , the cache interface moves data from the cache to a second predetermined storage location in a second control device. At  166 , the executor module reads the sync data from the second control device and updates the hard disk drive. At  170 , the executor module updates the write/sync status to the first control device. 
     The foregoing description is merely illustrative in nature and is in no way intended to limit the disclosure, its application, or uses. The broad teachings of the disclosure can be implemented in a variety of forms. Therefore, while this disclosure includes particular examples, the true scope of the disclosure should not be so limited since other modifications will become apparent upon a study of the drawings, the specification, and the following claims. For purposes of clarity, the same reference numbers will be used in the drawings to identify similar elements. As used herein, the phrase at least one of A, B, and C should be construed to mean a logical (A or B or C), using a non-exclusive logical OR. It should be understood that one or more steps within a method may be executed in different order (or concurrently) without altering the principles of the present disclosure. 
     As used herein, the term module may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC); an electronic circuit; a combinational logic circuit; a field programmable gate array (FPGA); a processor (shared, dedicated, or group) that executes code; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, such as in a system-on-chip. The term module may include memory (shared, dedicated, or group) that stores code executed by the processor. 
     The term code, as used above, may include software, firmware, and/or microcode, and may refer to programs, routines, functions, classes, and/or objects. The term shared, as used above, means that some or all code from multiple modules may be executed using a single (shared) processor. In addition, some or all code from multiple modules may be stored by a single (shared) memory. The term group, as used above, means that some or all code from a single module may be executed using a group of processors. In addition, some or all code from a single module may be stored using a group of memories. 
     The apparatuses and methods described herein may be implemented by one or more computer programs executed by one or more processors. The computer programs include processor-executable instructions that are stored on a non-transitory tangible computer readable medium. The computer programs may also include stored data. Non-limiting examples of the non-transitory tangible computer readable medium are nonvolatile memory, magnetic storage, and optical storage.