Browse Prior Art Database

STREAMS Transparent IOCTL Handling For Performance Improvement

IP.com Disclosure Number: IPCOM000013393D
Original Publication Date: 1999-Nov-01
Included in the Prior Art Database: 2003-Jun-18
Document File: 17 page(s) / 72K

Publishing Venue

IBM

Related People

Saurabh Desai: AUTHOR

Abstract

1. Introduction:

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 11% of the total text.

Page 1 of 17

STREAMS Transparent IOCTL Handling For Performance Improvement

1. Introduction:

---------

This disclosure is about improving STREAMS transparent ioctl process. The STREAMS subsystem is used to develop communication protocols, device drivers or pseudo device driver and it's defined in UNIX System V Release 4 Programmer's Guide. A Stream is a full-duplex processing data transfer path between a STREAMS driver in kernel space and a process in user space. In the kernel, a Stream is constructed by linking a Stream head, a driver, and zero or more modules between the Stream head and driver. When an application makes a system call with a STREAMS file descriptor, the Stream head routines are invoked, resulting in data copying, message generation, or control operations being performed. The Stream head is the only component in the Stream that can copy data between user space and kernel space.

2. Streams ioctl processing:

-------------------

The ioctl system call is used to perform I/O control operations on the Stream.

int ioctl(int fd, int command, ... /* arg */);

The particular control operation is identified by the command. The driver or modules usually process only one ioctl command at a time. There are two classes of ioctl commands used in STREAMS. One class is a command directed at a module or driver in the Stream. The other class is directed at the Stream head. This class consists of "generic" stream head ioctl commands and its processing is done entirely by the Stream head. The class of module and driver ioctl commands is further divided into two categories: I_STR and Transparent. This disclosure mainly talks about this type of ioctl.

2.1 I_STR ioctl processing:

------------------

The I_STR has a restricted format and restricted addressing for transferring ioctl-related data between the user and kernel space. The caller passes the address of the strioctl structure as the third argument to the ioctl, as:

struct strioctl str;

ioctl (fd, I_STR, &str);

The strioctl structure allows the user to specify one optional buffer to contain data to be sent along with the command. On success, data may be returned to the buffer. The Stream head translates the strioctl structure into a M_IOCTL type STREAMS message and sends it downstream to a module or the driver. This mechanism did not allow existing binary applications to use the ioctl with STREAMS-based drivers or modules since the command and data had to be massaged into the strioctl structure. Also, it did not support the use of more than one data buffer during ioctl processing. To solve these problems, Transparent ioctl is used.

2.2. Transparent ioctl processing:

-----------------------

This type of ioctl provides transparent support to applications developed before the introduction of STREAMS, and alleviates the need to recode and recompile the user level software to run over STREAMS files. The transparent mechanism also supports STREAMS applications that want to send ioctl data to a driver o...