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

Rust in enterprise kernels

lwn.net

Post reply on HN
Print view View original

1–10 of 14 posts

Re: Rust in enterprise kernels

#2

Post by alilleybrinker »

Greg KH's comment about not letting yourself be limited today by the needs of commercial users of old kernels is a good one [1]. That would be a tail wagging the dog situation, where newer APIs can't improve beyond the support that's available in old kernels. If that were the constraint, then improvements which rely on available toolchains would have to wait years for those toolchains to read wide enough distribution to users with slow adoption schedules for new kernels before you could even think of building on those toolchains.

[1]: https://lwn.net/ml/all/2024092614-fossil-bagful-1d59@gregkh/

Re: Rust in enterprise kernels

#3

Post by MBCook »

alilleybrinker wrote: post #2

Greg KH's comment about not letting yourself be limited today by the needs of commercial users of old kernels is a good one [1]. That would be a tail wagging the dog situation, where newer APIs can't improve beyond the support that's available in old kernels. If that were the constraint, then improvements which rely on available toolchains would have to wait years for those toolchains to read wide enough distribution…

I agree. If they care so much about the vGPU functionality there is already a solution: upgrade.

If they refuse but care enough, then back port all the necessary Rust stuff to your Franken-kernel too. You even get the advantage that you know the Rust side is checked for correctness by the compiler in a way C wouldn’t be.

“We can’t do X now because Y wasn’t in the kernel 7 years ago” is a very odd argument.

Re: Rust in enterprise kernels

#5

Post by alilleybrinker »

MBCook wrote: post #3
alilleybrinker wrote: post #2

Greg KH's comment about not letting yourself be limited today by the needs of commercial users of old kernels is a good one [1]. That would be a tail wagging the dog situation, where newer APIs can't improve beyond the support that's available in old kernels. If that were the constraint, then improvements which rely on available toolchains would have to wait years for those toolchains to read wide enough distribution…

I agree. If they care so much about the vGPU functionality there is already a solution: upgrade. If they refuse but care enough, then back port all the necessary Rust stuff to your Franken-kernel too. You even get the advantage that you know the Rust side is checked for correctness by the compiler in a way C wouldn’t be. “We can’t do X now because Y wasn’t in the kernel 7 years ago” is a very odd argument.

Right. A huge part of the value proposition of enterprise kernels is the stability, which you pay a cost for in the form of backporting and maintenance. That’s the thing that makes it valuable as a product!

It really can’t be the policy of the upstream to restrain enhancements because they might make backports harder. Companies get paid, and paid well, to do those backports! Let them be responsible for that burden.

Re: Rust in enterprise kernels

#6

Post by josefx »

MBCook wrote: post #3
alilleybrinker wrote: post #2

Greg KH's comment about not letting yourself be limited today by the needs of commercial users of old kernels is a good one [1]. That would be a tail wagging the dog situation, where newer APIs can't improve beyond the support that's available in old kernels. If that were the constraint, then improvements which rely on available toolchains would have to wait years for those toolchains to read wide enough distribution…

I agree. If they care so much about the vGPU functionality there is already a solution: upgrade. If they refuse but care enough, then back port all the necessary Rust stuff to your Franken-kernel too. You even get the advantage that you know the Rust side is checked for correctness by the compiler in a way C wouldn’t be. “We can’t do X now because Y wasn’t in the kernel 7 years ago” is a very odd argument.

> there is already a solution: upgrade.

To what? The article outright mentions that Rust support is still experimental at best, nor is Nova anywhere near ready to get merged into the mainline kernel.

Re: Rust in enterprise kernels

#8

Post by throwup238 »

> There is an increasing market for cloud-based systems with GPU access so that we can all enjoy the benefits of large language models appearing uninvited in every aspect of our lives.

I came for the Rust kernel drama, I stayed for the sick LLM burns.

I love LWN. Like with HN the comments are far more interesting than the article. I'm a huge Rust fan that's been using it since 1.0 and it's adoption by the linux kernel is one of the most interesting social phenomena I've seen. The tug of war between stability/backporting and moving forward with Rust in the comments is fascinating.

Re: Rust in enterprise kernels

#9

Post by aragilar »

MBCook wrote: post #3
alilleybrinker wrote: post #2

Greg KH's comment about not letting yourself be limited today by the needs of commercial users of old kernels is a good one [1]. That would be a tail wagging the dog situation, where newer APIs can't improve beyond the support that's available in old kernels. If that were the constraint, then improvements which rely on available toolchains would have to wait years for those toolchains to read wide enough distribution…

I agree. If they care so much about the vGPU functionality there is already a solution: upgrade. If they refuse but care enough, then back port all the necessary Rust stuff to your Franken-kernel too. You even get the advantage that you know the Rust side is checked for correctness by the compiler in a way C wouldn’t be. “We can’t do X now because Y wasn’t in the kernel 7 years ago” is a very odd argument.

I believe they're creating the vGPU functionality, which means they're working with what exists (at the current time). nouveau is in the kernel, and is also backportable and used existing kernel tooling (including the compiler), while nova is neither.
Post reply on HN