CVS difference for ais/ai-00357.txt

Differences between 1.8 and version 1.9
Log of other versions for file ais/ai-00357.txt

--- ais/ai-00357.txt	2004/09/10 00:43:33	1.8
+++ ais/ai-00357.txt	2004/09/14 01:25:57	1.9
@@ -2657,3 +2657,163 @@
 
 ****************************************************************
 
+From: Pascal Leroy
+Sent: Thursday, September  9, 2004  7:33 PM
+
+Well, this rule is bogus anyway because the "infeasible" case is already
+covered by the blanket statement about "impossible or impractical"
+features in 1.1.3(6).
+
+I disagree with the notion of adding optional features to the SNAs,
+because then "supporting the real-time annex" become a meaningless
+statement, or at least one that must be qualified by all sorts of
+additional information about the optional features.
+
+If we believe that AI 357 should be optional (and I am not necessarily
+disagreeing with that) we should create a new annex about advanced
+scheduling capabilities and put it there (together with the
+priority-specific stuff and round-robin, I guess).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, September 10, 2004  3:09 AM
+
+> Well, this rule is bogus anyway because the "infeasible" case is already
+> covered by the blanket statement about "impossible or impractical"
+> features in 1.1.3(6).
+
+I disagree. The point of adding that explicit implementation
+permission was precisely to signal that this particular feature
+is one that may well not be practical to implement. The idea
+benind 1.1.3(6) [AI 325 :-)] was to cover unusual cases. Something
+is wrong if we find that particular features are routinely
+not implemented and appealing to 1.1.3(6).
+
+> I disagree with the notion of adding optional features to the SNAs,
+> because then "supporting the real-time annex" become a meaningless
+> statement, or at least one that must be qualified by all sorts of
+> additional information about the optional features.
+
+That's rhetorical overkill here. We are talking about a small
+number of features (it appears that some people were not even
+aware of the existing practice since its scope is small :-)
+
+> If we believe that AI 357 should be optional (and I am not necessarily
+> disagreeing with that) we should create a new annex about advanced
+> scheduling capabilities and put it there (together with the
+> priority-specific stuff and round-robin, I guess).
+
+Seems overkill to me, but given these alternatives
+
+1. Junk the feature completely
+
+2. Keep it as some kind of secondary standard, like the old
+Ravenscar
+
+3. Keep it in a separate annex
+
+4. Put it in Annex D optional
+
+5. Put it in Annex D non-optional
+
+My preference would be for 2. I would also put the new
+priority specific stuff and round robin stuff there too.
+Why? Because this stuff has not been implemented or used,
+and I think it would be better to have some experience
+before it goes into the standard. The original Ravenscar
+document would have been premature as an addition to the
+standard. Instead it came out as a secondary standard
+and we gained valuable implementation and usage experience.
+
+I can also live with 1 or 4
+
+I dislike 3 (overkill, and I think you will get an annex
+that will be in danger of being ignored).
+
+I entirely reject 5.
+
+****************************************************************
+
+From: Alan Burns
+Sent: Friday, September 10, 2004  2:37 AM
+
+This general permission is current wording and is included in the new wording.
+I believe this makes it clear that applications need only support the new
+policies if they wish to, ie when a customer asks.
+
+
+Implementation Permissions
+
+Implementations are allowed to define other task dispatching policies, but
+need not support more than one task dispatching policy per partition.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, September 10, 2004  3:11 AM
+
+> I believe this makes it clear that applications need only support the new
+> policies if they wish to, ie when a customer asks.
+                            ^^
+You surely mean eg. You don't want to tell implementors to implement
+this *only* if customers ask!
+
+P.S. this confusion of ie for eg is so common that when we wrote
+our book on microprocessors, our copy editor said "you are the
+only authors I have worked with who use ie correctly. However,
+so many readers in the US mistake this for "for example" that
+I recommend eliminating all uses ... which we did :-)
+
+****************************************************************
+
+From: Alan Burns
+Sent: Friday, September 10, 2004  3:19 AM
+
+I meant ie just to overstate the case - of  course eg really.
+
+Does the permission wording eliminate your concerns?
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, September 10, 2004  4:53 AM
+
+Probably so, I have to read the entire statement in context
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, September 10, 2004  1:15 PM
+
+> Does the permission wording eliminate your concerns?
+
+No. The permission allows a vendor to insist that an entire partition use the
+same dispatching policy. One could argue that that permission means that an
+implementation doesn't have to support Priority_Specific_Dispatching, but I
+think that is stretching a rule to the breaking point. If we don't want to
+require such support, we should say so, in clear English, not hide it in some
+unrelated (and existing) permission. After all, we want to key users that such
+a feature is optional.
+
+Any, in any case, I don't see how it applies to a partition that is completely
+Round_Robin or EDF. Certainly, the permission does not say that an
+implementation doesn't have to implement language-defined policies, only that
+one such policy need be supported per partition. How could an implementation
+justify rejecting "pragma Task_Dispatching_Policy (Round_Robin);"? It certainly
+doesn't do anything that would trigger the permission.
+
+I know that you've said that these features are optional. In that case, there
+should be a clear statement to that effect in the wording, as there is with
+D.11(10). We do not want to confuse either the users nor the reviewers of the
+Amendment.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, September 10, 2004  4:34 PM
+
+For what it is worth, I agree with Randy.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent