CHAPTER 3

Networking and STREAMS

---

STREAMS ioctl Issues

- Transparent ioctls
- Well-Known ioctl Interfaces

Regular device drivers have user context in the ioctl(9E) call. However, in a STREAMS driver or module, the only guarantee of user context is in the open(9E) and close(9E) routines. Therefore you need to indicate the calling context, where data is used.

The notion of data models was introduced in Chapter 1, as well as new macros for handling data structure access. A STREAMS driver or module writer should use these ags and macros when dealing with structures that change size between data models.

A new set of flag values that represent the data model of the entity invoking the operation have been added to the ioc_flag field of the iocblk(9S) structure, the cq_flag of the copyreq(9S) structure, and the cp_flag of the copyresp(9S) structure.

The data model values encode is one of the three possibilities:

• IOC_ILP32
  
• IOC_LP64
  
• IOC_NATIVE

By looking at the data model flag field of the relevant iocblk(9S), copyreq(9S), or copyresp(9S) structures, the STREAMS module can determine the best method of handling the data.

---

Caution - The layout of the iocblk, copyreq, and copyresp structures is different between the 32-bit and 64-bit kernels. Be cautious of any data structure overloading in the cp_private, cq_private, or the cq_filler fields, since alignment has changed.

---

[TOP]

Transparent ioctls

Transparent ioctls are used from within modules to tell the stream head to perform a copyin() or copyout() on behalf of the module. The stream head must have knowledge of the data model of the caller in order to process the copyin/out properly. The user should use the ioctl macros as described in Chapter 1 when coding a STREAMS module that uses Transparent ioctls.

[TOP]

Well-Known ioctl Interfaces

Many ioctl operations are common to a class of STREAMS drivers or STREAMS modules. For example, modules that deal with terminals usually implement a subset of the termio(7I) ioctls. Similarly, drivers that deal with audio devices usually implement a subset of the audio(7I) interfaces.

No data structures have changed size as a result of the LP64 data model for either termio(7I) or audio(7I), so there should be no need to use any of the structure macros to decode any of these ioctls.

FIORDCHK

This ioctl returns the number of bytes to be read as the return value of ioctl itself. Even though FIORDCHK should be able to return more than MAXINT bytes, it is constrained to int by the type of the ioctl(2) function.

FIONREAD

This ioctl returns the number of data bytes, in all data messages queued, in the location pointed to by the arg parameter. The ioctl returns a 32-bit quantity on to both 32-bit and 64-bit applications, so code that is passing the address of a long variable needs to be fixed to pass an int as part of its 64-bit cleaning.

I_NREAD

The I_NREAD ioctl (streamio(7I)), is an informational ioctl that counts the data bytes, as well as the number of messages in the stream head read queue. The number of bytes in the stream head read queue is returned in the location pointed to by the arg parameter of the ioctl. The number of messages in the stream head read queue is returned as the return value of the ioctl.

Like FIONREAD, the arg parameter to the ioctl should be a pointer to an int, not a long. And like FIORDCHK, the return value is constrained to be less than or equal to MAXINT bytes, even if more data is available.

<< Previous | Contents

[TOP]