DMA 구현을 수정 한 것도 아니고, DMA API 를 직접 손 댄 것도 아니고, Rust 에서 DMA API 에 접근할 수 있게 FFI 바인딩을 작성한 PR 로 보입니다.
그런 PR 에 "No rust code in kernel/dma, please." 라는 단답으로 거절 한 거고, https://lwn.net/ml/all/20250108135951.GA18074@lst.de/
그럼 어떻게 하면 좋겠냐 물으니 "Keep the wrappers in your code instead of making life painful for others." 라고 합니다. https://lwn.net/ml/all/20250108151858.GB24499@lst.de/
(하라는 대로 한게 맞습니다. PR 은 kernel/dma 가 아니라 rust/kernel 하위 트리를 수정한겁니다.)
근데 바로 앞선 스레드에서 오간 얘기가 좀 재밌는데요,
'API 에 breaking change 가 생긴걸 Rust 팀이 재빠르게 대응하지 않으면 빌드가 터지고, Linus 가 PR 을 받아주지 않게 된다' 는 내용입니다.
아무래도 저는 breaking change 만든 모듈과 다른 모듈간의 문제라고 생각해보면 저는 Rust 가 있는 쪽이 더 나은 것 같습니다.
x 모듈이 breaking change 를 만들었고, y 모듈이 재빠르게 대응하지 못한 상황인데요,
해당 PR 메일 스레드입니다:
https://lwn.net/ml/all/…
DMA 구현을 수정 한 것도 아니고, DMA API 를 직접 손 댄 것도 아니고, Rust 에서 DMA API 에 접근할 수 있게 FFI 바인딩을 작성한 PR 로 보입니다.
그런 PR 에 "No rust code in kernel/dma, please." 라는 단답으로 거절 한 거고, https://lwn.net/ml/all/20250108135951.GA18074@lst.de/
그럼 어떻게 하면 좋겠냐 물으니 "Keep the wrappers in your code instead of making life painful for others." 라고 합니다. https://lwn.net/ml/all/20250108151858.GB24499@lst.de/
(하라는 대로 한게 맞습니다. PR 은 kernel/dma 가 아니라 rust/kernel 하위 트리를 수정한겁니다.)
물론 FFI 바인딩이 추가되면 DMA API 가 바뀔 때 Rust FFI 바인딩도 수정돼야 하긴 하는 부담이 있겠습니다만,
그건 rust 손대는 쪽에서 알아서 잘 하겠다고 했음에도, 해당 트리 담당이 아닌 사람이 이런 태도로 반발하는게 올바른건지는 잘 모르겠습니다.
(Christoph Hellwig 는 kernel/dma 메인테이너입니다: https://docs.kernel.org/process/maintainers.html#dma-mapping-helpers)
그래서 Hector Martin 이 Linus를 타래에 끌어들인 것 같습니다:
https://lwn.net/ml/all/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/
근데 바로 앞선 스레드에서 오간 얘기가 좀 재밌는데요,
'API 에 breaking change 가 생긴걸 Rust 팀이 재빠르게 대응하지 않으면 빌드가 터지고, Linus 가 PR 을 받아주지 않게 된다' 는 내용입니다.
아무래도 저는 breaking change 만든 모듈과 다른 모듈간의 문제라고 생각해보면 저는 Rust 가 있는 쪽이 더 나은 것 같습니다.
x 모듈이 breaking change 를 만들었고, y 모듈이 재빠르게 대응하지 못한 상황인데요,