SerenityOS - Architectural decisions

Indentification of key scalability challenges

SerenityOS is an graphical Unix-like operating system which supports the x86 and x86-64 instruction sets, features a preemptive kernel, and hosts multiple complex applications including its own web browser and integrated development environment (IDE)¹. All stakeholders have various needs and preferences and what they expect from SerenityOS are quite different. Therefore, it would be advantageous to stakeholders if SerenityOS exhibits great scalability.

In this article, we discuss the scalability of SerenityOS in four aspects: Modularity, Reusablity, Configurability and Design Consistency. They will be explored as follows:

Modularity

A modular design is an approach for product designing which is used to produce a complete product by integrating or combining smaller parts that are independent of each other. With the modular design approach, a complex product (in this case, SerenityOS) can be broken down or divided into smaller and simpler components that are independently designed and manufactured. Each of these individual components is then integrated (or assembled) together to form the final product. Modularity is essential for code reuse, separate compilation, incremental build, distributed deployment, etc. Even though C++ doesn’t have modules as a programming language, SerenityOS does have a structral decomposition of the architecture that is shown below. ²

Reusability

When developers want to scale up their design, code reusability is an important issue to consider. Reusability measures how many times a block of software can be used for different purposes. There are two types of reuse mechanisms, namely Fork (duplication) and Reference (dependencies). To guarantee reusability, components should possess trusted quality, standarized and documented interfaces. The ability to reuse relies in an essential way on the ability to build larger things from smaller parts, and being able to identify commonalities among those parts.³ Reusability implies some explicit management of build, packaging, distribution, installation, configuration, deployment, maintenance and upgrade issues. If these issues are not considered, software may appear to be reusable from design point of view, but will not be reused in practice.

In SerenityOS, reusability takes the form of common libraries which other components of the project are using to optimize tasks. Within the folder AK, there are plenty of files with suffix .h invoked by other modules, such as Math.h, ByteReader.h and URL.h.

Configurability

Configurability implies that the software allows system behavior to be varied by a small amount of user input. The more configurable a system is:⁴

• The more of this the user can do.
• The higher reuse is.
• The cheaper the system is.
• The faster it can be built.
• The more defect free it tends to be.

Users have different tastes and preferences and what they want from SerenityOS are quite varied. Therefore, software can have wider group of users with Configurability.

Design Consistency

Consistency is when all the elements of the design behave in the same way or follow the set pattern.⁵ To ensures the product matches customer expectations and users easily understand how to use the product, developers should creating a product that displays consistency in all its elements.

Modularity on Hardware

SerenityOS is a Unix-based operating system, and its tailorability is one of its major advantages. Developers can cut down the functions of kenel and userland as needed to reduce system size. For example, developers can cut out the graphics display of the entire os and only perform system operations through the command line. Thinking of this, we explored the tailorability and adaptability of Serenity os on different hardware platforms. First of all, in the mainstream liunx PC, qemu is used as the simulation platform to be compatible with most mainstream PCs. Users only need to install C++11 and complete the build with qumu to run. (For less popular linux distributions, such as openSUSE, Alpine Linux, OpenBSD, FreeBSD are all compatible). On the Raspberry Pi, Serenity doesn’t currently boot on Rasperry Pi, and it is only used for developer purposes to perform the same simulation as on the pc through qemu. However, on the Raspberry Pi, users can replace the kenel image and use the kernel of serenity os to run the environment. The official Serenity OS documentation also provides a list of currently compatible bootable hardware, including Network Adapters, Desktop machines, Laptops, notebooks and netbooks, and Motherboards.Compatible bootable hardware

Identified issues for system’s architecture

Serenity OS was originally developed by Andreas Kling alone, and then many dedicated to building their own retro unix system to contribute. Therefore, this open source software does not have a complete business model, but exists in the form of a geek project. Serenity OS was originally developed by Andreas Kling alone, and then many dedicated to building their own retro unix system to contribute. Therefore, this open source software does not have a complete business model, but exists in the form of a geek project. Therefore, although this open source software has a high degree of modularity, it does not have accessibility and has high third-party compatibility difficulties. For example, if Microsoft wants to cooperate with serenityos to use vscode as an ide on serenityos, then Microsoft cannot find a suitable general API interface, web server and required data structures, and the development language only has the option of C++, access to rust or Java also needs to be extended by itself. At the same time, the third party has to participate in the version iteration as a contributor rather than a cooperative identity, so there is also a slow review process, and the resolution of issues is also inefficient.

Proposal for architecture changes

As an operating system that does not use third-party code,Serenity OS has its own kernel, shell, desktop, libraries, etc. They are all written by developers in C++ with the kernel and user controls use custom standard libraries⁶. Since it dose not depend on the third-party libraries,the process is complicated for other developers to add their own libraries or functional applications.For example,they often need to write the complete code for the module or function they want to implement according to the project’s code submission policy⁷, and then add the module to the system architecture.

