M7: Process management
Currently your operating system has only been able to run one process,
sosh. In this milestone you will implement the
process related system calls:
process_wait. Obviously each
new process should run in its own address space. This will require you to
carefully manage seL4 address spaces.
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
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
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 := 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
- Use the following Kconfig template to create a Kconfig file:
bool "New app"
depends on LIB_SEL4 && HAVE_LIBC && LIB_SOS
A new app
Build system integration
- Modify the top level Kconfig file, adding the following line:
- 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.
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
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
New processes should have
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
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
kill commands work. Hint:
killing multiple instances of
sosh is a good test.
As always you should be able to explain the data structures and
- 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
- 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.
- A sound strategy for handling waiting on a process that exited
quickly (before the call to wait).
20 Jul 2017.