Chapter 2 ChorusOS 4.0 Operating System Design Changes

This chapter lists the changes and new features in the design of the ChorusOS 4.0 operating system.

2.1 Multiple RAM Disks

Up to 16 RAM disks are supported by the ChorusOS 4.0 operating system. This number does not include internal RAM disks used as memory banks. Configuration of multiple RAM disks is achieved by modifying the following tunables:

• iom.ramdisk.sizeMax specifies the maximum size (in bytes) of any RAM disk. The default value is 0x400000 (4 Megabytes). Any RAM disk whose size is greater than iom.ramdisk.sizeMax is reduced to the value of iom.ramdisk.sizeMax, and a warning message is displayed on the console when you attempt to access the RAM disk, by formatting it with the disklabel command for example.

• iom.ramdiskx.size specifies the size of RAM disk x, where x is a single hexadecimal digit between 0 and f. The default value for each instance of iom.ramdisk.size is -1 which means that the disk is not yet configured or usable.

These tunables can be read by the target, but not modified, using the sysctl command. Here are two examples:

To return the value of iom.ramdisk.sizeMax, the maximum size of any RAM disk, type:

$ arun sysctl drv.ramdisk.sizeMax

To return the size of RAM disk a, type:

$ arun sysctl drv.ramdiska.size

See the sysctl(1M) man page for more information.

After defining your RAM disks, you must associate them with a device. This is achieved using the mknod C_INIT command as follows:

$ mknod device_name device_type major_number minor_number 

The device_name is the device name within /dev, device_type is either c for character, or b for block, major_number is the major device number, and minor_number is the minor device number. The minor_number determines what number is allocated to each RAM disk according to the following table:

See the mknod(1M) man page for more information.

Here is an example of device definitions for RAM disk 0:

# Devices for RAM disk #0
# must define both block and character modes
# Character mode
mknod /dev/rrd0a c 13 0
mknod /dev/rrd0b c 13 1
mknod /dev/rrd0c c 13 2
mknod /dev/rrd0d c 13 3
mknod /dev/rrd0e c 13 4
mknod /dev/rrd0f c 13 5
mknod /dev/rrd0g c 13 6
mknod /dev/rrd0h c 13 7

# Block mode
mknod /dev/rd0a b 14 0
mknod /dev/rd0b b 14 1
mknod /dev/rd0c b 14 2
mknod /dev/rd0d b 14 3
mknod /dev/rd0e b 14 4
mknod /dev/rd0f b 14 5
mknod /dev/rd0g b 14 6
mknod /dev/rd0h b 14 7

Which partitions you define will depend on which entries you have defined in your /etc/disktab file. See the disktab(4CC) man page for more information.

Here is an example /etc/disktab entry which defines RAM disk rd1Meg with two partitions:

rd1Meg:\
        :ns#4:nt#4:nc#2048 \
        :pa#1024:oa#0:ta=MSDOS: \
        :pb#1024:ob#0:tb=MSDOS: \
        :pc#2048:oc#0:tc=unused:

Your device definition file will look like this:

Devices for RAM disk rd1Meg
# must define both block and character modes
# Character mode
mknod /dev/rrd0a c 13 0
mknod /dev/rrd0b c 13 1

# Block mode
mknod /dev/rd0a b 14 0
mknod /dev/rd0b b 14 1

Label the RAM disk using the disklabel command:

$ arun disklabel -w rd0 rd1Meg

Format the partitions as follows:

$ arun newfs_dos /dev/rrd0a
$ arun newfs_dos /dev/rrd0b

Finally, to mount the partitions, do the following:

$ mount -t msdosfs /dev/rd0a /mnt/a
$ mount -t msdosfs /dev/rd0b /mnt/b

See ChorusOS 4.0 File System Administration Guide for more information on RAM disks.

2.2 Flash Feature

The FLASH feature in ChorusOS 4.0 provides an interface to access memory devices through the Flite 1.2 BSP component. Two commands are available:

• format raw_device

  This command is new to ChorusOS 4.0 and performs a low-level format on the flash device. See the format(1M) man page for more information.

• flashdefrag raw_device [value]

  This command defragments flash memory and exists in ChorusOS 3.2 without the raw_device argument. See the flashdefrag(1M) man page for more information.

The mkdosflashfs and dosfsck commands, which create and check a DOS File system respectively, have been removed. Use the newfs_dos and fsck_dos commands instead. See the newfs_dos(1M) and fsck_dos(1M) man pages for more information.

For more information on the FLASH feature, see the FLASH(5FEA) man page. For more information on formatting a flash memory device, see "How to Format a Flash Memory Device" in ChorusOS 4.0 File System Administration Guide.

2.3 Swap System

In ChorusOS 3.2, the swap system was implemented over NFS. In ChorusOS 4.0, the swap system is implemented as a UFS-based file system which requires a local IDE or SCSI disk. Mount the swap system with the following command:

$ mount -t swap mount_point /swap

Swap areas greater than 2 Gigabytes are supported in ChorusOS 4.0. See "How to Activate a Swap Partition" in ChorusOS 4.0 File System Administration Guide for information on preparing and activating a swap partition.

2.4 Target Initialization and Administration

