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

Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

github.com

Post reply on HN
Print view View original

151–160 of 196 posts

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#151

Post by Iv »

uuddlrlr wrote: post #58
rakoo wrote: post #44

Earlier quoted context omitted.

> I know this kind of stuff spark the ``it's meaningless to rewrite everything (especially Linux) in Rust'' debate. I agree 100% that rewriting Linux in Rust (or your favorite language) is just a waste of time and such a project won't live long. Considering that this is exactly how Linux was born (just a hobby project for fun), I wouldn't assume so fast that it's useless. Moreover, you don't need to justify yourself…

Any rust project like this inevitably gets sardonic replies about rewrite-in-rust fanaticism. I agree they shouldn't have to justify themselves, but it is handy to preempt that.

Also, the rust community is too nice to openly admit it, but it's goal IS to displace C as the main low level language especially for the kernel. This is doomed to attract a lot of attention

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#152

Post by zokula »

dnautics wrote: post #129
PaulDavisThe1st wrote: post #121

Earlier quoted context omitted.

Mach's internals didn't follow the Unix model, and was by almost any metric a failure. There have been several other "real micro kernel based OS based on a message passing core", and they too, by almost any metric, have been a failure. Process scheduling in Linux in 2021 is far, far ahead of anything in any other OS, ukernel or MP-based. The idea that there hasn't been progress in this area is really completely absur…

> "real micro kernel based OS based on a message passing core", and they too, by almost any metric, have been a failure. BeOS wasn't half bad. The failure was probably mostly commercial. It is true that they moved their networking stack into the kernel, but it's not entirely clear to me that they had to do that, it was just the most expedient way to get acceptable performance and stability given the (programmer-time)…

BeOS wasn't a microkernel.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#153

Post by elihu »

afr0ck wrote: post #117
jacquesm wrote: post #60

Rewriting the Linux kernel in rust would be a rehash of why we ended up with Linux in the first place: rewriting an older OS from scratch. I would love to see a solid implementation of a real micro kernel based OS based on a message passing core in Rust to become a viable alternative to the now 50 year old Unix architecture. This would give us a possibility of some real progress on the security and process scheduling…

Why do people implicitly assume that micro kernels are the best OS design? In fact, micro kernels have a lot of issues and limit the possibilities of what an OS can do! One of the most important issues is they prevents resource sharing in a rich and efficient way between the components of the kernel. They make building rich relationships between kernel data structures and kernel subsystems very messy, complicated, im…

Historically, one of the main arguments against microkernels is that having a kernel that's broken up into a lot of threads that each have their own hardware-enforced memory protection and use message passing to communicate with each other is dreadfully inefficient. All those context switches are expensive, and copying all that data around when you send messages is expensive.

Rust's memory model largely makes those isolated address spaces unnecessary, and sending a message at runtime basically amounts to copying a pointer. So, with these performance issues resolved, I think it makes sense to look at microkernels again. The reasons why Linus was opposed to writing Linux as a microkernel in the 90's don't necessarily still apply now in 2021.

There may some things the Linux kernel does that can't be efficiently expressed using a message-passing style, but I don't know if that's actually true or not.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#154

Post by jacquesm »

PaulDavisThe1st wrote: post #121
jacquesm wrote: post #60

Rewriting the Linux kernel in rust would be a rehash of why we ended up with Linux in the first place: rewriting an older OS from scratch. I would love to see a solid implementation of a real micro kernel based OS based on a message passing core in Rust to become a viable alternative to the now 50 year old Unix architecture. This would give us a possibility of some real progress on the security and process scheduling…

Mach's internals didn't follow the Unix model, and was by almost any metric a failure. There have been several other "real micro kernel based OS based on a message passing core", and they too, by almost any metric, have been a failure. Process scheduling in Linux in 2021 is far, far ahead of anything in any other OS, ukernel or MP-based. The idea that there hasn't been progress in this area is really completely absur…

Meanwhile, the world runs on QnX. The fact that you don't realize it and don't see it is testimony to its success.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#155

Post by jacquesm »

chasil wrote: post #112
jacquesm wrote: post #60

Rewriting the Linux kernel in rust would be a rehash of why we ended up with Linux in the first place: rewriting an older OS from scratch. I would love to see a solid implementation of a real micro kernel based OS based on a message passing core in Rust to become a viable alternative to the now 50 year old Unix architecture. This would give us a possibility of some real progress on the security and process scheduling…

Fuchsia and QNX provide a lot of what you want. https://en.wikipedia.org/wiki/QNX https://en.wikipedia.org/wiki/Fuchsia_(operating_system) https://lobste.rs/s/p8bizb/getting_know_fuchsia_google_s_ope...

I think I'm aware of QnX ;) (I wrote a clone).

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#156

