Plan for Integrating DOT26 into DOT1
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
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 22.214.171.124:
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:
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
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".
<devctl.h> - Device control
DC #include <devctl.h>
The following shall be declared as functions and may
also be defined as macros. Function prototypes shall be
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
see XRAT Subclause B.2.12, "Device Control".