This is two instances of the same DeskTool program running in two different environments (one on Linux and the other on the new kernel) managed within a single desktop. This will probably not be very impressive to Linux/Unix users (X11 could do this already) but does demonstrate that features are starting to become stable and flexible enough for demonstrations.
Fonts & layout will be improved later, more features are coming sooner!
You’re told that there was a mysterious island in the Atlantic belonging to an advanced civilisation which vanished without a trace, and that the story is “a myth”.
The island never disappeared, it was still visible as clear as day in Plato’s time until today.
The cataclysm began with something like a hurricane, and at the end of the story the imperialists die fighting themselves – being unable to control the territories of others.
It happens about every 10,000 years. The last time it happened was around the end of the wooly mammoth era.
The word “myth” refers to it being a Greek history, although even some Greek historians in ancient times believed it was only a tale told to scare young empires. I guess we will find out.
I don’t support Australia’s Jewish war against Iran. Jews/Christians started this conflict and that group needs to be blamed for the outcome. I support African & European traditional religion, I only believe in the real Zeus.
I’m only kept in Australia because the “whites” can’t accept that they didn’t win the Suez conflict, so they need a fucking trophy to make them happy.
I was born Egyptian and I will die Egyptian, I want nothing to do with this cursed place or with white aka jewish people’s perpetual race issues. My parents raised me to be opposed to apartheid type policies but at a certain point I think people who want to be segregated just need to be isolated and left to die so that the rest of us can get on with our lives.
This involves running the desktop program on the laptop under Linux and the desktool program/s running along with the new kernel in a QEMU VM.
This configuration demonstrates just one advantage of having a networked architecture in the desktop system, as the desktop is faster when the whole thing doesn’t need to run in an emulated configuration.
The kernel is still fairly stable in QEMU but seems to be pretty broken when running under RVVM (which is more convenient for testing graphics features). The problem is probably in my code – not in the emulator – but since switching back to QEMU seems to resolve the issue and since I’m sick of debugging it I think that will be the solution for the short term.
The bug itself is probably in my code interfacing to SBI, which isn’t necessary in the QEMU build because I use some old xv6 bootstrap code instead on those builds. This code should be simple but there must be some quirks I’m unaware of with SBI’s timer setup, which may arise on real hardware but for now are only holding up testing when using RVVM.
The good news is I can probably get the desktop system working with QEMU now that I’ve got the foundations working, since the display part of the system can just be run on the host machine anyway – at least if I can get networking to function well enough in that configuration.
So I should be back to work again now (not just debugging my existing code…) and my scheduler itself should be stable as long as I can resolve any timer/interrupt problems later on.
RVVM seems to be a really good emulator though aside from my present issues so it’d be nice to get the system running properly on there eventually but isn’t really necessary to continue development (fixing structural things and testing on real hardware are both more important!).
Might actually be a good platform assuming their kernel is more stable than mine, despite the Linux people making jokes about it.
It feels like I’ve been battling scheduler lockups forever.
My scheduler bug is definitely due to missing some timer interrupts but it’s hard to tell exactly what’s going on as I think this only happens when booted via SBI. So the SBI firmware code manages setting up the timer, and I don’t know maybe the SBI interface is just not intended for the way I’m using it or maybe I’ve missed some other necessary initialisation on secondary cores.
There is a fallback plan if I can’t get it working, which would be like a legacy mode that maxes out each CPU core in a hot loop with no interrupts. This mode would probably work okay on modern hardware and would be responsive enough in a multi-core setup but might not be useful outside of demos (would waste battery power on devices).
In the longer term I need to finish the PLIC code to get all the interrupts set up properly, my short term approach will depend on whether I make a breakthrough soon or whether I get frustrated and revert to simpler ways of doing things.
I think I’ve worked out what’s going on with my scheduler code but I’m not sure – I may be have to expect some timer interrupts to be missed and perhaps use a repeat timer setup… Once this issue is resolved I think the scheduler will be stable.