-
Notifications
You must be signed in to change notification settings - Fork 203
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
Fix #777 deprecate sb #998
Fix #777 deprecate sb #998
Conversation
|
Updates the unit tests, unit test support, and stubs to replace deprecated SB APIs with MSG APIs.
146fa01
to
8514efa
Compare
Update documentation to replace deprecated SB APIs with MSG APIs
Update the core software from the deprecated SB APIs to the MSG APIs.
int32 Status; | ||
CFE_SB_MsgPtr_t EVS_MsgPtr; /* Pointer to SB message */ | ||
int32 Status; | ||
CFE_MSG_Message_t *MsgPtr; /* Pointer to SB message */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this comment should be change to not mention SB?
CFE_MSG_Message_t *MsgPtr; /* Pointer to SB message */ | |
CFE_MSG_Message_t *MsgPtr; /* Pointer to message */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Planning to address as part of #1009 cleanup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reviewed, and I'm honestly a little reluctant to go forth with this - we definitely have more to discuss here! I'm really not convinced we should be removing the CFE_SB_Msg_t
type. There is an important distinction between a message in its raw form and a message as its being transported via SB - like the analogy of a letter vs. an envelope going through the post office to be delivered to its destination. MSG lib should be dealing with letters while SB deals with envelopes. They are related, but different.
My concern is that this change set is undoing a lot of that distinction that was already there. I suppose we can put it back in #1009, or maybe we should hold off on at least the final commit in this change set.
FWIW - I am in agreement with the removal of the "clear" flag on init (first commit) and the removal of most "manipulator" routines - again with the analogy of an envelope, once it is "sealed" you can look at its basic stuff such as the address/delivery info (msgid, size) but not the stuff inside (timestamps, cmd codes, payload). So it makes sense that the SB functions that get/set internal message fields should be deprecated in favor of the MSG versions. But when dealing with messages in their delivery form we should still have an SB level API for that that works with SB defined types.
| Command Code | CFE_MSG_SetFcnCode | Command Only | | ||
| Checksum | CFE_MSG_GenerateChecksum | Command Only | | ||
| Time | CFE_SB_TimeStampMsg | Telemetry Only | | ||
| Time | CFE_MSG_SetMsgTime | Telemetry Only | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "applicability" column is a bit confusing now - Since the MSG module allows users to customize their headers - a user can now invent their own headers that have a checksum on every packet type and/or timestamps on commands, etc.
So "applicability" is always implementation defined now ... whats listed here is applicability when using the included "msg" implementation.
CFE_SB_CLEAR_DATA); | ||
CFE_MSG_Init((CFE_MSG_Message_t *) SAMPLE_AppData.BigPktPtr, | ||
SAMPLE_BIG_TLM_MID, | ||
SAMPLE_BIGPKT_MSGLEN); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Casting here is not desirable. We really shouldn't be documenting typecasts like this as the "recommended" way of doing things. I recognize that this was a preexisting issue in the docs though - and its just updated here.
Maybe this will also be affected by #1009 -- but we really should have a pattern that does not require casting when calling the basic APIs.
@astrogeco can we move forward with this one? Maybe create a new issue for the documentation and fix it later. |
Describe the contribution
Fix #777 - see issue for deprecated elements
Testing performed
Built and ran, enabled telemetry, checked noops. Unit tests built and passed.
Expected behavior changes
None
System(s) tested on
Additional context
#777
Third party code
None
Contributor Info - All information REQUIRED for consideration of pull request
Jacob Hageman - NASA/GSFC