RTOS, secure virtualization technology for real-time systems, DO-178B and hypervisor for the most demanding embedded operating system applications...

POSIX.1, POSIX.1b and POSIX.1c Function Calls A real-time embedded development reference guide

PROCESSES AND VIRTUAL MEMORY

This is the complete listing of function calls for POSIX®.1, POSIX.1b and POSIX.1c. All of them are fully supported by LynxOS®.

POSIX.1 function calls
FunctionPOSIX Description
access Tests for file accessibility
alarm Schedules an alarm
asctime Converts a time structure to a string
cfgetispeed Reads terminal input baud rate
cfgetospeed Reads terminal output baud rate
cfsetispeed Sets terminal input baud rate
cfsetospeed Sets terminal output baud rate
chdir Changes current working directory
chmod Changes file mode
chown Changes owner and/or group of a file
close Closes a file
closedir Ends directory read operation
creat Creates a new file or rewrites an existing one
ctermid Generates terminal pathname
cuserid Gets user name
dup Duplicates an open file descriptor
dup2 Duplicates an open file descriptor
execl Executes a file
execle Executes a file
execlp Executes a file
execv Executes a file
execve Executes a file
execvp Executes a file
_exit Terminates a process
fcntl Manipulates an open file descriptor
fdopen Opens a stream on a file descriptor
fork Creates a process
fpathconf Gets configuration variable for an open file
fstat Gets file status
getcwd Gets current working directory
getegid Gets effective group ID
getenv Gets environment variable
geteuid Gets effective user ID
getgid Gets real group ID
getgrgid Reads groups database based on group ID
getgrnam Reads groups database based on group name
getgroups Gets supplementary group IDs
getlogin Gets user name
getpgrp Gets process group ID
getpid Gets process ID
getppid Gets parent process ID
getpwnam Reads user database based on user name
getpwuid Reads user database based on user ID
getuid Gets real user ID
isatty Determines if a file descriptor is associated with a terminal
kill Sends a kill signal to a process
link Creates a link to a file
longjmp Restores the calling environment
lseek Repositions read/write file offset
mkdir Makes a directory
mkfifo Makes a FIFO special file
open Opens a file
opendir Opens a directory
pathconf Gets configuration variables for a path
pause Suspends a process execution
pipe Creates an interprocess channel
read Reads from a file
readdir Reads a directory
rename Renames a file
rewinddir Resets the readdir() pointer
rmdir Removes a directory
setgid Sets group ID
setjmp Saves the calling environment for use by longjmp()
setlocale Sets or queries a program's locale
setpgid Sets a process group ID for job control
setuid Sets the user ID
sigaction Examines and changes signal action
sigaddset Adds a signal to a signal set
sigdelset Removes a signal to a signal set
sigemptyset Creates an empty signal set
sigfillset Creates a full set of signals
sigismember Tests a signal for a selected member
siglongjmp Goes to and restores signal mask
sigpending Examines pending signals
sigprocmask Examines and changes blocked signals
sigsetjmp Saves state for siglongjmp()
sigsuspend Waits for a signal
sleep Delays process execution
stat Gets information about a file
sysconf Gets system configuration information
tcdrain Waits for all output to be transmitted to the terminal
tcflow Suspends/restarts terminal output
tcflush Discards terminal data
tcgetattr Gets terminal attributes
tcgetpgrp Gets foreground process group ID
tcsendbreak Sends a break to a terminal
tcsetattr Sets terminal attributes
tcsetpgrp Sets foreground process group ID
time Determines the current calendar time
times Gets process times
ttyname Determines a terminal pathname
tzset Sets the timezone from environment variables
umask Sets the file creation mask
uname Gets system name
unlink Removes a directory entry
utime Sets file access and modification times
waitpid Waits for process termination
write Writes to a file

 

