The following document contains a plan for integrating the current
POSIX.26 standard into the 2013 version of POSIX.

POSIX.26 defines an application program interface for controlling
device drivers. Although it is based on the widely used ioctl() system
call, the interface is type-safe and has a fixed number of parameters.

The relevant references are:

IEEE Standard for Information Technology— Portable Operating System 
Interface (POSIX®)— Part 26: Device Control Application Program 
Interface (API) [C Language]

The Open Group Standard Base Specifications, Issue 7, 2013 Edition,
which is the same as the IEEE Standard for Information
Technology—Portable Operating System Interface (POSIX®) Base
Specifications, Issue 7

Action plan
-----------

1. Add the following text coming from POSIX.26, "Introduction", as a
new subclause 2.10 in XSH Chapter 2, "General Information":

    2.10. Device control.

    Realtime systems interact with their physical environment using a
    variety of devices (such as analog-digital converters,
    digital-analog converters, counters, and video graphic equipment),
    which provide a set of services that cannot be fully utilized in
    terms of read and/or write semantics. Traditional practice uses a
    single function, called ioctl(), to encapsulate all the control
    operations on the different devices connected to the system, both
    special or common devices. Developers of POSIX.1-2003 (ISO/IEC
    9945:2003, Information Technology—Portable Operating System
    Interface (POSIX®)), decided not to standardize this interface
    because it was not type safe, it had a variable number of
    parameters, and it had behaviors that could not be specified by
    the standard because they were driver-dependent. Instead,
    POSIX.1-2003 defined a device-specific application program
    interface (API) for a common class of drivers, Terminals; and it
    restricted the ioctl() function to control of STREAMS devices.

    Although the POSIX.1 solution for common classes of devices is the
    best from the point of view of application portability, there is
    still a need for a way to interact with special, or even common
    devices, for which developing a full standard API is not
    practical. The device control option standardized in POSIX.26 and
    now defined in this standard is a general method for interfacing
    to the widest possible range of devices, through a new service to
    pass control information and commands between the application and
    the device drivers.

    A driver for a special device will normally not be portable
    between system implementations, but an application that uses such
    a driver can be made portable if all functions calling the driver
    are well defined and standardized. Users and integrators of
    realtime systems often add drivers for special devices, and a
    standardized function format for interfacing with these devices
    greatly simplifies this process.

1. Add a new option to XBD containing the new functionality being
merged from POSIX.26. This implies:

   1.a. Add the following option to the Codes section 1.7.1 of XBD:
        DC  Device Control

        The functionality described is optional. The functionality
        described is also an extension to the ISO C standard.  

        Where applicable, functions are marked with the DC margin
        legend in the SYNOPSIS section.  Where additional semantics
        apply to a function, the material is identified by use of the
        DC margin legend.


   1.b. A new symbol corresponding to the Device Control option will need
   to be added to the list defined under "The system may support one
   or more options", in XBD subclause 2.1.3.1:
        _POSIX_DEVICE_CONTROL

   1.c. The new option should be described in XBD section 13, "headers", in
   the <unistd.h> header, under "Constants for Options and Option
   Groups", with the "DC" margin legend: 
       _POSIX_DEVICE_CONTROL
          The implementation supports the device control option. If
          this symbol is defined in <unistd.h>, it shall be defined to
          be −1, 0, or 20YYMML. The value of this symbol reported by
          sysconf( ) shall either be −1 or 20YYMML.

          Note: YYMM reflects the year and month of the approval of the
          version of the standard containing this option.

    1.d. Add a configurable system variable and the corresponding
    value to the sysconf() manual page 
        _POSIX_DEVICE_CONTROL      _SC_DEVICE_CONTROL


2. Add the general concept "special device" defined in 3.1.1 of POSIX.26 to
XBD chapter 4, "General Concepts".

3. Add the new header <devctl.h> to XBD Chapter 13, "Headers".
    Name
          <devctl.h> - Device control

    Synopsis
    DC    #include <devctl.h>
    
    Description
          The following shall be declared as functions and may
          also be defined as macros. Function prototypes shall be
          provided.

    DC      int posix_devctl(int fildes, int dcmd, 
    DC             void *restrict dev_data_ptr, size_t nbyte,
    DC             int *restrict dev_info_ptr);

          Inclusion of the <devctl.h> header may make visible all
          symbols from <sys/ types.h>.
    
4.  Add a new man page in XSH containing the function posix_devctl()
defined in POSIX.26 subclause 5.1.1. This man page is marked with the
margin legend DC.

5. Add the rationale for device control contained in Annex B of
POSIX.26 to a new subclause B.2.12 of XRAT (thus renumbering the current
B.2.12 into B.2.13). The title of this subsection is:
    B.2.12. Device Control

6. In the "Rationale" section of the new posix_devctl() man page, add
a reference: 
    see XRAT Subclause B.2.12, "Device Control".