If you can't join 'em...

Posted Sep 5, 2024 12:31 UTC (Thu) by johill (subscriber, #25196)
In reply to: If you can't join 'em... by taladar
Parent article: Rust-for-Linux developer Wedson Almeida Filho drops out

I will just say - this is how you lose supporters, by declaring concerns to be invalid and only the result of pre-conceived hostility.

If you can't join 'em...

Posted Sep 10, 2024 9:55 UTC (Tue) by taladar (subscriber, #68407) [Link] (7 responses)

On the other hand you lose supporters much more quickly by insisting that your personal niche (e.g. keeping a platform alive that hasn't been in production for 20 years as a hobby) use case should trump every other priority in the project. In fact this kind of attitude might very well break the entire project if supporters wander off to form their own project without barriers like that instead of joining your project.

In a world of finite amounts of total effort available every bit of effort put into a project needs justification and so does every choice among mutually incompatible goals. The ratio of work generated to people who care to put in the work for every single decision is a big factor here.

If you can't join 'em...

Posted Sep 10, 2024 14:58 UTC (Tue) by johill (subscriber, #25196) [Link] (6 responses)

I'll ... try to actually take this on good faith, I guess?

Your previous comment is implying that e.g. me saying I need to care about platforms that Linux supports today etc. is actually just being done in support of my pre-conceived notion that rust is bad and not going anywhere etc.

Do you actually think that helps rust's cause? Because if so I think this thread simply ends here, there's nothing I can say to that.

On the other hand, maybe you're just confused? I don't have a _choice_ to care about platforms. I'm not going to be in a position to say that from this day on WiFi simply doesn't work on any platform without rust. That would be a pretty major regression, don't you agree?

Doesn't even matter if I like to use rust or if I think it's a bad idea, but like I said, implying that I say that just because I don't even want rust ... I feel your attitude probably isn't representative, and that can only be a good thing.

If you can't join 'em...

Posted Sep 10, 2024 16:14 UTC (Tue) by mb (subscriber, #50428) [Link] (5 responses)

Well, what actually are the platforms that support wifi today and at the same time don't have Rust compiler support today? That data is what I am missing for a judgement whether it would be a big regression.

With wifi support I mean you must actually be able to put a wifi device in there and use it.

Then we have a base for judging whether we should care about those users or not.

If you can't join 'em...

Posted Sep 10, 2024 16:49 UTC (Tue) by johill (subscriber, #25196) [Link] (4 responses)

I'd think ARM (32-bit) and MIPS are still relevant in routers, and MIPS is just getting an initial rust support as we speak.

SH enables wifi in the defconfig too.

USB device support is probably pretty universal across architectures.

Anyway, I'm just pointing out that saying "you were always against rust, so you just pretend you care about architectures" is the wrong way to go about this.

If you can't join 'em...

Posted Sep 10, 2024 17:19 UTC (Tue) by mb (subscriber, #50428) [Link] (3 responses)

Arm32 has tier 2 support. It works pretty well (I use it).

Rust compilers work pretty damn well, even if they don't have the official tier 1 blessing.
I only hit a compiler bug once, so far. In a tier 3 architecture (esp32) a couple of years ago.

And it's not that all stable gcc versions support building the kernel.
The kernel history is *full* of gcc workarounds and banning some gcc versions from building the kernel.
That can easily be done with Rust as well. If there's a buggy version, just ban it. Or the other way around pin a known-good set of Rust compilers. (That's how it currently works, as far as I understand it). That has been done with gcc, too.

Based on that, I think arm32 should not be a blocker.

We need to apply the same basic rules for gcc, clang and Rust.

>SH enables wifi in the defconfig too.

Ok. Is that really a big thing? Should that block us? These are the questions I'd like to see.
And yes, the answer *can* be yes, if there are facts that show this.

>USB device support is probably pretty universal across architectures.

Yes. But IMO that doesn't mean we should support users who stick an USB host controller into an Alpha machine to put an USB wifi into it.

>saying "you were always against rust, so you just pretend you care about architectures"
>is the wrong way to go about this.

Yes, correct. This is wrong to say.

"you do" and "you just" sprinkled with "religion" and "you force me to..." is the biggest problem in this whole discussion. And it's also not limited to the kernel. I saw this exact same behavior in completely different contexts, too.
It's unprofessional.
We all need to calm down a bit and get back to talking about facts.

If you can't join 'em...

Posted Sep 10, 2024 18:01 UTC (Tue) by johill (subscriber, #25196) [Link] (2 responses)

> Arm32 has tier 2 support. It works pretty well (I use it).

The kernel doesn't support it, according to the rust documentation. Maybe that's outdated, or maybe you're saying that just about the compiler?

> Ok. Is that really a big thing? Should that block us? These are the questions I'd like to see.
> And yes, the answer *can* be yes, if there are facts that show this.

I have no idea. WiFi is pretty universal these days.

But even the rust people don't yet seem to advocate making rust a hard dependency for much if anything, so I think the point is moot. They also don't have a story for calling rust from C rather than the other way around, which would actually be the use case I'd first be interested in here to make some critical parsing code better.

If you can't join 'em...

Posted Sep 10, 2024 18:35 UTC (Tue) by mb (subscriber, #50428) [Link]

>or maybe you're saying that just about the compiler?

Yes, I was only talking about the compiler. Adding kernel support looks like a minor issue to me.
Of course it has to be done and as long as it hasn't been done it's a blocker of course.

>They also don't have a story for calling rust from C

The Rust code just has to provide an unsafe extern-C function to be called. That's it. There's nothing special about that. It's a Rust function that has normal C linkage.

>But even the rust people don't yet seem to advocate making rust a hard dependency for much if anything,

People need to understand why that is on a case by case basis.
I completely agree with you that it's not prime time for Rust-Wifi, yet. But that doesn't say anything about how much work is left to that goal. And *that* actually is the interesting question that can be used to make progress.

Calling Rust from C

Posted Sep 10, 2024 19:06 UTC (Tue) by farnz (subscriber, #17727) [Link]

Calling Rust from C is fairly well established outside the kernel, with cbindgen helping to reduce the amount of C-side boilerplate you have to keep in-sync with the Rust #[no_mangle] code and #[repr(C)] data structures.

I would hope that the Rust-for-Linux people would be willing and able to help you do a good job if you were trying to write in-kernel Rust that's called from C - adding in things like cbindgen to the build system to make your life as simple as possible.