POSIX.1b function calls
FunctionPOSIX Description
aio_cancel Tries to cancel an asynchronous operation
aio_error Retrieves the error status for an asynchronous operation
aio_read Asynchronously reads from a file
aio_return Retrieves the return status for an asynchronous operation
aio_suspend Waits for an asynchronous operation to complete
aio_write Asynchronously writes to a file
clock_getres Gets resolution of a POSIX.1b clock
clock_gettime Gets the time according to a particular POSIX.1b clock
clock_settime Sets the time according to a particular POSIX.1b clock
fdatasync Synchronizes at least the data part of a file with the underlying media
fsync Synchronizes a file with the underlying media
kill, sigqueue Sends signals to a process
lio_listio Performs a list of I/O operations, synchronously or asynchronously
mlock Locks a range of memory
mlockall Locks the entire memory space down
mmap Maps a shared memory object (or possibly another file) into process's address space
mprotect Changes memory protection on a mapped area
mq_close Terminates access to a POSIX.1b message queue
mq_getattr Gets POSIX.1b message queue attributes
mq_notify Registers a request to be notified when a message arrives on an empty message queue
mq_open Creates/accesses a POSIX.1b message queue
mq_receive Receives a message from a POSIX.1b message queue
mq_send Sends a message on a POSIX.1b message queue
mq_setattr Sets a subset of POSIX.1b message queue attributes
msync Makes a mapping consistent with the underlying object
munlock Unlocks a range of memory
munlockall Unlocks the entire address space
munmap Undo mapping established by mmap
nanosleep Pauses execution for a number of nanoseconds
sched_get_priority_max Gets maximum priority value for a scheduler
sched_get_priority_min Gets minimum priority value for a scheduler
sched_getparam Retrieves scheduling parameters for a particular process
sched_getscheduler Retrieves scheduling algorithm for a particular purpose
sched_rr_get_interval Gets the SCHED_RR interval for the named process
sched_setparam Sets scheduling parameters for a process
sched_setscheduler Sets scheduling algorithm/parameters for a process
sched_yield Yields the processor
sem_close Terminates access to a POSIX.1b semaphore
sem_destroy De-initializes a POSIX.1b unnamed semaphore
sem_getvalue Gets the value of a POSIX.1b semaphore
sem_open Creates/accesses a POSIX.1b named semaphore
sem_post Posts (signal) a POSIX.1b named or unnamed semaphore
sem_unlink Destroys a POSIX.1b named semaphore
sem_wait, sem_trywait Waits on a POSIX.1b named or unnamed semaphore
shm_open Creates/accesses a POSIX.1b shared memory object
shm_unlink Destroys a POSIX.1b shared memory object
sigwaitinfosigtimedwait Synchronously awaits signal arrival; avoid calling handler
timer_create Creates a POSIX.1b timer based on a particular clock
timer_delete Deletes a POSIX.1b timer
timer_gettime Time remaining on a POSIX.1b timer before expiration
timer_settime Sets expiration time/interval for a POSIX.1b timer
wait, waitpid Retrieves status of a terminated process and clean up corpse

 

POSIX.1c function calls
FunctionPOSIX Description
pthread_atfork Declares procedures to be called before and after a fork
pthread_attr_destroy Destroys a thread attribute object
pthread_attr_getdetachstate Obtains the setting of the detached state of a thread
pthread_attr_getinheritsched Obtains the setting of the scheduling inheritance of a thread
pthread_attr_getschedparam Obtains the parameters associated with the scheduling policy attribute of a thread
pthread_attr_getschedpolicy Obtains the setting of the scheduling policy of a thread
pthread_attr_getscope Obtains the setting of the scheduling scope of a thread
pthread_attr_getstackaddr Obtains the stack address of a thread
pthread_attr_getstacksize Obtains the stack size of a thread
pthread_attr_init Initializes a thread attribute object
pthread_attr_setdetachstate Adjusts the detached state of a thread
pthread_attr_setinheritsched Adjusts the scheduling inheritance of a thread
pthread_attr_setschedparam Adjusts the parameters associated with the scheduling policy of a thread
pthread_attr_setschedpolicy Adjusts the scheduling policy of a thread
pthread_attr_setscope Adjusts the scheduling scope of a thread
pthread_attr_setstackaddr Adjusts the stack address of a thread
pthread_attr_setstacksize Adjusts the stack size of a thread
pthread_cancel Cancels the specific thread
pthread_cleanup_pop Removes the routine from the top of a thread's cleanup stack, and if execute is nonzero, runs it
pthread_cleanup_push Places a routine on the top of a thread's cleanup stack
pthread_condattr_destroy Destroys a condition variable attribute object
pthread_condattr_getpshared Obtains the process-shared setting of a condition variable attribute object
pthread_condattr_init Initializes a condition variable attribute object
pthread_condattr_setpshared Sets the process-shared attribute in a condition variable attribute object to either PTHREAD_PROCESS_SHARED or PTHREAD_PROCESS_PRIVATE
pthread_cond_broadcast Unblocks all threads that are waiting on a condition variable
pthread_cond_destroy Destroys a condition variable
pthread_cond_init Initializes a condition variable with the attributes specified in the specified condition variable attribute object
pthread_cond_signal Unblocks at least one thread waiting on a condition variable
pthread_cond_timedwait Automatically unlocks the specified mutex, and places the calling thread into a wait state
pthread_cond_wait Automatically unlocks the specified mutex, and places the calling thread into a wait state
pthread_create Creates a thread with the attributes specified in attr
pthread_detach Marks a threads internal data structures for deletion
pthread_equal Compares one thread handle to another thread handle
pthread_exit Terminates the calling thread
pthread_getschedparam Obtains both scheduling policy and scheduling parameters of an existing thread
pthread_getspecific Obtains the thread specific data value associated with the specific key in the calling thread
pthread_join Causes the calling thread to wait for the specific thread’s termination
pthread_key_create Generates a unique thread-specific key that's visible to all threads in a process
pthread_key_delete Deletes a thread specific key
pthread_kill Delivers a signal to the specified thread
pthread_mutexattr_destroy Destroys a mutex attribute object
pthread_mutexattr_getprioceiling Obtains the priority ceiling of a mutex attribute object
pthread_mutexattr_getprotocol Obtains protocol of a mutex attribute object
pthread_mutexattr_getpshared Obtains a process-shared setting of a mutex attribute object
pthread_mutexattr_init Initializes a mutex attribute object
pthread_mutexattr_setprioceiling Sets the priority ceiling attribute of a mutex attribute object
pthread_mutexattr_setprotocol Sets the protocol attribute of a mutex attribute object
pthread_mutexattr_setpshared Sets the process-shared attribute of a mutex attribute object to either PTHREAD_PROCESS_SHARED or PTHREAD_PROCESS_PRIVATE
pthread_mutex_destroy Destroys a mutex
pthread_mutex_init Initializes a mutex with the attributes specified in the specified mutex attribute object
pthread_mutex_lock Locks an unlocked mutex
pthread_mutex_trylock Tries to lock a not tested
pthread_mutex_unlock Unlocks a mutex
pthread_once Ensures that init_routine will run just once regardless of how many threads in the process call it
pthread_self Obtains a thread handle of a calling thread
pthread_setcancelstate Sets a thread's cancelability state
pthread_setcanceltype Sets a thread's cancelability type
pthread_setschedparam Adjusts the scheduling policy and scheduling parameters of an existing thread
pthread_setspecific Sets the thread-specific data value associated with the specific key in the calling thread
pthread_sigmask Examines or changes the calling thread's signal mask
pthread_testcancel Requests that any pending cancellation request be delivered to the calling thread

