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

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 0293 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 0293.

Report 0293 Actions

    Problem Report Number 0293
    Submitter's Classification Specification problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0009
    Raised 1993-08-03 08:00
    Updated 2003-03-13 08:00
    Published 1993-08-17 08:00
    Product Standard Internationalised System Calls and Libraries (XPG4)
    Certification Program The Open Brand certification program
    Test Suite VSX4 version 4.2.4
    Test Identification POSIX.os/devclass/cfsetospee 3
    Specification System Interfaces and Headers Issue 4
    Location in Spec See Problem Text
    Linked Problem Reports VWG/012/063092, err.4.2.4.030, (in, old, sy
    Problem Summary PIN4.009 Reference to : VWG/012/063092 : err.4.2.4.030 : VSX 4.2.4 release note The problem: =========== The concept of "modem disconnect" is not defined by POSIX. The implementation of the test assumes that t...
    Problem Text
    Reference to : VWG/012/063092
    : err.4.2.4.030
    : VSX 4.2.4 release note

    The problem:
    ===========

    The concept of "modem disconnect" is not defined by POSIX. The
    implementation of the test assumes that the terminal device on which
    B0 is done will itself sense a modem disconnect without any interaction
    from elsewhere.

    The traditional interpretation of "modem disconnect", in UNIX and many
    other operating systems, is that it consists of a hand-shake. One end
    of the connection requests a disconnect by lowering its modem lines; the
    other end senses this 'disconnect request', and, when it is ready to do
    so, lowers its modem lines; the requesting end senses this lowering of
    lines as a 'disconnect confirmation'.

    This is a useful definition. It enables a controlled disconnection to
    take place with tidying up at both ends. I believe it is also how
    POSIX.1 expects the system to behave.

    - section 7.2.1.2 (quoted above) says that setting B0 should
    cause the modem lines to be un-asserted;
    - it further says that this will "normally" disconnect the
    line. I believe the normal situation it refers to is where
    the other end of the connection lowers its lines in response,
    completing the disconnection.

    The traditional UNIX implementation of "modem disconnect" is that A
    un-asserts its modem lines. B detects this, usually by its tty being
    a controlling tty, and the un-assertion of the incoming modem lines
    causing a SIGHUP. B then closes its tty with HUPCL true, causing its
    outgoing lines to be un-asserted. If A is also a controlling tty, it
    senses this 'disconnect confirmation' by raising a SIGHUP. Hence it
    is not the setting of B0 on a controlling tty which, of itself, causes
    a SIGHUP from that controlling tty; it is the fact that the 'other end'
    lowers its lines in response which would "normally" cause the SIGHUP.
    What this boils down to is that 'set B0' means 'un-assert the outgoing
    modem lines'; and that SIGHUP means 'the controlling tty's incoming
    modem lines have been un-asserted'.

    This test sets B0 on a controlling tty with nothing 'listening' to the
    other end of the loopback - nothing is reading the other end, and the
    other end is not a controlling tty so doesn't generate a SIGHUP. In a
    traditional UNIX implementation, the initiator's incoming lines will not
    get un-asserted, so a SIGHUP will not be generated.

    ICL has avoided this problem before by modifying our drivers so that they
    report a hangup whenever they see B0 being set. This gets past the test,
    but causes various problems - not least confusion for those people
    who are used to the normal implementation of modem disconnect. It also
    breaks those applications which make use of the disconnect handshake.
    After considerable study and thought I have come to the conclusion that
    the test suite is at fault, and should be corrected.


    The fix:
    =======

    A simple change to the test would enable it to fully match the assertion
    from POSIX.3 and test the definitions from POSIX.1 while fitting in well
    with the traditional implementation. The change is to set B0 on the
    loopback file rather than the terminal file. The test then becomes the
    first half of the handshake - one end un-asserts its outgoing modem
    lines; the other end detects this, and since it is a controlling tty it
    raises SIGHUP.

    Test Output
    Test Information:
    SIGHUP not received by controlling process

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    The comment regarding the transmission of the SIGHUP signal with an
    outgoing modem disconnect is implementation dependent. It is unclear
    whether it is necessary for the modem disconnect to be reflected prior to
    the transmission of the SIGHUP signal or whether this should be produced
    irrespective of the reflection of the modem disconnect. My view is that
    both the XPG and POSIX are unclear about this. Unfortunately, the only
    indication of the correct actioning of the disconnect request that an
    application can detect is the receipt of this signal. In normal applications
    this is not a problem, since the application is likely to be working over a
    true modem line rather than working with a loop back between two asynchronous
    ports, as the test suite does. While the proposed solution would result in
    the test passing, it would not accurately reflect the normal usage of
    modem disconnect and would devalue the usefulness of the test.

    A permanent interpretation is recommended in line with that previously granted
    for the same test in XPG3.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Permanent Interpretation (PIN)
    Review Conclusion
    A permanent interpretation is granted.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority