OSDev.org

Hello everyone, this is my first post here.
I'm working on a POSIX-compliant operating system, called AquilaOS. Currently it has some good features for me to announce it.

----- UPDATE: Release -----
https://github.com/mohamed-anwar/Aquila ... v-build003

This is the command I use to start it, "-serial stdio" is used to show debug log and everything else should be self-explanatory. You can use any other VM though, VirtualBox works just fine too.


Here are some of the details you might concern yourself with:
* Kernel:
- Topology: Monolithic (no loadable modules yet).
* Arch:
- x86 32bit (though the kernel is designed to be ISA transparent, arch. dependent parts are handled with arch_ stubs)
* Memory Management:
- Physical Memory: 32-bit paging mode (4K pages), Buddy Algorithm for frame allocation
- Kernel Objects: Simple Linked List (implemented using an array), unified interface, no SLxB (yet).
- Forking: Lazy, copy-on-write.
- Userspace allocation: sbrk() interface only, lazy, allocate on demand.
* Process Management:
- Executable format: ELF only
- Scheduling algorithm: Simple round-robin algorithm for ready queue, no prioritization, constant time quanta.
- I/O handling: Both blocking (sleeping on read/write queues) and non-blocking are supported.
* Filesystems:
- Virtual filesystem: Mountpoints are handled with a tree
- initramfs: Used for ramdisk, supports CPIO archive (read only).
- tmpfs: Generic temporary filesystem (read/write).
- devfs: Just a tmpfs with static device nodes (the kernel doesn't populate devices yet).
- devpts: Just a tmpfs for pty slaves (automatically populated by the kernel).
- procfs: Simple (dumb) procfs implementation.
- ext2: Simple ext2 fs handler, no caching yet.
* Devices:
Kernel devices subsystem is called "kdev" and uses major/minor numbers same as LANANA.
- Basic stuff: i8042 (PS/2), PS/2 Keyboard, IBM TGA console.
- ATA: PIO mode only for now, lame, I know.
- fbdev: Framebuffer device, Linux API (Currently, only VESA 3.0 is partially supported).
- tty: Generic tty interface that could be attached to any device (pty, console, uart).
* System: (This is where the fun is)
- All implemented interfaces are POSIX compatible. (susv4tc1 standard)
- C Library: newlib-3.0.0.
- fbterm: Framebuffer based terminal (built using libvterm).
- aqbox: Aquila Box (like busybox) with (partial) support for (cat, clear, echo, env, ls, mkdir, mknod, ps, pwd, stat, uname, unlink, mount, login) utilities.
- tcc: Tiny C Compiler by Fabrice Bellard (distributed as binary).
- lua: Lua 5 programming language (distributed as binary).
- kilo: Text editor that interacts with VT100/ANSI terminal (distributed as binary).

Build Instructions:
- You need to build GCC generic compiler and Newlib, will fetch and build everything, beware though that some packages have dependencies (like makeinfo), it's a lengthy and tiring process, I'll provide the build binaries later but can't right now.
- After that in the root directory should build everything, it depends on cpio and grub2-mkrescue (provided in Fedora, Ubuntu users may need to use grub-mkrescue instead).

Transparently booting to UART console. Because ... UNIX ...

Wow! It looks very nice! Unfortunately, I was unable to get it to run using the provided binary and the command line you used (except I replaced qemu-kvm with qemu-system-i386 since I'm on MacOS).

Here are the last few lines: Here is the register dump: Note that the general purpose registers change after a couple seconds, so I'm not sure how much use that may be for you. I'm not sure if I'm unable to get it to run because I'm running Mac, but I doubt that's the case. Let me know if you need any more details.

The provided binaries are not compatible with i386 (it is built for i686 architecture). You can easily add a configuration file in "kernel/configs" for i386 targets though. (I use i686 for various compiler optimizations which use specific instructions).

For now though, you can still try it but you'd have to supply qemu with a different CPU model, you can try to list the available CPU models and choose the latest model available there (Haswell, Broadwell, etc...), I believe coreduo is available for most systems so it would work. Then use the following command (with the CPU model of choice) to run it.

manwar wrote:The provided binaries are not compatible with i386 (it is built for i686 architecture). You can easily add a configuration file in "kernel/configs" for i386 targets though. (I use i686 for various compiler optimizations which use specific instructions).

For now though, you can still try it but you'd have to supply qemu with a different CPU model, you can try

Code: Select all

qemu-system-i386 -cpu help

to list the available CPU models and choose the latest model available there (Haswell, Broadwell, etc...), I believe coreduo is available for most systems so it would work. Then use the following command (with the CPU model of choice) to run it.

Code: Select all

$ qemu-system-i386 -cpu Haswell -cdrom aquila.iso -serial stdio -m 1G -d cpu_reset -no-reboot -boot d

No go. I ran the exact line you provided, although I got warnings about how TCG didn't support certain features.

Just to be certain, I also tried using qemu-system-x86_64 which in theory should be compatible with i686, but I received the same results.

PoisonNinja wrote:

manwar wrote:The provided binaries are not compatible with i386 (it is built for i686 architecture). You can easily add a configuration file in "kernel/configs" for i386 targets though. (I use i686 for various compiler optimizations which use specific instructions).

For now though, you can still try it but you'd have to supply qemu with a different CPU model, you can try

Code: Select all

qemu-system-i386 -cpu help

to list the available CPU models and choose the latest model available there (Haswell, Broadwell, etc...), I believe coreduo is available for most systems so it would work. Then use the following command (with the CPU model of choice) to run it.

Code: Select all

$ qemu-system-i386 -cpu Haswell -cdrom aquila.iso -serial stdio -m 1G -d cpu_reset -no-reboot -boot d

No go. I ran the exact line you provided, although I got warnings about how TCG didn't support certain features.

Just to be certain, I also tried using qemu-system-x86_64 which in theory should be compatible with i686, but I received the same results.

Oh, I actually didn't try that release without kvm and ran into problems (with PIT and PIC when I tried later). I just pushed my source tree and triggered another build (and a release) https://github.com/mohamed-anwar/Aquila ... v-build004.
I have tried it without KVM and it does work, however, this is even more experimental than the release you have (my source tree is not yet clean). I'm working on lazy process image loading and page cache, but I didn't intend a release meanwhile.

Please note that without KVM some things will be slow, if you think it is stuck, give it some time (especially at the initial grey screen).

manwar wrote: Oh, I actually didn't try that release without kvm and ran into problems (with PIT and PIC when I tried later). I just pushed my source tree and triggered another build (and a release) https://github.com/mohamed-anwar/Aquila ... v-build004.
I have tried it without KVM and it does work, however, this is even more experimental than the release you have (my source tree is not yet clean). I'm working on lazy process image loading and page cache, but I didn't intend a release meanwhile.

Please note that without KVM some things will be slow, if you think it is stuck, give it some time (especially at the initial grey screen).

Whatever you changed worked! I got to play with it a bit, it's pretty awesome. As for performance without KVM, it's pretty good except when the buffer is being scrolled. Just for the lols, I tried using HAXM to accelerate which gave much better performance.

Anyways, nice work and thanks for fixing the issue so quickly!

Showcase of NuklearUI running on AquilaOS. Currently, it's used just as it is, immediate mode GUI, a single application hosting all windows. I'm still trying to wrap my head around the code to convert it to client/server model.



It makes heavy use of a single "context" structure that represents almost everything. My first idea is to use a single context for the compositor (that represents windows) and every application has its own context, the application then pushes the commands buffer (that represents widgets/canvas/etc) to some module in kernel space for acceleration, the resulting buffer would then be sent to the compositor (server).


======== UPDATE ========
I have done some work with the client/server model thing, you can read about it here http://aquilaos.com/2018-05-09-playing-with-nuklear/

How about porting Weston, which I believe uses a Unix socket for client server communication.

tay10r wrote:How about porting Weston, which I believe uses a Unix socket for client server communication.

I spent quite some time looking through various options. Obviously I started with X itself and KDrive Tiny X server, that was my initial decision for an entire GUI. Wayland doesn't have the sheer complexity of X, and is really promising. Nuklear on the other hand, is a library I have known for some time and enjoyed using it, so the main reason I'm trying to use it is that I know it. Maybe one day I'll try to port X or Wayland, but for now I'm sticking with Nuklear and trying to build something out of it.

Ironically though, I don't actually fancy stacking window managers, I've been using i3 for years and extremely comfortable with it :"D

I have just pushed NuklearUI code so far, it's a mess, and many things are done in a very simplistic/stupid way. Also there's no server/client model yet, just a demonstration of different contexts and only in one application. I've also triggered a release if anyone wants to try it, be aware though it is broken in many ways, you can't even exit Nuklear without crashing the system.

https://github.com/mohamed-anwar/Aquila ... 05-nuklear

Hey manwar,

great project! Keep it going.

What are your plans for the next versions?

Greets

max wrote:Hey manwar,

great project! Keep it going.

What are your plans for the next versions?

Greets

Hey max,
Thank you, Ghost OS has really been one of my learning sources and motivations to keep pushing this forward, so big thanks to you!

As of next versions, I have a few things in mind,

• - Make NuklearUI robust
  - Make the kernel SMP ready
  - Support another architecture (most of the code is ready for IA64, so I'd start with that)
  - And of course, network and more applications for usability

manwar wrote:Thank you, Ghost OS has really been one of my learning sources and motivations to keep pushing this forward, so big thanks to you!

As of next versions, I have a few things in mind,

• - Make NuklearUI robust
  - Make the kernel SMP ready
  - Support another architecture (most of the code is ready for IA64, so I'd start with that)
  - And of course, network and more applications for usability

Happy to hear that! Glad you could make sense of it, despite the occasional lack of documentation.

Sounds good, keep posting updates here so we can hear more about it.