PROCESSES AND VIRTUAL MEMORY

A LynuxWorks embedded OS is featured in this embedded system application:
Who else uses a LynuxWorks embedded operating system?
Security white papers
Separation Kernels Enable Rapid Development of Trustworthy Systems
By using separation kernel technology and a security abstraction design approach, military system developers can use off-the-shelf components and tools to rapidly build and maintain high security systems. (March 2014)
Coming Together of Safety and (Cyber) Security Changes Demands in RTOS Market
Separation kernels and secure hypervisors will be evermore in demand as safety and certification will be required in more and more applications. Governments are already working on infrastructures deploying this type of technology. (October 2012)
Building in RTOS Support for Safety- & Security-Critical Systems
LynuxWorks explains the differences between safety-critical and security-critical applications and how to meet their demanding requirements with the LynxOS-178 RTOS and the LynxSecure hypervisor. (EE Times Design, August 2011)
Enhancing Application Performance on Multicore Systems
Tips on optimizing a multicore real-time system, including virtualization, avoiding synchronization and concurrency while maximizing application parallelism. (Military Embedded Systems, February 2011)
Hardware Virtualization puts a new spin on Secure Systems
Real-time determinism and military security don't have to be separate realities. A combination of a secure separation kernel and an embedded hypervisor enables whole new levels of system security. (COTS Journal, October 2010)
Using a Separation Kernel to add Military-Grade Security to Legacy Systems
A challenge for the software designer is how to integrate modern military-grade software programs into legacy software designed long before security standards were predominant in system requirements. (VME Critical Systems, Summer 2010)
Virtualization: Keeping Embedded Software safe and Secure in an Unsafe World
A new, secure methodology is needed to separate systems of different security levels which run on shared resources—without compromising the performance of legacy systems. (EE Times, June 2010)
Secure Virtualization Combines Traditional Desktop OSs and Embedded RTOSes in Military Embedded Systems
Advances in software and hardware technologies now make it feasible to use both embedded and desktop operating systems in a secure military system. (Military Embedded Systems, May 2010)
DO-178B Provides Certification Safety net
Developers of commercial avionics software must demonstrate compliance with DO-178 guidelines. The FAA has issued additional guidance for so-called DO-178B Reusable Software Components (RSCs as defined in AC20-148), which allow for reuse of certifications. (COTS Journal, November 2009)
Designing Safety-critical Avionics Software Using open Standards
Safety-critical avionics systems have continually grown more complex and software-intensive. Regulatory authorities and avionics manufacturers have responded with guidance such as DO-178B and RSC to ensure that software performs safely, with controlled development cost. (Boards and Solutions, September 2009)
Two Different Realms: RTOS Support for Safety-critical vs. Security-critical Systems
Safety- and security-critical system functions are evolving simultaneously, with different yet similar requirements. Modern RTOSes are stepping up to meet these needs. (VME and Critical Systems, June 2009)
Virtualization Makes Better use of Open-source OSes and apps
With the introduction of the embedded hypervisor, embedded systems can avoid certain performance or licensing issues inherent to open-source OSes and applications. (EE Times, March 23, 2009)
Secure Virtualization Technology can Extend the life of Legacy Systems
By combining the concept of virtualization and security, one can consolidate multiple legacy systems running on heterogeneous operating systems onto a single host system with high-assurance security. (Military Embedded Systems, January/February 2009)
Virtual Machines: Intel's CPU Extensions Transform Virtualization
Virtualization has traditionally presented its share of design challenges in information-assurance-based systems. But now, Intel's VT-x and VT-d CPU extensions are changing the game and showing potential to become the de facto path to virtualization. (Military Embedded Systems, January 2009)
Separation Kernel for a Secure Real-time Operating System
The technical foundation adopted for the so-called MILS architecture is a separation kernel like LynxSecure, which permits multiple functions to be realised on a common set of physical resources without unwanted mutual interference. (Boards and Solutions Magazine, February 2008)
Advances in Virtualization aid Information Assurance
Advances in the newest Intel® processors are making virtualization much easier to implement in security applications than ever before. (Embedded Computing Design, January 2008)
Protecting our most Vital Systems
Some significant defence programmes are already committed to a new approach to high-threat, high-asset-value systems. Rance DeLong explains MILS. (Components in Electronics, April 2007)
Perspectives: Security and the Separation Kernel
Today's avionics systems are designed to support more than one application, using a partitioned operating system and memory management units to ensure applications have adequate separation. (Avionics Magazine, April 2007)
MILS: An Architecture for Security, Safety, and Real Time
The unrelenting growth and integration of embedded controls, information processing, and communications has created a need for systems that provide robust protection for resources and services in the face of serious threats. (Embedded Technology Magazine, November 2006)
Partitioning Operating Systems Versus Process-based Operating Systems
Partitioning operating systems are the latest buzz, while processes, by contrast, have been around for over 30 years. Both provide memory protection, however, the intent behind them is very different.
DO-178B and the Common Criteria: Future Security Levels
Although there are similarities between the airborne safety-critical requirements in RTCA/DO-178B and the Common Criteria, ISO 14508, compliance with the higher levels of security in the Common Criteria demands meeting additional security requirements. (COTS Journal, April 2006)
Reusing Safety-Critical Software Components
Safety-critical systems often operate together as a single "system-of-systems," making it important that they meet the most stringent and rigorous requirements for safety-criticality. The failure of one module in a system could create other failures or vulnerabilities, or worse yet, failure of the system as a whole. (COTS Journal, August 2005)
Using the Microprocessor MMU for Software Protection in Real-Time Systems
With minimal impact to overall system performance, user tasks and the kernel can be protected from accidental corruption by using multiple protected address spaces.
Improving code Migration and Reuse
The unrelenting growth and integration of embedded controls, information processing, and communications has created a need for systems that provide robust protection for resources and services in the face of serious threats. (Embedded Computing Design, August 2006)
FCS Program Rolls Forward in Formation
A wireless data network, with advanced communications and technologies, links soldiers with 18 new, lightweight manned and unmanned ground vehicles, unmanned aircraft, sensors and weapons—and it's all in one program. (COTS Journal, June 2005)
Secure Operating Systems for Deeply Embedded Devices
As we add more intelligence to our embedded devices, we find that they are becoming increasingly integrated into our information technology infrastructure. Though system security is not a new concept, security-in-depth is a new paradigm developers are now starting to address. (RTC Magazine, September 2004)
LynxSecure Separation Kernel and Embedded Hypervisor LynxOS-SE Embedded RTOS Luminosity Eclipse-based IDE
LynxOS Embedded RTOS RTOS: LynxOS-178 for software certification

 

SpyKer Embedded-System Trace Tool

Industry Solutions

Migration

Industry Standards

Embedded Systems Technology

RTOS Training for Embedded Systems

Training at LynuxWorks

LynuxWorks Support

Embedded Systems

LynxOS RTOS Support

Embedded System Consulting

Contact Us

About LynuxWorks

Press Room

Newsletter and Announcements

Careers

Partners

Site Map

Board Support Packages (BSPs)

BSP Device Drivers

BSP Targets by Operating System

BSP Targets by Form Factor

Third-party I/O Devices and Hardware

SynergyWorks: LynuxWorks partners


What is SynergyWorks?

Third-party add-ons for LynuxWorks operating systems

Copyright © LynuxWorks™, Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of LynuxWorks is prohibited.