Open 2shaar2059 opened 2 years ago
Using the OSAL calls provides the standard OSAL resources management support/knowledge/tracking across the system. Direct OS calls means the rest of the system will have no knowledge of that resource use w/o querying the OS directly, and you are "on your own" to manage that resource. Recommendation is to use OSAL APIs where possible.
Thanks, Jake. Can you please clarify what you mean by "the standard OSAL resources management support/knowledge/tracking"
See https://github.com/nasa/osal/blob/main/src/os/inc/osapi-idmap.h and https://github.com/nasa/osal/blob/main/src/os/inc/osapi-file.h. Using OSAL APIs means any other apps that manage or interact w/ resources through these APIs are going to just work as expected, the configuration limits (like OSAL_CONFIG_MAX_NUM_OPEN_FILES, OSAL_CONFIG_MAX_FILE_NAME, OSAL_CONFIG_MAX_PATH_LEN) and similar will be respected, etc. Using OS calls directly will not respect these limits and if violated you won't be able to manage (delete, move, get info about, send via CFDP, etc) the resource using the rest of cFS. There's nothing that really prevents apps from directly calling the OS to create files, spawn tasks, open streams, etc... it just defeats the core resource management concepts built into cFS.
My application involves reading data from a serial device (IMU) in a nonblocking fashion. Furthermore, I am writing code for a particular linux architecture so benefits from the standpoint of enabling OS abstraction are not really important. So, other than that: What is the difference between linux's read() and OS_read()? Is there a specific one that is recommended given my situation? If so, why that one?