|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
There are many global entries that allows you to jump from almost any state to IDLE. These cases simplifies the state machine.
Examples: pse_reset, iclass_lim_det, error_condition (the same for dual-signature).
The issue is about describing cycles of detection + classification until host decides to power on which is implementation specific and all the parts of it are already in the state machine.
Regard to this specific feature although it already allowed by the state machine by using pse_reset at any time we want (due to implementation specific reasons as this) we did add for clarity the states CLASSIFICATION_PRI and CLASS_PROBE_PRI and CLASS_RESET_PRI (and the same for secondary) just to allow using 3 class short events for detecting the class code in case of class 3 available power as we did for single-signature. In both cases, (single or dual) we can optionally go to IDLE by pse_reset).
Not clear why explicit exit is needed here. What will happen if we will not have it?
While I agree that we should not be making arcs for all POSSIBLE re-entries to the IDLE state, we should reserve the pse_reset path for ‘implementation specific’ entries, as it is described in the variable.
We SHOULD depict the paths for options specified in the standard in the state diagram – otherwise while there may be a path to interoperable behavior, if we don’t specify that behavior in the state diagram, the behavior described in the state diagram is incomplete.
Are there so many of these options specified in the standard that the state diagram becomes overly complex – I don’t think so, and I certainly hope not. That would be another issue in itself. Not capturing behavior specified in the standard in the state diagram isn’t the solution.
I agree with Lennart that “Arcs to IDLE should indicate mandatory transitions to IDLE”. The rest should be done by global pse_reset as we did for the high-level state diagram. Otherwise we will have incomprehensible state machine (return to IDLE from almost every state).
For the dual-sig state diagram there is a comment that addresses it i.e. by adding global pse_ready_pri/sec. See darshan_04_0917.pdf attached that addresses comments i-198 and i-269.
I’m not sure I agree with you. While you could go with a ‘generic’ return to IDLE for any one of a number of things,
if the standard is specifying a particular optional behavior that exits a specific state on a specific condition and returns to IDLE due to that, it should be specified as an arc.
There is a difference between ‘optional behavior’ and ‘proprietary’ or ‘implementation-specific’ behavior which is still compliant to the standard.
Where I am uncertain is how that return to idle is specified currently in the state diagram.
Right now, I see (page 125, top level diagram) a return from the test-states, and two entries – one from the disabled state, and one conditional on (pse_enable = enable) * (pse_reset + iclass_lim_det + error_condition)
If you are referring to entry into IDLE by means of pse_reset, then the definition of pse_reset wouldn’t imply using it for something like this. While it allows for “implementation-specific reasons require reset of PSE functionality”, that isn’t what Heath is specifying.
1. There is no need to add arcs to IDLE for optional behavior.
The PSE state diagram is at any time allowed to return to IDLE.
As such, the variable option_class_probe_only and the arc from CLASS_PROBE to IDLE are redundant.
2. Your logic for option_class_probe_only coming out of CLASS_PROBE is inverted to the meaning you assigned to it.
I really object to adding optional arcs to IDLE, since if we do this once, we open the floodgates to get arcs from every state to IDLE.
Arcs to IDLE should indicate mandatory transitions to IDLE.
On Fri, Sep 1, 2017 at 2:33 AM, Heath Stewart <00000855853231d4-dmarc-request@xxxxxxxx> wrote: