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

The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware

lwn.net

Post reply on HN
Print view View original

41–50 of 54 posts

Re: The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware

#41

Post by ceteia »

monocasa wrote: post #37
ceteia wrote: post #29

Earlier quoted context omitted.

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.

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.

I don't believe that I am. Especially given the other arguments and claims in the email.

Re: The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware

#42

Post by ceteia »

wtallis wrote: post #38
ceteia wrote: post #35

Earlier quoted context omitted.

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.

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.

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

Re: The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware

#43

Post by ceteia »

ladyanita22 wrote: post #39
ceteia wrote: post #35

Earlier quoted context omitted.

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.

I think this is true. But that'd be nonetheless up to the subsystem maintainers.

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.

Re: The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware

#44

Post by anthk »

jeroenhd wrote: post #8
davikr wrote: post #3

> 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

When the C absolutist maintainers fought for control over the ability to keep Rust out of their ballpark, I didn't expect the reverse to happen. Still, I think it makes a lot of sense. Completely new GPU drivers are quite rare and the macOS drivers from Asahi are a showcase proving that Rust and GPU drivers work together well. If there's any subcomponent switching to Rust-first for new contributions, it makes sense f…

The Rust crustaceans should apply their knowledge to Redox OS and top sending Rust crapware (which it might be fine for security, but Cargo it's a nightmware to maintain) and stop messing with GNU/Linux and, by proxy, the rest of the BSD's.

As tons of distros adopted LibreSSL, it might happen the same with KMS/DRM+MESA as it happened with Xenocara for X.org under OpenBSD and the special X server under NetBSD for legacy machines with really weird adapters leaving out the modular X.org -mainstream- to ports. They might call it VEGA (for MESA) and Iridium (for Gallium middleware).

Re: The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware

#45

Post by anthk »

ladyanita22 wrote: post #40
fowl2 wrote: post #36

Earlier quoted context omitted.

Windows already does, so you’re talking about the BSDs or Darwin?

BSDs and other Open Source OSes that rely on Linux drivers. Windows probably has not many (or any) drivers ported from Linux.

Please, stop pluralizing "BSD's", every BSD it's different and OpenBSD only reuses Linux drivers for KMS/DRM; FreeBSD has special layers and tons of drivers ported and NetBSD it's closer to philosophy in design.

Re: The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware

#46

Post by neobrain »

anthk wrote: post #44
jeroenhd wrote: post #8

Earlier quoted context omitted.

When the C absolutist maintainers fought for control over the ability to keep Rust out of their ballpark, I didn't expect the reverse to happen. Still, I think it makes a lot of sense. Completely new GPU drivers are quite rare and the macOS drivers from Asahi are a showcase proving that Rust and GPU drivers work together well. If there's any subcomponent switching to Rust-first for new contributions, it makes sense f…

The Rust crustaceans should apply their knowledge to Redox OS and top sending Rust crapware (which it might be fine for security, but Cargo it's a nightmware to maintain) and stop messing with GNU/Linux and, by proxy, the rest of the BSD's. As tons of distros adopted LibreSSL, it might happen the same with KMS/DRM+MESA as it happened with Xenocara for X.org under OpenBSD and the special X server under NetBSD for lega…

> Cargo it's a nightmware to maintain

To my knowledge, the Linux kernel doesn't use Cargo to build Rust code.

Re: The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware

#47

Post by monocasa »

ceteia wrote: post #41
monocasa wrote: post #37

Earlier quoted context omitted.

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.

I don't believe that I am. Especially given the other arguments and claims in the email.

I'm not seeing any claims in the email which counter my interpretation.

Re: The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware

#48

Post by stevekemp »

tialaramex wrote: post #9

> One simply cannot deploy a driver that [...] crashes and takes the user's work with it. Somebody needs to tell whoever wrote the drivers in the PC where I'm writing this.

I'm sure the volunteers behind those drivers will accept your bug reports.

Don't forget to be as detailed a possible.

Re: The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware

#49

Post by ladyanita22 »

anthk wrote: post #45
ladyanita22 wrote: post #40

Earlier quoted context omitted.

BSDs and other Open Source OSes that rely on Linux drivers. Windows probably has not many (or any) drivers ported from Linux.

Please, stop pluralizing "BSD's", every BSD it's different and OpenBSD only reuses Linux drivers for KMS/DRM; FreeBSD has special layers and tons of drivers ported and NetBSD it's closer to philosophy in design.

I will pluralize as all of them port some drivers from Linux

Re: The Future for Tyr, a Rust GPU Driver for Arm Mali Hardware

#50

Post by anthk »

ladyanita22 wrote: post #49
anthk wrote: post #45

Earlier quoted context omitted.

Please, stop pluralizing "BSD's", every BSD it's different and OpenBSD only reuses Linux drivers for KMS/DRM; FreeBSD has special layers and tons of drivers ported and NetBSD it's closer to philosophy in design.

I will pluralize as all of them port some drivers from Linux

So GNU/Linux now it's in the same group as FreeBSD as it has ZFS? Because neither NetBSD nor OpenBSD have it.

OpenBSD doesn't 'rely' on Linux drivers, thanks. Just a shim against KMS/DRM, everything else it's either homegroup or sometimes adapted (back and forth) from NetBSD but OFC patched for correctness and security. There's no ALSA. Pulse it's totally optional. There's no wpa_supplicant except for Eduroam or simlar niche crap under OpenBSD.

OpenBSD has OSS and sndiod. There's Xenocara, an X11 fork. Again, not Linux, X11, MESA and Gallium are damn generic. Show me the rest of ported Linux drivers into OpenBSD, please.

Are you sure OpenBSD is that dependant GNU/Linux?

Post reply on HN