Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

timod(7m) [opensolaris man page]

timod(7M)							  STREAMS Modules							 timod(7M)

NAME
timod - Transport Interface cooperating STREAMS module SYNOPSIS
#include <sys/stropts.h> ioctl(fildes, I_STR, &my_strioctl); DESCRIPTION
timod is a STREAMS module for use with the Transport Interface ("TI") functions of the Network Services library. The timod module converts a set of ioctl(2) calls into STREAMS messages that may be consumed by a transport protocol provider that supports the Transport Interface. This allows a user to initiate certain TI functions as atomic operations. The timod module must be pushed onto only a stream terminated by a transport protocol provider that supports the TI. All STREAMS messages, with the exception of the message types generated from the ioctl commands described below, will be transparently passed to the neighboring module or driver. The messages generated from the following ioctl commands are recognized and processed by the timod module. The format of the ioctl call is: #include <sys/stropts.h> - - struct strioctl my_strioctl; - - strioctl.ic_cmd = cmd; strioctl.ic_timout = INFTIM; strioctl.ic_len = size; strioctl.ic_dp = (char *)buf ioctl(fildes, I_STR, &my_strioctl); On issuance, size is the size of the appropriate TI message to be sent to the transport provider and on return size is the size of the appropriate TI message from the transport provider in response to the issued TI message. buf is a pointer to a buffer large enough to hold the contents of the appropriate TI messages. The TI message types are defined in <sys/tihdr.h>. The possible values for the cmd field are: TI_BIND Bind an address to the underlying transport protocol provider. The message issued to the TI_BIND ioctl is equivalent to the TI message type T_BIND_REQ and the message returned by the successful completion of the ioctl is equivalent to the TI mes- sage type T_BIND_ACK. TI_UNBIND Unbind an address from the underlying transport protocol provider. The message issued to the TI_UNBIND ioctl is equivalent to the TI message type T_UNBIND_REQ and the message returned by the successful completion of the ioctl is equivalent to the TI message type T_OK_ACK. TI_GETINFO Get the TI protocol specific information from the transport protocol provider. The message issued to the TI_GETINFO ioctl is equivalent to the TI message type T_INFO_REQ and the message returned by the successful completion of the ioctl is equivalent to the TI message type T_INFO_ACK. TI_OPTMGMT Get, set, or negotiate protocol specific options with the transport protocol provider. The message issued to the TI_OPTMGMT ioctl is equivalent to the TI message type T_OPTMGMT_REQ and the message returned by the successful completion of the ioctl is equivalent to the TI message type T_OPTMGMT_ACK. FILES
<sys/timod.h> ioctl definitions <sys/tiuser.h> TLI interface declaration and structure file <sys/tihdr.h> TPI declarations and user-level code <sys/errno.h> system error messages file. Please see errno(3C). SEE ALSO
Intro(3), ioctl(2), errno(3C), tirdwr(7M) STREAMS Programming Guide DIAGNOSTICS
If the ioctl returns with a value greater than 0, the lower 8 bits of the return value will be one of the TI error codes as defined in <sys/tiuser.h>. If the TI error is of type TSYSERR, then the next 8 bits of the return value will contain an error as defined in <sys/errno.h> (see Intro(3)). SunOS 5.11 26 Mar 1993 timod(7M)

Check Out this Related Man Page

tirdwr(7M)							  STREAMS Modules							tirdwr(7M)

NAME
tirdwr - Transport Interface read/write interface STREAMS module SYNOPSIS
int ioctl( fd, I_PUSH, "tirdwr"); DESCRIPTION
tirdwr is a STREAMS module that provides an alternate interface to a transport provider which supports the Transport Interface ("TI") functions of the Network Services library (see Section 3N). This alternate interface allows a user to communicate with the transport proto- col provider using the read(2) and write(2) system calls. The putmsg(2) and getmsg(2) system calls may also be used. However, putmsg and getmsg can only transfer data messages between user and stream; control portions are disallowed. The tirdwr module must only be pushed (see I_PUSH in streamio(7I)) onto a stream terminated by a transport protocol provider which sup- ports the TI. After the tirdwr module has been pushed onto a stream, none of the TI functions can be used. Subsequent calls to TI functions cause an error on the stream. Once the error is detected, subsequent system calls on the stream return an error with errno set to EPROTO. The following are the actions taken by the tirdwr module when pushed on the stream, popped (see I_POP in streamio(7I)) off the stream, or when data passes through it. push When the module is pushed onto a stream, it checks any existing data destined for the user to ensure that only regular data mes- sages are present. It ignores any messages on the stream that relate to process management, such as messages that generate signals to the user processes associated with the stream. If any other messages are present, the I_PUSH will return an error with errno set to EPROTO. write The module takes the following actions on data that originated from a write system call: o All messages with the exception of messages that contain control portions (see the putmsg and getmsg system calls) are transparently passed onto the module's downstream neighbor. o Any zero length data messages are freed by the module and they will not be passed onto the module's downstream neigh- bor. o Any messages with control portions generate an error, and any further system calls associated with the stream fails with errno set to EPROTO. read The module takes the following actions on data that originated from the transport protocol provider. All messages with the exception of those that contain control portions (see the putmsg and getmsg system calls) are transparently passed onto the module's upstream neighbor. The action taken on messages with control portions will be as follows: o Any data messages with control portions have the control portions removed from the message before to passing the mes- sage on to the upstream neighbor. o Messages that represent an orderly release indication from the transport provider generate a zero length data message, indicating the end of file, which will be sent to the reader of the stream. The orderly release message itself is freed by the module. o Messages that represent an abortive disconnect indication from the transport provider cause all further write and putmsg system calls to fail with errno set to ENXIO. All further read and getmsg system calls return zero length data (indicating end of file) once all previous data has been read. o With the exception of the above rules, all other messages with control portions generate an error and all further sys- tem calls associated with the stream will fail with errno set to EPROTO. Any zero length data messages are freed by the module and they are not passed onto the module's upstream neighbor. pop When the module is popped off the stream or the stream is closed, the module takes the following action: o If an orderly release indication has been previously received, then an orderly release request will be sent to the remote side of the transport connection. SEE ALSO
Intro(3), getmsg(2), putmsg(2), read(2), write(2), Intro(3), streamio(7I), timod(7M) STREAMS Programming Guide SunOS 5.11 3 Jul 1990 tirdwr(7M)
Man Page