-
Notifications
You must be signed in to change notification settings - Fork 46
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 #116 (plus others), separate logical vs. network PDU buffers #137
Conversation
This draft PR is intended to let folks get a preview of what's to come here. Important thing missing at this point is the unit tests, at this point I have unit tests disabled because they are NOT updated to work with these FSW changes yet. Probably will need to take a stab at #87 first, which should make it easier. Happy to hear any feedback about the proposed changes, if anyone has time to review them, it would be helpful. |
c074b39
to
c295364
Compare
3ba734d
to
9d0cdc8
Compare
Improves the distinction between PDU data being actively interpreted or created during the PDU receive or transmit process, and the encoded form of that data. CF formerly treated the two as the same, directly referencing the encoded form of the data. This creates many repeated translations. Furthermore, it would sometimes write a modified value back to the packet in a partially-decoded form, so it was never clear what was in a given buffer at a given time (it could be native byte order or network byte order, in the same fields). This introduces a "logical" buffer which correlates to the CFDP buffer, but is used for all in-work or temporary value storage. All values in the logical buffer are normalized to the native machine, that is they are aligned properly and always in the correct byte order for the host, so they can be used as normal values without any need for translation. When it comes time to transmit data to/from the network, a dedicated Encode/Decode function is used, to translate the entire content from its native form to the network form, or vice versa. FSW should typically not access the encoded form of data, outside of the codec routines, except under very limited circumstances with good reason (such as dynamically updating the total_length field in the base header after encode).
9d0cdc8
to
98801ae
Compare
Updated for initial review (preview) ... This is currently focused on the proposed FSW changes. Right now this has the unit test build disabled because the FSW changes break it. Required unit test updates will be added on in an additional commit. |
CCB:2022-01-05 APPROVED
|
A significant cleanup and overhaul of CF unit tests to follow patterns that are more consistent with other CFE/OSAL test modules. Since the FSW change in this PR requires significant test updates to go with it, this replaces all the "cfdp" tests with new implementations where there is a 1:1 ratio between test functions and implementation functions. Ths also does some minor cleanup on the FSW side where needed for testability. Note that all stub files in this version are now directly generated using the tool provided with UtAssert. These generated stubs should not be modified.
4137c78
to
3acc447
Compare
Commit 3acc447 updates all the unit tests to work with the FSW changes here. Back up to 100%/100% function/line coverage for all modified modules. Noted some other issues along the way but those can be fixed separately (issues written). This is done now.... |
The latest commit also added a fix for #33, as the (new) unit tests also revealed the fact that this did a null dereference here. |
Improves the distinction between PDU data being actively interpreted or created during the PDU receive or transmit process, and the encoded form of that data.
CF formerly treated the two as the same, directly referencing the encoded form of the data. This creates many repeated translations. Furthermore, it would sometimes write a modified value back to the packet in a partially-decoded form, so it was never clear what was in a given buffer at a given time (it could be native byte order or network byte order, in the same fields).
This introduces a "logical" buffer which correlates to the CFDP buffer, but is used for all in-work or temporary value storage.
All values in the logical buffer are normalized to the native machine, that is they are aligned properly and always in the
correct byte order for the host, so they can be used as normal values without any need for translation.
When it comes time to transmit data to/from the network, a dedicated Encode/Decode function is used, to translate the
entire content from its native form to the network form, or vice versa.
FSW should typically not access the encoded form of data, outside of the codec routines, except under very limited
circumstances with good reason (such as dynamically updating the total_length field in the base header after encode).
Fixes #116
Fixes #71
Fixes #68
Fixes #37
Fixes #35
Fixes #34
Fixes #33
Fixes #28
Also related to #61, #91, #95, #129, #109 - makes progress toward those goals but more work still needed.