It’s time for an overview of another month of Redox OS progress, and over the month of August – they’re a bit late, don’t believe the publication date – they’ve implemented multicore support for ARM, and considerably improved the I/O performance for the NVMe driver, RedoxFS, and RAMFS by implementing a ring buffer communication API. There’s also initial support for NUMA-based memory management, QEMU is now working on Redox, and much more.
Of course, there’s also the usual long list of improvements to the kernel, relibc, drivers, and more.
I will be first to admit I’m a newbie at building Operating Systems and have no real experience however…..
Why did they create a new file system RedoxFS?
IMHO the smart option is to start with the widely used EXT4 / exFat.
Your operating system is going to have a generic VFS layer and its guaranteed one day you will be supporting EXT4 and exFat.
Smart move is to start with support for those file systems, instead of spending extra 1o0s of hours implementing a new file system.
It would be interesting to see a Rust language implementation of EXT4 file system and compare to the Linux C implementation.
The Redox devs will say that want advanced features like transparent encrpytion etc etc…. IMHO those advanced features can wait. Supporting more hardware and software should be a higher priority.
The 100s hours saved NOT implementing a brand new file system can be better utilised for better hardware support etc etc.
tom9876543,
There’s no right answer. People working on these projects have different motivations.
If you want to maximize potential innovation, usually that favors taking new approaches with new code. However compatibility obviously favors the opposite.
It would be interesting, although I expect language differences to have minimal impact. When it comes to IO, FS and cache tuning is likely going to have more impact than the language.
Fair enough, but on the other hand anticipating future needs can create stronger foundations. Retrofitting features into legacy code that wasn’t designed for them is often more complicated and less optimal than designing for those features up front. Still there’s no single right answer and you’re right it depends on what you want to prioritize.
> Why did they create a new file system RedoxFS?
> IMHO the smart option is to start with the widely used EXT4 / exFat.
I am not associated with RedoxOS but it is clear that ext4 and especially exFat would not meet the needs of the project. They wanted a copy-on-write filesystem as an important RedoxOS goal. And the first thing they tried to do was write a read-only driver for ZFS. But they decided that the design was a poor fit for a microkernel (another major RedoxOS goal). In the end, they decided the best path was to write their own.
What the “Smart move” is depends entirely on what your goals are. They map these out in the first sentence of their website “Redox OS is a complete Unix-like microkernel-based operating system written in Rust, with a focus on security, reliability and safety.”
– Unix-like
– security
– reliability
– safety
– micro-kernel
– Rust
Choices like Rust and a micro-kernel design fall right out of their other design goals. I think a COW filesystem does as well.
If you are going to have to write your driver from scratch in Rust, and it is going to have to work well with a micro-kernel design, starting with a fresh FS may actually be just as easy or easier than trying to retrofit something else. Also, as RedoxOS is MIT licensed, they cannot look at GPL code or anything like that, so they would be relying on documentation for any other FS they chose.