Email or username:

Password:

Forgot your password?
Asahi Linya (朝日りにゃ〜)'s posts Post Back to profile
Top-level
Asahi Linya (朝日りにゃ〜)

Making the Rust bindings safe would have required duplicating much of the functionality of the C code just to track things to uphold the lifetime requirements. It made no sense. It would have been easier to just rewrite the whole thing in Rust (I might end up doing that).

To this day, bugs in the DRM scheduler have been the only causes of kernel panics triggered via my Apple GPU driver in production.

The design of that component is just bad. But because I come from the Rust world, the maintainer didn't want to listen to my suggestions.

If it takes a whole year to get a concept as simple as a trivial "device" wrapper upstreamed (not any device model functionality, literally just an object wrapping a struct device so we can pass it around) then how is Rust for Linux ever going to take off?

Rust works. I'm pretty sure I'm the only person ever to single handedly write a complex GPU kernel driver that has never had a memory safety kernel panic bug (itself) in production, running on thousands of users' systems for 1.5 years now.

Because I wrote it in Rust.

But I get the feeling that some Linux kernel maintainers just don't care about future code quality, or about stability or security any more. They just want to keep their C code and wish us Rust folks would go away. And that's really sad... and isn't helping make Linux better.

29 August at 13:06 | Open on vt.social
70 comments
Imikoy
bitzero
@lina At this point, I guess it’s a cultural clash that has little to do with Rust’s supposed pros and cons. I myself don’t like the language that much, but plainly ignoring it is probably extreme. And is not helping anyone.
29 August at 13:17 | Open on corteximplant.net
Sobex
romu

@lina Keep it up 😺, you can do it 😸

29 August at 13:19 | Open on techhub.social
Scherzog von Beast Oil

@lina There is a *fuckton* of pride at stake among C (and C++) developers.

"C(++) is a perfectly good language, just write your code correctly from the start and never make mistakes" is a statement I hear with almost frightening regularity. Of course that usually also correlates with said people being rather found dead than admitting they may have made bad design decisions in the past (or worse, mistakes while implementing said designs).

29 August at 13:37 | Open on mastodon.gamedev.place
crazyeddie

@scherzog @lina A lot of C++ developer actually hate the language and refuse to use its modern features, but I would be shocked to hear that said by one who does use them. C++ is an evolving language that's trying more and more to leverage compile time safety assertions. Rust is more or less just an extreme application of the same concept: it's better if the compiler can catch your errors.

Aren't the kernel developers hostile to anything not C or asm? Linus really hates us C++ devs...

29 August at 13:53 | Open on mastodon.social
rastilin

@crazyeddie @scherzog @lina

The worst part is that in benchmarks, Rust beats out C++ and is only very slightly slower than C (by 7%), but would probably be more secure and more reliable in practice.

It might also be faster than C in production since it can better optimize itself.

29 August at 14:08 | Open on aus.social
crazyeddie

@rastilin @scherzog @lina I can readily beat the crap out of a great amount of C code, performance wise, with C++ so I'm not sure what you're measuring there. Look at how a C vs. C++ developer might make a binary tree for example: C++ version is faster and safer. If you want to do build time processing in C you're also stuck with the preprocessor. Maybe the C++ code was crap, or maybe it's something C++ is really bad at...I dunno, but it sounds suspect.

29 August at 16:42 | Open on mastodon.social
mid_kid

@crazyeddie @rastilin @scherzog @lina Benchmarks like that are ran against theoretically perfect implementations of various algorithms, not whatever a developer would realistically write unless given infinite time and knowledge. Having readily available and well-optimized algorithm and other utility libraries is very helpful, like you say.

30 August at 9:38 | Open on fosstodon.org
rastilin

@mid_kid @crazyeddie @scherzog @lina

So the question is also, which language can self-optimize better? I think Rust would beat out C and C++ in these situations. Though I can't be sure.

30 August at 12:11 | Open on aus.social
crazyeddie

@rastilin @mid_kid @scherzog @lina Entirely possible. C++ uses its type system to help optimize, I'm sure Rust can.

I don't know Rust, but it at least has the potential to do things I don't see C++ ever being able to achieve, or at least a long time. Thread safety for example: way back I watched Meyers present his "red/green" stuff that tried...but it was ungainly and nothing came of it. We have other tools to help, but yeah...it's a thing.

30 August at 13:58 | Open on mastodon.social
Ludovic Archivist Lagouardette

@rastilin @crazyeddie @scherzog @lina

I do not know what benchmark you are using as comparison as generally C++ is faster than C due to the optimizations afforded by templates.

Modern C++ and Rust are quite on par with one another, both performance-wise and safety-wise. And if a C++ developer tells me they "hate modern C++" I lose all respect for them whatsoever.

I feel like the resistance pulled by the Linux Kernel maintainers stems from ignorance of what Rust does, just like it was the case for C++ long ago. They are trapped in a bubble where they practice between 1 and 3 languages between C, bash and Python and do not have the capacity to currently work with Rust, and feel shoehorned into reviewing code they do not understand well enough

@rastilin @crazyeddie @scherzog @lina

I do not know what benchmark you are using as comparison as generally C++ is faster than C due to the optimizations afforded by templates.

Modern C++ and Rust are quite on par with one another, both performance-wise and safety-wise. And if a C++ developer tells me they "hate modern C++" I lose all respect for them whatsoever.

29 August at 21:28 | Open on social.linux.pizza
rastilin

@Archivist @crazyeddie @scherzog @lina

I dug around for the article so I could reference it and I've linked it here. I'm referring to the second column of the first chart, which tracks runtime.

thenewstack.io/which-programmi

Their tests might be a bit simplistic, but even in more complex tests, Rust might be able to optimize more heavily in situations where C wouldn't be able to.

It's annoying to realize, that, for example, PHP is 27 times slower than C.

@Archivist @crazyeddie @scherzog @lina

I dug around for the article so I could reference it and I've linked it here. I'm referring to the second column of the first chart, which tracks runtime.

thenewstack.io/which-programmi

Their tests might be a bit simplistic, but even in more complex tests, Rust might be able to optimize more heavily in situations where C wouldn't be able to.

30 August at 3:32 | Open on aus.social
Ludovic Archivist Lagouardette

@rastilin oh yeah, I remember that one. The C++ code they used was pretty bad, they were writing C++ as if it were Java and taking a bunch of overhead. Expect that C++ is generally between Rust and C in performance (Rust advantage here being not following calling convention that C++ must abide too to just compile, C++ advantage being not taking 6 million years to compile the 24 million lines of the codebase)

30 August at 4:39 | Open on social.linux.pizza
Scherzog von Beast Oil

@crazyeddie @lina Idk, the person I hear it most from is very much a C++Next fanboy. The usual reactions to any complaints about the language are "ah but C++25/30/40 will address that" and that failing again "skill issue, shoulda used $feature".

My biggest problem with C++ is that nothing really pushed people towards the modern helper features so all the old style code remains mainstream.

29 August at 14:08 | Open on mastodon.gamedev.place
crazyeddie

@scherzog @lina Yep. The number of C++ developers who actually get to use modern features of the language is way smaller than the total number of C++ devs. Community members are one thing, but in the field it's all old shit and nobody wants to update for fear the whole house of cards will collapse if some intern flies off the handle using new features they don't understand...you know, because code reviews are in the process but it all just gets checked off.

That's how those discussions go

29 August at 16:52 | Open on mastodon.social
crazyeddie

@scherzog @lina But whoever said, "Just make it right the first time," had to be pure moron. Doesn't matter the language. An experienced developer has experienced too much failure to think remotely like that anymore. You only think you can write consistently elegant code and designs that always just work is if you've never tried to do it. In ANY language. I'd have a hard time working with a person that said that. I'd be always thinking how stupid they must be.

29 August at 17:03 | Open on mastodon.social
pinskia

@scherzog @crazyeddie @lina It should be noted that all languages suffer from it will be in the next version. Rust is no difference. Just Rust versioning is not as mainstream; you almost always required to use the newest version and never support 5-10 year old software. Plus Rust the langauge still does not a decent specifications; it is what ever rustc does. Yes there is a movement to fix that but not fast enough.

29 August at 19:02 | Open on hachyderm.io
Scherzog von Beast Oil

@pinskia @crazyeddie @lina The difference is that in Rust the compiler bugs you to actually adopt the latest best practices with varying degrees of insistence and helpfulness, while in C++ you can go for 20 years without ever even hearing about them.

And if you do hear about them chances are that at least one of the developers of the code base is an old curmudgeon who doesn't like the syntax for new features and so you are stuck with (a subset of) C++98.

29 August at 22:10 | Open on mastodon.gamedev.place
robinm

@pinskia @scherzog @crazyeddie @lina

> Plus Rust the langauge still does not a decent specifications

Could we please stop to use this argument where the arternatives don't have specs either. The language used in the kernel is /not/ ISO C, it's C with GNU dialect. It litteraly took years to make it possible to compile it with clang and it's not possible to compile it with MSVC. Having a spec does help C in the kernel. Rust not having a spec should therfore be a non issue.

29 August at 23:14 | Open on fosstodon.org
pinskia

@robinm @scherzog @crazyeddie @lina Actually GNU C has a specifications.
Now the whole not compiling with clang is because even though clang claims it implements GNU C; it never did. and most GNU C extensions are documented; it is just clang never got them right; inline-asm is an example where it never got it right and still is in the wrong. E.g. nested functions is not implemented in clang even though it is documented.

Also talking about specs; compare Rust to P4.

@robinm @scherzog @crazyeddie @lina Actually GNU C has a specifications.
Now the whole not compiling with clang is because even though clang claims it implements GNU C; it never did. and most GNU C extensions are documented; it is just clang never got them right; inline-asm is an example where it never got it right and still is in the wrong. E.g. nested functions is not implemented in clang even though it is documented.

29 August at 23:20 | Open on hachyderm.io
robinm

@pinskia @scherzog @crazyeddie @lina I may have been in the wrong, I didn't know GNU extension where specified. I still don't think that spec are needed, just good documentation.

29 August at 23:23 | Open on fosstodon.org
Neal Gompa (ニール・ゴンパ) :fedora:

@robinm @pinskia @scherzog @crazyeddie @lina For a programming language, a specification is actually really important. It resolves ambiguities and also defines where ambiguities are. People argue about undefined behavior problems because we *know* where those are. And that's incredibly valuable.

30 August at 7:04 | Open on fosstodon.org
robinm

@Conan_Kudo @pinskia @scherzog @crazyeddie @lina How is a spec more valuable than documentation?

And UB are unfortunately underspecified in Rust, C and C++. We don't have a complete list for any of those languages.

30 August at 7:22 | Open on fosstodon.org
Neal Gompa (ニール・ゴンパ) :fedora: replied to robinm

@robinm @pinskia @scherzog @crazyeddie @lina Well, a spec *is* documentation. But I imagine that's not what you meant, and you refer to usage documentation (e.g. documenting how to consume it rather than what it is).

But you need both for a good picture of the language you are using. Rust has great usage documentation but crap documentation about Rust *itself*. And that can be a problem when you hit weird edges that you need clarity to resolve.

30 August at 7:26 | Open on fosstodon.org
robinm replied to Neal Gompa (ニール・ゴンパ) :fedora:

@Conan_Kudo @pinskia @scherzog @crazyeddie @lina I'm surprised because I read a lot of C++ papers (I'd about 5% of them since many years) for fun, but I never needed to refer to them to resolve issue when using C++. However I do use cppreference.com a lot. And the only time I did not found what I needed in cppreference and had to open the corresponding paper (it was about deducing this), I just read the usage example, lot the implementation notes in legalized language.

30 August at 7:35 | Open on fosstodon.org
Neal Gompa (ニール・ゴンパ) :fedora: replied to robinm

@robinm @pinskia @scherzog @crazyeddie @lina At least for me, it's rare that I go back to the spec documentation, but when I have to, it's mostly to understand the intent of things and what the constraints they designed it for. But I know people that use that same information to come up with "tricks" to squeeze out everything from the language without breaking things.

(I'm also glad I don't live in that world where I need to think of that! 😂)

30 August at 7:39 | Open on fosstodon.org
robinm replied to Neal Gompa (ニール・ゴンパ) :fedora:

@Conan_Kudo @pinskia @scherzog @crazyeddie @lina In your case, aren't the Rust RFC enough, or does divergeance between when they where accepted and the real implementation too much?

