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

OSAL should have an inverse function to OS_API_Init() #944

Closed
jphickey opened this issue Apr 5, 2021 · 0 comments · Fixed by #948 or #956
Closed

OSAL should have an inverse function to OS_API_Init() #944

jphickey opened this issue Apr 5, 2021 · 0 comments · Fixed by #948 or #956
Assignees
Milestone

Comments

@jphickey
Copy link
Contributor

jphickey commented Apr 5, 2021

Is your feature request related to a problem? Please describe.
Once OSAL is initialized, normally it runs forever until rebooted, or the process exits in the case of Linux. In that light, resources obtained during OS_API_Init() cannot directly/simply be released via the API - there is no opposite/inverse routine defined.

However under testing conditions, and for general completeness of API, it is useful to have an inverse function to tear down the API structures and return the system to the state it was prior to the OS_API_Init() call.

This can (almost) be done with the current OSAL API, but it must be done in two parts:

  1. OS_DeleteAllObjects() will clean up any remaining user-instantiated objects in the tables.
  2. OS_ApplicationShutdown(true) will cause any internal resources, such as the console utility task, to also self-exit.

The combination of these two basically leaves the system in a state similar to what it was before OS_API_Init() was run. (its not perfect, but its close).

But its not ideal because a user shouldn't have to call two functions (one of which also has a parameter) to undo the init call.

Describe the solution you'd like
Implement a void OS_API_Teardown(void) routine which would be just be a wrapper around these two currently-existing functions, to make it simpler to do this.

Importantly, being a void/void routine means that it can be easily used with unit tests and the UtTest_AddTeardown() routine.

Describe alternatives you've considered
Leave as-is

Additional context
Issue #197 which calls for something like this that unit tests can use.

Requester Info
Joseph Hickey, Vantage Systems, Inc.

@jphickey jphickey self-assigned this Apr 5, 2021
astrogeco pushed a commit that referenced this issue Apr 11, 2021
This cleans up all OSAL resources as best as possible, ideally leaving
the system in a state where OS_API_Init() may be invoked again.
astrogeco added a commit that referenced this issue Apr 11, 2021
@skliper skliper added this to the 6.0.0 milestone Sep 24, 2021
jphickey pushed a commit to jphickey/osal that referenced this issue Aug 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants