From ajosey@rdg.opengroup.org Thu Apr 5 10:29:29 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 KAA83086 for ; Thu, 5 Apr 2001 10:29:23 +0200 (CEST) (envelope-from ajosey@rdg.opengroup.org) Received: by mailgate.rdg.opengroup.org; id AA27662; Thu, 5 Apr 2001 08:28:24 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:28 BST 2001 Received: (from ajosey@localhost) by skye.rdg.opengroup.org (8.9.3/8.8.7) id JAA00930; Thu, 5 Apr 2001 09:25:33 +0100 Date: Thu, 5 Apr 2001 09:25:33 +0100 From: Andrew Josey Message-Id: <1010405082532.ZM929@skye.rdg.opengroup.org> Reply-To: ajosey@rdg.opengroup.org (Andrew Josey) X-Mailer: Z-Mail (5.0.0 30July97) To: f.prindle@opengroup.org Subject: Finalised PASC 1003.1 Interpretation #121,123, Cc: stds-pasc-ieee-officers@ieee.org, sc22wg15@dkuug.dk Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.11010405082532.ZM929.rdg.opengroup.org" -- --PART-BOUNDARY=.11010405082532.ZM929.rdg.opengroup.org Content-Type: text/plain; charset=us-ascii To: Frank Prindle From: Andrew Josey, PASC Interpretations Functional Chair Reference: PASC 1003.1 #121, 123 Dear Mr. Prindle 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=.11010405082532.ZM929.rdg.opengroup.org Content-Description: Text Content-Type: text/plain ; name="pasc-1003.1-121" ; charset=us-ascii Content-Disposition: attachment ; filename="pasc-1003.1-121" X-Zm-Content-Name: pasc-1003.1-121 _____________________________________________________________________________ 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 #121 _____________________________________________________________________________ Interpretation Number: XXXX Topic: posix_trace_trid_eventid_open() Relevant Sections: Section 21.3.8.2 PASC Interpretation Request: ---------------------------- From: Frank Prindle 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 --PART-BOUNDARY=.11010405082532.ZM929.rdg.opengroup.org Content-Description: Text Content-Type: text/plain ; name="pasc-1003.1-123" ; charset=us-ascii Content-Disposition: attachment ; filename="pasc-1003.1-123" X-Zm-Content-Name: pasc-1003.1-123 _____________________________________________________________________________ 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 #123 _____________________________________________________________________________ Interpretation Number: XXXX Topic: 1003.1q errors Relevant Sections: Section 21.3.2.4 PASC Interpretation Request: ---------------------------- From: Frank Prindle Date: 2001 23 Jan ------------------------------------------------------------------------ 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): Draft 8 dated March 2000, Page 34, Section 21.3.2.4, Lines 470-472 Draft 8 dated April 2000, Page 35, Section 21.3.2.4, Lines 477-479 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): Note that the ENOMEM error for posix_trace_attr_init() is optional; that is, it need only be returned if the insufficient memory condition is detected. The corresponding ENOMEM error for pthread_attr_init() is mandatory; that is, it must be returned if it occurs, so it must be detected if it occurs. There are far too many optional error values specified throughout the standard, as compared to similar functions in other standards. I suspect the following errors, currently optional, should be mandatory: Draft 8 dated March 2000 Draft 8 dated April 2000 ------------------------ ------------------------ P34, L472 P35, L479 P36, L542 P37, L549 P39, L671 P40, L678 P42, L776 P43, L783 P48, L987 P49, L995 P50, L1070 P51, L1078 P50, L1073 P51, L1081 P50, L1077 P51, L1085 P51, L1115 P52, L1123 P53, L1182 P54, L1190 P54, L1235 P56, L1243 P54, L1237 P56, L1245 P56, L1274 P57, L1282 P56, L1276 P57, L1284 P58, L1347 P59, L1355 P59, L1397 P60, L1405 P59, L1399 P60, L1407 P61, L1450 P62, L1458 P63, L1556 P65, L1561 P63, L1559 P65, L1564 P63, L1562 P65, L1567 P64, L1566 P65, L1571 P64, L1568 P65, L1573 ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): Change the wording above the listed errors from "If the following condition(s) is(are) detected" to "If the following condition(s) occur(s)". (but review the list above for completeness and/or correctness) ------------------------------------------------------------------------ Interpretation response ------------------------ The standard is clear - an implementation is not required to detect or return and error indication for any of the errors specified above. However, the working group intended that implementations be required to detect many of these errors and return an error indication. The "if detected" terminology in many of these error descriptions was inadvertently carried forward from, for example, line 480 on page 35, or line 1411 on page 60, where it is legitimate. From the list above, however, several are correct as "if detected" based on precedent - that is, those which return EINVAL when an argument is invalid but no specific explanation of what constitutes invalid is specified (L549, 678, 783, 1190). See pthread_attr_setscope(), pthread_attr_setpolicy(), pthread_attr_setschedparam() for precedent regarding this incompletely specified type of error. This is a defect in the standard. Forward to sponsor with a recommendation to adopt the solution proposed by the submitter except do not change the "if detected" for the errors listed on lines 549, 678, 783, and 1190, since these do not specify testable criteria for invalidity of the argument(s). Rationale ------------- Francois Riche's response follows: It would make sense to make these changes for consistency with pthread library, for example pthread_attr_init() function. Notes to the Project Editor (not part of this interpretation): --------------------------------------------------------------- AGR D5 @ page 1434 line 29983 section posix_trace_clear() objection The same problem and action also applies to: page 1409 line 29504 [is for some reason already fixed in D5] page 1445 line 30363 page 1445 line 30365 page 1445 line 30370 page 1450 line 30498 page 1454 line 30616 page 1464 line 30810 page 1443 line 30282 page 1436 line 30036 page 1452 line 30561 page 1458 line 30724 page 1458 line 30726 page 1458 line 30728 page 1458 line 30731 Problem: There are far too many optional error values specified throughout the trace functions, as compared to other similar functions in the standards. The lines indicated reflect currently optionally detected error conditions that should be mandatory for implementations. Action: Change "may" on these lines to "shall". Forwarded to Interpretations Group: 25 January 2001 Proposed resolution: 21 March 2001 Finalized: April 5 2001 --PART-BOUNDARY=.11010405082532.ZM929.rdg.opengroup.org--