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

111–120 of 144 posts

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

#111

Post by Animats »

telotortium wrote: post #106
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…

What is the state of documentation on QNX? Is there sufficient documentation that it would be possible to write a QNX-compatible kernel from the documentation (plus access to a QNX machine, which has to be available somehow outside of industry, right?)?

Until Blackberry bought it, it was open source. There were free downloads. Now it's proprietary. But there's a lot of info out there from the open source era. The manuals are available.

Here's the original QNX paper.[1]

[1] https://cseweb.ucsd.edu/~voelker/cse221/papers/qnx-paper92.p...

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

#112

Post by steveklabnik »

comex wrote: post #110
gammagoblin wrote: post #96

Earlier quoted context omitted.

>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…

Based on [1], also full support for s390x (IBM mainframes), as well as support for SPARC, WebAssembly, and asm.js as targets only (you can't run rustc itself on them, but can cross-compile to them). RISC-V support was recently merged into master (not sure why it's not on that page). AVR and m68k (seriously) both have actively developed ports which are living in forks until they're ready to be merged. Anyway, most of…

It’s not on that page for the simplest reason in open source: nobody sent in a PR.

I’ll look into it tomorrow, thanks.

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

#113

Post by steveklabnik »

paavoova wrote: post #107
pjmlp wrote: post #102

Earlier quoted context omitted.

Because it is a big difference to have 100% of the code unsafe or just a set of visible code regions marked as such.

Hyperbole, or do really believe every line of C is unsafe, in the literal sense, by default? Pray tell me what is the difference between // safe, tested, C ... // potentially dangerous C deemed thus for whatever arbitrary reason And // "safe" Rust ... // "unsafe" Rust

Static analysis.

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

#114

Post by steveklabnik »

qaq wrote: post #22
adamnemecek wrote: post #15

Rust allows for new architectures. Eg beos style os would be a match made in heaven as rust really shines when it comes to async code. Also maybe you could have a less complicated memory manager as you can deal with allocations statically.

"rust really shines" they need to land async/await

We really do. It’s in nightly; likely to hit stable early next year. One of its precursors is being stabilized as we speak.

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

#115

Post by arcticbull »

tom_mellior wrote: post #86
arcticbull wrote: post #58

Earlier quoted context omitted.

> Slide 12: IMO the big GC related issue is lack of determinism especially in the management of external resources. If you need that in a managed language you're forced into grafting reference counting on top which is particularly error-prone and unpleasant. Interacting with other languages can be slow, and bridging uncomfortable. > Slide 14: Rust can be faster than C in the general case because of the optimizations…

> Rust can be faster than C in the general case because of the optimizations permitted by, among other things, strict aliasing rules. Sure. The same is true for Fortran, for example. It's just that the few benchmarks of Rust vs. C I have seen so far all seem rigged in one way or another.

Definitely, and Rust isn't the only language that can be faster than C. All benchmarks are rigged in some way :)

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

#116

Post by arcticbull »

weberc2 wrote: post #108
arcticbull wrote: post #74

Earlier quoted context omitted.

Lack of determinism is absolutely a property of GCs, by definition. You’re never 100% sure when a resource is going to get deallocated/finalized with absolute certainty. This is a dealbreaker for kernel type applications. For instance think of a network socket wrapped in a structure, you can’t rely on a finalizer invocation to close your file descriptor, you don’t know when if ever it will happen so you have to wrap…

> I’m not criticizing pause times, but rather that you can’t rely on code inspection to identify the point of resource deallocation, which is pretty much the flagship feature of a GC :) This is completely wrong. The flagship feature of a GC is memory management, __not__ filehandle management or management of other resources. While many GCs support finalizer hooks, most languages with GCs (Go, Python, etc) explicitly…

In re-reading my statement, I understand the confusion, when I said 'not being able to rely on code inspection is the flagship feature of a GC' I meant, glibly, that non-deterministic deallocation of memory in a way the programmer does not have to (alternatively, cannot) reason about meaningfully.