In order to achieve better modularity and extensibility of the system, we propose to allow the import of third-party libraries or code to implement certain features in the system architecture. Installing third-party libraries in the operating system is simplified as follows: first find the required library source, then add it to the folder path, and finally compile, test and run it. Currently developers use CMake to manage and compile project, which also provides a standardized procedure for adding external libraries, which also facilitates the addition of external libraries⁸.

Diagrams in a standard notation depicting the “as is” and the “to be” architectural designs

SerenityOS is a *nix-like system. One of the goals of SerenityOS is to develop an operating system that can be used independently as the main operating system of the host computer.⁶ But SerenityOS is an open-source project with no management operations team who will plan the project’s development roadmap but only project maintainers.

Currently, the architectural design of the future version is not settled for the SerenityOS project. Many functions and features are only raised as issues to develop when some contributors need some features in the library or the main project contributor, and project maintainers who have ideas on the difference between the general structure of the current structure and what they want will post some features that need to be implemented as a task list in the issue. As one of the issue policies of the SerenityOS, when some features are wanted on the SerenityOS, one should develop them himself.

From the project description, we can make a feature diagram with a basic structure similar to the Linux system, Kernel space user space structure.

Even the project doesn’t have a clear development plan, due to the final goal of developing an independent operating system that can use as the main operating system, we can still use a structure of a Linux system as a future design to compare with and learn about the difference between the current version and the target.

We can see that most of the kernel functions of the SerenityOS have been realized compared to the Linux system. But one can see that the System call interface is not listed in the description. These system calls are actually implemented in the library LibMain. We can find some of these features still haven’t been realized in an open issue of the project. This also indicates the current situation of the project that there is no clear development roadmap for SerenityOS. Some features are only raised as an issue and start to develop when developers run into the scenario that they need a certain function but find out it hasn’t been implemented yet.

Argument showing how the proposed changes will address the identified scalability issues

Here we will indicate the reason why we propose the architecture change that allows third-party library and code to be used in the SerenityOS. By analyzing an open issue that was raised for developing a new application in SerenityOS. This open issue is actually to implement the SerenityOS version of Discord. The open issue provides a checklist of the features that need to be implemented for Discord as an application itself. But it also raises some requirements for new features or functions in the LibWeb – the HTML/CSS engine library. This library is currently listed in the readme document as a feature or library that can be directly used in the SerenityOS like the library of the C++ templates and containers AK, where AK library is already be implemented as a base library for all the applications.

This means key libraries the project provides have to be modified frequently to expand its support features if there is a new application that has the requirement for using some features they haven’t considered before. Before the functions or features have been implemented in the library, the development of the application in the SerenityOS can not push on.

However, by allowing third-party libraries, such as WebKit, which is a mature open-source web browser engine, the development of the Userland application like Discord won’t need to wait until the features in the library are implemented by some contributor who is interested in developing library.

We do notice that the project sponsor intends to develop the SerenityOS with no third-party code.⁶ But from the business view, without third-party code, the goal of developing the SerenityOS into an independent operating system that can be used as a main operating system will be hard to realize.

Because as a host operating system, it should be able to handle new applications from new user requirements.

In this development pattern, with the project growing, project contributors will have to learn more details about the operating system and library features to see whether there are features they need but are not supported. The project maintainer must learn more details from upper-level kernel function to bottom-level application development. This increases the hardness of developing SerenityOS into a main operating system.

Therefore, from the view of developing the SerenityOS into a usable main operating system for the host computer, we propose to add the third-party code. But of course, SerenityOS can still work as a project that provides practicing opportunities for developers who are interesting in the operating system and application from scratch.

Reference

---

1. Wikipedia SerenityOS.from https://en.wikipedia.org/wiki/SerenityOS ↩︎

2. What is a Modular Design? Everything You Want to Know in 8 Easy Answers!https://www.jigsawacademy.com/blogs/product-management/modular-design/ ↩︎

3. Wikipedia Reusability.from https://en.wikipedia.org/wiki/Reusability ↩︎

4. Configurability SerenityOS.from https://www.thwink.org/soft/article/future_app_dev/Configurability.html#:~:text=Configurability%20is%20that%20quality%20allowing,this%20the%20user%20can%20do. ↩︎

5. Consistency SerenityOS.from https://medium.com/nyc-design/why-design-consistency-is-crucial-4e7b117bbef6 ↩︎

6. Blog SerenityOS.from https://blog.jetbrains.com/clion/2021/11/talking-to-serenityos-contributors/ ↩︎

7. Github Codeing Style. from https://github.com/SerenityOS/serenity/blob/master/Documentation/CodingStyle.md ↩︎

8. Github Codeing Style. from https://www.selectiveintellect.net/blog/2016/7/29/using-cmake-to-add-third-party-libraries-to-your-project-1 ↩︎