Readit News logoReadit News
ceteia commented on The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware   lwn.net/Articles/1055590/... · Posted by u/todsacerdoti
ladyanita22 · a day ago
I think this is true. But that'd be nonetheless up to the subsystem maintainers.
ceteia · a day ago
That means that, even if a C developer used or added C bindings to DRM when wanting to write a new driver, they would be forced to write their new driver in Rust regardless. That seems to run counter to the promises made by Linus.
ceteia commented on The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware   lwn.net/Articles/1055590/... · Posted by u/todsacerdoti
wtallis · a day ago
Whether that's true or false depends on what your hypothetical developer wants to do in the future. When an all-new driver is written in Rust, then working on that driver will require knowing Rust. But nobody's talking about trying to re-write all the existing drivers in Rust, so there will still be plenty of C code to work on even in the DRM subsystem.
ceteia · a day ago
> When an all-new driver is written in Rust, then working on that driver will require knowing Rust.

But that is not what the claim is about, it is about any new driver, not a specific one.

ceteia commented on The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware   lwn.net/Articles/1055590/... · Posted by u/todsacerdoti
monocasa · a day ago
You're confusing the audience here. That's directed at subsystem maintainers, not just 'anyone who wants to submit a patch'. If a subsystem doesn't want to deal with Rust code, they won't be forced to. But there's no restriction on the inverse.
ceteia · a day ago
I don't believe that I am. Especially given the other arguments and claims in the email.
ceteia commented on The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware   lwn.net/Articles/1055590/... · Posted by u/todsacerdoti
cwillu · a day ago
Nothing is happening “suddenly”, and it remains true that “people who want to work purely on the C side can very much continue to do so”.
ceteia · a day ago
But, is this true or false?

> If any C developer developed drivers in C previously for the DRM subsystem, they might in the future be forced to learn Rust.

ceteia commented on The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware   lwn.net/Articles/1055590/... · Posted by u/todsacerdoti
monocasa · a day ago
Dave Airlie is saying that the subsystem maintainers are themselves choosing to move to Rust.
ceteia · a day ago
But what about this statement that Linus wrote:

> That's been made clear pretty much from the very beginning, that nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so.

If any C developer developed drivers in C previously for the DRM subsystem, they might in the future be forced to learn Rust.

ceteia commented on The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware   lwn.net/Articles/1055590/... · Posted by u/todsacerdoti
davikr · 2 days ago
> Dave Airlie just announced in the Maintainers Summit that the DRM subsystem is only ""about a year away"" from disallowing new drivers written in C and requiring the use of Rust.

wow

ceteia · a day ago
Weren't the old Linux kernel developers promised the opposite by Linus Torvalds? That they would be able to continue writing in C?

https://lkml.org/lkml/2025/2/20/2066

> The document claims no subsystem is forced to take Rust

ceteia commented on D Programming Language   dlang.org/... · Posted by u/arcadia_leak
atilaneves · 2 days ago
No, you can just write D. It'll have the same performance as C, if you write C-like code. It might have better performance than C if you use templates (just like in C++).
ceteia · 2 days ago
But why then did arcadia_leak imply as far as I understood him that C is needed for performance in D?

But D is not included in the benchmarks game at debian.net, which isn't fair to D either as far as I can tell.

ceteia commented on D Programming Language   dlang.org/... · Posted by u/arcadia_leak
gavinray · 2 days ago
dplug is a framework for building audio plugins that do realtime signal processing, and its creator has produced several well-sold plugins under the "Auburn Sounds" studio name.

https://github.com/AuburnSounds/Dplug

ceteia · 2 days ago
Interesting. That might fit the bill, though I am not completely sure.

Do you happen to know why D has not been accepted into the benchmarks games at debian.net? I heard that D developers contributed D code, but that D was never accepted.

ceteia commented on D Programming Language   dlang.org/... · Posted by u/arcadia_leak
pron · 2 days ago
> If you really want to call that a GC you should at least make a huge distinction that it works at compile time: the generated code will have drop calls inserted without any overhead at runtime. But no one calls that a GC.

Except for the memory management literature, because it's interested in the actual tradeoffs of memory management. A compiler inferring lifetimes, either automatically for some objects or for most objects based on language annotations, has been part of GC research for decades now.

The distinction of working at compile time or runtime is far from huge. Working at compile time reduces the work associated with modifying the counters in a refcounting GC in many situations, but the bigger differences are between optimising for footprint or for throughput. When you mathematically model the amount of CPU spent on memory management and the heap size as functions of the allocation rate and live set size (residency), the big differences are not whether calling `free` is determined statically or not.

So you can call that GC (as is done in academic memory management research) or not (as is done in colloquial use), but that's not where the main distinction is. A refcounting algorithm, like that found in Rust's (and C++'s) runtime is such a classic GC that not calling it a GC is just confusing.

ceteia · 2 days ago
> A refcounting algorithm, like that found in Rust's (and C++'s) runtime is such a classic GC that not calling it a GC is just confusing.

But is it not easy to opt out of in C, C++, Zig and Rust, by simply not using the types that use reference counting?

And how does your performance analysis consider techniques like arenas and allocating at startup only?

ceteia commented on D Programming Language   dlang.org/... · Posted by u/arcadia_leak
nicwilson · 2 days ago
Sociomantic (bought by Dunhumby, now defunct IIRC) had a realtime advertisement business built in D.

Weka have a realtime distributed filesystem written in D, used for ML/HPC workloads.

ceteia · 2 days ago
> Weka have a realtime distributed filesystem written in D, used for ML/HPC workloads.

This https://github.com/weka ?

Most of the D repositories appear to have very little activity. The Go repositories seem to have more activity.

u/ceteia

KarmaCake day1February 5, 2026View Original