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

161–170 of 196 posts

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

#161

Post by elihu »

hnlmorg wrote: post #89
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…

I don't see why we need to pretend that every hobby has the potential for greatness. Being a hobby is a good enough end to itself. In fact in this instance I think it's a little disingenuous to quote Linux and say it could happen again. The industry is totally different now. There's much more competition than there was when Linux was released and that competition is much more mature too. Plus the bar for a production…

> There's much more competition than there was when Linux was released and that competition is much more mature too.

I think it's the opposite. When Linux was released, basically every major tech company had their own variant of Unix. Now almost everyone has migrated to Linux or Windows.

Competing with modern Linux by creating a drop-in replacement for Linux would be a pretty difficult task given that people have been optimizing Linux for decades now, but on the other hand I think there are ways to improve dramatically on the traditional POSIX-style API that Linux mostly adheres to. For a random example, why can't a given process have more than one "current working directory" at a time? That seems like an arbitrary limitation imposed by an implementation detail in early Unix system, and it causes problems for modularity. There are many other little details like that. I think if Linux is replaced by something eventually, it'll most likely be because the new thing has a cleaner, more powerful, or more generally usable API.

(Kerla is apparently not trying to invent a new API; I'm just saying that's the direction I would recommend to anyone project with a goal of seriously competing with Linux.)

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

#162

Post by ativzzz »

fitzn wrote: post #157
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…

Thanks!

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

#163

Post by elihu »

elihu wrote: post #161
hnlmorg wrote: post #89

Earlier quoted context omitted.

I don't see why we need to pretend that every hobby has the potential for greatness. Being a hobby is a good enough end to itself. In fact in this instance I think it's a little disingenuous to quote Linux and say it could happen again. The industry is totally different now. There's much more competition than there was when Linux was released and that competition is much more mature too. Plus the bar for a production…

> There's much more competition than there was when Linux was released and that competition is much more mature too. I think it's the opposite. When Linux was released, basically every major tech company had their own variant of Unix. Now almost everyone has migrated to Linux or Windows. Competing with modern Linux by creating a drop-in replacement for Linux would be a pretty difficult task given that people have bee…

Follow up to add: another way to compete with Linux is on security. The Linux kernel generally has a pretty good security record I think, but there have been plenty of serious bugs over the years. How many exploitable array-out-of-bounds errors or use-after-free errors remain in the Linux kernel? No one knows. If you can rule those out by using a safer language, that might be compelling to a lot of users who care about security above other concerns.

Of course that's hard to pull off in practice. Linux might have classes of errors that wouldn't exist if it were written in Rust, but even if using Rust eliminates three fourths of the code defects, the end result could be less secure if Linux gets ten or a hundred times as much scrutiny from people actively looking through the code for bugs to fix.

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

#164

Post by PaulDavisThe1st »

jacquesm wrote: post #154
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…

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

I know that QnX is widespread, but far more devices run Android than QnX. It's a bit of a philosophical debate whether the software that runs most smartphones "runs the world" more or less than the stuff covered by QnX, but I'd say that's its a bit of a stretch to just give the win to QnX :)

But you're right, QnX is the one (probably the only?) micro-kernel that has seen widespread adoption. Almost all of it has been in the context of embedded systems, which doesn't invalidate the substantial success, but it does leave QnX as the exception that proves the rule. It also leaves QnX as yet another example of the general failure of microkernels as general purpose computing platforms. QnX design is excellent for the contexts where it is deployed, but there's a reason you don't run it on PCs, tablets, data crunchers, smartphones and many other sorts of computing contexts.

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

#165

Post by PaulDavisThe1st »

zokula wrote: post #152
dnautics wrote: post #129

Earlier quoted context omitted.

> "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.

I should have (and did) know better. Thanks for the reminder.

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

#166

Post by dnautics »

zokula wrote: post #152
dnautics wrote: post #129

Earlier quoted context omitted.

> "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.

Depends on your definition of microkernel. Maybe it wasn't pure, but It was in many ways closer to a microkernel than a monolith; sure the filesystem ran in ring 0, but it was scheduled onto its own threads by the scheduler just like any other process.

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

#167

Post by jacquesm »

PaulDavisThe1st wrote: post #164
jacquesm wrote: post #154

Earlier quoted context omitted.

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

