AquilaOS

Hello mmap!

2018-05-20T00:00:00+00:00

The moment I have been avoiding for way too long. Finally we have a very very modest implementation of POSIX mmap, currently we only support MAP_FIXED and only VESA fbdev implements mmap, but it's a good start.

As a demonstration of it, fbterm now uses mmap instead of I/O functions, which should be a lot faster since it now writes to framebuffer directly instead of going through the kernel and I/O functions.

The VMR covering region 0xB0000000 to 0xB0300000 is mapped to VESA framebuffer (using the normal MM API). Private maps will be a lot easier now, with load on demand and all the good stuff in our memory manager :)

Playing with NuklearUI

2018-05-09T00:00:00+00:00

About a month ago, I posted about using Nuklear GUI library in AquilaOS. We also have a video of NuklearUI with custom font, images and wallpaper. I have been trying to wrap my head around the code, understanding exactly how Nuklear works and how to convert it to client/server model instead of a single binary hosting all windows.

I decided that the server would do the compositing and window decorations while each client would be responsible for drawing the window contents (widgets, canvas, etc). From my understanding of Nuklear, it uses a single context structure to do about everything, so in order to seperate window content from compositor, each window would have a seperate context structure and the compositor would have a single context structure.

Mouse & Keyboard in Nuklear

My first problem was how to integrate mouse & keyboard support into NuklearUI properly. In the first trials and the video shown above, the application simply reads (blocking I/O) from /dev/mouse and translates the packets at each iteration, but since the read was blocking, if the mouse doesn't move (buffer empty) the screen is not redrawn. Later on I decided to use a seperate thread that reads from /dev/mouse and fills in an internal ring buffer, then the application would simply scan the ring buffer at each iteration and process input if any is available. I then used the same idea for keyboard, but instead of reading from /dev/kbd directly (and go through scancode translation and processing) I decided to simply read from stdin which is hooked to a terminal (we go into non-canonical mode and read input) the input is buffered to a ring just as in mouse. All in all, it works and here is an eye candy:

Window Compositing

So we need a version of Nuklear that does compositing only. I stripped down Nuklear to the bare minimum required for compositing and window decorations (almost all widgets are removed) and used it to build a simple compositing application. In the application I created a simple window with no content, then I created a seperate Nuklear context and created a window in it that starts at the top left corner of the screen, has no borders or title bar and draws a single widget, a button. The context which has the window contents is then rendered to a back buffer and an nk_image is exported. The compositor would then render the nk_image inside the empty window created in it (using a custom command buffer command -- it just copies the nk_image contents to the window buffer), and here is the result:

The first thing you would notice is the two cursors, this is because the contents of the window is an entirely seperate Nuklear context (which has its own cursor), this was easily solved by hiding the cursor. But that is not the major problem, now since we have two different contexts, we must find a way to send input relevant to window contents to the other context.

Compositor Input Handling

This is the part that need most attention to exactly how Nuklear works. Since the compositor keeps track of window position and bounds, we could easily check if mouse is in window region. Also we can check if window is active (by checking if its top-most window, i.e. window == ctx->end). We then get the bounds of the contents region (Nuklear people are generous enough to have a function for that) and then calculate the relative mouse offsets inside the window contents region. We then send the input event to the other context and make it redraw to back buffer.

And since we also check if window is currently active, the input is only passed if the window actually has focus, so overlaying windows are handleled correctly, as shown.

This is all for now, I can say that I believe this may actually work just fine. I still have to figure out many things but so far so good! Stay tuned for upcoming updates. Happy hacking ;)

Memory Management System Redesign

2018-05-07T00:00:00+00:00

I won't lie, memory management is the most frustrating thing in OS design for me. It takes the most time and debugging it is nevertheless exhausting. I have, however, redesigned it to be more generic than before and relax much more arch. dependent code.

The New Design

Physical Memory Management

AquilaOS uses zoned buddy memory allocation technique, which is used in Linux and many *BSDs. Currently we only have two zones ZONE_DMA and ZONE_NORMAL which have identical functionality to that found in Linux.

Virtual Memory Management

In the new design, the kernel deals with a one level of paging while the archticture handles the intermediate paging levels. Now each process has defined memory mapped regions wich is either lazily loaded from file, lazily allocated or lazily copied on fork. This allows for very efficient memory use (even the stack is allocated on demand). And finally, AquilaOS has no more memory leaks.

Nuklear based GUI

2018-04-09T00:00:00+00:00

I have been looking into various options of GUI/Windowing systems to implement in AquilaOS and here is what I found so far

X

While X is the defacto when it comes to GUI, it is extremely heavy, mostly optimized for Linux and requires too much dependencies.

Wayland

Wayland is a little promising than X due to its lightweight design, however it still makes certain assumptions about the underlying kernel that might not be very easy for everyone to support.

Picogui

That could have been a really promising project, only now it is deprecated and way out-of-sync.

Nuklear

Well, first, Nuklear should have not been on this list, it is not a replacement for X server but it supports a few features that took my interest way too far:

Extrememly portable, doesn't even depend on libc!
Entirely written in C with many bindings
Has a basic windowing system and widgets
Can be optimized to use HW acceleration for various targets easily
It's design is simple and straightforward

All in all, Nuklear is an amazing GUI library, well done Micha Mettke!

So, one could say that Nuklear is a replacement for GTK/X for example, only Nuklear is not based on a server/client model, all applications are hosted in the same binary and executed as a single program.

However, that doesn't stop us from trying to make it work as a server/client model, I've started project NuklearUI exactly for that, it should serve as a starting point for OSDevers willing to incorportate a GUI system in their OS with minimum requirements. My first idea is to use POSIX shared-memory for communication due to its simplicity, but we could think of other design patterns (like Nuklear would be fully contained in kernel space). I will try to make that decision on the developer side.

Currently, there isn't much, other than some "Hello, Nuklear!" stuff. I just managed to implement a basic PS/2 Keyboard & Mouse drivers and Aquila framebuffer backend, it works as a standalone application and safetly returns to fbterm (and shell).

Here is a screenshot of a demo of Nuklear running on AquilaOS

And a video showing the switch between fbterm and Nuklear https://youtu.be/gfuRbHAGhl8

First post!

2018-02-17T00:00:00+00:00

This is my first post, how exciting!