Version 0.1.4

Changelog

• Started working towards multi-core support.
  However, the system is still only functional in single-core mode.

• I fixed a ton of race conditions and the application is usable again.

• I added a nice video to show of the project.

Version 0.1.3

Changelog

• Read from UART via DMA to avoid races and to avoid dropping data if input arrives quickly. This also greatly increased the buffer size.
• Choose a license for the project.
• Enable at least some compiler warnings.
• Fix all sorts of minor issues.

Version 0.1.2

Now we don't block the entire kernel when waiting for user input. The disadvantage is that we sometimes drop characters because the input queue of the UART device is disabled.

Changelog

Features

• Accept UART via interrupt

• Execute system calls outside of interrupt handlers and block threads from scheduling.

• Use RefPtr<T> to keep track of complex relationships instead of leaking the memory.

Bugs

• Lookup devices via VirtualFile::m_device_id instead of runtime objects.

Version 0.1.1

Now, it is possible to run applications many times without running out of memory.

This wasn't possible previously because the memory regions that are allocated for new processes were not freed.

Changelog

Features

• Utilize buddy page allocator instead of allocating twice as much memory for alignment.

Tweaks

• Editor.elf can now loads the file passed in the first argument.

Bugs:

• argv and envp were allocated in kernel memory and thus inaccessible to userland processes.

• Free previous stack when loading executable.

• Free allocated regions when destroying threads.

Acceptance Test

Example.elf
Example.elf
Example.elf
Example.elf
Example.elf
Example.elf
Example.elf
Example.elf
Example.elf
Editor.elf example.txt
% p
% q

Version 0.1.0

At this point it should be sensible to call this an "operating system". Most of the basic functionality is there.

Syscalls

The following system calls are supported:

i32 sys$read(i32 fd, u8 *buffer, usize count);
i32 sys$write(i32 fd, const u8 *buffer, usize count);
i32 sys$open(const char *pathname, u32 flags, u32 mode);
i32 sys$close(i32 fd);
i32 sys$fstat(i32 fd, UserlandFileInfo *statbuf);
i32 sys$wait(i32 *status);
i32 sys$exit(i32 status);
i32 sys$chdir(const char *pathname);
i32 sys$get_working_directory(u8 *buffer, usize *size);

i32 sys$posix_spawn(
    i32 *pid,
    const char *pathname,
    const UserlandSpawnFileActions *file_actions,
    const UserlandSpawnAttributes *attrp,
    char **argv,
    char **envp);

However, most of the functionality is only mocked. Notice that fork() is not supported because a Cortex-M0+ does not posses an MMU. Originally, vfork() was supported but posix_spawn() is simply better.

Acceptance Test

The following script can be executed on the system to illustrate it's capability:

echo foo bar
stat /example.txt
ls
cd /bin
ls ../dev
cat /example.txt
touch foo
cat foo
Editor.elf
% 0a
% bar
% .
% w foo
% q
cat foo
Shell.elf
ls

Isolation and Security

Since this is (more or less) a microcontroller, only very basic protection is possible, and currently there is not even much done for that.

Secure:

• User code is executed unprivileged.

• There is basic memory isolation, the user code can not write into kernel memory directly.

Insecure:

• Currently, there is a "handler trampoline" in place that simply executes a provided function pointer without checking anything.

• The user code can read the kernel code, which is problematic but acceptable.

• Bugs, lots of bugs.