OS News Archive

System calls are a way for unprivileged, user applications to request services from the kernel. In the RISC-V architecture, we invoke the call using the ecall instruction. This will cause the CPU to halt what it’s doing, elevate privilege modes, and then jump to whatever function handler is stored in the mtvec (machine trap vector) register. Remember, this is the “funnel” where all traps are handled, including our system calls. We have to set up our convention for handling system calls. We can use a convention that already exists, so we can interface with a library, such as newlib. But, let’s make this ours! We get to say what the system call numbers are, and where they will be when we execute a system call. This is part 7 in a long series about writing a RISC-V operating system in Rust.

KnightOS is an operating system I started writing about 10 years ago, for Texas Instruments line of z80 calculators — the TI-73, TI-83+, TI-84+, and similar calculators are supported. It still gets the rare improvements, but these days myself and most of the major contributors are just left with starry eyed empty promises to themselves that one day they’ll do one of those big refactorings we’ve been planning… for 4 or 5 years now. Still, it was a really interesting operating system which was working under some challenging constraints, and overcame them to offer a rather nice Unix-like environment, with a filesystem, preemptive multiprocessing and multithreading, assembly and C programming environments, and more. The entire system was written in handwritten z80 assembly, almost 50,000 lines of it, on a compiler toolchain we built from scratch. The things people can squeeze out of these limited devices astounds me every single time.

Lilith is “a POSIX-like x86-64 kernel and userspace written in Crystal”, which only raises the question what Crystal, exactly, is. It’s a programming language whose syntax is “heavily inspired by Ruby’s, so it feels natural to read and easy to write, and has the added benefit of a lower learning curve for experienced Ruby devs”.

Linking to The Verge, because the original report is stuck behind a paywall: Facebook is developing its own operating system that could one day reduce the company’s reliance on Google’s Android, according to a new report by The Information. Development is currently being led by Mark Lucovsky, a Microsoft veteran who co-authored the Windows NT operating system. The report provides a limited amount of information about how the new operating system could be used, but it notes that both Facebook’s Oculus and Portal devices currently run on a modified version of Android. According to one of Facebook’s AR and VR heads, Ficus Kirkpatrick, “it’s possible” that Facebook’s future hardware won’t need to rely on Google’s software, which would reduce or remove entirely the control Google has over Facebook’s hardware. Nope. Nope. Nope. Nope. Nope.

Seriously, what do you do with your computer? Over time 9front sanded off its rough edges. I can do just about everything I need to do from a bare metal install. Today, we even have vmx(1) for hosting OpenBSD or Linux virtual machines (just in case you need to interface with the U.S. government via the now-required modern web browser). A previous release of the 9front DASH1 manual was created entirely on a ThinkPad running 9front (and Gimp running inside OpenBSD running inside vmx(1)). 9front now even ships with a primitive Microsoft Paint clone, several native Sega and Nintendo emulators, and a full port of DOOM. I never would have dreamed anything like this was possible back in 2009. As time goes by, there is less and less reason to boot anything else. For what I do, I’m perfectly happy with it. Clearly not the most typical user, but that doesn’t make their experiences any less interesting.

webOS OSE 2.1.0 has been released. Since I’m sure not everyone has kept track of where webOS has ended up, this is where we stand today: webOS is a web-centric and usability-focused software platform for smart devices, which has proven its performance and stability in over 70 million LG Smart TVs. Since its adaptation to display products, webOS has come a long way and evolved into a software platform applicable to a broader range of products. The open source project of webOS, called webOS Open Source Edition (OSE), was announced in March 2018 under the philosophy of open platform, open partnership, and open connectivity. On top of the core architecture of webOS, webOS OSE offers additional features that allow extension to more diverse industry verticals. This release seems light on changes, as the release notes illustrate.

LegoOS is a disseminated, distributed operating system designed for hardware resource disaggregation. It is an open-source project built by researchers from Purdue University. LegoOS splits traditional operating system functionalities into loosely-coupled monitors and run them directly on disggregated hardware devices. LegoOS also manages distributed resources and handles hardware component failures in a disaggregated cluster. For more information, please check out our recent awarded paper. You can get LegoOS here.

SerenityOS, a UNIX-like OS written from scratch has turned one year old today. The authors have made huge progress and impressively it can now run Doom and render HTML content in its own HTML engine. Be sure to scroll down the page for an overview of the progress that’s been made, including a bunch of screenshots that really show just how fast the project has evolved.

I expect our global supply chain to collapse before we reach 2030. With this collapse, we won’t be able to produce most of our electronics because it depends on a very complex supply chain that we won’t be able to achieve again for decades (ever?). Among these scavenged parts are microcontrollers, which are especially powerful but need complex tools (often computers) to program them. Computers, after a couple of decades, will break down beyond repair and we won’t be able to program microcontrollers any more. To avoid this fate, we need to have a system that can be designed from scavenged parts and program microcontrollers. We also need the generation of engineers that will follow us to be able to create new designs instead of inheriting a legacy of machines that they can’t recreate and barely maintain. This is where Collapse OS comes in. That’s one way to introduce an operating system. This is a very unique project aimed at creating an operating system that can run on microcontrollers and which can self-replicate.