Post by cormacrelf »

bluejekyll wrote: post #120
cormacrelf wrote: post #91

Earlier quoted context omitted.

An addendum to tie this back to the original discussion: the reason kernel devs want these APIs more than userland is that (a) in a kernel, panicking = crashing the computer, which would be bad, and (b) they have a much bigger toolbox for handling OOM. They can kill entire misbehaving processes. What are you going to do in your little program, clear a cache whose objects are sprinkled evenly across 150 different page…

> panicking = crashing the computer That isn't very accurate. In Rust when programming in no_std, you can (must?) define your own panic handler: https://doc.rust-lang.org/nomicon/panic-handler.html Which you would define in the kernel. While I'm not going to speculate on exactly what the implementation would look like, you definitely do not need to "crash" the computer. I haven't done any kernel programming, but I'm…

Mm no, it's pretty accurate. For a start, notice that the Linux community has been very clear that panicking is unacceptable. The reason is that they cannot realistically do anything to recover.

> panic handler [...] Which you would define in the kernel. While I'm not going to speculate on exactly what the implementation would look like, you definitely do not need to "crash" the computer.

The panic handler loses so much of the context that crashing the computer is the only thing you can practically achieve. You can't retry an operation generically from with a panic handler, it doesn't know anything about the operation you were attempting. The OOM handler gets a Layout struct only. You could try unwinding or something, but within a syscall handler, I don't see how anything good can come from that. Unwinding in the kernel is simply a terrible idea. What else are you going to do?

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#157

Post by fitzn »

ativzzz wrote: post #143

What are some ways I can increase my knowledge in this domain that the OP is very skilled at, meaning low level OS development? I've taken an intro to OS class and am currently going through Linux From Scratch [1], which is interesting and is teaching me a lot, but it's more about how to setup a Linux distro using existing packages and not really about reading/writing the code involved. Any recommendations? [1] https…

I think you're on the right track. I am similar to you and not so skilled at low level OS development. There is an educational OS called PIOS from Yale's CS department with specific parallelism goals in mind, but it boots from metal so the code is a great resource. Here's the code: https://github.com/bford/PIOS

Also, you could try reading the Plan 9 source code.

(I would say the code is what you're after now, but in case you are interested in more of the theory of why it's designed that way, you can check out the research paper here: https://dedis.cs.yale.edu/2010/det/)

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#158

Post by nuta »

bitcoinmoney wrote: post #102
nuta wrote: post #41

Author here. I'm surprised to see my hobby project on Hacker News. I know this kind of stuff spark the ``it's meaningless to rewrite everything (especially Linux) in Rust'' debate. I agree 100% that rewriting Linux in Rust (or your favorite language) is just a waste of time and such a project won't live long. That said, what I'd say here is that it's fun. Really fun. Implementing ABI compatibility requires you to und…

How long did it take you to write this?

About 3-4 months in total: took 1.5 month to run a simple Hello World program, 1 month to implement bunch of system calls, and another 1 month to implement features essential to run Dropbear SSH server (tty/pry, bug fixes, …).

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#159

Post by nuta »

a-dub wrote: post #98
nuta wrote: post #41

Author here. I'm surprised to see my hobby project on Hacker News. I know this kind of stuff spark the ``it's meaningless to rewrite everything (especially Linux) in Rust'' debate. I agree 100% that rewriting Linux in Rust (or your favorite language) is just a waste of time and such a project won't live long. That said, what I'd say here is that it's fun. Really fun. Implementing ABI compatibility requires you to und…

nice project! curious how the rust ownership model works in a monolithic kernel context. are the lifetimes of kernel structures associated with a process "owned" by the process itself somehow?

I’m not sure this answers what you asked, objects that are referenced from multiple objects are simply wrapped with Arc.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#160

Post by nuta »

allochthon wrote: post #114
nuta wrote: post #41

Author here. I'm surprised to see my hobby project on Hacker News. I know this kind of stuff spark the ``it's meaningless to rewrite everything (especially Linux) in Rust'' debate. I agree 100% that rewriting Linux in Rust (or your favorite language) is just a waste of time and such a project won't live long. That said, what I'd say here is that it's fun. Really fun. Implementing ABI compatibility requires you to und…

I'm new to Rust and am far less along than you are, as evidenced by this project. I noticed that in the few files I spot checked, there aren't many/any tests. Without any context or opinion, I'm curious whether unit and integration testing are hard for a project like this.

Good point. As you say Kerla lacks unit tests I focused on running a SSH server as soon as possible.

IMO, writing and running tests in the kernel space is pretty easy thanks to Rust’s flexible testing feature [1].

[1]: https://os.phil-opp.com/testing/

Post reply on HN