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

[pal666]

I'm interested to know what your definition of toy language is because Rust doesn't fit mine. It may not have much usage ... Now I've only been making small programs... Servo is written

servo isn't written yet and will not be written for years. otherwise you pretty much nailed definition of toy language

Sidenote: Not sure how you come to the conclusion that an image decoder might be non-trivial.

i came to opposite conclusion

[SpyroRyder]

servo isn't written yet and will not be written for years. otherwise you pretty much nailed definition of toy language

i came to opposite conclusion

My bad, I forgot a word, the rest of the point still stands however. And i am not sure how something with 16,000 git comits counts as not written. Seriously the data is here https://github.com/servo/servo . As to you selectively sniping the part about me only making small programs, I have known the language for less than a week. I am doing small logic demos and games to get a good grasp of the language before I code larger things in it.

[CrystalGamma]

The real truth is when your CPU is running at !00% full load, the vast majority of what it's doing is waiting on latency. Perhaps a backside cache would be useful for addresses already generated, but front side cache would hurt latency badly.

If you followed the talk, the point is that you rarely (certainly not for a simple process switch) invalidate the page table, so you don't need to look up physical addresses that often.

[vadix]

ok, name few serious projects in rust
Also, PLEASE learn to read. i specifically mentioned future tense. That is coming from someone with disabled brain

https://github.com/kud1ing/awesome-rust

Also, the full crates.io website filled with tons of crates. I see stuff on a daily basis and libraries for almost anything you want. Servo is a perfect example of a large Rust project.

Also, how is C++ safer in the future tense? C++ is inherently not nearly as safe as Rust due to the different type systems.

Can C++ statically check the safety of function objects to ensure no race conditions or use after frees happen? Rust can, and at the same time it statically inlines it by default. Rust has so many features far beyond C++. Name me one thing C++ does better over rust and ill debate about it, but the community knows its faults and is always looking to improve the language, while C++ is stuck perpetually as it is.

[SystemCrasher]

Really strange thing. Microkernel to get crappy performance? ZFS to make it even worse, turning into a resource hog? MIT license to ensure corporations would not contribute back? Exotic language & kernel design to ensure there're no contributors? Hmm, failure isn't opttion, It seems it going to be hardcoded default value instead.

[log0]

https://github.com/kud1ing/awesome-rust

Also, the full crates.io website filled with tons of crates. I see stuff on a daily basis and libraries for almost anything you want. Servo is a perfect example of a large Rust project.

Also, how is C++ safer in the future tense? C++ is inherently not nearly as safe as Rust due to the different type systems.

Can C++ statically check the safety of function objects to ensure no race conditions or use after frees happen? Rust can, and at the same time it statically inlines it by default. Rust has so many features far beyond C++. Name me one thing C++ does better over rust and ill debate about it, but the community knows its faults and is always looking to improve the language, while C++ is stuck perpetually as it is.

There is work on adding type, bounds and lifetime checking to c++, which is quite nice.

https://www.youtube.com/watch?v=hEx5DNLWGgA

No idea how it compares to rust though.

[SystemCrasher]

There is work on adding type, bounds and lifetime checking to c++, which is quite nice.

Furthermore, those who are worried about it could use asan, ubsan, tsan and so on to get there. At the end of day, all kinds of extra checks are killing performance and if some runtime does it unconditionally, it going to hit java performance domain at very best. And expressing things the way it convenient for CPU is much easier when no crap gets in the way. C and C++ to some extent are quite unique in this regard, the only thing which gives more control on what's going on is assembly, which is non-portable and tiresome.

[andreano]

SystemCrasher: The so called "borrow checker" in Rust runs during compilation — you are forbidden from compiling most kinds of memory bugs. I think you will have to add Rust to your list of “unique in this regard” languages regarding performance.

[Zoxc]

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.

Actually there is a way around that, but not for arbitrary x86 code. My microkernel project (WIP: https://github.com/AveryOS/avery) uses software-fault isolation on processes ensuring that they are isolated. The processes all run in a single address space in kernel mode. This software-fault isolation also happens to prevent control-flow hijacking attacks, but it does have a overhead compared to regular x86 code.

Yeah, but address generation behind cache would be horribly slow. I know cache seems fast, but really it's just a compromise.Most time you need to have addresses readily available, and most times that's not true. Logically speaking putting the AGU behind a caching system would at minimum add that caching systems latency to address generation.

The real truth is when your CPU is running at !00% full load, the vast majority of what it's doing is waiting on latency. Perhaps a backside cache would be useful for addresses already generated, but front side cache would hurt latency badly.

What do you mean by address generation? A key benefit of having caches indexed by virtual memory (like the Mill, but unlike x86) is that you don't have to look up the physical address in the TLB before going to the caches.

[CrystalGamma]

Actually there is a way around that, but not for arbitrary x86 code. My microkernel project (WIP: https://github.com/AveryOS/avery) uses software-fault isolation on processes ensuring that they are isolated. The processes all run in a single address space in kernel mode. This software-fault isolation also happens to prevent control-flow hijacking attacks, but it does have a overhead compared to regular x86 code.


What do you mean by address generation? A key benefit of having caches indexed by virtual memory (like the Mill, but unlike x86) is that you don't have to look up the physical address in the TLB before going to the caches.

Ah yeah, software isolated processes … I left those out because AFAICS it's next to impossible to do without GC or unsafety.
I'm assuming duby229 means address translation by what they posted.