Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 1356 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 1356.

Report 1356 Actions

    Problem Report Number 1356
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Test Suite Deficiency (TSD)
    Problem Resolution ID TSD.X.0638
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published 1997-02-03 08:00
    Product Standard Internationalised System Calls and Libraries Extended (UNIX 95)
    Certification Program The Open Brand certification program
    Test Suite VSU version 4.1.1
    Test Identification CAPIbase/readv 22
    Problem Summary TSD4U.00179 This test may fail on implementations where the input buffer is shared on pseudo-terminals and data is not transmitted until it is read.
    Problem Text
    In PG4U.00116 the following was offered as an explanation for
    the failure:

    This test was changed to use ptys, the previous version
    using ttys passed on our implementation. This test
    fails on our implementation because tcdrain() is different
    for ptys. The test forks a child process which
    writes some characters on the slave side, then does
    a tcdrain() which waits for character transmission
    to be completed. For ptys, completed transmission
    means that a read has been done on the characters
    on the master side, and the master sends an acknowlegment
    that all characters are read back to the slave. In this
    case, the transmission will never complete because there
    are no reads done on master side. In the meantime, the
    parent process is doing a wait which eventually times out
    and gives us the error. If the tcdrain() is removed from
    the test, it will complete and pass.

    The consultant's response below:


    We recommend this request be refused.

    Pseudo-terminals have the same behavior as terminals.

    The XBD describes a pseudo-terminal as follows:

    pseudo-terminal

    A pseudo-terminal provides the process with an interface that
    is identical to the terminal subsystem.

    The behavior of terminals is specified such that data can be written
    and transmitted prior to data being read. Section 9.1.5 Input
    Processing and Reading data states the following about the input
    queue:

    Each terminal device file has an input queue, associated with
    it, into which incoming data is stored by the system before
    being read by a process. The system may impose a limit,
    {MAX_INPUT}, on the number of bytes that may be stored in the
    input queue.

    In the test, the number of characters being written is far below
    POSIX_MAX_INPUT. Consequently, there should be no problem in transmitting
    the few characters into space available in input queue.

    We beleive the tcdrain() behavior described by the submitter is an
    implementation conformance issue.


    Additional commentary from the Implementor


    We still believe that testcase is in error, from XPG4 XBD the full
    definition of a psuedo-terminal is:


    " A pseudo-terminal provides the process with an interface that
    is identical to the terminal subsystem. A pseudo-terminal is composed
    of two devices, the master device and a slave device. The slave
    device provides processes with an interface which is identical
    to the terminal interface, although there need not be hardware behind
    that interface. Anything written to the master device is presented
    to the slave device as input and anything written on the slave device
    is presented as input on the master side."

    But more important, there are fundamental internal differences that are
    not addressed by this definition.


    The "classic" tty driver, one that drives physical asynchronous
    hardware, consists of a line discipline (ldterm), a driver top half which
    runs in the context of the application and provides application program
    interface for the open(), close(), read(), write(), and ioctl() system
    calls, and a driver bottom half which runs in the context of hardware device
    interrupts and provides the hardware-specific interface. This configuration
    is shown in Figure 1, below



    +-----------------+
    | application |
    +-----------------+
    application space
    -----------------------------------------------------
    kernel space
    +-------------------+
    | line discipline |
    +-------------------+
    |tty driver top half| application interface
    +----------------------+
    |tty driver bottom half| hardware interface
    +----------------------+
    |
    |
    +--------------+
    | device | physical hardware
    +--------------+




    Figure 1

    The pseudo-tty driver was written to allow users connected to a
    system by something other than asynchronous hardware to access applications
    which use the X/open application program interface and expect to be talking
    to a "classic" tty driver. The "slave" side of the pty device driver
    supports open(), close(), read(), write(), and ioctl() system calls from
    the application and is roughly equivalent to a tty driver top half. The
    "master" side of the pty device driver emulates the hardware interface and
    is roughly equivalent to a tty driver bottom half. The actual hardware
    emulation is provided by a daemon process, such as telnetd and rlogind,
    running in application space and providing the interface between the
    network device driver and the pty master side. This configuration is
    shown in Figure 2, below. Note that it takes both "sides" of the pty
    driver to make a complete driver.



    +-----------------+ +----------------------+
    | application | | daemon process |
    +-----------------+ +----------------------+
    application space
    -----------------------------------------------------
    kernel space
    +-------------------+
    | line discipline |
    +----------------------+------------------------+
    |pty driver slave side | pty driver master side |
    +----------------------+------------------------+

    Figure 2




    The XPG4 XSH page 642 for tcdrain() states: "The tcdrain() function waits
    until all output written to the object referred to by fildes has been
    transmitted." For tty drivers controlling physical hardware, this has usually
    been interpreted to mean that tcdrain() does not return until the tty driver
    has processed a transmit complete interrupt and found no more data available
    to be transmitted. That is, the tcdrain() does not return until the driver
    has done everything physically possible to ensure that the data has actually
    been transmitted to a device. If that device is in a state such that it
    will not accept data, sent the "busy" flow control indicator for example,
    then a tcdrain() call can hang indefinitely.
    The pty driver does not have a device to which to transmit the data,
    but it does have a daemon process emulating that device. Accordingly, a
    tcdrain() call to a pty driver should not return until the data has been
    "transmitted to a device" or read by the process providing that device
    emulation. If that process is not accepting data, not issuing a read()
    system call for example, then the tcdrain() call can hang indefinitely.

    Test Output
    TEST CASE: readv

    TEST PURPOSE #22
    A call to ssize_t readv(int fildes, const struct iovec
    *iov, int iovcnt) when the function is interrupted by
    a signal after it has successfully read some data
    shall return the number of bytes read.
    PREP: Read IOV_MAX system configuration
    PREP: Allocate and initialize I/O buffers
    PREP: Open and initialize the terminal files
    PREP: Write less than MIN bytes to the terminal
    ERROR: wait_for: Timed-out waiting for child to exit.
    PREP: Open and initialize the terminal files
    PREP: Interrupt the parent with a SIGINT
    TEST: An interrupted readv returns EINTR
    CLEANUP: Free iovec buffers
    22 FAIL

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    We agree this is a test suite deficiency in the test
    suite version(s) listed.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Test Suite Deficiency (TSD)
    Review Conclusion
    This is an agreed Test Suite Deficiency.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority