Input/Output (I/O)

When ChorusOS actors use the ChorusOS Console Input/Output API, all I/O operations (such as printf() and scanf()) will be directed to the system console of the target.

If an actor uses the ChorusOS POSIX Input/Output API and is spawned from the host with rsh, the standard input and output of the application will be inherited from the rsh program and sent to the terminal emulator on the host on which the rsh command was issued.

In fact, the API is the same in both cases, but the POSIX API uses a different file descriptor.

I/O Options

The ChorusOS operating system provides the following optional I/O services:

FS_MAPPER

The FS_MAPPER feature provides support for swap in the IOM. It requires SCSI_DISK to be configured, as well as VIRTUAL_ADDRESS_SPACE and ON_DEMAND_PAGING.

The FS_MAPPER feature exports the swapon() system call.

For details, see the FS_MAPPER(5FEA) man page.

DEV_CDROM

The DEV_CDROM feature provides an interface to access SCSI CD-ROM drives.

The DEV_CDROM feature does not itself export an API.

DEV_MEM

The DEV_MEM feature provides a raw interface to memory devices such as /dev/zero, /dev/null, /dev/kmem, and /dev/mem.

The DEV_MEM feature does not export an API itself, but allows access to the devices listed in the preceding paragraphs.

For details, see the DEV_MEM(5FEA) man page.

DEV_NVRAM

The DEV_NVRAM feature provides an interface to the NVRAM memory device.

For details, see the NVRAM(5FEA) man page.

RAM_DISK

The RAM_DISK feature provides an interface to chunks of memory that can be seen and handled as disks. These disks may then be initialized and used as regular file systems, although their contents will be lost at system shutdown time. This feature is also required to get access to the MS-DOS file system, which is usually embedded as part of the system boot image.

The RAM_DISK feature does not export any APIs itself.

For details, see the RAM_DISK(5FEA) man page.

FLASH

The FLASH feature provides an interface to access a memory device. The flash memory may then be formatted, labelled, and used to support regular file systems. The FLASH feature relies on the flash support based on the Flite 1.2 BSP, and is not supported for all target family architectures. See the appropriate book in the ChorusOS 5.0 Target Platform Collection for details of which target family architecture supports the Flite 1.2 BSP.

The FLASH feature does not itself export an API.

For details, see the FLASH(5FEA) man page.

RAWFLASH

The RAWFLASH feature provides an interface to access a raw memory device. The flash memory may then be formatted, and written to with utilities such as dd. The RAWFLASH feature is mostly used to flash the boot image onto the raw memory device.

For details, see the RAWFLASH(5FEA) man page.

VTTY

The VTTY feature provides support for serial lines on top of the BSP driver for higher levels of protocols. It is used by the PPP feature (see"Point-to-Point Protocol (PPP)" ).

The VTTY feature does not itself export any APIs.

For details, see the VTTY(5FEA) man page.

SCSI_DISK

The SCSI_DISK feature provides an interface to access SCSI disks. The SCSI_DISK feature relies on the SCSI bus support provided by the BSP to access disks connected on that bus.

The SCSI_DISK feature does not itself export an API.

For details, see the SCSI_DISK(5FEA) man page.

File Systems

This section introduces the file systems supported by the ChorusOS operating system. For full details of the implementation of these file systems, see "Introduction to File System Administration for ChorusOS" in ChorusOS 5.0 System Administrator's Guide.

UNIX File System (UFS)

The UNIX file system option provides support for a disk-based file system, namely, the file system resides on physical media such as hard disks.

The UNIX file system option supports drivers for the following types of physical media:

• SCSI disks

• IDE disks

• RAM disks

The UFS feature provides POSIX-compatible file I/O system calls on top of the UFS file system on a local disk. Thus, it requires a local disk to be configured and accessible on the target system. At least one of the RAM_DISK, or SCSI_DISK features must be configured. UFS must be embedded in any configuration that exports local files through NFS.

The UFS feature API is identical to the API exported by the NFS_CLIENT feature. However, some system calls in this API will return with error codes since the underlying file system layout does not support all these operations. For general information on the API provided by this feature, see the POSIX standard (IEEE Std 1003.1b-1993).

UFS API

The UFS feature API is summarized in the following table. It is identical to the API exported by the NFS_CLIENT feature. However, some system calls in this API will return with error codes since the underlying file system layout does not support all these operations. For general information on the API provided by this feature, see the POSIX standard (IEEE Std 1003.1b-1993). Some of the calls listed are also included in other features.

