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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1671 Actions

    Problem Report Number 1671
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0475
    Raised 2000-10-24 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Internationalised System Calls and Libraries Extended V2 (UNIX 98)
    Certification Program The Open Brand certification program
    Test Suite VSU version 5.0.4
    Test Identification CAPIbase/poll 12
    Problem Summary PG4U.00178 This IR appeals against the refusal of PG4U.00177
    Problem Text

    In PG4U.00177 the consultants state:

    I can find nothing in the XSH5 specification to substantiate the claim
    that the pts driver doesn't have to queue the band 1 message "because
    it is not flow-controlled".

    We believe the consultants to be correct in their statement that they
    cannot find any text in XSH5 concerning bands not being flow-controlled,
    yet we believe that this request should be approved. The intent
    of the XSH5 text was to document System V Release 4 UNIX STREAMS
    historical practice, however, the text currently does not do so.

    All references from this point will come from the UNIX System V RELEASE 4
    Programmers Guide: STREAMS (Prentice Hall, 1990, ISBN 0-13-947003-4). We
    believe that this document accurately reflects current STREAMS programming
    practice and is the best indicator of proper STREAMS documentation.

    Chapter 5, 5-28, "Flow Control" states the flow control mechanisms for
    STREAMS. The first thing it states is that "high-priority" messages are
    not subject to flow control. We should not confuse this with the issue
    of bands -- "high-priority" has a special meaning, and such messages are
    not subject to bands. The documentation for putmsg() and putpmsg()
    describes how a "high-priority" message is created.

    Next, 5-28 through 5-30 describes how messages are processed. Each band
    may or may not be 'flow-controlled' -- in fact, specific APIs are described
    to test whether or not a specific band is flow-controlled. If it is,
    higher bands may or may or may not be flow-controlled, but if a given
    band is, all the lower bands are also (else lower band messages might
    get passed abead of higher-band, but flow-controlled, ones).

    There are other places in this book that describe things not in XSH5,
    but are required behaviors for a proper STREAMS implementation.

    The upshot of all this is simple: We feel that the XSH5 specification
    is there to promote portability, not to interfere with historical and
    proper STREAMS practice. We feel that STREAMS is incompletely
    specified in XSH5, and this should not be taken to inhibit proper
    STREAMS behavior in an otherwise-conforming system.


    Test Output
    TEST CASE: poll

    TEST PURPOSE #12
    A successful call to int poll(struct pollfd fds[],
    nfds_t nfds, int timeout) shall examine each element
    of the fds array for instances where the POLLWRBAND
    flag is set in the events member and data for a
    priority band greater than 0 which has been written to
    at least once can be written to the file descriptor
    specified by the fd member without blocking and shall
    set the POLLWRBAND flag in the corresponding revents
    member when found.
    PREP: Create two streams
    PREP: Open master pseudo tty
    PREP: Determine if pseudo tty is a stream
    PREP: Open slave side of pseudo tty
    PREP: Initialize the file descriptors and event structure
    TEST: poll returns correctly when no data has been written
    TEST: poll does not set POLLWRBAND when no data has been written
    PREP: Write band 0 data onto file descriptor
    TEST: poll returns correctly when only band 0 data has been written once
    TEST: poll does not set POLLWRBAND when only band 0 data has been written once
    PREP: Write band 1 data onto file descriptor
    TEST: poll returns correctly when band 1 has been written once
    ERROR: poll returned incorrect value
    Expected 1
    Received 0
    12 FAIL


    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    The consultant's comments in PG4U.00177 were in two parts. The first
    part questioned the validity of the submitter's rationale, but it was
    the second part (beginning "In any case ...") that was the main reason
    for recommending refusal. The submitter's new rationale concerns
    itself only with the first part, and does not address the second part
    at all.

    The crux of the matter is whether or not the condition "band 1 has
    been written to at least once" is satisfied at the point where the
    call to poll() is made that fails the test. Since putpmsg() is
    not an asynchronous call (like aio_write()), once a successful call
    to putpmsg() with the MSG_BAND flag set and band=1 has been made,
    then as far as the API is concerned band 1 has "been written to".

    If, as is claimed, the intention in XSH5 was to document SVR4 STREAMS
    historical practice, then referring to SVR4 documents for guidance
    in places where XSH5 seems unclear is certainly a valid thing to do.
    However, the XSH5 text is not unclear as regards the behaviour
    expected by the test, and moreover it *does* correspond with both
    historical and current SVR4 STREAMS practice (except for the issue
    identified in PIN4U.00057, but that concerns a different part of
    the test.)

    Unfortunately it is not possible to use the current test suite code
    to demonstrate that the behaviour of SVR4 STREAMS is the same as
    the behaviour expected by this part of the test, because the test
    terminates early when it encounters the failure associated with
    PIN4U.00057. However, by modifying the test so that it continues
    running after reporting the failures related to PIN4U.00057, the
    following results have been obtained:

    TEST: poll returns correctly when no data has been written
    ERROR: poll returned incorrect value
    Expected 0
    Received 1
    TEST: poll does not set POLLWRBAND when no data has been written
    ERROR: POLLWRBAND was set even when no data was written
    PREP: Write band 0 data onto file descriptor
    TEST: poll returns correctly when only band 0 data has been written once
    ERROR: poll returned incorrect value
    Expected 0
    Received 1
    TEST: poll does not set POLLWRBAND when only band 0 data has been written once
    ERROR: POLLWRBAND was set when only band 0 data was written once
    PREP: Write band 1 data onto file descriptor
    TEST: poll returns correctly when band 1 has been written once
    TEST: poll sets POLLWRBAND when band 1 data has been written once
    12 FAIL

    The modified test was run on two SVR4-based systems from different
    vendors, one fairly old and one recent. They both produced identical
    results. It can be seen from these results that the error reported on
    the submitter's system after the line

    TEST: poll returns correctly when band 1 has been written once

    does not occur with SVR4 STREAMS.

    Since the submitter's stated intention is for his system to follow
    historical SVR4 STREAMS behaviour, but the above test results show
    that SVR4 STREAMS behaviour is the same as the behaviour the test
    expects, not the same as the behaviour of the submitter's system,
    it is recommended that this request is refused.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion
    This request is refused.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority