3 ms·

As far as I can tell, Rust OS projects generally use gratuitous amounts of unsafe code and are not substantially different than if they were written in C. I cou

As far as I can tell, Rust OS projects generally use gratuitous amounts of unsafe code and are not substantially different than if they were written in C. I could just be looking in the wrong places. Are there any that take advantage of Rust's type system to provide real guarantees?

Rusky 11y ago
That may just be the impression given by tutorials, which spend most of their time dealing with the hardware. In a real OS, you'd wrap that up in safe interfaces and then the core of things like scheduling, file systems, etc. could be in a safe layer on top of the unsafe drivers.
- cwzwarich 11y ago
  But has anyone actually done that? Can you even express those as safe interfaces in Rust?
  - Jweb_Guru 11y ago
    IMO, the answers to those questions are "no" and "yes" respectively. Redox in particular seems like it has way more unsafe code than it actually has to (though it seems to have gotten a bit better very recently).
  - chadaustin 11y ago
    It's the same thing with Haskell, or any other "real" system that, at some level, has to interface with low-level primitives. The platform gives you a pile of unsafe, low-level primitives ( https://hackage.haskell.org/package/ghc-prim-0.4.0.0/docs/GHC-Prim.html https://hackage.haskell.org/package/ghc-prim-0.4.0.0/docs/GH... ) on top of which you (or a library writer) can provide safe interfaces, e.g. https://hackage.haskell.org/package/buffer-builder https://hackage.haskell.org/package/buffer-builder
    - MaxGabriel 11y ago
      The unsafe low-level stuff gives rise to some great function names like `reallyUnsafePtrEquality` and `accursedUnutterablePerformIO` https://github.com/haskell/bytestring/blob/dd3c07d115840d13482426a0084a39201eb6b6d4/Data/ByteString/Internal.hs#L515-L546 https://github.com/haskell/bytestring/blob/dd3c07d115840d134...
kibwen 11y ago
The OP talks about this in the most recent post: "In the previous post we switched from assembly to Rust, a systems programming language that provides great safety. But so far we are using unsafe features like raw pointers whenever we want to print to screen. In this post we will create a Rust module that provides a safe and easy-to-use interface for the VGA text buffer."
- deleted 11y ago
  [deleted]
steveklabnik 11y ago
I expect a lot of this to be like this at first: https://www.reddit.com/r/rust/comments/3mw67c/i_am_jackpot51_the_writer_of_redox_a_rust/cvizko4?context=2 https://www.reddit.com/r/rust/comments/3mw67c/i_am_jackpot51... There's a period of writing only all the usual stuff that you've done before, then slowly discovering what kinds of abstractions you can put over it, and what kinds of stuff needs to remain super-low.
ntrepid8 11y ago
There are times that you have to do "unsafe" things when interacting directly with hardware. That's not to say one shouldn't attempt to limit the use of "unsafe" to use cases that absolutely require it.

Rusky 11y ago

That may just be the impression given by tutorials, which spend most of their time dealing with the hardware. In a real OS, you'd wrap that up in safe interfaces and then the core of things like scheduling, file systems, etc. could be in a safe layer on top of the unsafe drivers.

cwzwarich 11y ago
But has anyone actually done that? Can you even express those as safe interfaces in Rust?
- Jweb_Guru 11y ago
  IMO, the answers to those questions are "no" and "yes" respectively. Redox in particular seems like it has way more unsafe code than it actually has to (though it seems to have gotten a bit better very recently).
- chadaustin 11y ago
  It's the same thing with Haskell, or any other "real" system that, at some level, has to interface with low-level primitives. The platform gives you a pile of unsafe, low-level primitives ( https://hackage.haskell.org/package/ghc-prim-0.4.0.0/docs/GHC-Prim.html https://hackage.haskell.org/package/ghc-prim-0.4.0.0/docs/GH... ) on top of which you (or a library writer) can provide safe interfaces, e.g. https://hackage.haskell.org/package/buffer-builder https://hackage.haskell.org/package/buffer-builder
  - MaxGabriel 11y ago
    The unsafe low-level stuff gives rise to some great function names like `reallyUnsafePtrEquality` and `accursedUnutterablePerformIO` https://github.com/haskell/bytestring/blob/dd3c07d115840d13482426a0084a39201eb6b6d4/Data/ByteString/Internal.hs#L515-L546 https://github.com/haskell/bytestring/blob/dd3c07d115840d134...

kibwen 11y ago

The OP talks about this in the most recent post: "In the previous post we switched from assembly to Rust, a systems programming language that provides great safety. But so far we are using unsafe features like raw pointers whenever we want to print to screen. In this post we will create a Rust module that provides a safe and easy-to-use interface for the VGA text buffer."

deleted 11y ago
[deleted]

steveklabnik 11y ago

I expect a lot of this to be like this at first: https://www.reddit.com/r/rust/comments/3mw67c/i_am_jackpot51_the_writer_of_redox_a_rust/cvizko4?context=2 https://www.reddit.com/r/rust/comments/3mw67c/i_am_jackpot51... There's a period of writing only all the usual stuff that you've done before, then slowly discovering what kinds of abstractions you can put over it, and what kinds of stuff needs to remain super-low.

ntrepid8 11y ago

There are times that you have to do "unsafe" things when interacting directly with hardware. That's not to say one shouldn't attempt to limit the use of "unsafe" to use cases that absolutely require it.