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

Either deprecated or require OS_TaskRegister #853

Closed
skliper opened this issue Mar 10, 2021 · 1 comment · Fixed by #926 or #927
Closed

Either deprecated or require OS_TaskRegister #853

skliper opened this issue Mar 10, 2021 · 1 comment · Fixed by #926 or #927
Assignees
Milestone

Comments

@skliper
Copy link
Contributor

skliper commented Mar 10, 2021

Is your feature request related to a problem? Please describe.
OS_TaskRegister has comments that it is obsolete, but never got officially deprecated.

Describe the solution you'd like
Need to either officially deprecate or officially support.

Describe alternatives you've considered
None

Additional context
Impacts apps, better now in a major release than later for removal.

Requester Info
Jacob Hageman - NASA/GSFC, OSAL code review

@jphickey
Copy link
Contributor

My vote would be to deprecate if we must do something.

@ejtimmon can you confirm if any GSFC apps are currently calling OS_TaskRegister()?

Grepping the copies that I have locally, I don't see any current references to OS_TaskRegister. So it seems like we should be able to remove, but I'm not sure.

Historically - old (last-gen) OSAL would directly/immediately invoke the application-specified entry point of a new task. In order to update the internal structures, there was then a requirement that the user application calls "OS_TaskRegister()" to complete the registration process so OSAL could update its globals and track the state of the new task, and make it so e.g. OS_TaskGetID() would work correctly, etc.

Now, in the current design - OSAL invokes the application-specified entry point via a wrapper, and this wrapper performs all registration(s) that must be done in the context of the new task. Therefore all global table/state updates are already done before the entry point is even called, and OS_TaskGetID() and other functions work immediately with no extra action required on the application side.

This design is both simpler and less error prone (no chance of forgetting to call register/indeterminate state/half-initialized entries, etc). OSAL does this on all platforms. So I cannot think of a reason why one would want to go back to the old design of having an extra function that must be explicitly called by the user application in its entry point function. Or put another way, I can't think of any initialization actions that couldn't be handled in the wrapper that runs before invoking the entry point, such that we would ever need to revive/use this function.

Unless someone can think of a use-case where some initialization bits can only be done via something like OS_TaskRegister() and cannot be done before calling the entry point? I can't....

jphickey added a commit that referenced this issue Mar 23, 2021
This function is no longer needed and has been a no-op since v5.0.0.
astrogeco added a commit that referenced this issue Mar 30, 2021
jphickey pushed a commit to jphickey/osal that referenced this issue Aug 10, 2022
Fix nasa#830, Set Revision to 99 for development build
jphickey pushed a commit to jphickey/osal that referenced this issue Aug 10, 2022
Apply nasa#853 to Bootes, Set Revision to 99 for development build
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