Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000729 [1003.1(2013)/Issue7+TC1] System Interfaces Objection Enhancement Request 2013-08-08 07:20 2013-08-08 07:20
Reporter Don Cragun View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Don Cragun
Organization IEEE PASC
User Reference Integrate 1003.26 into Issue 8
Section posix_devctl()
Page Number -
Line Number -
Interp Status ---
Final Accepted Text
Summary 0000729: Integrate posix_devctl() from standalone IEEE Std 1003.26 into the next revision of IEEE Std 1003.1
Description The POSIX Real-Time working group requests that IEEE Std 1003.26 (an approved stand-alone standard) be integrated into the next revision of IEEE Std 103.1. The Desired Action below was prepared by Michael GonzalezHarbour (the P1003.26 project editor) at the direction of the IEEE PASC Chair (Joseph Gwinn).

This new (to POSIX.1) interface is sponsored by IEEE PASC and is submitted by the PASC OR.
Desired Action 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

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

   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
a reference: 
    see XRAT Subclause B.2.12, "Device Control".
Tags issue8
Attached Files

- Relationships

There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2013-08-08 07:20 Don Cragun New Issue
2013-08-08 07:20 Don Cragun Name => Don Cragun
2013-08-08 07:20 Don Cragun Organization => IEEE PASC
2013-08-08 07:20 Don Cragun User Reference => Integrate 1003.26 into Issue 8
2013-08-08 07:20 Don Cragun Section => posix_devctl()
2013-08-08 07:20 Don Cragun Page Number => -
2013-08-08 07:20 Don Cragun Line Number => -
2013-08-08 07:20 Don Cragun Interp Status => ---
2013-08-08 07:46 Don Cragun Tag Attached: issue8

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker