5 ms·

My take is this: Hellwig is unhappy because he doesn't want Linux to become a multi-language project, at least if we take his words at face value (he did explic

by nialv7 2y ago

My take is this: Hellwig is unhappy because he doesn't want Linux to become a multi-language project, at least if we take his words at face value (he did explicitly say he doesn't dislike rust, quote: ".. this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade"). This might have some technical merits, but that ship has already sailed when Linus decided to merge R4L into the kernel. If Hellwig wants to reverse that decision, he'll have to bring it to Linus, instead he's trying to block R4L patches and waste everyone's time and energy.

oguz-ismail 2y ago
My daily soap opera fix
raverbashing 2y ago
Yeah pretty much this And I think Linus should be very clear that rust is there to stay
- flohofwoe 2y ago
  That still doesn't mean that 'Rust idiomatics' have to creep into every Linux subsystem which the Rust code needs to talk to. It just feels like a poor technical design to not keep both sides entirely separated.
  - timeon 2y ago
    > It just feels like a poor technical design to not keep both sides entirely separated. Maybe you should read the mail thread if the article was not clear enough. The PR was inside Rust folder.
  - simonask 2y ago
    As I understand it, the proposed patches do not "creep" into any other subsystem, but act as another user of the existing APIs, just like any driver using the C API.
