Driver attribute functions
If the driver wishes to provide driver specific attributes to the user it must implement the following functions:
globus_xio_driver_attr_init_t globus_xio_driver_attr_copy_t globus_xio_driver_attr_cntl_t globus_xio_driver_attr_destroy_t
|
callback interface This is the function signature of callbacks for the globus_xio_driver_open/close().
|
|
Data Callback interface. This is the function signature of read and write operation callbacks.
|
|
Create a driver specific attribute. The driver should implement this function to create a driver specific attribute and return it via the out_attr parameter. |
|
Copy a driver attr. When this function is called the driver will create a copy of the attr in parameter src and place it in the parameter dst. |
|
Destroy the driver attr. Clean up all resources associate with the attr. |
|
get or set information in an attr. The cmd parameter determines what functionality the user is requesting. The driver is resonsible for providing documentation to the user on all the possible values that cmd can be.
|
|
Initialize a server object. The driver developer should implement this function if their driver handles server operations (pasive opens). In the tcp driver this function should create a listener.
|
|
destroy a server. When this function is called the driver should free up all resources associated with a server.
|
|
Accept a server connection. The driver developer should implement this function if their driver handles server operations. Once the accept operation completes, the connection is established. The user still has an opertunity to open the link or destroy it. They can query the link for additional information on which to base the decision to open.
|
|
Query a server for information. This function allows a user to request information from a driver specific server handle.
|
|
destroy a link The driver should clean up all resources associated with the link when this function is called.
|
|
Open a handle. This is called when a user requests to open a handle.
|
|
transport open
|
|
this call *must* return an GLOBUS_XIO_ERROR_COMMAND error for unsupported command numbers. (use GlobusXIOErrorInvalidCommand(cmd)) Drivers that have reason to support the commands listed at globus_xio_handle_cmd_t should accept the xio generic cmd numbers and their driver specific command number. Do NOT implement those handle cntls unless you really are the definitive source. |
|
Close an open handle. This is called when a user requests to close a handle. The driver implemntor should clean up all resources connected to there driver handle when this function is called.
|
|
Read data from an open handle. This function is called when the user requests to read data from a handle. The driver author shall implement all code needed to for there driver to complete a read operations.
|
|
Write data from an open handle. This function is called when the user requests to write data to a handle. The driver author shall implement all code needed to for there driver to complete write operations.
|
|
Touch driver specific information in a handle object. pass the driver to control a specific driver pass NULL for driver for XIO specific cntls pass GLOBUS_XIO_QUERY for driver to try each driver (below current) in order |
|
Driver API finished accept. This function should be called to signal globus_xio that it has completed the accept operation requested of it. It will free up resources associated with the accept_op and potientially cause xio to pop the signal up the driver stack.
|
|
Driver API Open. This function will pass an open request down the driver stack. Upon completion of the open operation globus_xio will call the cb function, at which point the handle structure will be intialized and available for use. As soon as the function returns the handle is valid for creating other operations.
|
|
Driver API finished open. This function should be called to signal globus_xio that it has completed the open operation requested of it. It will free up resources associated with the op and potientially cause xio to pop the signal up the driver stack.
|
|
Driver API Create Operation. This function will create an operation from an initialized handle This operation can then be used for io operations related to the handle that created them.
|
|
Is Operation blocking. If the operation is blocking the driver developer may be able to make certian optimizations. The function returns true if the given operation was created via a user call to a blocking funciton. |
|
Driver API Close. This function will pass a close request down the driver stack. Upon completion of the close operation globus_xio will call the funciton pointed to by the cb arguement.
|
|
Driver API finished_close. The driver calls this function after completing a close operation on a driver_handle. Once this function returns the driver_handle is no longer valid.
|
|
Driver read. This function passes a read operation down the driver stack. After this function is called the op structure is no longer valid. However when the driver stack finishes servicing the read request it will pass a new operation structure in the funciton pointed to by cb. Finishe read can be called on the new operation received.
|
|
Finished Read. This function is called to signal globus_xio that the requested read operation has been completed.
|
|
EOF state manipulation. This function is used by drivers that allow multiple outstanding reads at a time. It can only be called on behalf of a read operation (while in the read interface call or the pass_read callback). Typical use for this would be to hold a driver specific lock and call this when an internal eof has been received. The read operation this is called on behalf of must be finished with an eof error or the results are undefined. In general, you should not have an eof flag in your driver. Use this call and globus_xio_driver_eof_received() instead. This is necessary to support xio's automatic eof resetting. If your driver absolutely can not be read after an eof has been set, then you will need your own eof flag. This call will typically only be used just before a finished_read() call.
|
|
EOF state checking. This function is used by drivers that allow multiple outstanding reads at a time. It can only be called on behalf of a read operation (while in the read interface call or the pass_read callback). Typical use for this would be to hold a driver specific lock (the same one used when calling globus_xio_driver_set_eof_received()) and call this to see if an eof has been received. If so, the operation should immediately be finished with an eof error (do not _return_ an eof error). This call will typically only be used in the read interface call.
|
|
Driver write. This function passes a write operation down the driver stack. After this function is called the op structure is no longer valid. However when the driver stack finishes servicing the write request it will pass a new operation structure in the funciton pointed to by cb. Finished write can be called on the new operation received.
|
|
Finished Write. This function is called to signal globus_xio that the requested write operation has been completed.
|
|
Finishes an operation and merge two op structures. (XXX not implemented yet) This function will join to operations together and signal globus_xio that it has completed. This is an advanced function. Most drivers will not require its use. This function takes an operation that was created by this driver and passed on to drivers lower on the stack and an operation that came in on the interface function (that has seen the top half of the stack) and joins them together. The purpose of this function is to join data descriptors that were prestaged and cached with those that have later come in at the users request. See the read ahead doc for more information.
|
about globus |
globus toolkit |
dev.globus
Comments? webmaster@globus.org