Command	Description
access	Check access permissions
chdir, fchdir	Change current directory
chflags	Modify file flags (BSD command)
chmod, fchmod	Change access mode
chown, fchown	Change owner
chroot	Change root directory
close	Close a file descriptor
dup, dup2	Duplicate an open file descriptor
fcntl	File control
flock	Apply or remove an advisory lock on an open file
fpathconf	Get configurable pathname variables
fsync	Synchronize a file's in-core statistics with those on disk
getdents	Read directory entries
getdirentries	Get directory entries in a file system independent format
getfsstat	Get list of all mounted file systems
ioctl	Device control
link	Make a hard file link
lseek	Move read/write file pointer
mkdir	Make a directory file
mkfifo	Make FIFOs
mknod	Create a special file
mount, umount	Mount or unmount a file system
open	Open for reading or writing
read, readv	Read from file
readlink	Read a value of a symbolic link
rename	Change the name of a file
revoke	Invalidate all open file descriptors (BSD command)
rmdir	Remove a directory file
stat, fstat, lstat	Get file status
statfs, fstatfs	Get file system statistics
symlink	Make a symbolic link to a file
sync	Synchronize disk block in-core status with that on disk
truncate, ftruncate	Truncate a file
umask	Set file creation mode mask
unlink	Remove a directory entry
utimes	Set file access and modification times
write, writev	Write to a file

The following library calls do not support multithreaded applications:

Function	Description
opendir()	Open a directory
closedir()	Close a directory
readdir()	Read directory entry
rewinddir()	Reset directory stream
scandir()	Scan a directory for matching entries
seekdir()	Set the position of the next readdir() call in the directory stream
telldir()	Return current location in directory stream

First-in, First-Out File System (FIFOFS)

The FIFOFS feature provides support for named pipes. It requires either NFS_CLIENT or UFS to be configured as well as POSIX_SOCKETS and AF_LOCAL.

For details, see the FIFOFS(5FEA) man page.

FIFOFS API

The FIFOFS feature does not have its own API, but enables nodes created using mkfifo() to be used as pipes.

Network File System (NFS)

The Network File System (NFS) option provides transparent access to remote files on most UNIX (and many non-UNIX) platforms. For example, this facility can be used to load applications dynamically from the host to the target.

NFS_CLIENT

The NFS_CLIENT feature provides POSIX-compatible file I/O system calls on top of the NFS file system. It provides only the client side implementation of the protocol and thus requires a host system to provide the server side implementation of the NFS protocol. The NFS_CLIENT feature can be configured to run on top of either Ethernet or the point-to-point protocol (PPP). The NFS_CLIENT requires the POSIX_SOCKETS feature to be configured.

The NFS protocol is supported over IPv4 or IPv6 and supports both NFSv2 and NFSv3 over the user datagram protocol (UDP) and transmission control protocol (TCP).

The NFS_CLIENT feature API is summarized in the following table. For general information on the API provided by this feature, see the POSIX standard (IEEE Std 1003.1b-1993). Note that some of the calls listed are also included in other features.

Function	Description
access()	Check access permissions
chdir, fchdir()	Change current directory
chflags()	Modify file flags (BSD function)
chmod, fchmod()	Change access mode
chown, fchown()	Change owner
chroot()	Change root directory
close()	Close a file descriptor
dup, dup2()	Duplicate an open file descriptor
fcntl()	File control
flock()	Apply or remove an advisory lock on an open file
fpathconf()	Get configurable pathname variables
fsync()	Synchronize a file's in-core stats with those on disk
getdents()	Read directory entries
getdirentries()	Get directory entries in a file system independent format
getfsstat()	Get list of all mounted file systems
ioctl()	Device control
link()	Make a hard file link
lseek()	Move read/write file pointer
mkdir()	Make a directory file
mkfifo()	Make FIFOs
mknod()	Create a special file
mount, umount()	Mount or unmount a file system
open()	Open for reading or writing
read, readv()	Read from file
readlink()	Read a value of a symbolic link
rename()	Change the name of a file
revoke()	Invalidate all open file descriptors (BSD function)
rmdir()	Remove a directory file
stat, fstat, lstat()	Get file status
statfs, fstatfs()	Get file system statistics
symlink()	Make a symbolic link to a file
sync()	Synchronize disk block in-core status with that on disk
truncate, ftruncate()	Truncate a file
umask()	Set file creation mode mask
unlink()	Remove a directory entry
utimes()	Set file access and modification times
write, writev()	Write to a file

The following library calls do not support multi-threaded applications:

Function	Description
opendir()	Open a directory
closedir()	Close a directory
readdir()	Read directory entry
rewinddir()	Reset directory stream
scandir()	Scan a directory for matching entries
seekdir()	Set the position of the next readdir() call in the directory stream
telldir()	Return current location in directory stream

