Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making a RISC-V Operating System Using Rust

web.eecs.utk.edu

Post reply on HN
Print view View original

21–30 of 47 posts

Re: Making a RISC-V Operating System Using Rust

#21

Post by mrec »

flohofwoe wrote: post #15
mrec wrote: post #13

Earlier quoted context omitted.

If you do, definitely ping flohofwoe, who a) maintains a Zig port of his lightweight Sokol graphics API and b) has a penchant for retro consoles. https://github.com/floooh/sokol-zig

The zig wrapper is only a minimal experiment and work in progress now, also I've hit a little bug :) https://github.com/ziglang/zig/issues/3211 BUT the sokol_app.h and sokol_gfx.h headers require an underlying platform 3D-API (e.g. GL, D3D11 or Metal) and window system to setup the swap chain. On a bare metal machine with only a 2D framebuffer they're not all that useful unfortunately.

Ah yes, I didn't really think that one through. I know Redox OS (Rust) has OpenGL working, but I think they're just using the Mesa software renderer.

Re: Making a RISC-V Operating System Using Rust

#22

Post by tal8d »

coldnose wrote: post #17

Rust is build around the expectation that allocations happen automatically and can never fail. I’m curious to see how they deal with this in a kernel...

Try harder: https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html#t...

You can implement your own global allocator, use an existing crate, or (in the case of user applications) use the system's. That is for the stdlib level, not even core...

Re: Making a RISC-V Operating System Using Rust

#23

Post by DannyB2 »

loquor wrote: post #19

For someone with a standard CS undergraduate education, how much effort (in hrs/week) would such an endeavour require?

Old wives tail from ancient times, before CompuServe:

The first 20% of the effort gets you about 80% of the results. So everything seems exciting. But to that that last 20% of the results requires 80% of the total work.

There is a ton of un-fun, un-glamorous work getting a gazillion device drivers written, for example.

Re: Making a RISC-V Operating System Using Rust

#24

Post by kbenson »

DannyB2 wrote: post #14
GRBurst wrote: post #8

I really really like the first sentence > RISC-V ("risk five") and the Rust programming language both start with an R, so naturally they fit together

When RISC-V inevitably renames itself CISC-V, then what language would naturally fit together? And don't say cobol.

Why nor CRISC-V? Or CaRISC-V? Or (eww) RaCISC-V?

It's not like current "CISC" architectures haven't taken a lot of the good aspects of RISC already too...

Re: Making a RISC-V Operating System Using Rust

#25

Post by duckqlz »

Wow! What an awesome tutorial/book. I look forward to reading more chapters. This is already an extremely useful resource since it covers cross compilation from an x86 system. I love to play around with this kind of stuff in my free time but connecting to dev boards and constantly shifting paradigms was annoying enough to limit my enthusiasm. It took a lot of research to find out how to do what the author fits in a single chapter. Thank you for this awesome post!

Re: Making a RISC-V Operating System Using Rust

#26

Post by gpm »

DannyB2 wrote: post #14
GRBurst wrote: post #8

I really really like the first sentence > RISC-V ("risk five") and the Rust programming language both start with an R, so naturally they fit together

When RISC-V inevitably renames itself CISC-V, then what language would naturally fit together? And don't say cobol.

Cython with a rust core?

Re: Making a RISC-V Operating System Using Rust

#27

Post by nickpsecurity »

DannyB2 wrote: post #23
loquor wrote: post #19

For someone with a standard CS undergraduate education, how much effort (in hrs/week) would such an endeavour require?

Old wives tail from ancient times, before CompuServe: The first 20% of the effort gets you about 80% of the results. So everything seems exciting. But to that that last 20% of the results requires 80% of the total work. There is a ton of un-fun, un-glamorous work getting a gazillion device drivers written, for example.

You can always use a hypervisor, a driver OS that re-uses Windows/Linux drivers, and the new OS in a VM using virtual drivers. That's what some L4-based setups, including commercial OKL4, did. They also let you write native drivers directly on the microkernel or in OS VM's for situations where effort was justified. I'm surprised more haven't done this.

Rump kernels are the closest trend.

Re: Making a RISC-V Operating System Using Rust

#28

Post by mindcrime »

DannyB2 wrote: post #14
GRBurst wrote: post #8

I really really like the first sentence > RISC-V ("risk five") and the Rust programming language both start with an R, so naturally they fit together

When RISC-V inevitably renames itself CISC-V, then what language would naturally fit together? And don't say cobol.

Ceylon?[1]

Crystal?[2]

Church?[3]

Coq?[4]

[1]: https://ceylon-lang.org/

[2]: https://crystal-lang.org/

[3]: https://en.wikipedia.org/wiki/Church_(programming_language)

[4]: https://en.wikipedia.org/wiki/Coq

Re: Making a RISC-V Operating System Using Rust

#29

Post by Someone »

DannyB2 wrote: post #14
GRBurst wrote: post #8

I really really like the first sentence > RISC-V ("risk five") and the Rust programming language both start with an R, so naturally they fit together

When RISC-V inevitably renames itself CISC-V, then what language would naturally fit together? And don't say cobol.

COMTRAN would be a way better choice than COBOL :-) (https://en.wikipedia.org/wiki/COMTRAN)

Common Lisp would be a decent choice, too, with

    CISC:RISC = Common Lisp:Scheme

Re: Making a RISC-V Operating System Using Rust

#30

Post by madmulita »

DannyB2 wrote: post #14
GRBurst wrote: post #8

I really really like the first sentence > RISC-V ("risk five") and the Rust programming language both start with an R, so naturally they fit together

When RISC-V inevitably renames itself CISC-V, then what language would naturally fit together? And don't say cobol.

Obviously: Clojure.
Post reply on HN