I suppose in reality it depends. Finalizer hooks are absolutely bad, I agree. Which means that resource management has to be grafted on top of a GC memory model. Since the compiler won't be helping you enforce the management of resources since, as you point out, it's out of scope, it introduces a new vector for error. Rust allows you to bind the two and handle them together, both in a checked/enforced way. I've yet to see a GC'd language that does the same, but I can't think of why one couldn't exist.

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

#117

Post by arcticbull »

rwmj wrote: post #104
arcticbull wrote: post #74

Earlier quoted context omitted.

Lack of determinism is absolutely a property of GCs, by definition. You’re never 100% sure when a resource is going to get deallocated/finalized with absolute certainty. This is a dealbreaker for kernel type applications. For instance think of a network socket wrapped in a structure, you can’t rely on a finalizer invocation to close your file descriptor, you don’t know when if ever it will happen so you have to wrap…

Sorry but this is nonsense. There's a whole field of study of hard realtime garbage collection, and several implementations. Also it's easy even in ordinary GCs to determine when a resource will be freed in the cases when you need that, eg by providing a socket.close() method.

I think we probably agree. I'm not arguing that you can't have hard realtime constraints on a GC language, just that when you're interfacing GC memory with underlying resources you have to graft your own ownership model on top (socket.close()) which is not enforced by the compiler (in any language I've seen) introducing a new vector for error. Rust binds the two deterministically and statically validates both.

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

#118

Post by arcticbull »

jonathanstrange wrote: post #79
arcticbull wrote: post #74

Earlier quoted context omitted.

Lack of determinism is absolutely a property of GCs, by definition. You’re never 100% sure when a resource is going to get deallocated/finalized with absolute certainty. This is a dealbreaker for kernel type applications. For instance think of a network socket wrapped in a structure, you can’t rely on a finalizer invocation to close your file descriptor, you don’t know when if ever it will happen so you have to wrap…

Why should the GC not be able to inform the programmer/language designer when memory is discarded? This is a non-issue. Besides, a kernel has to deal with plenty of forms of nondeterminism anyway.

How would the GC in this case inform you when an object is deallocated? The whole point is scope can be extended arbitrarily by anything and that finalization may happen, or it may not, at some point in the future.

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

#119

Post by dman »

Animats wrote: post #111
telotortium wrote: post #106

Earlier quoted context omitted.

What is the state of documentation on QNX? Is there sufficient documentation that it would be possible to write a QNX-compatible kernel from the documentation (plus access to a QNX machine, which has to be available somehow outside of industry, right?)?

Until Blackberry bought it, it was open source. There were free downloads. Now it's proprietary. But there's a lot of info out there from the open source era. The manuals are available. Here's the original QNX paper.[1] [1] https://cseweb.ucsd.edu/~voelker/cse221/papers/qnx-paper92.p...

I am amazed that I cannot find a copy of the source code from the time it was freely available now.

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

#120

Post by arcticbull »

jonathanstrange wrote: post #77
arcticbull wrote: post #58

Earlier quoted context omitted.

> Slide 12: IMO the big GC related issue is lack of determinism especially in the management of external resources. If you need that in a managed language you're forced into grafting reference counting on top which is particularly error-prone and unpleasant. Interacting with other languages can be slow, and bridging uncomfortable. > Slide 14: Rust can be faster than C in the general case because of the optimizations…

Any dynamic memory allocation lacks determinism, which is why in high integrity systems it often forbidden to dynamically allocate memory. As for Rust can be faster than C, well, people said the same about Ada but it rarely is the case so I wouldn't hold my breath for Rust either. After all, those languages use the same backends - GCC in the case of C & Ada, LLVM in the case of C & Rust. But it's enough to as fast as…

Rust doesn't require a heap, you can use it fully statically and still get the deterministic destructors when your stack object is destroyed.
Post reply on HN