Ubuntu Blog Talks Up Rust Schedulers, Potential For Micro-Kernel Design Future

[phoronix]

Phoronix: Ubuntu Blog Talks Up Rust Schedulers, Potential For Micro-Kernel Design Future

Ubuntu/Canonical has for a while now promoted the prospects of Rust programming within the Linux kernel and one of their kernel engineers, Andrea Righi, wrote a Rust-written Linux scheduler with promising results that leverages eBPF for dynamically loading it at run-time. While Ubuntu isn't yet committing to using it as part of their distribution, appearing on the Ubuntu blog today was more praise for the work and even talking about the potential for a "micro-kernel design" in the future via leveraging Rust and eBPF...

https://www.phoronix.com/news/Ubuntu-Rust-Scheduler-Micro

[spicfoo]

I see the title of Rust takes control and I am worried this is going to shake the bubble of some people. Let the delusions commence.

[stormcrow]

I see the title of Rust takes control and I am worried this is going to shake the bubble of some people. Let the delusions commence.

More annoyed by the full page cookie banner on the blog till I created a uBlock rule for it. Everyone dislikes cookie banners, but this one is just stupidly annoying.

I really get annoyed by people trying to make Linux into something that it's not, however. If they want micro-kernel fail over robustness, then use a real micro-kernel. Stop trying to shoehorn a monolithic kernel into a micro-kernel. Linux is a monolithic architecture, no matter what you do to it it will never have the reliability of a well implemented micro architecture. Trying to make it so will just make it less reliable because trying to do so adds complexity rather than reducing it. Complexity is the enemy of reliability.

This is another one of those cases of "because we can" but never stopped to think "but should we?" This smacks of trying to fulfill compliance check marks with the letter of the rules, but circumventing the spirit of those rules. Sticking a screwdriver into a bus circuit breaker comes to mind. It's fine till you cause a fire because someone overloaded the circuit, which would have blown a proper bus fuse before burning down the building.

[Jumbotron]

I was thinking the same with the added Linux snowflake inducing mention of “microkernels”. Add the cherry on top that this is coming from Ubuntu and tears are about to fall.

[skeevy420]

More annoyed by the full page cookie banner on the blog till I created a uBlock rule for it. Everyone dislikes cookie banners, but this one is just stupidly annoying.

I really get annoyed by people trying to make Linux into something that it's not, however. If they want micro-kernel fail over robustness, then use a real micro-kernel. Stop trying to shoehorn a monolithic kernel into a micro-kernel. Linux is a monolithic architecture, no matter what you do to it it will never have the reliability of a well implemented micro architecture. Trying to make it so will just make it less reliable because trying to do so adds complexity rather than reducing it. Complexity is the enemy of reliability.

This is another one of those cases of "because we can" but never stopped to think "but should we?" This smacks of trying to fulfill compliance check marks with the letter of the rules, but circumventing the spirit of those rules. Sticking a screwdriver into a bus circuit breaker comes to mind. It's fine till you cause a fire because someone overloaded the circuit, which would have blown a proper bus fuse before burning down the building.

We are heading towards a micro-kernel design that has the potential to pave the way to certification on Linux: in the aforementioned scenario, if the user-space scheduler crashes, tasks will seamlessly transition to the default in-kernel scheduler, ensuring continuous system usability without any downtime.

This suggests that a similar approach could be used in other subsystems as well, allowing the Linux kernel to provide fully redundant and crash-safe systems.

Even I can see that what they propose won't solve anything since it seems to operate on the premise that the kernel is infallible. Yeah, the user-space scheduler crashes and the kernel can fallback to the kernel scheduler long enough to restart the user-space scheduler, but if the kernel scheduler crashes it can't restart itself so the system can still go down. It's redundancy, but only to a point.

What are they gonna do, rewrite ever single kernel driver in Rust for eBPF? It sounds like they smoke more and better weed than me. It's like: Yo dawg. I heard you liked drivers so I wrote drivers for all your drivers.

I'm not trying to talk that much shit because the scheduler itself seems great. But that micro kernel stuff, really now?

[stormcrow]

Even I can see that what they propose won't solve anything since it seems to operate on the premise that the kernel is infallible. Yeah, the user-space scheduler crashes and the kernel can fallback to the kernel scheduler long enough to restart the user-space scheduler, but if the kernel scheduler crashes it can't restart itself so the system can still go down. It's redundancy, but only to a point.

What are they gonna do, rewrite ever single kernel driver in Rust for eBPF? It sounds like they smoke more and better weed than me. It's like: Yo dawg. I heard you liked drivers so I wrote drivers for all your drivers.

I'm not trying to talk that much shit because the scheduler itself seems great. But that micro kernel stuff, really now?

Yeah my comment isn't directed towards the quality of the code work itself, merely the mischaracterization that this is similar to micro-kernel style features. While redundancy might be part of a micro-kernel overall system design, it doesn't require it.

[ilgazcl]

Congratulations Mr. Nadella ;-)

[tildearrow]

I see the title of Rust takes control and I am worried this is going to shake the bubble of some people. Let the delusions commence.

You think that's it, but on top of that add "microkernel Linux" and it gets even worse.
Wasn't this debated long ago?

[spicfoo]

You think that's it, but on top of that add "microkernel Linux" and it gets even worse.
Wasn't this debated long ago?

That part is just Canonical being Canonical. A bit of tech with a lot of marketing spiel which often rubs people the wrong way.

[timofonic]

Congratulations Mr. Nadella ;-)

I agree!

Also, I agree with others that said this is typical Canonical timewaste research. With more words and a lot more detailed, but that is.

Shoehorn microkernel stuff using eBPF and userspace? What can go wrong? People are cautious of eBPF stuff, despite it's overly very hyped. Maybe it can be useful for experimenting algorithms and such.

What does Microsoft says about this? It will be exact to Canonical one, I'm sure