And when you speak about squeezing out everything from the language feels like compiler work (which isn't an issue if there is a single blessed implementation) than application/library work, or do I miss something?

30 August at 12:22 | Open on fosstodon.org
Neal Gompa (ニール・ゴンパ) :fedora: replied to robinm

@robinm @pinskia @scherzog @crazyeddie @lina Sometimes the divergence is meaningful between RFC and implementation. And even with a single compiler implementation, squeezing everything out the language matters. Because if you don't know what is safe to squeeze, the assumption can be violated in an upcoming revision without any real warning. It's the equivalent of dealing with nightly/unstable rust features.

I'm also for having multiple compiler implementations, which is way harder with no spec.

30 August at 13:05 | Open on fosstodon.org
pinskia

@robinm @scherzog @crazyeddie @lina Let's compare Rust to P4. Yes P4 is a much smaller language but it has a specifications and even that specifications had holes in it which has been fixed when someone started implementing a secondary compiler for it. Rust still is behind in that matter. P4-16 had a spec from the begining while Rust didn't. P4-16 was a language designed over P4-14 to be a specifications driven language while Rust was done as an implementation driven language.

29 August at 23:23 | Open on hachyderm.io
argv minus one

@scherzog

And then we all pay dearly for their recklessness when some crime gang discovers the buffer overflow du jour.

@lina

29 August at 19:01 | Open on mstdn.party
tizilogic

@lina I just wish there were fewer people that go religious crazy about such things and more people trying to argue on well researched and as objective as possible facts..

saddest problem is that these things tend to spark some form of "war" where it is one group against the other.. can't we just get along?

29 August at 14:08 | Open on mastodon.gamedev.place
tizilogic

@lina tbc, not accusing you of "going religious crazy" about rust..

also DISCLAIMER: I love C simply because it just works everywhere and compiles fast as heck, even with all its downsides it comes with by design.
To me, Rust currently fulfills 0.9 out of those 2 criteria and once it is >1 I likely would dive in head first into it and probably forget I ever had any love for C in the first place

29 August at 14:11 | Open on mastodon.gamedev.place
Sandy Vujaković

@tizilogic @lina I wonder how C compares to C++ in those regards 🤔

29 August at 23:12 | Open on pleroma.envs.net
Ben Leggett

@lina

The longer you work in this stuff the more you realize a lot of people are just acting like children about code. That's all it is. It's not great skill or genius. It's just childish obsessiveness.

29 August at 14:11 | Open on sunny.garden
Sean

@dadregga @lina yeah my experience is that people tend to get defensive about their projects and suggesting that they might be able to improve on something or that you have a need they didn’t consider gets an immediate negative reaction, no matter what community the report comes from. This even happens between teams working at the same company.

29 August at 16:30 | Open on hachyderm.io
argv minus one

@complexmath

As someone who has changed favorite languages several times in his life, each time tending toward greater type/memory/concurrency safety, I find it difficult to fathom these people's attachment to C.

@dadregga @lina

29 August at 19:03 | Open on mstdn.party
Ben Leggett

@argv_minus_one

They're *really, really* good at C. Built their entire careers around it, most likely.

The idea that someone could come along and negate that does terrify them, and should! I can't blame them for that, it's a terribly human reaction.

29 August at 19:23 | Open on sunny.garden
argv minus one

@dadregga

Is it? I would think they'd find it relieving that they can now write code without worrying about all the things C makes you worry about.

Now, if programmers in general were obsolete, that would be another story. 😬 That's what “AI” is trying to do, but so far, it's failing miserably.

29 August at 21:01 | Open on mstdn.party
Gina Peter Banyard

@argv_minus_one @dadregga I don't think that's how they see it.
They see it like their whole career has been invalidated, even if that is not the case, as Rust did not exist at the beginning of their career.

This ego and pride also affects academia and PhD applications being rejected by a panel of expert where the subject of the PhD would "invalidate" all their prior research (and I am not talking about CompSci or Maths here)

29 August at 22:12 | Open on phpc.social
Ben Leggett

@Girgias

@argv_minus_one

Exactly. And it will happen to you! And me! The trick is being able to understand your own response, when it *does * happen to you, for what it is.

29 August at 22:16 | Open on sunny.garden
Gina Peter Banyard

@dadregga @argv_minus_one Honestly, at this point in time, my whole job is to invalidate prior decisions PHP has done, and I am dealing with those emotions constantly.
There even are some PHP RFCs that I voted in favour that not even 3 years later I wonder if it wasn't a mistake and something people after me will need to "clean-up".

We make bad decisions all the time, it doesn't mean that everything we have done was pointless or not sensible at the time.

@dadregga @argv_minus_one Honestly, at this point in time, my whole job is to invalidate prior decisions PHP has done, and I am dealing with those emotions constantly.
There even are some PHP RFCs that I voted in favour that not even 3 years later I wonder if it wasn't a mistake and something people after me will need to "clean-up".

29 August at 22:30 | Open on phpc.social
Sean

@argv_minus_one @dadregga @lina I dunno. It's comparatively easy to write a C compiler and toolchain, so the language is available literally everywhere. And it's very WYSIWYG, which is handy when you're writing low-level code. I think there's a strong argument for being good at C in various fields. But much less of an argument for having it be your favorite language. The simplicity of the language offloads the burden of complexity onto the programmer, which means maintenance issues and bugs.

29 August at 19:55 | Open on hachyderm.io
argv minus one

@complexmath

I would not call C WYSIWYG unless you are using a non-optimizing compiler. Optimizing compilers can and will generate machine code drastically different from your source code. I've seen a case where dozens of lines were reduced to a single instruction.

For that matter, x86 assembly itself is a rather misrepresentative abstraction of the hardware's actual behavior. It looks sequential, but the CPU executing it is anything but sequential. queue.acm.org/detail.cfm?id=32

@dadregga @lina

@complexmath

I would not call C WYSIWYG unless you are using a non-optimizing compiler. Optimizing compilers can and will generate machine code drastically different from your source code. I've seen a case where dozens of lines were reduced to a single instruction.

For that matter, x86 assembly itself is a rather misrepresentative abstraction of the hardware's actual behavior. It looks sequential, but the CPU executing it is anything but sequential. queue.acm.org/detail.cfm?id=32

29 August at 21:13 | Open on mstdn.party
Raul

@lina Even Linus himself recently pointed his own finger directly at memory management issues in Linux, and yet this perennial resistance to change persists:

"You'd think that all the basics would have been fixed long ago, but they're not. We're still dealing with basic issues such as memory management."

zdnet.com/article/linus-torval

29 August at 14:20 | Open on social.treehouse.systems
argv minus one

@raulinbonn

Rust doesn't have it all figured out yet, either. The standard library types like `Vec` will, by default, abort on memory allocation failure, which is obviously not acceptable in a kernel.

Many of them can report an error in that situation instead, but then you are holding a large-caliber footgun: you have to make sure to never ever call any of the methods that might abort. The compiler will *not* warn you if you, or a library you call, does so.

@lina

29 August at 19:05 | Open on mstdn.party
Asahi Linya (朝日りにゃ〜)

@argv_minus_one @raulinbonn This is solved in kernel code by disallowing those methods that abort. That was decided early on. The approach has changed a few times but fallible allocation was pretty much always banned.

29 August at 19:20 | Open on vt.social
argv minus one

@lina

How is this disallowing enforced?

@raulinbonn

29 August at 19:20 | Open on mstdn.party
Asahi Linya (朝日りにゃ〜)

@argv_minus_one @raulinbonn The Linux kernel uses no_std. Until recently there was an internal fork of the alloc crate with those fallible constructors outright gated off. Now things are switching to custom allocators where the Box types (there are several to allow for different allocators in the kernel) are outright always fallible with the standard constructors.

lore.kernel.org/lkml/202408160

29 August at 19:28 | Open on vt.social
Orca🌻 | 🏴🏳️‍⚧️

@lina@vt.social last time I heard there's even work in progress to proactively remove all Rust code from the kernel for religious-like reasons... These people should really just get the f out and handle the maintaining to someone else with a right state of mind.

29 August at 14:30 | Open on nya.one
Jessica's new Main

@lina@vt.social C developers not beating the "old as dirt gatekeepers" allegation

29 August at 14:49 | Open on kitsunes.club
Timo Zimmermann

@lina I have seen many disputes over the last two decades Linux kernel maintainers had.

Most didn’t appear like anyone wants to improve things or actually do something useful for users.

It came down to personal preference, ego, ideology and power trips.

Personally I don’t know how anyone can find the mental energy to deal with that, but I truly appreciate everyone who still tries to improve things!

29 August at 15:41 | Open on social.screamingatmyscreen.com
ludiofines

@lina the simplest solution is usually the best, 5$ shovel...

jokes aside, i see this around me as well and believe is more about "don't make me work since i am close to retire". i see this in people close to 60 taking care of providing for their family and rewriting something in Rust "just because" will not change anything in their routines.

keep it up and wait until they retire when you will be the second in command and take charge. It is the most painful, i know.

29 August at 17:36 | Open on cyberplace.social
Lizzie

@lina@vt.social this kind of stuff is currently my biggest issue with linux. We haven't seen many innovations in the kernel for a long time. The hardware is getting more complex and requires more effort into making sure the kernel can understand what it is and how to use it at least basic enough to get some drivers installed. But its always the drivers have to work with the kernel, and not the other way around, and that stops so much from working as well as it could. And these people refuse to even budge a centimeter on the idea that they might be wrong in that decision. And those kinds of people tend to ruin everything they hold any power in.

@lina@vt.social this kind of stuff is currently my biggest issue with linux. We haven't seen many innovations in the kernel for a long time. The hardware is getting more complex and requires more effort into making sure the kernel can understand what it is and how to use it at least basic enough to get some drivers installed. But its always the drivers have to work with the kernel, and not the other way around, and that stops so much from working as well as it could. And these people refuse to even...

29 August at 17:39 | Open on zoner.work
DELETED

@lina do you know if the video is available anywhere else? i can't sign in to watch it

29 August at 19:11 | Open on gotgoat.com
Psyhackological

@lina imagine having the biggest open source operating system in the world and get along with each other when comes to choices and preferences.

Shame that in the end many great programmers have their ego that high so they are toxic. This reminds me of Hyprland dev: blog.vaxry.net/articles/2024-o

29 August at 22:58 | Open on mastodon.social
mawei

@lina The problem is, you can not just rewrite the DRM scheduler and expect all the other drm drivers to just migrate to rust.

To the end users, they do not really care a little, as long as their Intel/AMD/Nvidia GPUs mostly work.

But if one day all those drivers suddenly won't be supported just because they are not written in Rust, then they care a lot.

30 August at 0:22 | Open on mastodon.social
mawei

@lina I have seen the same situation in fs realms too, some "not-so-polite" MM guys want to improve their work and pushing new interfaces to fses.

But the main objective of the maintainer for any fs, is to keep their fs working without regression. So migrating to newer interface is not the priority and will only happen gradually.

30 August at 0:26 | Open on mastodon.social
mawei

@lina To me, as long as the discussions are still kept constructive, (not some BS like "yeah, this feature is already implemented in XXX several years ago and it's all your fs' fault not to do it", or "XXXfs is definitely better than YYYYfs") some delay of merging is totally acceptable, and if one really needs to fix others' bugs, that's just bonus patches to me.

It may looks frustrating for now to fix both rust and C, but aren't more contribution better?

30 August at 0:30 | Open on mastodon.social
Asahi Linya (朝日りにゃ〜)

@mawei You're completely misunderstanding what I tried to do... I just tried to fix what arguably are bugs in drm_sched, which didn't change the API at all, they only made it reasonable to use by turning some usages from a crash to handled gracefully. And the maintainer rejected that. Because the only driver he cares about doesn't run into this issue, so he thinks it shouldn't be fixed.

30 August at 8:24 | Open on vt.social
mawei

@lina Then it looks weird, as normally fixing BUG_ON() or whatever to proper error handling should never be questioned.

30 August at 8:26 | Open on mastodon.social
Asahi Linya (朝日りにゃ〜)

@mawei It wasn't even BUG_ON, it would outright crash and oops... the maintainer said I was using the API wrong, but enforcing using it "right" by his definition without fixing this would require reimplementing half the logic in the scheduler outside of it just to duplicate its functionality enough to track and avoid the problem case. It's nuts. The problem could be easily fixed within the scheduler, it was just a non-intrusive change to one function to correctly handle a particular case.

30 August at 8:28 | Open on vt.social
mawei

@lina Well, that's worse than BUG_ON(). Unhandled error path I guess.

30 August at 8:29 | Open on mastodon.social
Asahi Linya (朝日りにゃ〜)

@mawei I'm not going to touch the existing DRM scheduler, I'm just going to write my own that is part of the driver. If Nova wants to use it we'll figure out how to make it common Rust code. C drivers can continue to use the broken C one that's already there, and fight the brokenness themselves.

The DRM scheduler is helper code, it's not a core part of the DRM subsystem. You can simply choose not to use it and roll your own. Half of DRM is like this.

(Nova is the new Nvidia driver, and yes, it's written in Rust, so Rust will be mandatory for open source upstream support of new Nvidia GPUs. That's already decided.)

@mawei I'm not going to touch the existing DRM scheduler, I'm just going to write my own that is part of the driver. If Nova wants to use it we'll figure out how to make it common Rust code. C drivers can continue to use the broken C one that's already there, and fight the brokenness themselves.

The DRM scheduler is helper code, it's not a core part of the DRM subsystem. You can simply choose not to use it and roll your own. Half of DRM is like this.

30 August at 8:19 | Open on vt.social
mawei

@lina Well, after some years I'm pretty sure some other guy would jump out and try to extract the helper into a "generic" framework, and some newer driver will need some unique feature, and again non-constructive discussion.

I'm already so tried of handling one MM guy pushing his "superior" infrastructure without acknowledge some missing features.

It's the usual software development shenanigans, just older guys are much harder to handle.

30 August at 8:33 | Open on mastodon.social
Go Up