Stub out the interface that the kernel needs, and provide an interface for the bits (reading disk blocks and so on) that the file system needs from the kernel. This way, you can decouple it completely from the kernel, test it independently, port it without forking the code, and then it can easily be used in userland, too.
There are a lot of small operating systems that take the decoupled route - but you'll almost certainly never see them because they're either research-based, or suffer from the problem of most hobbyist operating systems which is "lack of hardware support". Doesn't matter how modern/sexy an O/S is if you cant run it upon your hardware. (Relatedly once you can run it you need software on it too..)
That said there are some compromises available, even with Linux. If you use something like FUSE you can write your own filesystem in 100% user-space - something I've done for a couple of niche applications.
Also, I'll pat myself on the back and say the Ion shell looks nice, because it borrowed some ideas from the Oil shell [1] :) In particular, we talked a fair bit about the array syntax and semantics, and lack of word splitting.
All this in a language that's ~2 years old is pretty impressive.
$ var='my program.py'
$ python $var
and $ python "$var"
You need double quotes to protect against word splitting. Almost all shell tutorials guides hammer this point home repeatedly, because if you omit double quotes, it works most of the time, and then blows up with incomprehensible error messages when you have spaces.If you have a filename with spaces, like "my program.py", then python would be invoked with TWO arguments in the first case ["my", "program.py"].
But it will be invoked with single argument in the second case ["my program.py"], which is the correct thing.
I talk about how word splitting is really a hack around the historical lack of arrays in bash here:
"Thirteen Incorrect Ways and Two Awkward Ways to Use Arrays"
One of the coolest aspects of all of these tools are that they aren't exclusive to Redox. In fact, they are rather portable. For example, the new file system (tfs) can run on operating systems other than Redox. One of the team members wrote an "atomic hash table" for it, and it was open sourced as well. It even uses an open source hash function by the same author.
Congrats to the team. Writing an operating system is incredibly hard, and it's great to see something like this written in Rust. I'm a big fan of all of the core contributors, and can't wait to see where Redox goes.