esjeon 2y ago
AFAIK, the merge was for the sake of change, not like he fully agreed with the adoption of Rust nor prioritization of Rust. The point is to have actual discussions, rather than pushing things with 10-feet poles just for being new and different. Anything that make sense will become the outcome of those discussions.
flohofwoe 2y ago
I wonder why that C file which maps a more abstract Rust-friendly C-API on top of the existing API can't live inside the Rust directory and build structure. If I would be one of the Rust maintainers, I would try to be as non-intrusive to the established project structure as possible, ideally completely invisible. It's also cleaner to keep all the Rust-related changes on the 'Rust side' of the project, even if they happen to be written in C (I'm also still wondering why Rust-for-Linux cannot live completely downstream in a temporary fork). I also can fully understand that a C programmer doesn't want to deal with such a 'Rust idiomatic' C API.
- ekimekim 2y ago
  > I wonder why that C file which maps a more abstract Rust-friendly C-API on top of the existing API can't live inside the Rust directory and build structure This is more or less what the RfL folks are asking for - they have a Rust API to be used by other Rust code, which uses the existing C API, and are promising to maintain that API themselves. It lives in the Rust "directory". The C maintainer is rejecting this, seemingly because his goal isn't to find a compromise that works but to completely block the project.
- dralley 2y ago
  >I wonder why that C file which maps a more abstract Rust-friendly C-API on top of the existing API can't live inside the Rust directory and build structure. That's what this patch does. It's what the patch _always_ did. Christoph seems not to have actually looked at the patch before rejecting it. When it was pointed out to him that his initial complaints were in fact unfounded, he didn't say "oh well, I guess it's OK then", he came up with more unfounded reasons to reject it. And when those points were addressed, he basically said "nah, I don't want to". I should note that he does not actually have any authority to reject the patches, since they're not in his subsystem. They are bindings to the DMA subsystem, he was CC'd as an advisory, but he has no more right to reject the patches than he would to reject a GPU driver that used DMA. This is a waste of everyone's time.
  - abacate 2y ago
    > Christoph seems not to have actually looked at the patch before rejecting it. I had the same impression as well, in particular due to his wording: > "No rust code in kernel/dma, please" When, in fact, the code is in "rust/kernel/dma" not "kernel/dma". It seems like he missed this and then doubled down on his stance when questioned.
pjmlp 2y ago
Additionally regardless of what upstream decides to do, Microsoft and Google are pretty much down on having Rust on their Linux forks, e.g. Sphere OS, Azure Linux, Android, ChromeOS.
arp242 2y ago
> that ship has already sailed when Linus decided to merge R4L into the kernel Of course not. Merging the basic infra for Rust didn't come with "it can be used in every single part of the kernel, regardless of what the people maintaining that think"-kind of guarantee. One way to use Rust is to only use it in drivers for example, and it seems Hellwig is not against that: "do that in your driver so that you have to do it".
- UtherII 2y ago
  That's exactly the point. The patch in question is not to be used in any part of the kernel. It is a wrapper around the C API. It has no impact on current code and it will only be used by Rust drivers using DMA, the people of Rust for Linux were clear about it. Duplicating this wrapper in every driver would just make painful the usage of DMA for Rust drivers for not benefit.
  - arp242 2y ago
    And Hellwig feels that's better done by "keep[ing] the wrappers in your code instead of making life painful for others". I can see where he's coming from. I can also see why doing that is painful. I don't really know what the best possible solution is. I do know that "Linus decided on Rust4Linux, therefore, this must be merged" is not a good argument. "Linus decided «moduke» is merged, therefore, accept my patches that are useful to «module» on «some other subsystem»". That doesn't really work, obviously.

by nialv7 2y ago

oguz-ismail 2y ago

My daily soap opera fix

raverbashing 2y ago

Yeah pretty much this And I think Linus should be very clear that rust is there to stay

flohofwoe 2y ago
That still doesn't mean that 'Rust idiomatics' have to creep into every Linux subsystem which the Rust code needs to talk to. It just feels like a poor technical design to not keep both sides entirely separated.
- timeon 2y ago
  > It just feels like a poor technical design to not keep both sides entirely separated. Maybe you should read the mail thread if the article was not clear enough. The PR was inside Rust folder.
- simonask 2y ago
  As I understand it, the proposed patches do not "creep" into any other subsystem, but act as another user of the existing APIs, just like any driver using the C API.

esjeon 2y ago

AFAIK, the merge was for the sake of change, not like he fully agreed with the adoption of Rust nor prioritization of Rust. The point is to have actual discussions, rather than pushing things with 10-feet poles just for being new and different. Anything that make sense will become the outcome of those discussions.

flohofwoe 2y ago

I wonder why that C file which maps a more abstract Rust-friendly C-API on top of the existing API can't live inside the Rust directory and build structure. If I would be one of the Rust maintainers, I would try to be as non-intrusive to the established project structure as possible, ideally completely invisible. It's also cleaner to keep all the Rust-related changes on the 'Rust side' of the project, even if they happen to be written in C (I'm also still wondering why Rust-for-Linux cannot live completely downstream in a temporary fork). I also can fully understand that a C programmer doesn't want to deal with such a 'Rust idiomatic' C API.

ekimekim 2y ago
> I wonder why that C file which maps a more abstract Rust-friendly C-API on top of the existing API can't live inside the Rust directory and build structure This is more or less what the RfL folks are asking for - they have a Rust API to be used by other Rust code, which uses the existing C API, and are promising to maintain that API themselves. It lives in the Rust "directory". The C maintainer is rejecting this, seemingly because his goal isn't to find a compromise that works but to completely block the project.
dralley 2y ago
>I wonder why that C file which maps a more abstract Rust-friendly C-API on top of the existing API can't live inside the Rust directory and build structure. That's what this patch does. It's what the patch _always_ did. Christoph seems not to have actually looked at the patch before rejecting it. When it was pointed out to him that his initial complaints were in fact unfounded, he didn't say "oh well, I guess it's OK then", he came up with more unfounded reasons to reject it. And when those points were addressed, he basically said "nah, I don't want to". I should note that he does not actually have any authority to reject the patches, since they're not in his subsystem. They are bindings to the DMA subsystem, he was CC'd as an advisory, but he has no more right to reject the patches than he would to reject a GPU driver that used DMA. This is a waste of everyone's time.
- abacate 2y ago
  > Christoph seems not to have actually looked at the patch before rejecting it. I had the same impression as well, in particular due to his wording: > "No rust code in kernel/dma, please" When, in fact, the code is in "rust/kernel/dma" not "kernel/dma". It seems like he missed this and then doubled down on his stance when questioned.

pjmlp 2y ago

Additionally regardless of what upstream decides to do, Microsoft and Google are pretty much down on having Rust on their Linux forks, e.g. Sphere OS, Azure Linux, Android, ChromeOS.

arp242 2y ago

> that ship has already sailed when Linus decided to merge R4L into the kernel Of course not. Merging the basic infra for Rust didn't come with "it can be used in every single part of the kernel, regardless of what the people maintaining that think"-kind of guarantee. One way to use Rust is to only use it in drivers for example, and it seems Hellwig is not against that: "do that in your driver so that you have to do it".

UtherII 2y ago
That's exactly the point. The patch in question is not to be used in any part of the kernel. It is a wrapper around the C API. It has no impact on current code and it will only be used by Rust drivers using DMA, the people of Rust for Linux were clear about it. Duplicating this wrapper in every driver would just make painful the usage of DMA for Rust drivers for not benefit.
- arp242 2y ago
  And Hellwig feels that's better done by "keep[ing] the wrappers in your code instead of making life painful for others". I can see where he's coming from. I can also see why doing that is painful. I don't really know what the best possible solution is. I do know that "Linus decided on Rust4Linux, therefore, this must be merged" is not a good argument. "Linus decided «moduke» is merged, therefore, accept my patches that are useful to «module» on «some other subsystem»". That doesn't really work, obviously.