Originally posted by Vorpal
View Post
Announcement
Collapse
No announcement yet.
Redox OS Scores A Massive Performance Boost For I/O
Collapse
X
-
Originally posted by Quackdoc View Post
did you forget that phoronix is also "open source news?" it's not just about linux lolHi
Comment
-
Originally posted by justinkb View PostI 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?
Comment
-
Originally posted by stiiixy View Post
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'.
Comment
-
Originally posted by mrg666 View PostAt 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.
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.
- Likes 1
Comment
-
Originally posted by Vorpal View Post
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.
Here is one:
The open source community advancing eBPF gathered at a virtual eBPF Summit today that featured a demonstration of use in a Windows environment.
I am aware it is not trraditional microkernel though.
- Likes 1
Comment
-
Originally posted by stiiixy View Post
How does the name matter? It's still the same question, no matter whom asks it.
Comment
-
Originally posted by pabloski View Post
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.
Comment
-
Originally posted by Vistaus View Post
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.
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
Comment
Comment