Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

nbuf(4) [ultrix man page]

nbuf(4) 						     Kernel Interfaces Manual							   nbuf(4)

       nbuf - select multiple-buffer operation to a raw device

       #include <sys/ioctl.h>

       ioctl(d, FIONBUF, count)
       int d;
       int *count;

       status=ioctl(d, FIONBDONE, buffer)
       int d, status;
       char **buffer;

       The I/O operations to raw devices are usually performed through a single buffer. This means that the issuing process must wait for a buffer
       to complete before the process can do anything else. An N-buffered I/O operation allows a process to begin an I/O  operation  and  continue
       doing  something else until the operation has finished. Once N-buffered operation is enabled, and acts as before except that buffer comple-
       tion is not guaranteed when the call returns.  If the operation starts without errors, and return as  if  the  operation  were  successful.
       That  is,  the  number of requested bytes have transferred and file pointers are updated.  On read operations, the process must not use the
       contents of the started buffer until the buffer actually completes.  On write operations, the process must not reuse the buffer	until  the
       operation  actually  completes.	A second is used to check the status of previously issued N-buffered read/write requests to determine when
       the operation has really completed.

       N-buffered I/O is used through a set of calls.  Setting the request argument in an call to FIONBUF enables count buffers to  be	used  with
       the raw device associated with the file descriptor d.  If count is zero, the N-buffered operation is terminated and any pending buffers are
       completed. A count less than zero is invalid.  Any started I/O buffer's status is checked by the call with  the	request  argument  set	to
       FIONBDONE,  with  the  address  of the buffer used as an argument.  The status field returns the actual byte count transferred or any error
       encountered on the I/O operation. The FIONBDONE ioctl must be called before re-using a buffer. FIONBDONE blocks the process until the given
       buffer  completes  (unless FNDELAY has been specified with at which point EWOULDBLOCK is returned).  In addition, a signal can be generated
       whenever a buffer completes, if FIOASYNC has been specified with

       The call is also useful in checking on the status of pending buffers.  The call returns immediately if less than count operations have been
       started on an N-buffered channel. Otherwise, blocks the specified amount of time for a buffer to become done. At this point, FIONBDONE must
       be used to return actual status of the pending buffer.

       The call fails if one or more of the following are true:

       [EBADF]	      The d argument is not a valid descriptor.

       [ENOTTY]       The d argument is not associated with a character special device.

       [ENOTTY]       The specified request does not apply to the kind of object which the descriptor d references.

       [EINVAL]       The request or argp argument is not valid. Returned for FIONBDONE, if requested buffer was never started. Also returned  for
		      FIONBUF, if this device does not support N-buffered I/O.

See Also
       fcntl(2), ioctl(2), select(2)


Check Out this Related Man Page

rmt(8)							      System Manager's Manual							    rmt(8)

rmt - Allows remote access to magnetic tape devices SYNOPSIS
rmt [debug-output-file] DESCRIPTION
The rmt command is started as a server process when requests from an rdump or rrestore call enter the system to operate a storage device through an interprocess communications connection. After the remote programs have finished, rmt exits and will be started again at the next request. The rmt command is normally invoked with an rexec or rcmd system call. This process performs the commands described in the following table and responds with a status indication to tell a user the result of the commanded process. When the rmt command is called with a filename specified as the debug-output-file parameter, all status responses are passed to the debug-output-file in ASCII and in one of two possible formats. Consequently, a system administrator can debug both software and hardware problems associated with previously issued backup commands to storage devices. Responses to successful commands are in the format: Anumber where A identifies a normal response, number is an integer that defines the number of the response as an ASCII integer, and is a newline in the C-language idiom. Responses to unsuccessful commands are in the format: Eerror_number error_message where E identifies a response to an error, error_num- ber is one of the possible error numbers values described in intro(2), error_message is the corresponding error-message string, which is output in response to a call to perror(3), and is a newline. Debug information returned by rmt is stored in the named debug-output-file file. The rmt command is called from the rdump or rrestore process with no file argument only when the debug-output-file parameter is specified. To activate the debug option of rmt your system administrator should rename the original rmt to rmt.ORG, for example, and create a new shell executable rmt that calls rmt.ORG debug-out- put-file. Note The rdump command starts remote server /usr/sbin/rmt or /etc/rmt on the client machine to access the storage medium. Another vendor's rdump command may fail because rmt is not located in /etc. To avoid this problem, it may be necessary to provide a symbolic link on the Tru64 UNIX machine pointing to /usr/sbin/rmt as shown in the following example: ln -s /usr/sbin/rmt /etc/rmt All numerical arguments of the following commands are transferred as ASCII strings: Opens the device, which must be a full pathname. The flag parameter is a flag value suitable for the open system call. When the device is successfully opened, the response is A0 . Closes the current open device. When this command is successful, the response is A0 . Performs a seek operation. The offset and whence parame- ters have the same significance as the offset and whence parameters of the lseek system call. When this command successfully completes, the response is An , where n has the same value returned by a normally successful lseek system call. Writes data to the device (see the O command above). The rmt command reads count bytes from the connection. This process is aborted when an EOF (End-of-File) is detected before the number of characters specified by count is transferred. The response to this command is An , where n is the number of characters writ- ten. Reads count bytes of data from the open device. When the value of count exceeds the size of the data buffer (10 kilobytes), the num- ber of characters read is truncated to the data buffer size. The rmt command then does the requested read operation. The response to this command is An , where n is the number of characters read. Performs an ioctl system call on the open device. The operation parameter is a value passed to the mt_op member of a type mtop structure for an MTIOCTOP ioctl (magnetic tape operation) command. Valid values for the magnetic tape operations are defined in the /usr/include/sys/mtio.h include file. The count parameter is the value to pass to the mt_count member of the type mtop structure and specifies the number of operations performed on the tape drive. The response to this command is An , where n is the count. Returns the status of the open device, which is obtained with a MTIOCGET ioctl system call. A successful response to this command is An , where n is the size of the status buffer, together with the contents of the status buffer in binary. FILES
Specifies the command path Describes the possible error numbers. A header file that defines magnetic tape operations. RELATED INFORMATION
Commands: rdump(8), rrestore(8). Functions: rcmd(3), rexec(3), open(2), ioctl(2) delim off rmt(8)
Man Page