Defect Report concerning: IEEE Std. 1003.1-1996, ISO/IEC 9945-1:1996 - C API
Clause: Section 21.3.8.2
PASC Interpretation Ref: pasc-1003.1-121
Topic: posix_trace_trid_eventid_open()


This is an unapproved interpretation of PASC 1003.1-1996, ISO/IEC 9945-1:1996 - C API.

Use of the information contained in this unapproved document is at your own risk.

Last update: 10 April,2001


                                         1003.1-96  #121


_____________________________________________________________________________


     Interpretation Number:   XXXX
     Topic:              posix_trace_trid_eventid_open()
     Relevant Sections:  Section 21.3.8.2



PASC Interpretation Request: (Defect Report)
----------------------------

     Date: 2001 Jan 23


------------------------------------------------------------------------

 7  Defect Report concerning (number and title of International Standard
    or DIS final text, if applicable):

Additional Realtime Extensions: IEEE Std 1003.1q-2000

------------------------------------------------------------------------

 8  Qualifier (e.g. error, omission, clarification required):

3

Error=1 , Omission=2, Clarification=3

------------------------------------------------------------------------

 9  References in document (e.g. page, clause, figure, and/or table
    numbers):

Draft 8 dated March 2000, Page 48, Section 21.3.8.2, Line 1004
Draft 8 dated April 2000, Page 49, Section 21.3.8.2, Line 1012

------------------------------------------------------------------------

10  Nature of defect (complete, concise explanation of the perceived
    problem):


It is not at all clear that the function posix_trace_trid_eventid_open()
need be provided ONLY if the Trace Event Filter option is supported (in
addition to the Trace option). Is obtaining a trace event identifier for
a trace event name only necessary (in the trace controller process) for
purposes of specifying filters, or might the controller process need to
perform this mapping for some other purpose? If the latter is true, this
function should be provided by implementations that support the Trace
option but not the Trace Event Filter option.

------------------------------------------------------------------------

11  Solution proposed by the submitter (optional):

Either remove the dependency on the Trace Event Filter option for this
function, or provide in the rationale why it is not necessary if this
option is not supported.

------------------------------------------------------------------------

Interpretation response
------------------------
The standard is clear - the function posix_trace_trid_eventid_open() need be
provided only by an implementation that supports the Trace Event Filter option.
This is intentional, as the filtering of specified events is the only operation
which requires that the trace controller process obtain trace event identifiers
for a specified stream. The traced process needs these identifiers for many
other operations, but may obtain such identifiers by using the
posix_trace_eventid_open() function, which is not dependent on the Trace Event
Filter option.

The only references to posix_trace_trid_eventid_open() in the rationale are
in the context of event filtering. However, the following paragraph of
rationale is misleading (P93, L847-849):

 "The function posix_trace_trid_eventid_open() allows the application to get
  the system trace event type identifier back from the system, given its
  well-known trace event name. One possible use of this function is to qualify
  a filter."

Given that the only use of this function is for a controller process to qualify
a filter, forward this interpretation to the sponsor suggesting that this
paragraph of rationale be changed to:

 "The function posix_trace_trid_eventid_open() allows the application to get
  the system trace event type identifier back from the system, given its
  well-known trace event name. This function is useful only when a controlling
  process needs to specify events to be filtered."

Rationale
-------------

Francois Riche's response follows:
There are two functions to create new trace event identifiers:
- The posix_trace_eventid_open() usable only from the traced process
without trace stream identifier because this process may be not
traced at the time of the creation of the mapping between
trace event type identifier and the trace event name.
- The posix_trace_trid_eventid_open() usable only from the controller
process, a trace stream identifier is requested to identify where
this mapping should be memorized. If the controller process has no
need to control the set of event types, the fact to get back the
trace event type identifier for a given trace event name from
the traced process is useless. Therefore, there is no need to add
the implementation of a useless function for an implementation
not interested by event type set manipulation.
Please have a look to two examples that demonstrates:
- B.21.5.6.2, programming example for traced process,
- B.21.5.4.2, programming example for controller process.

On the other hand, I guess there is an indentation error from
line 1047 to 1063,there is a bad one level of indentation for
these lines. We have to suppress this indentation. The two other
functions are required for the analyzer process as you can see at
lines 437 (introduction).



Notes to the Project Editor (not part of this interpretation):
---------------------------------------------------------------
AGR D5

@ page 3487 line 7903-7904 section B.2.11.5 objection

Problem:
Rationale conflicts with posix_trace_trid_eventid_open() being part of the
Trace Event Filter option. It implies there are other uses for this function,
which cannot be the case if this option is not supported.

Action:
Replace "One possible use of this function is to qualify a filter." with
"This function is useful only when a controlling process needs to specify
specific events to be filtered."


Forwarded to Interpretations Group: 25 January 2001
Proposed resolution: 21 March 2001
Finalized: April 5 2001