StuBS
|
Although you will implement a fully functional operating system over the course of this semester, you won't have to start completely from scratch – you are provided a very basic skeleton including the boot up code required for the x64 architecture and some helper classes (e.g. for the Advanced Configuration and Power Interface).
There are basically two different variants of StuBS (Studentenbetriebssystem):
Each version has separate handouts, however, they only differ in a few places. If you are still unsure which variant you want to implement, we recommend starting with MPStuBS as it is relatively easy to downgrade from MPStuBS to OOStuBS at a later point in time.
You can find the description of the development environment here.
This website houses both assignments and documentation, in fact, they are quite closely linked: In the class documentation, methods to be implemented or extended are visually marked with a yellow border and contain further details in their descriptions. Optional tasks are marked with blue border. Since OOStuBS and MPStuBS are very similar, the documentation on the website is valid for both variants (if a variant requires special handling, it is explicitly mentioned).
The described class interfaces (and the file structures) are usually required for subsequent assignments, so please try to stick to the specification. However, it is totally fine to add helper attributes/methods/functions (or even classes).
We provide an example solution for each assignment (and variant), usually with a customized example application demonstrating the functionality of the assignments objectives. It can either be executed on the test hardware (in the corresponding Netboot menu) or launched in the emulator: The Makefile
provides a target solution
, which needs to be suffixed with the desired assignment number. For example, to see the solution for assignment 1, execute the following in your project's root on a computer in the sys lab:
make solution-1
In case you don't feel challenged enough by the regular assignments: We will frequently supply you with ideas for voluntary enhancements. These are easily recognizable by blue borders.
Similar to Google C++ Style Guide but with following exceptions:
Use the lint
target (employing cpplint) to check the compliance of your code:
make lint
folder/classname.cc
Implement output (on the CGA Text Mode) and input (via Keyboard). Optionally, you can support the serial interface as well. The Class Overview will help you understand the structure of StuBS.
When it comes to basic debugging in StuBS, output functions are quite essential. For simplicity, TextStream provides the same basic interface as the C++ I/O streams library. It is implemented with the help of the classes OutputStream (which itself is based on Stringbuffer) and TextWindow (based on TextMode, which makes use of the already implemented IOPort).
In case you have successfully solved the (voluntary) assignment 0, you should be able to use your solution of the OutputStream without any modifications.
TextMode is the central abstraction for the text mode, managing the output of characters on the screen and controlling the text cursor position. The derived class TextWindow can be configured via the constructor in such a way that it displays the output on an adjustable rectangular section of the screen. This allows you to divide the screen and have separate TextWindow instances responsible for the output in those individual subareas (so called windows). Furthermore, you can configure whether each corresponding window should use the hardware cursor or not.
To make sure that the output functions can be used everywhere in the operating system, several global TextStream objects should be created:
kout
for application output using the hardware cursor.dout
, whereas MPStuBS uses an array of objects for each CPU core (also called dout
with Core::MAX elements), providing a separate debug window for each core.The file debug/output.h
defines the macro DBG, which employs dout
and should be used for debug output: In MPStuBS this macro will select the dout
object for the corresponding core it is executed on (using Core::getID()).
All instances of the class TextStream should output their output in disjunctive areas of the screen to avoid overlapping output. Instead of statically defining those areas, you can implement an automatic arrangement of the windows as a voluntary extension.
Demonstrate the functionality of the output with the following code:
You can divide this task into three independent parts that can be solved and tested very well individually. We therefore recommend to implement the necessary classes in the following order:
In addition to text output, input via keyboard should also be supported (whereby the test of input is not possible without output). For this purpose you should complete the PS2Controller by using the KeyDecoder (which evaluates Make & Break codes in order to decode pressed keys).
Your test application should repeatedly query pressed keys from the keyboard and print their ASCII values using kout
.
For MPStuBS, the test program should look quite similar to OOStuBS: It is sufficient to run the test application on the first core (aka BSP, boot processor) – the other cores (aka APs, application processors) should only do output using the debug macro to verify their functionality.
kout
, you will end up in an alphabetical jumble. Try to locate the root cause of this issue (you will be able to fix it in subsequent assignments).Extend your StuBS with a serial interface. A SerialStream further enables output in a VT100-compatible terminal. This is useful when debugging your code on real hardware. To test your implementation on real hardware, have a look at Development environment for StuBS for using the serial console on our test machines. Please pay attention to the todo list as well as to the annotations. Not all methods are mandatory, some are voluntary.
Qemu will redirect the COM1
port to a separate tab in the QEMU gui. Click on View
, and select serial0
.