search

nasa / osal

The Core Flight System (cFS) Operating System Abstraction Layer (OSAL)
Apache License 2.0
540 stars 213 forks source link

read() vs OS_read() Clarification #1269

Open 2shaar2059 opened 2 years ago

2shaar2059 commented 2 years ago

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?

skliper commented 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.

2shaar2059 commented 2 years ago

Thanks, Jake. Can you please clarify what you mean by "the standard OSAL resources management support/knowledge/tracking"

skliper commented 2 years ago

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.