Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[sfputilbase] Extend get_transceiver_change_event return event #50

Merged
merged 5 commits into from
Aug 6, 2019
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 7 additions & 3 deletions sonic_platform_base/sonic_sfp/sfputilbase.py
Original file line number Diff line number Diff line change
Expand Up @@ -1253,8 +1253,12 @@ def get_transceiver_change_event(self, timeout=0):
event. When timeout is non-zero, the function can also return when the timer expires.
When timer expires, the return status is True and events is empty.
:returns: (status, events)
:status: Boolean, True if call successful, False if not;
:events: dictionary for pysical port index and the SFP status,
status='1' represent plug in, '0' represent plug out like {'0': '1', '31':'0'}
:status: Boolean, True if call successful and no system level event/error occurred,
False if call not success or system level event/error occurred.
jleveque marked this conversation as resolved.
Show resolved Hide resolved
:events: dictionary for physical port index and the SFP status,
status='1' represent plug in, '0' represent plug out like {'0': '1', '31':'0'}
when it comes to system level event/error, the index will be '-1',
and status can be 'system_not_ready', 'system_become_ready', 'system_fail',

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

system_become_ready [](start = 48, length = 19)

From design perspective, system_become_ready is not necessary. If this event is really happen, the logic could continue run as a normal successful case or a timeout case. Then all the system level events are actually errors in concept.

Copy link
Collaborator

@stephenxs stephenxs Aug 2, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Qi,
I admit that in terms of state machine any normal event, like sfp module insertion or removal, can indicate the xcvrd has entered a normal state. However, an explicit notification can make the flow more clear. Without system_bdcom_ready we can hardly tell whether the xcvrd is in a normal state, monitoring the sfp modules' state, or waiting for ready.
In this sense, I suggest keeping this state.

like {'-1':'system_not_ready'}.
"""
return