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

Is it time to rewrite the operating system in Rust? [slides]

slideshare.net

Post reply on HN
Print view View original

91–100 of 144 posts

Re: Is it time to rewrite the operating system in Rust? [slides]

#91

Post by tom_mellior »

jcranmer wrote: post #84
protomyth wrote: post #78

Earlier quoted context omitted.

What makes C problematic is that the language is specified in terms of an abstract machine that looks absolutely nothing like real hardware, and executing instructions that make no sense in the abstract machine but are very well-defined in the real hardware is liable to cause problems for the optimizer in the compiler. Is there a language (other than assembly) that would have a closer model to the hardware?

To my knowledge, there isn't any language that really tries to be the kind of "portable assembler" that people try to shoehorn C into. There just really isn't the demand for it, since trying to be a portable assembler requires trading off fidelity to hardware for optimization, and most people would rather have faster code than more accurate hardware representation. The internal IRs of compilers (such as LLVM IR or GC…

The claim about compiler IRs is strange. For one thing, hardware is different. Which hardware are you claiming LLVM IR is "accurate" to?

More concretely, LLVM IR has integer types for any bit size, while actual hardware architectures have only a few. Many real CPUs have condition code registers set as side effects of operations, while LLVM requires explicit compares, etc.

Re: Is it time to rewrite the operating system in Rust? [slides]

#92

Post by Animats »

m0th87 wrote: post #80
Animats wrote: post #76

I'd really like to see an open-source QNX-type microkernel in Rust. Everybody is re-implementing early Unix in Rust, but that's not a good model. The great thing about the QNX model is that the tiny kernel barely changes from year to year, because everything is outside it and not very trusted. So it approaches being totally debugged. L4 is too low-level - you have to run another OS on top of it, usually Linux. QNX of…

Would it be possible to use rump kernels with this to get support for the myriad hardware out there from the get-go? Or are QNX-esque microkernels and rump kernels mutually exclusive for some reason?

Using the drivers from rump kernels with a QNX kernel might work. QNX runs drivers, file systems, and networking in userland. The rump kernel people have those components. The QNX kernel itself does only memory allocation, process management, CPU dispatching, timers, and inter-process messaging. So it's tiny, relatively trouble-free, and has a small attack surface.

So if someone implemented a QNX-style microkernel in Rust, file systems and networking could be adapted from rump kernels. Drivers would require more porting. That would be a nice way to get a usable but small OS for embedded and IoT devices. Linux has more than you want in an embedded device.

Re: Is it time to rewrite the operating system in Rust? [slides]

#93

Post by paulddraper »

burntsushi wrote: post #88
gammagoblin wrote: post #28

Earlier quoted context omitted.

>The question is whether we will end up using their efforts or whether we keep on going back to the same monolith kernels we have been using for the last thirty years or so. Whether it is NT, Linux, or any of the BSD kernels, they each have decades of history behind them. Please just... stop. You are using terms that you clearly don't understand the meaning of. What is a "monolith" from your point of view? Because I…

>> At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C. People are already re-implementing libraries, popular command line tools, > Yes, but some (e.g. ripgrep) don't actually do the same thing as the programs they are supposed to "re-implement". Most Rust "re-implementations" don't actually re-implement programs, they are new programs doing a similar-but-not-quite…

> a distinction worth making, but certainly not in this context.

It is a worthwhile distinction, because the "re-implementation" talked about is often materially different, to the point that it no longer adheres to what little standardization there is.

So realistically we are talking about a new product, or a radical evolution of an existing one. It and everything above it also have to change.

Re: Is it time to rewrite the operating system in Rust? [slides]

#94

Post by gammagoblin »

throwaway_se099 wrote: post #51
gammagoblin wrote: post #43

Earlier quoted context omitted.

>Is there a reason that command line tools cannot be re-implemented in Rust and maintain GNU and POSIX compliance? No, there isn't, but what "re-implementations" that I know of don't even try to do that. >If not then the fact that ripgrep is not compliant is irrelevant to the larger point that Rust command line tools could eventually replace existing C command line tools. Of course it's possible. You can go ahead and…

> C++ at least has extern "C" going for it, which disables name mangling. Rust doesn't have that It does, it's called "#[no_mangle]", and together with an extern "C" fn declaration you get a non-mangled function directly callable from C.

I see, I admittedly didn't know that. Thanks.

Re: Is it time to rewrite the operating system in Rust? [slides]

#95

Post by m0th87 »

lucozade wrote: post #90
m0th87 wrote: post #81

Earlier quoted context omitted.

Despite what the Nim documentation says, realtime and garbage collection are mutually exclusive (unless you count non-deferred reference counting and give up on collecting cycles.) Setting maximum pause times doesn't change the fact that the garbage will be collected nondeterministically, which is a problem for kernels.

Those are 3 orthogonal(ish) things. Realtime just means that actions triggered by event occur in an explicitly bounded time. It doesn't usually mean that they occur in the same time. So a GC with bounded pause could be used in a realtime system assuming you could guarantee the explicit bounds. I can't comment on whether or not this is true of Nim and pause time probably isn't sufficient (depends on how it's defined)…

> So a GC with bounded pause could be used in a realtime system assuming you could guarantee the explicit bounds.

You can't guarantee explicit bounds on when a given resource will be collected with GC. Bounded times can provide upper bounds on GC pass runtime, but they do that by potentially deferring further collection. Those deferrals make it nondeterministic.

> And most kernels don't need to be realtime unless they are realtime kernels.

That's not true. Most (all?) kernels have internal realtime needs, e.g. responding to interrupts.

