[CSE]  Advanced Operating Systems 
COMP9242 2017/S2 
CRICOS Provider
Number: 00098G

PRINTER Printer-Friendly Version

M7: Process management

Currently your operating system has only been able to run one process, probably sosh. In this milestone you will implement the process related system calls: process_create, process_delete, my_id, process_status and process_wait. Obviously each new process should run in its own address space. This will require you to carefully manage seL4 address spaces.

Currently process_create need only run executables that have been archived by the cpio program and placed in the boot image. All the functionality for process creation can be found in the start_first_process() in main.c. You can use this as a guide to create a clean internal SOS interface to process creation and destruction.

sosh has an exec command. This command provides a simple interface to the process_create system call. In a similar style to UNIX shells, if the third argument to exec is an '&' then it will run the process in the background. Otherwise sosh will use process_wait to wait until the child process has finished executing.

Note: the difficult part of this milestone is not process creation, it is process deletion. Now you will discover whether the data structures you have chosen have kept enough information for you to clean up a process and return the resource to the various allocators.

Adding new applications

  • Create the following folder structure for your new app:
  • Copy and appropriately modify the crt0.c from sosh or tty_test.
  • Use the following Makefile template to create the Makefile:
               # Targets
    TARGETS := newapp.bin
    # Source files required to build the target
    CFILES   := $(patsubst $(SOURCE_DIR)/%,%,$(wildcard $(SOURCE_DIR)/src/*.c))
    CFILES   += $(patsubst $(SOURCE_DIR)/%,%,$(wildcard $(SOURCE_DIR)/crt/*.c))
    # Libraries required to build the target
    LIBS := muslc sel4 sos
    #export DEBUG=1
    include $(SEL4_COMMON)/common.mk
  • Use the following Kconfig template to create a Kconfig file:
    config APP_NEWAPP
        bool "New app"
        depends on LIB_SEL4 && HAVE_LIBC && LIB_SOS
        select HAVE_SEL4_APPS
            A new app

Build system integration

  • Modify the top level Kconfig file, adding the following line:
    source "apps/newapp/Kconfig"
  • Modify the apps/newapp/Kbuild file, to look like:
    apps-$(CONFIG_APP_NEWAPP) += newapp
    newapp: $(libc) libsel4 libsos
  • Modify the apps/sos/Kbuild file to know about your new application and build it into the SOS cpio archive. Add the following line (where intuitively appropriate):
    sos-components-$(CONFIG_APP_NEWAPP) += newapp
  • Lastly, you need to include your new application in the build process by selecting it in the configuration menu.

Design issues

As with most milestones, a lot of the design work will be working out suitable data structures to hold process information. You may also need to extend other data structures in your operating system to handle multiple processes.

You also probably want to check how the crt works, so you can make sure that when a process's main function exits it will kill itself.

Processes require some kind of ID. IDs should eventually be re-used, but they should not be re-used to soon to avoid race conditions.

New processes should have stdout and stderr already opened on file descriptors 1 and 2, respectively; this is assumed by muslc. For apps that require stdin, it must be explicitly opened before performing any I/O and must be allocated to file descriptor 0. If you implemented the lowest-available policy, simply open console as the first file syscall in your app. Since SOS implements a single-reader console policy, you must be prepared for this to fail.

Remember, anything allocated while a process runs should be de-allocated when it exits or is killed (e.g. in-kernel TCB, frames, paging file space, etc..).



You should show sosh executing a sub-process and show that the ps and kill commands work. Hint: execing and killing multiple instances of sosh is a good test.

As always you should be able to explain the data structures and algorithms used.

Show Stoppers

  • Leaking process IDs (e.g. a monotonically increasing counter with no strategy for wrap around).
  • Recycling process IDs immediately.
  • Only supporting < 16 processes.
  • More than constant time lookup from process ID to the PCB.
  • Not handling or cleaning up outstanding async requests when a process exists (or after it exits).
  • Failing to free paging file space on process destruction.

Better Solutions

  • A sound strategy for handling waiting on a process that exited quickly (before the call to wait).

Last modified: 20 Jul 2017.