mirror of
https://github.com/drasko/codezero.git
synced 2026-01-12 02:43:15 +01:00
Tasks boot fine up to doing ipc using their utcbs. UTCB PLAN: - Push ipc registers into private environment instead of a shared utcb, but map-in a shared utcb to pass on long data to server tasks. - Shared utcb has unique virtual address for every thread. - Forked child does inherit parent's utcb, but cannot use it to communicate to any server. It must explicitly obtain its own utcb for that. - Clone could have a flag to explicitly not inherit parent utcb, which is the right thing to do. - MM0 serves a syscall to obtain self utcb. - By this method, upon forks tasks don't need to map-in a utcb unless they want to pass long data.
141 lines
7.1 KiB
Plaintext
141 lines
7.1 KiB
Plaintext
|
|
Codezero Microkernel 'Toy' release
|
|
|
|
Copyright (C) 2007 Bahadir Balban
|
|
|
|
|
|
What is Codezero?
|
|
|
|
Codezero is a small microkernel based on the L4 microkernel principles and has
|
|
its own interpretation of the L4 microkernel API. In addition, it has server
|
|
tasks that implement memory management, a virtual filesystem layer, and these
|
|
servers currently support a small but essential subset of the POSIX API.
|
|
|
|
Codezero project is an effort to implement a modern, open source operating
|
|
system based on the latest technology in microkernel and OS design. It targets
|
|
realtime, high-end embedded systems and has an emphasis on the ARM architecture.
|
|
|
|
It is quite common to see open source projects developed in a closed-doors
|
|
fashion. Codezero project goes beyond just publishing source code as open source
|
|
but also uses the latest open source development practices such as those used by
|
|
the Linux Kernel.
|
|
|
|
|
|
Why the name Codezero?
|
|
|
|
The project focuses on simplicity, elegance, cleanliness, which are important
|
|
assets in software engineering. The philosophy is to implement a structurally
|
|
complete system with most modern OS features while retaining simplicity in the
|
|
implementation as much as possible. This objective also fits well with embedded
|
|
platforms, which usually have rigorous memory and performance requirements. Also
|
|
the project is written from scratch, so the name emphasises that.
|
|
|
|
|
|
Design & Features:
|
|
|
|
Based on L4 microkernel principles, there are only a few system calls in
|
|
Codezero. These system calls provide purely mechanism; threads and address
|
|
spaces, and the methods of inter-process communication between them. Anything
|
|
beyond these are policy and they are implemented in the userspace. Due to this
|
|
rigorously simple design the same microkernel can be used to design completely
|
|
different operating systems.
|
|
|
|
In terms of other features, the microkernel is preemptive, and smp-ready.
|
|
Currently only synchronous communication is implemented, but this will change in
|
|
the near future.
|
|
|
|
MM0 is the system task that implements memory management. It contains memory and
|
|
page allocators. It implements demand paging by managing page faults, physical
|
|
pages and their file/task associations. It provides the default paging mechanism
|
|
on Codezero.
|
|
|
|
FS0 is the system task that implements a simple, modern virtual filesystem layer.
|
|
It is designed to serve file requests from MM0. Since it abstracts the low-level
|
|
filesystem details, it is a relatively easy job to port a new filesystem to be
|
|
used under FS0.
|
|
|
|
MM0 and FS0 both reside in the userspace, and they are not mandatory services.
|
|
For example the virtual and physical memory resources can be partitioned by
|
|
Codezero among pagers, and a third-party pager can override Codezero's MM0
|
|
pager on the same run-time, and implement an independent paging behaviour
|
|
for its own memory partition. This feature provides the option of having an
|
|
adjustable mixture of generalisation and specialisation of system services at
|
|
the same run-time, by using a combination of Codezero's abstract posix-like
|
|
page/file management services and an application-specific pager that depends on
|
|
its own paging abilities. For example a critical task could both use posix-like
|
|
files benefiting from the abstraction and simplification that it brings, but at
|
|
the same time rely on its own page-fault handling for its critical data so that
|
|
even though it handles its memory in a specialised way, it does not depend on
|
|
another pager's grace for correct, stable operation.
|
|
|
|
|
|
License:
|
|
|
|
The current 'Toy' release is distributed under GNU General Public License
|
|
Version 3 and this version only. Any next version will be released in the same
|
|
license, but there are intentions to keep the project in a dual-licensed manner.
|
|
In any case, the project source code will always be released as open source as
|
|
in the OSI definition, and with copyleft clauses.
|
|
|
|
The third party source code under the directories loader/ tools/ libs/c libs/elf
|
|
have their own copyright and licenses, separate from this project. All third
|
|
party source code is open source in the OSI definition. Please check these
|
|
directories for their respective licenses.
|
|
|
|
|
|
Why yet another POSIX microkernel?
|
|
|
|
There are many open source POSIX operating systems with advanced features such
|
|
as BSD versions and Linux. However, neither of these were originally designed
|
|
for embedded systems. Multiple problems arise due to this fact.
|
|
|
|
These systems are well established. They target a broad range of platforms and
|
|
uses, but consequently their user base has saturated, and embedded platforms
|
|
don't get enough emphasis.
|
|
|
|
Unix itself and all the tools built upon weren't meant for using on small
|
|
devices. Accordingly, these operating systems contain a lot of historical code.
|
|
Their code base is so big, that it gets more and more difficult to understand
|
|
how their internals work. On these systems usually much of the code is
|
|
irrelevant to a new problem, and embedded systems tend to raise new problems
|
|
often. Codezero is written from scratch to solely target embedded systems and
|
|
as such the source code is %100 relevant. It is small and free from legacy code.
|
|
|
|
From a design perspective, these kernels have a monolithic design, and as such
|
|
they may have issues with dependability due to much of the code sharing the same
|
|
address space. This is an important issue on embedded systems since their
|
|
operation is more sensitive to disruptions. Being a microkernel design, Codezero
|
|
aims to defeat this problem and increase dependability.
|
|
|
|
Other than these modern kernels, there are existing operating systems targeting
|
|
embedded devices. Most of them are proprietary, with their own users. Some of
|
|
them are structurally too simplistic, and lack modern features such as paging.
|
|
There ones that are well established, but Codezero will contrast them by
|
|
providing an alternative that will follow the open source development principles
|
|
more closely. Many embedded software projects still use older development
|
|
methods and the right open source methodology would prove favorable in the
|
|
fast-paced nature of development.
|
|
|
|
Finally, there are new ideas in literature that would improve systems software
|
|
but aren't implemented either because they have no existing users or may break
|
|
compatibility (e.g. some are presented in Plan 9). Existing kernels tend to
|
|
oppose major design overhauls, which limits their innovation capability for this
|
|
kind of experimentation. As well as practising realistic development methods
|
|
Codezero project aims to keep up with the latest OS literature and provide the
|
|
opportunity to incorporate the latest ideas in OS technology.
|
|
|
|
|
|
Can you summarise all this? Why should I use Codezero, again?
|
|
|
|
Codezero is an operating system that targets embedded systems. It supports the
|
|
most fundamental posix features. Different from other posix-like systems,
|
|
it is based on a microkernel design. It supports modern features such as
|
|
demand-paging, virtual filesystem support. It has a cleanly separated set of
|
|
services, and it is small. For these reasons it is a good candidate as systems
|
|
software to be used on embedded systems. Currently it has little or no users,
|
|
therefore compared to systems with a saturated user base it is possible to
|
|
tailor it rapidly towards the needs of any users who want to be the first to
|
|
incorporate it to their needs.
|
|
|
|
|