Re: [802.3_MAINT] Summary of maintenance adhoc call on MAC interface
Shimon,
I wasn't suggesting changing the Pascal. Rather something like adding a state machine variable that we say goes true when function TransmitFrame returns. And I agree it is one way of fixing it.
And yes, this still doesn't resolve the basic issue of how the .request service primitive works. We would still need to add an explanation somewhere of what is intended. Possibly a text explanation is also the way to fix that one.
BTW, see 48.2.6.2.1 Transmit for 10GBASE-X for an example of where we include text saying what paces state diagram transitions instead of using a pacing variable on the transitions - "This state diagram makes exactly one transition for each transmitted ordered_set that is processed." The comparable state machine for 1000BASE-X has a variable indicating that the transmission of the ordered set was complete pacing each transition.
Pat
-----Original Message-----
From: Shimon.Muller@xxxxxxx [mailto:Shimon.Muller@xxxxxxx]
Sent: Thursday, July 31, 2008 1:49 PM
To: Pat Thaler
Cc: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_MAINT] Summary of maintenance adhoc call on MAC interface
> RE figure 4-6: The issue with the figure is the ambiguous
> meaning of calling a psuedo-Pascal function from a state
> machine state with a UCT exit condition.
Correct. This is the root of the problem. We are mixing our
traditional state-machine conventions with the Pascal rules,
and in this case the two do not work together.
> Some read it as an action that doesn't complete until the
> function returns a result (as a program would act when it
> made a function call). Others read it as the action being
> complete as soon as the function is called. Therefore you
> leave the state almost immediately. If read the second way,
> you could get another MA_DATA.request and enter the state
> to try to call Function transmitFrame again while transmit
> Frame is still processing the last call.
Right, and either one of them can be a valid interpretation.
Since this is a mix of a state-machine and Pascal, we do not
know which one should take precedence, unless we are explicit
about it.
> One way to make the state machine operation unambiguous
> would be to add an exit condition that keeps the machine
> in the GENERATE_TRANSMIT_FRAME state until TransmitFrame
> has returned a result.
That would be one way of fixing it. Unfortunately, as currently
defined, TransmitFrame does not return a good exit condition as
part of TransmitStatus that we could use. We would have to add
a global variable "transmit_Done" to it, but I am reluctant to
make any changes to the MAC Pascal. Every time we tried to fix
this, we opened another can of worms. Also, this would only
work if we define the primitive MA_DATA.request as persistent.
I don't believe this is specified anywhere, and it is another
major ambiguity.
The more I think about it, the more I am leaning towards just
documenting this behavior in a note somewhere in clause 4, where
we explain why it "just works".
Shimon.