diff --git a/docs/src/osal_fs.dox b/docs/src/osal_fs.dox deleted file mode 100644 index 6a8b8cf29..000000000 --- a/docs/src/osal_fs.dox +++ /dev/null @@ -1,94 +0,0 @@ -/** -\page osalfsovr File System Overview - - The File System API is a thin wrapper around a selection of POSIX file APIs. - In addition the File System API presents a common directory structure and - volume view regardless of the underlying system type. For example, vxWorks - uses MS-DOS style volume names and directories where a vxWorks RAM disk might - have the volume “RAM:0”. With this File System API, volumes are represented - as Unix-style paths where each volume is mounted on the root file system: - - - - This abstraction allows the applications to use the same paths regardless of - the implementation and it also allows file systems to be simulated on a desktop - system for testing. On a desktop Linux system, the file system abstraction can - be set up to map virtual devices to a regular directory. This is accomplished - through the OS_mkfs call, OS_mount call, and a BSP specific volume table that - maps the virtual devices to real devices or underlying file systems. - - In order to make this file system volume abstraction work, a “Volume Table” - needs to be provided in the Board Support Package of the application. The table - has the following fields: - - -**/ - -/** -\page osalfsfd File Descriptors In Osal - - The OSAL uses abstracted file descriptors. This means that the file descriptors - passed back from the OS_open and OS_creat calls will only work with other OSAL OS_* - calls. The reasoning for this is as follows: - - Because the OSAL now keeps track of all file descriptors, OSAL specific information - can be associated with a specific file descriptor in an OS independent way. For -instance, the path of the file that the file descriptor points to can be easily - retrieved. Also, the OSAL task ID of the task that opened the file can also be - retrieved easily. Both of these pieces of information are very useful when trying - to determine statistics for a task, or the entire system. This information can all - be retrieved with a single API, OS_FDGetInfo. - - All of possible file system calls are not implemented. "Special" files requiring OS - specific control/operations are by nature not portable. Abstraction in this case is - is not possible, so the raw OS calls should be used (including open/close/etc). Mixing - with OSAL calls is not supported for such cases. #OS_TranslatePath is available to - support using open directly by an app and maintain abstraction on the file system. - - There are some small drawbacks with the OSAL file descriptors. Because the related - information is kept in a table, there is a define called OS_MAX_NUM_OPEN_FILES that - defines the maximum number of file descriptors available. This is a configuration -parameter, and can be changed to fit your needs. - - Also, if you open or create a file not using the OSAL calls (OS_open or OS_creat) - then none of the other OS_* calls that accept a file descriptor as a parameter will -work (the results of doing so are undefined). Therefore, if you open a file with - the underlying OS's open call, you must continue to use the OS's calls until you - close the file descriptor. Be aware that by doing this your software may no longer - be OS agnostic. -**/ diff --git a/docs/src/osal_timer.dox b/docs/src/osal_timer.dox deleted file mode 100644 index 793bc24c7..000000000 --- a/docs/src/osal_timer.dox +++ /dev/null @@ -1,8 +0,0 @@ -/** - \page osaltimerover Timer Overview - - The timer API is a generic interface to the OS timer facilities. It is - implemented using the POSIX timers on Linux and vxWorks and the native timer - API on RTEMS. The number of timers supported is controlled by the configuration - parameter OS_MAX_TIMERS. -**/ diff --git a/docs/src/osalmain.dox b/docs/src/osalmain.dox deleted file mode 100644 index 7502b6991..000000000 --- a/docs/src/osalmain.dox +++ /dev/null @@ -1,121 +0,0 @@ -/** - \mainpage Osal API Documentation - - -**/ - -/** - \page osalIntro OSAL Introduction - - The goal of this library is to promote the creation of portable and - reusable real time embedded system software. Given the necessary OS - abstraction layer implementations, the same embedded software should - compile and run on a number of platforms ranging from spacecraft - computer systems to desktop PCs. - - The OS Application Program Interfaces (APIs) are broken up into core, - file system, loader, network, and timer APIs. See the related document - sections for full descriptions. - - @note The majority of these APIs should be called from a task running - in the context of an OSAL application and in general should not be called - from an ISR. There are a few exceptions, such as the ability to give a - binary semaphore from an ISR. -**/ - - -