Hacker News Reader

Comment by flohofwoe | Hacker News Reader

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.

View on HN

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

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

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

Reply on news.ycombinator.com