The BROADCAST Received (x) messages
that are received in by the SL_CC0:Idle or the SL_CC1:ArbSel specifically
result in a Change Received confirmation. That confirmation will trigger
a discovery of the topology. A Broadcast (Asynchronous Event) should not
be causing any confirmation will trigger a discovery of the topology. There
are no other states in which a Broadcast results in a confirmation to a
management layer.
So the question is; Should the Broadcast
(Asynchronous Event) cause a notification to the management layer or is
it like other Broadcasts that are handled in some other fashion. If the
management layer does care then there will have to be a new confirmation
added to some state machines states (probably SL_CC0:Idle or the SL_CC1:ArbSel).
Then the next question is how far up the stack does it have to go. If it
only needs to go to the management layer, then using the same method as
change would work. But if the information needs to go up to the application
client then there is a problem in that SAM has no definition on how to
handle an asynchronous event.
Stephen FINCH <steve.finch@st.com> Sent by: owner-t10@t10.org
06/15/2006 04:05 PM
To
<t10@t10.org>
cc
Subject
BROADCAST ASYNCHRONOUS EVENT
* From the T10 Reflector (t10@t10.org), posted by:
* Stephen FINCH <steve.finch@st.com>
*
I noticed that in sas2r04 that we define BROADCAST (ASYNCHRONOUS EVENT)
and have a way to send it, but we don't allow anyone to receive it. I
think we need to add to the SL_CC state machine, in states CC0, CC1 and
CC2, the requirement for the CC state machine to send a ASYNCHRONOUS EVENT
RECEIVED confirmation to the management layer. This is how the reception
of a BROADCAST (CHANGE) is handled.
Or maybe we should make the change more generic and allow _any_ received
BROADCAST to cause a confirmation to be sent to the management layer with
a type argument?
Regards,
Steve Finch
STMicroelectronics
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo@t10.org