Example init descriptions

This section provides examples of init descriptions that demonstrate various aspects of starting processes.

Starting a client and server and creating an IPC channel between them

In this example, a process of the Client class and a process of the Server class are started. The names of the processes are not specified, so they will match the names of their respective process classes. The names of the executable files are not specified, so they will also match the names of their respective process classes. The processes will be connected by an IPC channel named server_connection.

init.yaml

entities:

- name: Client

connections:

- target: Server

id: server_connection

- name: Server

Starting processes from defined executable files

This example will start a Client-class process from the executable file named cl, a ClientServer-class process from the executable file named csr, and a MainServer-class process from the executable file named msr. The names of the processes are not specified, so they will match the names of their respective process classes.

init.yaml

entities:

- name: Client

path: cl

- name: ClientServer

path: csr

- name: MainServer

path: msr

Starting two processes from the same executable file

This example will start a Client-class process from the executable file named Client, and two processes of the MainServer and BkServer classes from the executable file named srv. The names of the processes are not specified, so they will match the names of their respective process classes.

init.yaml

entities:

- name: Client

- name: MainServer

path: srv

- name: BkServer

path: srv

Starting two servers of the same class and a client, and creating IPC channels between the client and servers

This example will start a Client-class process (named Client) and two Server-class processes named UserServer and PrivilegedServer. The client will be connected to the servers via IPC channels named server_connection_us and server_connection_ps. The names of the executable files are not specified, so they will match the names of their respective process classes.

init.yaml

entities:

- name: Client

connections:

- id: server_connection_us

target: UserServer

- id: server_connection_ps

target: PrivilegedServer

- task: UserServer

name: Server

- task: PrivilegedServer

name: Server

Setting the startup parameters and environment variables of programs

This example will start a VfsFirst-class process (named VfsFirst) and a VfsSecond-class process (named VfsSecond). The program that will run in the context of the VfsFirst process will be started with the parameter -f /etc/fstab, and will receive the ROOTFS environment variable with the value ramdisk0,0 / ext2 0 and the UNMAP_ROMFS environment variable with the value 1. The program that will run in the context of the VfsSecond process will be started with the -l devfs /dev devfs 0 parameter. The names of the executable files are not specified, so they will match the names of their respective process classes.

init.yaml

entities:

- name: VfsFirst

args:

- -f

- /etc/fstab

env:

ROOTFS: ramdisk0,0 / ext2 0

UNMAP_ROMFS: 1

- name: VfsSecond

args:

- -l

- devfs /dev devfs 0

On hardware platforms with x86 and x86-64 processor architectures, you can define program startup parameters and environment variables not only with fixed values but also with links to kernel startup parameters:

• ${BOOTARG:<name of the kernel startup parameter>[:=<default program startup parameter value>]}

  The specified program startup parameter takes the value of the kernel startup parameter with the defined name. You also have the option to specify a default value that is applied if the kernel startup parameter with the defined name is not passed to the kernel. If the default value is not specified, and the kernel startup parameter with the defined name is not passed to the kernel, the defined program startup parameter will not be passed to the program.

  Example:

  args:

  - ${BOOTARG:ROOTFS:=/opt/data}

  - ${BOOTARG:test_switch}

  - -f ${BOOTARG:FSTAB:=/etc/fstab}

  - --message ${BOOTARG:MOTD}

  - --timeout=${BOOTARG:timeout:=60}

• <name of the program environment variable>: $ {BOOTARG:<name of the kernel startup parameter>[:=<default program environment variable value>]}

  The program environment variable with the defined name takes the value of the kernel startup parameter with the defined name. You also have the option to specify a default value that is applied if the kernel startup parameter with the defined name is not passed to the kernel. If no default value is specified and the kernel startup parameter with the defined name is not passed to the kernel, the program environment variable with the defined name will not be created.

  Example:

  env:

  rootdir: ${BOOTARG:FS:=/home}

Kernel startup parameters that are passed to programs as startup parameters and environment variables have the following format:

<name>=<value>

To pass parameters via the kernel command line to QEMU, use the QEMU startup parameter -append.

Example of setting kernel startup parameters on QEMU using the CMake command build_kos_qemu_image():

set(QEMU_FLAGS "-append \"ROOTFS=/opt/data test_switch=-b FSTAB=/etc/fstab MOTD=Hello! timeout=30 FS=/home\"")

build_kos_qemu_image(kos-qemu-image

...

QEMU_FLAGS "${QEMU_FLAGS}")

To find out how to pass parameters via the command line of the kernel on a hardware platform, please refer to the documentation for the loader that you are using.

Setting the startup order of processes and the signs of successful startup of a process

In this example:

• The Einit process will mount the additional romfs.1 file system to the romfs/1 mount point.
• The Server class process will be started from the server file in the main ROMFS file system before processes of the Client_A and Client_B classes. The Einit program will wait for the em_notify_ready() signal from the Server.
• The Client_A class process will be started from the romfs/1/client_a file after the Server class process. The Einit program will wait for the main() function to run successfully in Client_A.
• The Client_B class process will be started from the romfs/1/client_b file after the Server and Client_A class process. The Einit program will wait five minutes for Client_B to finish successfully.

init.yaml

mount_romfs:

"romfs.1": "romfs/1"

entities:

-name: Server

path: "server"

wait_for: ready

before:

- Client_A

- Client_B

-name: Client_A

path: "romfs/1/client_a"

wait_for: start

after:

- Server

-name: Client_B

path: "romfs/1/client_b"

wait_for: { event: exit_success, timeout: 5min }

after:

- Client_A

- Server

Page top