There is a way to write a kernel with a GC'd language, as Niklaus Wirth has demonstrated, by circumventing the GC where needed. But the critique I was bringing up was simply that there's no such thing as a realtime GC.

Re: Is it time to rewrite the operating system in Rust? [slides]

#96

Post by gammagoblin »

fredmorcos wrote: post #57
gammagoblin wrote: post #43

Earlier quoted context omitted.

>Is there a reason that command line tools cannot be re-implemented in Rust and maintain GNU and POSIX compliance? No, there isn't, but what "re-implementations" that I know of don't even try to do that. >If not then the fact that ripgrep is not compliant is irrelevant to the larger point that Rust command line tools could eventually replace existing C command line tools. Of course it's possible. You can go ahead and…

I don't want to be defending Rust but your post has so many misconceptions. May I ask where you got all that information and what your background is? > C++ at least has extern "C" going for it, which disables name mangling. Rust doesn't have that, nor does it have a stable ABI. Rust has #[no_mangle] and extern "C" and those two guarantee that ABI stability you're looking for. > Then furthermore, a vast amount of effo…

>I don't want to be defending Rust but your post has so many misconceptions. May I ask where you got all that information and what your background is?

I am primarily a systems programmer and write software for the petroleum industry in my country. I work with C++ and in some (rare) cases C, and I've been doing that for the past 4 years. I have my own WIP hobby unix-like microkernel project written in C as well.

>Rust has #[no_mangle] and extern "C" and those two guarantee that ABI stability you're looking for.

I admittedly did not know this before it was pointed out to me.

>That's actually a breeze in Rust, including cross-compilation (which is relatively painful in C/C++).

It really isn't. Have you looked at rustc's compiler targets? It's not a very long list. Support is improving, but there's still a lot of key areas that are completely missing. To my knowledge it supports x86, ARM, MIPS and POWER. That's not a long list.

>There's work towards that: https://gitlab.redox-os.org/redox-os/relibc

That's good, and is genuinely what's necessary to put Rust in key components.

Re: Is it time to rewrite the operating system in Rust? [slides]

#97

Post by jcranmer »

tom_mellior wrote: post #91
jcranmer wrote: post #84

Earlier quoted context omitted.

To my knowledge, there isn't any language that really tries to be the kind of "portable assembler" that people try to shoehorn C into. There just really isn't the demand for it, since trying to be a portable assembler requires trading off fidelity to hardware for optimization, and most people would rather have faster code than more accurate hardware representation. The internal IRs of compilers (such as LLVM IR or GC…

The claim about compiler IRs is strange. For one thing, hardware is different. Which hardware are you claiming LLVM IR is "accurate" to? More concretely, LLVM IR has integer types for any bit size, while actual hardware architectures have only a few. Many real CPUs have condition code registers set as side effects of operations, while LLVM requires explicit compares, etc.

The big thing that you see in LLVM IR that you don't see in C is vector register support. There is also support for multiple return values, as well as some better coverage of hardware instructions via intrinsics (e.g., fma). It is somewhat poor in support for things like exposing hardware exceptions and the condition code support, and its support for vectors, floating point, and bit sizes is definitely in the realm of supporting union of architectural possibilities instead of the intersection.

I definitely would not call LLVM IR accurate to hardware, but it is more accurate than C is.

Re: Is it time to rewrite the operating system in Rust? [slides]

#98

Post by paavoova »

jillesvangurp wrote: post #18

I think the question is wrong. People are already writing new operating systems in Rust just because they can. The question is whether we will end up using their efforts or whether we keep on going back to the same monolith kernels we have been using for the last thirty years or so. Whether it is NT, Linux, or any of the BSD kernels, they each have decades of history behind them. These will of course still be around…

> A lot of these implementations have clear merit in the sense that they are faster, safer to use, easier to scale, maintain, etc.

Depends on who you ask. Hipp on Rust in 2016:

Rewriting SQLite in Rust, or some other trendy “safe” language, would not help. In fact it might hurt.

https://blog.regehr.org/archives/1292#comment-18452

> drivers written in Rust

If you have to write inline assembly, and generally bypass Rust's security features and use "unsafe" code, why wouldn't you just use C?

Re: Is it time to rewrite the operating system in Rust? [slides]

#99

Post by eatbitseveryday »

magduf wrote: post #39
exabrial wrote: post #29

Earlier quoted context omitted.

Hilarious example of why English is a terrible language: I meant for the the pronoun to refer to Joyent, not [necessarily] the CTO.

No, that's an example of someone not knowing the language very well. You should have written something like, "which is the company that...". I can't think offhand of any language that's really better here in a sense of being more efficient, except probably Classical Latin which is horribly complicated and of course a dead language.

>> Presentation by the Joyent CTO btw, who hired a lot of the old Sun Solaris team.

> No, that's an example of someone not knowing the language very well.

I disagree. The sentence is clear and unambiguous as written. The subject of the first part of the sentence is the CTO himself. If the continuation of the sentence is intended to switch subjects, then it must be written so. For example, '... by the Joyent CTO, whose company ...', or '... by Joyent, who/which ...' thus 'who' refers to 'CTO'.

Re: Is it time to rewrite the operating system in Rust? [slides]

#100

Post by bryanrasmussen »

tux1968 wrote: post #63
bryanrasmussen wrote: post #2

http://www.erights.org/elang/intro/index.html

Hadn't heard about this before, and it does look interesting. But not sure why you're linking to it in this context without comment? Especially since it seems to be a moribund project.

E had a pretty interesting security model and there were in various E writings expressions of pipe dreams that operating systems should be rewritten using it. I should probably have linked to one of those to make the connection more explicit, but really it was just a momentary bit of snarkiness that didn't deserve more than what I gave it.
Post reply on HN