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.
apps/newapp apps/newapp/crt apps/newapp/crt/crt0.c apps/newapp/src apps/newapp/Makefile apps/newapp/Kbuild apps/newapp/Kconfig
# 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
config APP_NEWAPP bool "New app" depends on LIB_SEL4 && HAVE_LIBC && LIB_SOS select HAVE_SEL4_APPS help A new app
source "apps/newapp/Kconfig"
apps-$(CONFIG_APP_NEWAPP) += newapp newapp: $(libc) libsel4 libsos
sos-components-$(CONFIG_APP_NEWAPP) += newapp
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:
exec
ing and kill
ing multiple instances of
sosh
is a good test.
As always you should be able to explain the data structures and algorithms used.