For details, see NFS_CLIENT(5FEA).

NFS_SERVER

The NFS_SERVER feature provides an NFS server on top of a local file system, most commonly UFS, but possibly MSDOSFS. It provides only the server side implementation of the protocol, the client side being provided by the NFS_CLIENT feature. The NFS_SERVER requires the POSIX_SOCKETS and UFS features.

The NFS protocol is supported over IPv4 and IPv6; it supports both NFSv2 and NFSv3 over UDP and TCP.

The NFS_SERVER feature API is summarized in the following table. For general information on the API provided by this feature, see the POSIX standard (IEEE Std 1003.1b-1993). Some of the calls listed are also included in other features.

Function	Description
getfh()	Get file handle
nfssvc()	NFS services

For details, see the NFS_SERVER(5FEA) man page.

MS-DOS File System (MSDOSFS)

The MSDOSFS feature provides POSIX-compatible file I/O system calls on top of the MSDOSFS file system on a local disk. This feature requires a local disk to be configured and accessible on the target system.

At least one of RAM_DISK or SCSI_DISK must be configured. It is usually embedded in any configuration which uses a file system as part of the boot image of the system. MSDOSFS is frequently used with Flash memory.

The MSDOSFS feature supports long file names and file access tables (FATs) with 12, 16, or 32-bit entries.

For details, see MSDOSFS(5FEA).

MSDOSFS API

The MSDOSFS feature API is identical to the API exported by the NFS_CLIENT feature. However, some system calls in this API will return with error codes since the underlying file system layout does not allow support all of these operations; for example, symlink() and mknod(). For general information on the API provided by this feature, see the POSIX standard (IEEE Std 1003.1b-1993). Some of the calls listed are also included in other features.

FS_MAPPER

The FS_MAPPER feature provides support for swap in the system. It requires either the SCSI_DISK to be configured, as well as VIRTUAL_ADDRESS_SPACE. Swap is only supported on local disks. Swapping to a remote device or file over NFS is not supported. This feature uses a dedicated file system layout on disks.

The FS_MAPPER feature exports the swapon() system call.

For details, see the FS_MAPPER(5FEA) man page.

ISOFS

The ISOFS file system is used to access CD_ROM media.

PROCFS

The ChorusOS operating system provides a /proc file system derived from the FreeBSD 4.1 implementation of /proc. Due to major differences in the implementation of the two systems, only a subset of the FreeBSD /proc file system has been retained. However, due to enhancements of the process model introduced by the ChorusOS operating system, such as the support of multi-threaded processes, extensions have been introduced to reflect the multi-threaded nature of the processes.

Such a file system is usually mounted, by convention, under the /proc directory. This directory is then populated and depopulated dynamically and automatically depending on the life cycle of the processes. ChorusOS actors are not reflected in this file system. Upon process creation (using fork() or posix_spawn()) an entry whose name is derived from the process identifier is created in the /proc directory. This per-process entry is in turn a directory whose layout is almost identical from one process to another. Threads running in this process are also represented by a regular file in the /proc file system (on a basis of one-to-one correspondence).

PROCFS API

The API supported by the PROCFS file system are similar to those exported by the UFS file system, although many of calls that do not have any significance when applied to a process will return with an error code. The list of entries that are supported below each process are listed in the following table.

Entry	Description
/proc	Mount point
/proc/curproc	Symbolic link to the current process
/proc/xxx	Per-process directory (where xxx is the PID of the process)
/proc/xxx/file	Symbolic link to the executable file
/proc/xxx/stats	Per-process instrumentation
/proc/xxx/status	Process status information mostly used by ps(1)
/proc/xxx/threads/	Process threads directory
/proc/xxx/threads/tt	Per-thread directory (where tt is the id of the thread)
/proc/xxx/threads/tt/stats	Per-thread instrumentation

PDEVFS

The PDEVFS feature is a file system that has been specifically developed for ChorusOS. By convention, it is usually mounted in the /dev and /image directories. It enables an application to create device nodes without having an actual file system such as MSDOSFS, UFS or NFS available. All data structures are maintained in memory and have to be recreated upon each reboot.

It is also used internally by the ChorusOS operating system at system startup time. File types supported are:

• Block/character devices

• Directories

Regular files and FIFOs are not supported in this PDEVFS file system.

PDEVFS API

The PDEVFS API is the one exported by any file system, although most of the system calls will return with an error, since only a limited subset of operations are supported and meaningful. By default, the system mounts the PDEVFS file system as the root.