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

Fix #651, Use resource ID for memory pools #917

Merged

Conversation

jphickey
Copy link
Contributor

Describe the contribution

Instead of identifying a memory pool by its memory address, use a resource ID. IDs are a constant size, regardless of
whether the host machine is 32 or 64 bits.

  • IDs can be put into commands/telemetry and maintain a more consistent format with consistent alignment requirements.
  • IDs can be independently verified without dereferencing memory. Previously the only way to validate a memory pool was to read the address pointed to, which results in a segfault if the address was bad.

Fixes #651

Testing performed
Build and sanity test CFE, run all unit tests
Confirm code coverage up to par.

Expected behavior changes
The CFE_ES_MemHandle_t type is no longer a direct CPU address. Instead it is an abstract resource identifier.
This should fix issues with unexpected padding of CMD/TLM messages that contain memory pool handles.

System(s) tested on
Ubuntu 20.04
RTEMS 4.11

Additional context
Fairly extensive changes in the memory pool implementation to support abstract handles, but the API exposed to applications should be backward compatible, so long as apps did not rely on the specific pool layout.

The downside is that there is a limit to the total number of abstract identifiers that can exist, which is a new platform config limit.

Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.

@jphickey jphickey added the CCB:Ready Ready for discussion at the Configuration Control Board (CCB) label Sep 29, 2020
Instead of identifying a memory pool by its memory address,
use a resource ID.  IDs are a constant size, regardless of
whether the host machine is 32 or 64 bits.

- IDs can be put into commands/telemetry and maintain a more
  consistent format with consistent alignment requirements.
- IDs can be independently verified without dereferencing
  memory.  Previously the only way to validate a memory pool
  was to read the address pointed to, which results in a SEGV
  if the address was bad.
@astrogeco astrogeco added CCB-20200930 and removed CCB:Ready Ready for discussion at the Configuration Control Board (CCB) labels Sep 30, 2020
@jphickey
Copy link
Contributor Author

Confirmed this also fixes #854

@jphickey jphickey linked an issue Sep 30, 2020 that may be closed by this pull request
@astrogeco
Copy link
Contributor

astrogeco commented Sep 30, 2020

CCB 2020-09-30:

  • Creates a memory pool implementation that mirrors how we handle other abstract resources
  • @jphickey will submit an issue to update CDS

APPROVED

@astrogeco
Copy link
Contributor

@jphickey is #854 the issue we discussed opening at the CCB?

@astrogeco astrogeco changed the base branch from main to integration-candidate October 1, 2020 21:34
@astrogeco astrogeco merged commit 3a809eb into nasa:integration-candidate Oct 1, 2020
@jphickey
Copy link
Contributor Author

jphickey commented Oct 2, 2020

@jphickey is #854 the issue we discussed opening at the CCB?

No, the old issue about CDS mempool is in #56 ... it has been on the to-do list for about 5 years.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants