From ajosey@rdg.opengroup.org Thu Apr 5 10:30:42 2001 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by dkuug.dk (8.9.2/8.9.2) with SMTP id KAA83110 for ; Thu, 5 Apr 2001 10:30:36 +0200 (CEST) (envelope-from ajosey@rdg.opengroup.org) Received: by mailgate.rdg.opengroup.org; id AA31093; Thu, 5 Apr 2001 08:29:41 GMT Received: from skye.rdg.opengroup.org [192.153.166.247] by smtp.opengroup.org via smtpd V1.38 (00/07/25 13:18:13) for ; Thu Apr 05 09:29 BST 2001 Received: (from ajosey@localhost) by skye.rdg.opengroup.org (8.9.3/8.8.7) id JAA00937; Thu, 5 Apr 2001 09:27:09 +0100 Date: Thu, 5 Apr 2001 09:27:09 +0100 From: Andrew Josey Message-Id: <1010405082708.ZM936@skye.rdg.opengroup.org> Reply-To: ajosey@rdg.opengroup.org (Andrew Josey) X-Mailer: Z-Mail (5.0.0 30July97) To: j.farley@opengroup.org Subject: Finalised PASC 1003.1 Interpretation #127-130 Cc: stds-pasc-ieee-officers@ieee.org, sc22wg15@dkuug.dk Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.11010405082708.ZM936.rdg.opengroup.org" -- --PART-BOUNDARY=.11010405082708.ZM936.rdg.opengroup.org Content-Type: text/plain; charset=us-ascii To: Joanna Farley From: Andrew Josey, PASC Interpretations Functional Chair Reference: PASC 1003.1 #127-130 Dear Joanna Subject: IEEE Standard 1003.1 Interpretations Enclosed is the official response for your request for an interpretation of IEEE Standard 1003.1. This response was developed and approved by the members of the 1003.1 Interpretations Committee. To obtain an understanding of the PASC Guidelines for interpretations and their classifications please read http://www.pasc.org/interps/ Please can you confirm receipt of this electronic mail message within ten working days, please carbon copy your response to the IEEE (stds-pasc-ieee-officers@ieee.org) Sincerely, Andrew Josey PASC Functional Chair Interpretations Enclosures Cc: IEEE PASC Officers, SC22 WG15 ----- Andrew Josey The Open Group PASC FC Interpretations Apex Plaza,Forbury Road, Email: a.josey@opengroup.org Reading,Berks.RG1 1AX,England Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110 PASC Interpretations Web Site: http://www.pasc.org/interps/ or http://pasc.opengroup.org/interps/ --PART-BOUNDARY=.11010405082708.ZM936.rdg.opengroup.org Content-Type: text/plain ; name="pasc-1003.1-127" ; charset=us-ascii Content-Disposition: attachment ; filename="pasc-1003.1-127" X-Zm-Content-Name: pasc-1003.1-127 _____________________________________________________________________________ Notice: This is an unapproved draft PASC interpretation. Use at your own risk. Please direct any questions to a.josey@pasc.org _____________________________________________________________________________ PASC Interpretation reference 1003.1-96 #127 _____________________________________________________________________________ Interpretation Number: XXXX Topic: 1003.1q Relevant Sections: Section 21 line 1307 ... 1326 PASC Interpretation Request: ---------------------------- From: Joanna Farley Date: 2001 Feb 26 ------------------------------------------------------------------------ 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): 1 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): Section 21 line 1307 ... 1326 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): These lines appear to be copied from lines 1022 ... 1043 without modification. These lines refer to an incorrect function and to an incorrect argument name: References of function: posix_trace_trid_eventid_open on lines 1307 and 1317 Should be: posix_trace_eventid_open References of argument: event on lines 1310 and 1320 Should be: event_id ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): ------------------------------------------------------------------------ Interpretation response ------------------------ This is a defect in the standard, since the description of the posix_trace_eventid_open() function does not describe that function, and in fact that function is not described. Forward to sponsor with recommendation to replace "posix_trace_trid_eventid_open()" on lines 1307 and 1317 with "posix_trace_eventid_open()"; and replace "event" on lines 1310 and 1320 with "event_id". Rationale ------------- Francois Riche's response follows: This is perfectly right, it looks like a bad cut and paste from referenced lines. So I propose to adopt the proposed changes. For lines 1307 and 1317, change name of function from posix_trace_trid_eventid_open to posix_trace_eventid_open For lines 1310 and 1320, change name of argument from event to event_id. Notes to the Project Editor (not part of this interpretation): --------------------------------------------------------------- XSH D5: @ page 1442 line 30252,30255,30260,30263 section posix_trace_event() objection Problem: This descriptive text for posix_trace_eventid_open() uses the wrong function name and one wrong argument name. Action: Replace "posix_trace_trid_eventid_open() on lines 30253 and 30260 with "posix_trace_eventid_open()". Replace "event" on lines 30255 and 30263 with "event_id". Forwarded to Interpretations Group: 27 Feb 2001 Proposed resolution: 21 March 2001 Finalized: April 5 2001 --PART-BOUNDARY=.11010405082708.ZM936.rdg.opengroup.org Content-Description: Text Content-Type: text/plain ; name="pasc-1003.1-128" ; charset=us-ascii Content-Disposition: attachment ; filename="pasc-1003.1-128" X-Zm-Content-Name: pasc-1003.1-128 _____________________________________________________________________________ Notice: This is an unapproved draft PASC interpretation. Use at your own risk. Please direct any questions to a.josey@pasc.org _____________________________________________________________________________ PASC Interpretation reference 1003.1 #128 _____________________________________________________________________________ Interpretation Number: XXXX Topic: 1003.1q Relevant Sections: Annex B line 678, 683 PASC Interpretation Request: ---------------------------- From: Joanna Farley Date: 2001 Feb 26 ------------------------------------------------------------------------ 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): 1 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): Annex B line 678, 683 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): The example is a little bit misleading, because posix_trace_emptyset() is called before posix_trace_event_set_fill(). According to the specification (Section 21 line 1160,1161) it is not necessary to call posix_trace_emptyset() before posix_trace_event_set_fill(). ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): ------------------------------------------------------------------------ Interpretation response ------------------------ There is no defect in the standard, as the code shown will work properly in spite of the fact that the line cited is a NO-OP. Forward to sponsor with a recommendation that an additional comment be added before line 678: /*(not strictly required because posix_trace_event_set_fill() /*will ignore the prior contents of the event set.)*/ Rationale ------------- Francois Riche's response follows: This is perfectly right, there is no need to call posix_trace_emptyset() before the call of posix_trace_event_set_fill() as referenced in section 21 line 1160-1. This is a little bit confusing, but this generates no mistake, this is cautious programming style to avoid surprise with future modification of the code. I would agree to add a comment like this one: It is not required here before a call to posix_trace_event_set_fill() but it is a programming precaution. Notes to the Project Editor (not part of this interpretation): --------------------------------------------------------------- AGR D5 @ page 3483 line 7732 section B.2.11.3 objection Problem: The example is misleading because it implies that this posix_trace_eventset_emptyset() is required before the posix_trace_eventset_fill() that follows. It is not. Action: Add before this line the following comment lines /*(not strictly required because posix_trace_event_set_fill() /*will ignore the prior contents of the event set.)*/ Forwarded to Interpretations Group: 27 Feb 2001 Proposed resolution: 21 March 2001 Finalized: April 5 2001 --PART-BOUNDARY=.11010405082708.ZM936.rdg.opengroup.org Content-Description: Text Content-Type: text/plain ; name="pasc-1003.1-129" ; charset=us-ascii Content-Disposition: attachment ; filename="pasc-1003.1-129" X-Zm-Content-Name: pasc-1003.1-129 _____________________________________________________________________________ Notice: This is an unapproved draft PASC interpretation. Use at your own risk. Please direct any questions to a.josey@pasc.org _____________________________________________________________________________ PASC Interpretation reference 1003.1 #129 _____________________________________________________________________________ Interpretation Number: XXXX Topic: 1003.1q Relevant Sections: Section 21.3.8.1 line 1005-1010,1093 PASC Interpretation Request: ---------------------------- From: Joanna Farley Date: 2001 Feb 26 ------------------------------------------------------------------------ 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): 1 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): Section 21.3.8.1 line 1005-1010,1093 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): The argument type trace_eventid_t is used in several places when it is believed the type trace_event_id_t is intended. It is believed this mistake occurs in a number of other places in this standard. See B.21.5.6.2 line 528 ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): ------------------------------------------------------------------------ Interpretation response ------------------------ This is a defect in the standard, as the type name specified is not defined by this standard. The working group intended to use the type name: trace_event_id_t The misspelling is a typographical error. Forward to sponsor with recommendation to replace "trace_eventid_t" with "trace_event_id_t" on P49 L1006,1007,1009,1010; P51 L1094; P84 L528; and P110 in the index. Rationale ------------- Francois Riche's response follows: This is perfectly right. We find also this typo error in synopsis 21.3.8.1 page 49 and 21.3.9.1 page 51. This needs to be fixed everywhere it occurs. Notes to the Project Editor (not part of this interpretation): --------------------------------------------------------------- AGR D5 @ page 3479 line 7580 section B.2.11.3 objection Problem: posix_event_id_t is misspelled posix_eventid_t. Action: Replace "posix_eventid_t" with "posix_event_id_t". @ page 1444 line 30304 section posix_trace_eventid_equal() objection See also: page 1444 line 30305 page 1444 line 30306 page 1444 line 30310 page 1446 line 30389 page 1450 line 30476 page 1467 line 30846 Problem: posix_event_id_t is misspelled posix_eventid_t. Action: Replace "posix_eventid_t" with "posix_event_id_t". Forwarded to Interpretations Group: 27 Feb 2001 Proposed resolution: 21 March 2001 Finalized: April 5 2001 --PART-BOUNDARY=.11010405082708.ZM936.rdg.opengroup.org Content-Description: Text Content-Type: text/plain ; name="pasc-1003.1-130" ; charset=us-ascii Content-Disposition: attachment ; filename="pasc-1003.1-130" X-Zm-Content-Name: pasc-1003.1-130 _____________________________________________________________________________ Notice: This is an unapproved draft PASC interpretation. Use at your own risk. Please direct any questions to a.josey@pasc.org _____________________________________________________________________________ PASC Interpretation reference 1003.1 #130 _____________________________________________________________________________ Interpretation Number: XXXX Topic: 1003.1q Relevant Sections: Section 21.3.14 PASC Interpretation Request: ---------------------------- From: Joanna Farley Date: 2001 Feb 26 ------------------------------------------------------------------------ 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): Section 21.3.14 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): Extracting filters from trace logs: If the stream full policy is POSIX_TRACE_LOOP, it may happen, that the latest POSIX_TRACE_FILTER event is overwritten and that there is no POSIX_TRACE_FILTER event left in the trace stream. posix_trace_get_filter() doesn't work on trace logs (Section 21 lines 1378 ...1382). Thus, we can't reconstruct the event filters from the trace log. They are neither readable from an POSIX_TRACE_FILTER event (because there is no such event) nor from the meta data of the trace log (because there is no interface). Is this a correct interpretation of the standard? ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): ------------------------------------------------------------------------ Interpretation response ------------------------ The original question is not clear as to whether the concern is over a POSIX_TRACE_FILTER event being overwritten in a trace stream (because the policy is POSIX_TRACE_LOOP) or being lost from a trace log (when the trace stream policy is POSIX_TRACE_FLUSH and a log overrun occurs and events are lost from the log, one of which may be a POSIX_TRACE_FILTER event). We need some clarification on that. The former is not really an issue, because the filters associated with an active trace stream are retrievable out of band (posix_ trace_get_filter()). Therefore lets assume the latter (note however that POSIX_TRACE_LOOP policy plays no part in this unless the application is explicitly attempting to keep the trace stream flushed to a trace log with calls to posix_trace_flush(), since POSIX_TRACE_LOOP is not required to ever flush on its own): It is a correct interpretation that you can't reconstruct the trace filters from the trace log if it contains any POSIX_TRACE_OVERFLOW events, since one of the lost events may have been a POSIX_TRACE_FILTER event. This does not represent a defect in the standard, only an implementation's failure to be able to flush a highly active (FLUSHING) trace stream to a trace log without losing events, while the trace controller is changing the set of events filtered. Rationale ------------- Francois Riche's response follows: There are two levels of storage to memorize trace event identifiers and their arguments: - the first one is the trace stream, we can guess this one is real memory with small size and play the buffer role if it is associated with a trace log, - the second one is the trace log, we can guess this one is mass-storage, and the size is big enough considering the duration of tracing or the volume of trave events to memorize. Therefore, the strategy for these two types of trace event storage are generally different. Maybe as you imagine, the trace stream is looping, and the associated trace log is enough big to memorize your tracing sample. We guess the rate of trace events is not too high and the trace stream can be flushed to the trace log and all trace events can be flushed in the trace log before the trace stream loops. Because the POSIX_TRACE_FILTER is a trace event, when the trace stream is terminated, you can open the trace log, read the trace events, especially the POSIX_TRACE_FILTER events and know the set of trace event types even if this one has changed during the tracing sample. On the other hand, this is right, these trace events are lost in the trace stream, but stored in the trace log. In the case of a trace stream associated with a trace log, as you can read only the trace log, so you can retrieve the filter information. Forwarded to Interpretations Group: 27 Feb 2001 Proposed resolution: 21 March 2001 Finalized: April 5 2001 --PART-BOUNDARY=.11010405082708.ZM936.rdg.opengroup.org--