AquilaOS v0.0.1a [NuklearUI]

[manwar]

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.

Code: Select all

$ qemu-kvm -cdrom aquila.iso -serial stdio -m 1G -d cpu_reset -no-reboot -boot d

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,

Code: Select all

$ cd build-tools && bash build.sh

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

Code: Select all

$ make aquila.iso

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).

[manwar]

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

[PoisonNinja]

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:

Code: Select all

KDev: Registered chrdev 140: ptsdev
KDev: Registered chrdev 141: ptsdev
KDev: Registered chrdev 142: ptsdev
KDev: Registered chrdev 143: ptsdev
KDev: Registered blkdev 1: ramdisk
Loading ramdisk
Kernel: Loading init process
8254 PIT: Setting period to 419 ns
qemu-system-i386: warning: I/O thread spun for 1000 iterations

Here is the register dump:

Code: Select all

EAX=d0003400 EBX=d00033ec ECX=cff00000 EDX=d0003400
ESI=d0000f18 EDI=d0000dfe EBP=d00033e0 ESP=c007fe30
EIP=c02113b7 EFL=00000086 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =002b c0256338 00000068 0000e900 DPL=3 TSS32-avl
GDT=     c0240000 000007ff
IDT=     c02563a0 000007ff
CR0=80000011 CR2=00000000 CR3=00201000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 
DR6=ffff0ff0 DR7=00000400
EFER=0000000000000000
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000

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.

[manwar]

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

[PoisonNinja]

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.

[manwar]

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).

[PoisonNinja]

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!

[manwar]

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/

[tay10r]

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

[manwar]

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

[manwar]

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

[max]

Hey manwar,

great project! Keep it going.

What are your plans for the next versions?

Greets

[manwar]

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

[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

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.