Eventually, that’s going to mean a single software stack common across VW Group’s vehicles—everything from the instrument displays and the infotainment to powertrain and chassis management (think traction and stability control or advanced driver assistance systems), plus a common connected car infrastructure and cloud. However, each brand will still get to develop its own UX in the same way that Porsche and Audi can build very different-looking vehicles from the same MLB Evo toolbox. They’re going to base it on Android, but without much of the Google parts because of privacy concerns (i.e., VW wants that data for itself, not share it with Google). And, as always in the car world, it will be many, many years before this initiative will make its way to VW Group’s cars – the unit won’t be fully staffed until 2025.

James Lu, Product Manager of Huawei recently shared the roadmap of Harmony OS at an event in Jakarta. The Huawei product manager also explained the company’s latest operating system. According to the roadmap, the Harmony OS will make its mark to the smartwatches and bands, head units, and most importantly, what they call “Innovative PCs” by the end of 2020. It’ll also be able to power other devices such as smart speakers, VR glasses two years down the line. One of the largest technology companies dropping Android and Linux and going for an entirely homegrown multi-device open source operating system that other countries and regions can adopt and adapt to their needs is probably not the outcome the US government should be aiming for. I don’t think sharpies will be enough here.

In the city of Dongguan, China, Huawei finally took the wraps off its long-rumored, first-party operating system. The OS, called Harmony OS, has been in development for several years, but it’s recently taken on a role as a key player in Huawei’s contingency plan since the U.S. enacted a trade ban on the Chinese technology company. At the Huawei Developer Conference, Huawei finally shared the first details about its in-house OS, but the company wasn’t ready to show off Harmony on smartphones just yet. Tomorrow, the company will show off Harmony OS on the Honor Vision TV. For now, Android remains the go-to mobile OS for Huawei and Honor smartphones and tablets. The operating system runs on a custom microkernel architecture that’s been developed in-house, which makes sense considering Huawei has been holding talks about microkernels at FOSDEM for a few years now (2018, 2019). They claim it’s faster than the competition, more secure, and more flexible – so much so that they say they can switch over from Android in a matter of days. Other details about HarmonyOS include no root access, because Huawei considers it a security risk. Huawei will be supplying an IDE for the operating system, capable of building applications for various device types. Huawei also intends to release HarmonyOS as open source. There’s a lot of skepticism about Huawei’s ability to build an operating system out there, but I do not share that at all. Huawei is one of the largest, most successful technology companies in the world, for both enterprise networking technology as well as consumer technology, and there’s no doubt in my mind that they are more than capable of developing a good, solid operating system. That being said, the real issue is of course that between iOS and Android, there isn’t really much room left for a viable third option. HarmonyOS could certainly work in China – especially since it boasts Android compatibility and Chinese Android phones are Google-free anyway – but in the rest of the world people expect their smartphones to be either iOS or Google Android. I highly doubt any non-Android smartphone, with or without Android application compatibility, has any serious chance in the market. Which is obviously sad, but that’s the way it is.

The Genode OS Framework is written in C++, but has support (to one degree or another) for writing components in several other languages. Perhaps foremost of these is Ada/SPARK, thanks in part to active development/support by Componolit, which maintains the Ada/SPARK toolset for Genode (SPARK is a subset of Ada, designed to be verifiable). On Genodians.org, there have been three recent articles exploring the use of Ada/SPARK on Genode, each approaching the subject from a different angle. First, in “C++ and SPARK as a Continuum“, Genode co-founder Norman Feske shows how to create hybrid C++/SPARK components. There are a few restrictions, but the results fit well with the Genode component philosophy. By regarding C++ and SPARK as a continuum rather than an black-and-white decision, we can use SPARK at places where we regard formal verification as most valuable while not restricting Genode components to be entirely static. It gives us Genode developers the chance to slowly embrace the application of formal methods and recognize their benefit in practice. Second, Martin Stein takes the first steps toward converting (a fork of) the in-house “base-hw” kernel to Ada in “Spunky: A Kernel Using Ada – Part 1: RPC“. This is just the beginning of this project, so stay tuned. What should I say? Thanks to the almost pedantic need for correctness of the Ada compiler and the sheer endless chain of complains it kept throwing at me, the final image worked out of the box and put a big smile on my face. Third, Johannes Kliemann of Componolit dives into the deep end of the pool in “SPARK as an Extremum: Components in Pure SPARK“, which describes the arduous journey that led them to create an API for creating components completely in SPARK. With the realization that generated bindings are not feasible and both binding and API need to be created by hand, previous API limitations such as functions that are not allowed in SPARK could be removed. This API should not resemble any characteristics of any language or platform that implements it. The goal was to create a pure SPARK API for asynchronous verified components. The result is the Componolit Ada Interface, an interface collection that provides component startup, shutdown and platform interaction. As you can see, even though the Genode core has become pretty mature, there is still much interesting research and experimentation being done on the eternal quest for more trustworthy computing.

VSI is porting OpenVMS to x86-64. The company has done a lot of work, and it is beginning to bear fruit. Recently they’ve managed to boot the kernel and perform a DIR command. Grand steps indeed. Truly amazing work!