리눅스커널 러스트 논쟁, 다시 불타오르다
(byline.network)- Direct Memory Access API를 구현한 러스트 코드가 리눅스 커널 리포지토리로 풀 리퀘됨.
- 리눅스 커널의 중간 관리자 Christoph Hellwig가 러스트 코드를 리눅스 커널로 들이지 말라면서 거부하고 분쟁이 시작됨.
- 분쟁의 크기가 점점 커지면서, Christoph Hellwig가 러스트를 암 세포에 비유함.
- 아사히 리눅스의 총 책임자 Hector Martin은 이 암 세포 발언에 반발해, 소셜 미디어에서 리누스 토르발스를 끌어들이면서 맹비난함.
- 리누스 토르발스는 Hector Martin에게 "문제는 당신 자신"이라며 "소셜 미디어에서 여론 선전(Brigading)을 하지 말라"고 경고함.
- 현재 Hector Martin은 애플 Arm 호환 하드웨어를 지원하는 업스트림 리눅스 코드 관리자에서 사임을 요청.
안녕하세요. 좋은 글 올려주셔서 감사합니다. 즐겁게 읽었습니다.
하지만 원문을 확인해보고, 원문의 제목을 확인했을 때 약간 우려되는 사항이 있어서 댓글을 달아봅니다.
https://news.hada.io/guidelines
기본적으로 글의 원 제목을 붙이거나, 제목을 한글로 번역해서 올려주세요.
라고 제안하고 있고. 해당 글의 내용을 읽어봤을 때, "리눅스커널 러스트 논쟁, 다시 불타오르다." 대신 "리누스 토발즈 '문제는 당신'" 이란 제목은 원래 제목보다도 글의 내용에 오해가 생길 소지가 있다고 생각합니다.
요약과 글을 소개해주셔서 다시 한번 감사합니다. 좋은 하루 되세요.
좀더 정확한 설명을 위해 제목에 저만의 부제목을 다는 게 버릇이었는데, 제목이 다른 분에게 맞지 않았을 뿐더러 이런 규정이 있다는 것을 몰랐군요. 다음부턴 원문 그대로 내놓겠습니다.
원 제목은 무엇에 관한 이야기인지 바로 알 수 있는 반면 변경하신 제목은 자칫 낚시성이라는 오해를 불러일으킬 소지가 있어 보입니다. 개인 의견입니다.
큰 프로젝트를 자기 언어의 시험장으로 쓰는 것 좋아보이지 않네요.
수틀리면 포크하던 옛날로 돌아갈 필요 있습니다.
기기전반을 다루는 커널에서 rust써봐야 unsafe 쓰기시작하면 읽기 어려운 문제생기는 코드가 되는걸로 밖에 생각이 안들어요.
무슨 0.91 0.92 0.99 0.991 뭐 이런식의 메인 릴리즈 앖는 프로젝트도 아니고 잘돌아가던 부분들을 포팅하고 있는지 모르겠네요.
큰 버그 나와서 잡는김에 안전하게 바꿨습니다도 아니구요.
해당 PR 은 포팅이 아닙니다. 기존 DMA API 를 새로 작성하는 Rust 기반 모듈에서도 쓸 수 있게 Rust 쪽에서 FFI 바인딩을 추가한 PR 입니다. 그걸 DMA 담당자가 막아선거구요.
큰 c 코드베이스에 러스트를 붙이는게 생각처럼 재밌지 않더라구요. 메모리 안전성을 높인다고 하기엔 어차피 unsafe 영역이 커져서 실효성이 크지 않고.... 그냥 러스트 사용영역이 커지는 것 이상의 의미가 없고.... 해서 기존 c개발자들의 반발을 초래하는게 자연스러운 수순인 것 같습니다. 진짜 러스트로 처음부터 시작하는 커널 프로젝트에 집중하는게 나을 수 있을 것 같습니다.
해당 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 모듈이 재빠르게 대응하지 못한 상황인데요,
- y 모듈이 Rust 짜임: 컴파일이 터져서 Linus 가 머지해주지 않음
- y 모듈이 C로 짜임: 컴파일은 돼서(??) Linus 가 머지해줌 (????)
리눅스 커널에서 러스트가 unsafe쓰는 부분은 대부분이 C와 wrapping하는 부분입니다.
그 외에도 메모리를 직접 다뤄야되는 하드웨어 제어 부분도 있지만 매우 적은 부분입니다.
러스트가 적용되는 부분은 드라이버 개발입니다. 메모리 관리나 블럭 레이어 등 커널 자체는 건드릴 필요도 없고 할 수도 없습니다.
커널 자체 코드보다 훨씬 더 많은 코드가 드라이버 코드입니다. 그리고 문제가 생기는 지점들도 대부분 드라이버 코드입니다.
저는 드라이버 개발 부분이 C보다 더 메모리 안전성이 높고 보안성이 좋은 언어로 개발되는게 맞다고 생각합니다.
그게 러스트이든 Zig이든 뭐가 될지는 모르겠지만요.
러스트는 일반 어플을 개발하기에 과하게 복잡하고 C언어 개발자가 빨리 배우기에도 어렵다는 것은 저도 공감합니다.
그래도 무슨 언어가 됐던간데 드라이버 개발만이라도 최신형 언어로 바뀌길 바랍니다.
제가 이전회사에서 몇천줄 안되는 드라이버를 개발하고 안정화하는데 대략 7년의 시간이 걸렸는데 완전히 단순화할 수는 없지만 대략 3년 정도는 디버깅만 한것 같습니다.
대부분이 메모리 관련 버그였고요. 데드락같은 논리적인 오류는 소수였습니다.
토르발스가 말한 문제는 당신이라는 말은 러스트 도입과 무관하게 기술적 문제의 해답이 SNS가 될 수 없다는 논지였습니다만, 이 요약만 보면 오해의 소지가 있을 것 같습니다.
헥터 마틴으로선 어쩔 수 없는 선택이었습니다.
리눅스 중간 관리자가 전부 c 전문가로 채워져 있는데 소수 인원인 러스트 개발자의 의견 따위, 받아줄 리 있겠습니까.
기사 본문에 인용 원문이 없어서 아쉽네요. 궁금해서 원문 찾아서 읽어보고 왔는데, 저도 제대로 파악한건 아니지만 단순히 원문처럼 이야기 하기에는 뒷이야기가 좀 많은것 같습니다.
토발즈는 해당 논쟁에서 러스트에 대해 한마디도 안했습니다.
기술적 의견 분쟁이 있을 때, 기술적인 근거로 토론을 진행해야지
SNS에서 여론을 만들어서 분쟁을 끝내려는 행위를 하지 말라는 소리죠.