Writing an OS in Rust: Introduction to Paging

Re:Writing an OS in Rust: Introduction to Paging by fermienrico on Monday January 14, 2019 @10:21AM (#18903582)

As a side note: I wish Rust would come to embedded development ASAP running a real time OS written in Rust. You can use massive Boost libraries and Qt frameworks on non-embedded systems with C/C++, but in embedded, there is no such luxury. I am new to it but it is painful and I wish to see a day where we have a complete LLVM based ARM compiler toolchain with Rust sitting on top. I think there were some blog posts about running Rust on STM32 but it is still very early.

[ Parent | on HN ]

Re:Writing an OS in Rust: Introduction to Paging by jamesmunns on Monday January 14, 2019 @10:56AM (#18903895)

Hey, I saw that links to the Embedded Working Group[0], TockOS[1], and others have been posted already, and those are great places to start!

My company, Ferrous Systems[2], is also focused on embedded systems development in Rust, and we are already helping companies both with embedded linux and bare-metal/RTOS projects in Rust.

We're also running a conference in Berlin on April 26th-29th called OxidizeConf[3] if you are interested in learning more about what is already going on in the Embedded Rust world :)

[0]: https://github.com/rust-embedded/wg

[1]: https://www.tockos.org/

[2]: https://ferrous-systems.com

[3]: https://oxidizeconf.com

[ Parent | on HN ]

Re:Writing an OS in Rust: Introduction to Paging by nicoburns on Monday January 14, 2019 @10:25AM (#18903622)

It is still pretty early, but if there's been quite a bit of progress this year. This is probably the closest to what you are looking for that exists at the moment: https://github.com/japaric/cortex-m-rtfm

You can also follow the Rust Embedded Working Group blog if you wish: https://rust-embedded.github.io/blog/

[ Parent | on HN ]

Re:Writing an OS in Rust: Introduction to Paging by fermienrico on Monday January 14, 2019 @10:33AM (#18903686)

Thank you for sharing, subscribed. As I read through the Rust Embedded Work Group manifesto, it is comforting to see the level of organizational skills, planning and vision of the team involved. Bravo. https://github.com/rust-embedded/wg

[ Parent | on HN ]

Re:Writing an OS in Rust: Introduction to Paging by bluejekyll on Monday January 14, 2019 @10:26AM (#18903631)

Have you looked at TockOS? https://www.tockos.org

I took a class in it about 2 years ago now, it was really cool. I’m not an embedded developer though, so not sure of your needs here.

[ Parent | on HN ]

Re:Writing an OS in Rust: Introduction to Paging by vardump on Monday January 14, 2019 @10:39AM (#18903742)

Ooh that looks pretty interesting!

Tock appears to be a Rust based embedded OS, so relevant to this discussion.

https://github.com/tock/tock

[ Parent | on HN ]

Re:Writing an OS in Rust: Introduction to Paging by wyldfire on Monday January 14, 2019 @10:37AM (#18903731)

> I wish Rust would come to embedded development ASAP running a real time OS written in Rust.

You want someone to write a Rust RTOS? Or would it suffice for a vendor to release a BSP with Rust support? IMO your current RTOS vendor can (and should!) offer this. Lots of existing RTOS companies will vendor a gcc or clang toolchain for their customers. The fact that C and C++ are well specified independent of their implementation really helps, though. But the baseline rust toolchain already provides a lot of what's needed. They "just" need to offer integration with their C library, designate llvm triple(s), etc.

If your RTOS vendor offers support for C and C++ already, chances are you can write rust for your target already. Unfortunately you'll need to stick to no_std until that BSP shows up though. :)

[ Parent | on HN ]

Re:Writing an OS in Rust: Introduction to Paging by bluejekyll on Monday January 14, 2019 @11:17AM (#18904068)

BSP, board support package.

I had to look that up, seem like what you’re talking about here.

[ Parent | on HN ]

Re:Writing an OS in Rust: Introduction to Paging by wyldfire on Monday January 14, 2019 @11:24AM (#18904122)

Sorry, yes, that's what I meant. It's a soup-to-nuts working+tested configuration of a board, bootstrap code, examples that exercise board features, etc. IIRC this is common for chip/computer/board/RTOS vendors to provide.

[ Parent | on HN ]

Re:Writing an OS in Rust: Introduction to Paging by SlowRobotAhead on Monday January 14, 2019 @10:47AM (#18903823)

Get used to the idea that embedded is 15 years behind PC. Which is initially frustrating but if you step back is kind of a good thing.

I’d also like to see Rust make it’s way into embedded. C support for things like data serialization or RPC for interfacing to web stuff is limited, people just don’t port it to C. And C++ doesn’t thrill me in terms of its non-deterministic garbage handling and difficult to debug nature. Rust though, seems modern and still safe, but I looked over the crates for embedded it’s prstty slim pickings!

When I see mfgs pushing out their own Rust libs, or a professional IDE with support I can buy that uses the Rust compiler, I’ll give it a try. Until then, it’s clearly hobbiest-only.

[ Parent | on HN ]

Re:Writing an OS in Rust: Introduction to Paging by sidcom on Monday January 14, 2019 @12:35PM (#18904668)

Non deterministic garbage handling doesn't sound right in combination with C++. You have to do it your self. And you can make it deterministic.

[ Parent | on HN ]

Re:Writing an OS in Rust: Introduction to Paging by mlindner on Monday January 14, 2019 @04:18PM (#18906590)

C++ has deterministic garbage collection.

[ Parent | on HN ]

Re:Writing an OS in Rust: Introduction to Paging by intea on Tuesday January 15, 2019 @06:17AM (#18910342)

C++ does not have garbage collection of any sorts. Objects leave the scope and are destroyed, however the order in which they are destroyed is not defined by the standard.

[ Parent | on HN ]

Re:Writing an OS in Rust: Introduction to Paging by pjmlp on Tuesday January 15, 2019 @05:07PM (#18915958)

C++ has a garbage collection interface API since ISO C++11, it is up to the respective implementation to provide an optional implementation.

[ Parent | on HN ]