New support for target initialization and administration is provided in the ChorusOS 4.0 operating system:

• A new actor, ADMIN, provides administration utilities such as ifconfig, route, and netmask, which can be run before the file system is initialized.

• The C_INIT actor, loaded at system start-up, has a command interpreter which reads the sysadm.ini file embedded in the ChorusOS system image and executes any initialization instructions it finds. See the C_INIT(1M) man page for more information.

This is a more flexible and easy-to-configure approach than in ChorusOS 3.2, where network and file system initialization was handled by the IOM actor. See "System Administration in the Extended Environment" in ChorusOS 4.0 Introduction for more information.

You can customize system initialization using a /etc/rc.chorus file. See the rc.chorus(4CC) man page for more information.

To build a system image, you now need a sysadm.ini file in order to configure the network and any devices. See the sysadm.ini(4CC) man page for more information.

2.5 Compressed Executables

The storage space of executable files may be reduced by compressing them with the GNU zip utility gzip. When the GZ_FILE feature is enabled, the afexec() and aload() system calls will automatically uncompress .gz files before loading them into memory. Here is an example:

1. Compress the ls tool on your host:

   $ gzip ls.r

2. Run ls as normal, omitting the .gz extension:

   $ arun ls

   or

   $ arun ls.r

Dynamic libraries can also be compressed in the same way. See the GZ_FILE(5FEA), the afexec(2K), and the aload(2K) man pages for more information.

2.6 Running Executable Files From Memory

It is now possible to run executable files directly from memory by specifying the path to the relocatable binary in the following form:

ram:0xstart:0xlength:

start is the starting address at which the binary is stored and length is the length of the binary.

See the afexec(2K) man page for more information.

2.7 Hot Restart

Hot restart is now available on all platforms and is enabled with the HOT_RESTART feature. Although the essence of hot restart is the same in the ChorusOS 4.0 operating system, it has been reimplemented since the ChorusOS 3.2 operating system, with significant differences in behavior and API. See the ChorusOS 4.0 Hot Restart Programmer's Guide and the HOT_RESTART(5FEA) man page for more information.

2.8 PPP and SLIP Architecture

The PPP architecture has been redesigned in the ChorusOS 4.0 operating system, making its use and operation much closer to that used in BSD UNIX. There is no longer a specific API to dynamically manage serial lines as there was in the ChorusOS 3.2 operating system.

The IOM actor now includes standard tty line discipline functionalities, as well as support for pseudo ttys, which are devices that are not associated with any real hardware. They are used to simulate the functions of a real tty. A tty line can be opened in raw mode, then switched to PPP or SLIP line discipline using standard ioctl() calls. This is used by the PPP or SLIP daemon to configure the serial line for the PPP or SLIP protocol.

The ChorusOS 4.0 PPP daemon is an improved version of the BSD daemon, which is able to handle multiple serial lines by assigning a separate thread to each one. All the usual PPP functions, including dial-up on demand, are supported through the pppd options.

The PPP API is provided by the actor pppstart and three C_INIT commands, pppd, pppstop, and pppclose. See the pppstart(1M), pppd(1M), pppstop(1M), and the pppclose(1M) man pages, and "Setting Up PPP" in ChorusOS 4.0 Network Administration Guide for more information.

2.9 POSIX Message Queues

The mq_open() system call establishes the connection between an actor and a message queue with a message queue descriptor. In the ChorusOS 3.2 operating system, the identifier returned by mq_open() was from an identifier space specific to the POSIX message queue. In the ChorusOS 4.0 operating system, this identifier is a standard file descriptor, similar to the file descriptor returned by open(), as stated in the POSIX standard.

See the mq_open(2POSIX) man page for more information.

2.10 BSD Compatible Interfaces

The 4.3 BSD compatible interfaces in the ChorusOS 3.2 operating system have been replaced by 4.4 BSD compatible interfaces in the ChorusOS 4.0 operating system. IOM is no longer compiled with the COMPAT_43 option.

As a result of this change, the sockaddr structure has a new field, sa_len:

struct sockaddr {
    u_char sa_len;    /* total length */
    u_char sa_family; /* address family */
    char sa_data[14]; /* actually longer; address value */ 
}  

Any applications using the old form of sockaddr, without the sa_len field, must be updated to initialize the structure correctly.

2.11 RTTY

The raw serial line device feature, RTTY, has been removed from the ChorusOS 4.0 operating system. Line disciplines, used to control input from the tty, have been implemented instead. The following line disciplines are available:

• General Line Discipline.

• PPP Line Discipline.

• SLIP Line Discipline.

See the tcsetattr(3POSIX) and tcgetattr(3POSIX) man pages for more information.

2.12 POSIX_FILEIO

POSIX_FILEIO, the POSIX compliant I/O system calls feature, has also been removed from the ChorusOS 4.0 operating system as compliant I/O system calls have been integrated into the file system.

For information on POSIX compliant I/O system calls on top of the MSDOS File System, see the MSDOSFS(5FEA) man page. For information on POSIX compliant I/O system calls on top of the UNIX File System, see the UFS(5FEA) man page. For information on POSIX compliant I/O system calls on top of the Network File System implementation, see the NFS_CLIENT(5FEA) man page.