Redox OS Scores A Massive Performance Boost For I/O

[mrg666]

Are there ways to optimise this? Maybe, proponents say that it can be done, but monolithic kernel still dominates outside some very specific niches. Mac OS X is based on a micro kernel (XNU) that over the years morphed into a monolithic kernel for performance reasons.

At the same time, Linux morphed into a modular kernel with microkernel capabilities through eBPF. It seems neither pure microkernel nor complete monolithic architectures are ideal.

[stiiixy]

did you forget that phoronix is also "open source news?" it's not just about linux lol

Mate, I'm not confusing 'open-source' anything; I'm asking if this methodology can be applied between languages, or in this case, entire operating systems. Can this approach be applied to linux as it's applied to RedoxOS. Objectively, it has nothing to do with 'open/close' sourceing, and simply 'can we re-use this theory in our project'.

[mmstick]

I noticed they have a rust written libc implementation for this Redox OS. As far as I understand it, there is no truly self hosted rust language implementation that doesn't rely on already having some kind of c library available at rust build time and runtime, so I don't currently see the necessity of that subproject. Can anyone clarify?

Rust's standard library relies on libc, and the same is true for Redox OS. The standard library could use Redox's system calls directly, but that'd require submitting a lot of patches to Rust's standard library to keep up with kernel developments.

[Quackdoc]

Mate, I'm not confusing 'open-source' anything; I'm asking if this methodology can be applied between languages, or in this case, entire operating systems. Can this approach be applied to linux as it's applied to RedoxOS. Objectively, it has nothing to do with 'open/close' sourceing, and simply 'can we re-use this theory in our project'.

My bad, I had you mistaken with mirmirmir since I didn't read the name just the post, apologies

[Vorpal]

At the same time, Linux morphed into a modular kernel with microkernel capabilities through eBPF. It seems neither pure microkernel nor complete monolithic architectures are ideal.

I would not say that eBPF is a microkernel technology though. It is sandboxed code running within ring zero (so full privileges as far as the CPU knows, but limited thanks to the BPF verifier instead).

Microkernels traditionally use the CPU privilege separation mechanism (rings on x86, not sure if the same terminology is used on other architectures, but similar concepts apply everywhere).

I don't think eBPF would make for a good replacement for microkernels either (as far as I understand the tech, not an expert on this). It only allows provably bounded loops for example. This would be very restrictive for writing general purpose drivers.

More microkernel-like is FUSE (file system in userspace). Unfortunately performance is a problem here, so it really only used (currently) where that doesn't matter. Though there is work on improving this I believe.

[mrg666]

I would not say that eBPF is a microkernel technology though. It is sandboxed code running within ring zero (so full privileges as far as the CPU knows, but limited thanks to the BPF verifier instead).

Microkernels traditionally use the CPU privilege separation mechanism (rings on x86, not sure if the same terminology is used on other architectures, but similar concepts apply everywhere).

I don't think eBPF would make for a good replacement for microkernels either (as far as I understand the tech, not an expert on this). It only allows provably bounded loops for example. This would be very restrictive for writing general purpose drivers.

More microkernel-like is FUSE (file system in userspace). Unfortunately performance is a problem here, so it really only used (currently) where that doesn't matter. Though there is work on improving this I believe.

There are several discussions on the net about eBPF giving Linux microkernel-like capabilities.

Here is one:

https://devops.com/latest-ebpf-advances-are-harbingers-of-major-changes-to-it/

I am aware it is not trraditional microkernel though.

[stiiixy]

My bad, I had you mistaken with mirmirmir since I didn't read the name just the post, apologies

How does the name matter? It's still the same question, no matter whom asks it.

[Quackdoc]

How does the name matter? It's still the same question, no matter whom asks it.

yes, because the context of the previous question and reply to it "How does it compare to Linux? It got to be more performant for such a headline" > "So nobody can ever talk about a big performance boost in software unless it is faster than the equivalent capability / subsystem in Linux?" > " ...and can the 'concept'/change be simply ported and tested to existing regular Linucii? Or is this feature a Rust language exclusive?"

[Vistaus]

The problem is that it needs Linux specific functions and subsystems. Unless someone ports Bcachefs to RedoxOS ( unlikely ). So please no, I am already crying because of LinuxBSD ( FreeBSD implementing more and more Linux subsystems ). I hope those OSes remain independent and maintain their personality.

A lot of OS's are making steps towards another nowadays. BSD using more Linux stuff, Haiku using a BSD layer for drivers, Windows implementing more Linux stuff, etc.

[pabloski]

A lot of OS's are making steps towards another nowadays. BSD using more Linux stuff, Haiku using a BSD layer for drivers, Windows implementing more Linux stuff, etc.

as long as it doesn't compromise the system architecture, it is a good thing

Haiku, FreeBSD, they all add syscalls through kernel modules, so it doesn't change the architecture...obviously it means that another layer of indirection is added ( slowing the code down, adding bloating ) and it gives driver programmers no incentive to build native drivers

this is where Wayland "shines"....being only a set of protocols, everyone can make its own implementation....although FreeBSD goes the other route and implements DRM in order to get Wayland, others could instead build their Wayland rendering pipeline based on their graphics stack...at the application level, user code will see the same Wayland APIs that are present on other platforms, so no problem porting these software to the new OS