Redox OS 0.6.0

https://www.redox-os.org/news/release-0.6.0/

by jackpot51 • 6 years ago

111 28 6 years ago

jackpot514• 6 years ago

I am Jeremy Soller, the creator of Redox OS, please let me know if you have questions!

Iolaum• 6 years ago

Can you share what are the things missing from redoxOS before it can take advantage of the full capabilities of a system76 laptop?

jackpot514• 6 years ago

iwlwifi, a more complete USB stack, i2c hid, graphics acceleration.

What does work is pretty cool though. Ethernet, input, non-accelerated graphics, nvme and ahci storage

hiq3• 6 years ago

What's next for Redox OS? I couldn't find a roadmap, but maybe you have one?

jackpot514• 6 years ago

Next up is probably a graphical installer

cycloptic2• 6 years ago

Any plans for what to do about GPU drivers?

jackpot514• 6 years ago

Port DRM drivers to userspace and use mesa, probably

zesterer3• 6 years ago

Hey Jeremy! What sort of support do you have for graphical APIs like windowing, graphics, etc.? I'd be really interested in working with you to port Veloren (https://veloren.net/), also written in Rust, to Redox at some point in the future: if nothing else, as a demonstration of what a pure Rust tech stack can do. If you're interested in this, feel free to message me on Reddit (same username).

schaefer• 6 years ago

Hi Jeremy,

Is there a port of Redox OS which runs under xen as a guest OS (paravirtual or otherwise)?

Lots of tiny OSes, such as Minix, have been ported to this environment and I think this could be a fun way to run Redox while leveraging the broad device support of a traditional Linux Kernel.

Thanks!

nateinaction• 6 years ago

Love seeing the progress on this! Thank you for sharing!

yjftsjthsd-h• 6 years ago

rmm, a complete rewrite of the kernel memory manager. This has eliminated kernel memory leaks, which became quite an issue with the previous memory manager

Hang on, I thought the whole point of writing in Rust was that this didn't happen. Is there something about a memory manager that requires unsafe? (Keeping in mind that I neither know Rust nor kernel design, so there's a very good chance that I'm just missing something here)

chipsa• 6 years ago

Memory managers are intrinsically unsafe. Rust generally passes around already allocated memory, but allocating the memory requires that you start with an undifferentiated bucket of bits, so the memory manager passes around raw pointers.

cesarb• 6 years ago

In Rust, memory leaks are considered "safe"; you don't need unsafe to create a memory leak. There's even a function in the standard library (std::mem::forget) to explicitly leak a value, and it's not marked as unsafe. And even without that function, it's very easy to leak memory in safe code (just create a cycle with reference-counted values).

But yes, memory managers generally require unsafe. Consider what happens when you release memory containing a value of type A, and that memory is later allocated for a value of type B. This is equivalent to a transmute between types A and B, which requires unsafe.

jhvkjhk• 6 years ago

The book[1] (something like bible of Rust) wrotes:

memory leaks are memory safe in Rust

[1] https://doc.rust-lang.org/book/ch15-06-reference-cycles.html...

retrac• 6 years ago

There's probably no way to guarantee that there are no memory leaks in a general purpose language where you can allocate memory dynamically. How can the allocator know if you actually need those 1 MB chunks forever, like you keep requesting?

hiq3• 6 years ago

Couldn't the language demand that, as long as a memory chunk is allocated and not freed, there's a path to use this memory chunk? Meaning it's not a memory leak in the sense of 'we are certain (we could prove) that this memory chunk will never be used again', such as the std::mem::forget mentioned elsewhere in the thread.

In practice that would mean that you need to write some formal proof, but that doesn't seem impossible. Just like some formal languages require that you write a termination proof to define a recursive function. Of course I'm not saying this is a practical solution for a language like Rust to demand this kind of proofs for every program, but since programs written in a subset of C have been formally verified, it should be possible (and sometimes desirable) for Rust too.

majewsky• 6 years ago

In addition to what others have already said: "unsafe" just means that the compiler does not understand your data structure well enough to enforce its invariants. And that's okay! The zen of Rust is not to eliminate unsafe code. That would require a compiler so ludicrously sophisticated that it would be borderline magical. The zen of Rust is to reduce unsafe code to the minimum, to have only 1% or 0.1% of your code that is unsafe and needs to be reviewed extra-super-duper-rigorously.

moonchild2• 6 years ago

The zen of Rust is not to eliminate unsafe code. That would require a compiler so ludicrously sophisticated that it would be borderline magical

I'm not sure what you mean by ‘borderline magical’. There are formal verification tools for e.g. c and a subset of ada. The sel4 microkernel has been completely formally verified; i.e. it has no unsafe code.

mlindner• 6 years ago

Memory leaks have nothing to do with "safe programming". Rust simply guarantees that if something is not freed, there is a reference to it. That doesn't mean that circular references or self-referential references can't be created that indeed don't violate what I stated above.

Redox OS 0.6.0

Related Stories