I know that QnX is widespread, but far more devices run Android than QnX. It's a bit of a philosophical debate whether the software that runs most smartphones "runs the world" more or less than the stuff covered by QnX, but I'd say that's its a bit of a stretch to just give the win to QnX :) But you're right, QnX is the one (probably the only?) micro-kernel that has seen widespread adoption. Almost all of it has been…

Lots of devices run on Android but that's because there isn't a valid alternative. QnX and it's brethren are used where failure is not an option.

I used it daily on my PC for years and it was hands down the best environment I've used with distance (mostly compared to IRIX, Windows and Linux). Super responsive, never locks up, no weird delays it just works, 24x7, year after year. The whole throughput argument never worked anyway, that was just Linus talking about something that he didn't have direct experience with, it's latency that is far more important than raw throughput in interactive computing because interactive computing is a real time task.

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

#168

Post by hnlmorg »

elihu wrote: post #161
hnlmorg wrote: post #89

Earlier quoted context omitted.

I don't see why we need to pretend that every hobby has the potential for greatness. Being a hobby is a good enough end to itself. In fact in this instance I think it's a little disingenuous to quote Linux and say it could happen again. The industry is totally different now. There's much more competition than there was when Linux was released and that competition is much more mature too. Plus the bar for a production…

> There's much more competition than there was when Linux was released and that competition is much more mature too. I think it's the opposite. When Linux was released, basically every major tech company had their own variant of Unix. Now almost everyone has migrated to Linux or Windows. Competing with modern Linux by creating a drop-in replacement for Linux would be a pretty difficult task given that people have bee…

> I think it's the opposite. When Linux was released, basically every major tech company had their own variant of Unix. Now almost everyone has migrated to Linux or Windows.

There wasn't many UNIXes that targeted x86 aside from 386BSD. And even those that were available were often expensive. Even Minix wasn't free at that time. Which is exactly the reason Linus created his hobby OS.

Now we have a dozen different flavours of BSD, countless Linux distributions and several OpenSolaris spin offs too. Plus many other underdogs used in speciality domains. And that's before even looking at the commercial offerings like QNX, Solaris and macOS.

Just because there are a couple of industry heavyweights that take up the majority of common use cases, don't be fooled into thinking there is a lack of choice nor even that the industry is scared to use anything outside of Linux and Windows.

> Competing with modern Linux by creating a drop-in replacement for Linux would be a pretty difficult task given that people have been optimizing Linux for decades now, but on the other hand I think there are ways to improve dramatically on the traditional POSIX-style API that Linux mostly adheres to. For a random example, why can't a given process have more than one "current working directory" at a time? That seems like an arbitrary limitation imposed by an implementation detail in early Unix system, and it causes problems for modularity. There are many other little details like that. I think if Linux is replaced by something eventually, it'll most likely be because the new thing has a cleaner, more powerful, or more generally usable API.

That's not the goal of this nor any other project that aims for ABI compatibility with Linux and there are plenty of research kernels out there if that's your thing.

> (Kerla is apparently not trying to invent a new API; I'm just saying that's the direction I would recommend to anyone project with a goal of seriously competing with Linux.)

The only way to seriously compete with Linux would be to get large commercial backing. And even then, good luck. Linux won not because it is the best but instead because it's "good enough". Same is true with Windows. Any engineer with aspirations of creating a "better kernel" or "better OS" needs to remember that.

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

#169

Post by adwn »

elihu wrote: post #153
afr0ck wrote: post #117

Earlier quoted context omitted.

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

> Rust's memory model largely makes those isolated address spaces unnecessary,

I think you're confusing several concepts. Rust's "memory model" is the C++11 memory model. Maybe you meant the borrow checker and the distinction between shared and exclusive references? Yes, those make it much harder to accidentally screw up other parts of your address space, but it's downright trivial to do it on purpose – you just need an unsafe block and std::ptr::write.

There's nothing about Rust that could replace isolated address spaces. Rust is typically compiled to native machine instructions, there's no sandbox or virtual machine that will protect different modules from each other.

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

#170

Post by globular-toast »

adwn wrote: post #169
elihu wrote: post #153

Earlier quoted context omitted.

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

> Rust's memory model largely makes those isolated address spaces unnecessary, I think you're confusing several concepts. Rust's "memory model" is the C++11 memory model. Maybe you meant the borrow checker and the distinction between shared and exclusive references? Yes, those make it much harder to accidentally screw up other parts of your address space, but it's downright trivial to do it on purpose – you just need…

I think we have to assume that people aren't putting malicious code into the kernel, don't we?
Post reply on HN