-
Notifications
You must be signed in to change notification settings - Fork 215
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 a "OS_GetVersionString()" function #821
Comments
Suggestion is to add a new OSAL API, something simple like:
Which just returns the value of the |
I vote we fix for Caelum. |
OK! It's trivial enough, I can do this real quick. |
jphickey
added a commit
to jphickey/osal
that referenced
this issue
Feb 17, 2021
Adds 3 simple API calls: const char *OS_GetVersion(void); const char *OS_GetVersionCodeName(void); const char *OS_GetVersionDescription(void); These directly return the values of string macros in osapi-version.h. The accessor function should be the preferred way to get the OSAL version string (vs. using macro directly) as it is evaluated at OSAL library compile time, rather than application compile time, and thus will remain correct in the event that OSAL is relinked without recompiling the application.
jphickey
added a commit
to jphickey/osal
that referenced
this issue
Feb 17, 2021
Adds 3 simple API calls: const char *OS_GetVersion(void); const char *OS_GetVersionCodeName(void); const char *OS_GetVersionDescription(void); These directly return the values of string macros in osapi-version.h. The accessor function should be the preferred way to get the OSAL version string (vs. using macro directly) as it is evaluated at OSAL library compile time, rather than application compile time, and thus will remain correct in the event that OSAL is relinked without recompiling the application.
This was referenced Feb 18, 2021
jphickey
added a commit
to jphickey/osal
that referenced
this issue
Mar 2, 2021
Adds 4 version API calls: const char *OS_GetVersionString(void); const char *OS_GetVersionCodeName(void); void OS_GetVersionNumber(uint8[4]); uint32 OS_GetBuildNumber(void); These return the values of current macros in osapi-version.h. The accessor function should be the preferred way to get the OSAL version info (vs. using macro directly) as it is evaluated at OSAL library compile time, rather than application compile time, and thus will remain correct in the event that OSAL is relinked without recompiling the application.
jphickey
added a commit
to jphickey/osal
that referenced
this issue
Mar 2, 2021
astrogeco
added a commit
to astrogeco/osal
that referenced
this issue
Mar 2, 2021
Fix nasa#821, add accessor functions for version strings Fix format in `osapi-utstub-version.c`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Currently the OSAL version is a string that is made available as a macro -
OS_VERSION_STRING
- which defined inosapi-version.h
The problem with this is that because its a preprocessor macro - the replacement is done at the point the macro is referenced and therefore the value ends up getting built into the binary code for whatever referenced this (in CFE use case this is
cfe_es_task.o
)This means if that code is later linked with a different/updated OSAL library (but the CFE code using OSAL is not recompiled) it will still report the original OSAL version string, which is wrong.
Describe the solution you'd like
There should be a function call into OSAL to get the version string, rather than a macro in a header. Therefore if/when re-linking without recompilation, it will report the correct value.
Additional context
In summary - the OSAL version string should be stored within the OSAL library binary file, rather than stored within the CFE library binary file. This is confirmed via the "strings" tool that right now its in the wrong place:
This shows that the actual string showing the OSAL version as reported by the cFE event is baked into the CFE library, not the OSAL library where it should be.
Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: