Redox: A Rust-Written, Microkernel Open-Source OS

[SystemCrasher]

Yes. You gave me more examples than I was aware of, but you're supposed to be able to do all of that in Rust — in any case where the borrow checker can't prove your code to be correct, you can mark the block of code with the unsafe keyword, which really means "trust me".

This particular feature could be quite fancy. However, need to learn different language and rewrite software IS bad. Furthermore, learning different toolchain is AWFUL when it comes to system programming. Say, I have some ideas how to make gcc linker to behave. It means I can persuade it to compose me binary in a really custom manner, and it needed quite often when it comes to system level programming. It takes some efforts to learn toolchain at THIS level, and it could take years before toolchain mature enough to do it in adequate ways which aren't pain in the rear. As well as being able to handle e.g. inline assembly parts. It is a "bad" thing, but sometimes it could be easier or much faster to call small piece of carefully crafted assembly. Gcc toolchain isn't bad at it. So it is extremely powerful system programming tool. One can easily write kernel, boot loader, device driver or even program microcontroller using same toolchain and reusing knowledge. Which is good. It could sound a bit lazy or stubborn, but speaking for myself I would only learn new toolchin if there is groundbreaking advantage, while retaining compatibility with existing software and so on (hopefully it explains why clang mimics gcc so hard in quite many regards). And starting new OS.. it is kinda hard thing to do in modern world. At most one can try to displace niche exotic things like QNX, but to beat existing general purpose OSes... well, these days bar is high. So we have Yet Another Useless Task Switcher. What about porting some brand new 1.5MiB-sized GPU driver? Preferrably with competitive performance. Inconvenient question, eh?

[name99]

isn't it nice when real programs in your 'safe' language consist mostly of unsafe blocks?


i.e. it will be as successfull as hurd

Or SeL4 --- which ships on every iPhone...

[name99]

Hurd isn't successful because it has no goals, is over 15 years old. and still ended up with shoddy design.
There's nothing wrong with the concept of a microkernel... it actually has quite a few advantages over monolithic kernels. The main downside of the micro kernel from my understanding is the latency introduced due to the IPC between user space and kernel space (which exists in monolithic kernels as well if you ever write a user space USB driver for instance in Linux).

There are many ways to handle this. You can simply make the IPC fast (eg L4 has done this). You can remove the barriers (and costs) that hardware separation requires and put everything in the same address space. (Singularity). You can DESIGN to separate address spaces (thus enforcing ALL communication to be by message passing as opposed to shared memory), but ultimately co-locate the separate code in the same address space. (This is feasible, even without the language constraints of the Singularity solution if you're a company like Apple that controls the entire kernel including all drivers and kernel servers).
Or you could simply say you're willing to pay the (generally minor in the grand scheme of things) cost of the IPC for the value provided in terms of security, robustness, debuggability. This is to some extent what Apple is doing today with their aggressive use of XPC on iOS and OSX to strongly enforce separation between apps and their "plugins" -- the same model can (and likely will) be extended to the OS, and if you know anything about how third party devices work on iOS, you'd realize that that's pretty much already the model for third party drivers.

An obsession with speed as the SINGLE priority for an OS made sense in the 80s and 90s; it makes less sense today in almost all use cases.

[name99]

IIRC not kernel ⇔ userspace but userspace A ⇔ userspace B is the problem. In a mode switch (kernel ⇔ user) there are no TLB flushes, which are expensive, but when you remap the address space (context switch), there are. And with the ring-based security model of the x86 MMU, there is basically no way around giving every process its own address space to ensure isolation.

Every modern CPU uses address-space tagged TLBs. Transitioning between address spaces is not free, but it doesn't require TLB flushes the way you suggest.

[CrystalGamma]

Every modern CPU uses address-space tagged TLBs. Transitioning between address spaces is not free, but it doesn't require TLB flushes the way you suggest.

Interesting. But doesn't that mean that the TLB has to be bigger to be useful? That's gotta cost, especially since it's on the critical path …

[name99]

Interesting. But doesn't that mean that the TLB has to be bigger to be useful? That's gotta cost, especially since it's on the critical path …

What causes problems with CAM structures is not so much their absolute size as the number of entries. More entries is tough; larger entries is easy.