GN⁺: Greg K-H: "Rust로 새로운 코드 작성은 모두에게 이익"
(lore.kernel.org)Rust를 리눅스 커널에 도입해야 하는 이유
- 지난 15년 동안 거의 모든 리눅스 커널 버그 수정과 보안 문제를 살펴본 경험을 바탕으로, Rust 도입의 필요성을 이야기하고자 함
- 모든 버그 수정이 안정 버전 트리에 반영되는 것은 아니지만, 대체로 중요한 것들은 반영되며, 나는 모든 커널 CVE를 확인하는 입장에 있음
C의 한계와 Rust의 장점
- 리눅스 커널에서 발생하는 버그의 대부분은 C 언어의 구조적 한계에서 비롯됨
- 특히, 단순한 실수로 인해 발생하는 버그가 많으며, 이러한 문제들은 Rust에서는 거의 발생하지 않음
- 메모리 오버라이트 (Rust가 모든 경우를 잡아내지는 않지만 상당 부분 해결 가능)
- 에러 경로 정리 문제
- 에러 값 체크 누락
- Use-after-free(해제 후 사용) 버그
- Rust를 커널에 도입하면 개발자와 유지보수 담당자가 이런 기초적인 실수에서 벗어나, 진짜 어려운 문제(논리 오류, 경쟁 상태 등)에 집중할 수 있음
기존 C 코드베이스도 계속 유지해야 함
- 현재 리눅스 커널은 3천만 줄 이상의 C 코드로 구성되어 있으며, 단기간 내에 이를 Rust로 대체하는 것은 불가능함
- 따라서, Kees와 Gustavo를 비롯한 개발자들이 진행하는 C 코드 보안 강화 작업은 필수적이며 계속되어야 함
- Rust가 기존 코드를 대체하는 것이 아니라, 새로운 코드(특히 드라이버)를 Rust로 작성하여 문제를 줄이는 방식이 이상적임
Rust가 제공하는 API 안전성
- Rust는 커널 내부 API를 더 안전하고 사용하기 쉽게 설계할 수 있도록 함
- 현재 C 기반 커널 API는 복잡하고 실수하기 쉬우며, 유지보수자가 세밀하게 검토해야 하는 경우가 많음
- 예를 들어,
struct cdev같은 구조체를 안전하게 사용하는 방법은 여러 가지가 있으며, 이를 올바르게 활용하기 위해 많은 경험이 필요함 - Rust를 사용하면 API를 더 명확하게 정의할 수 있어, 개발자가 실수할 가능성을 크게 줄일 수 있음
- 이는 단순히 Rust 사용자만을 위한 것이 아니라, 기존 C 코드 사용자들에게도 도움이 되는 변화임
Rust 도입이 어려울 것이라는 우려에 대한 반론
- Rust는 만능 해결책이 아님 → 하지만 기존 문제의 상당 부분을 해결 가능
- 유지보수자들의 부담 증가 → 하지만 Rust 도입을 원하는 개발자들이 직접 작업을 하고 있음
- 혼합 언어 코드베이스의 유지보수 난이도 → 하지만 리눅스 커널은 지금까지 훨씬 더 어려운 문제들을 해결해 왔음
결론
- 리눅스는 전 세계 수많은 개발자가 문제를 해결하기 위해 사용하는 도구이며,
- 이제 하드웨어를 위한 안전한 코드 작성을 원한다는 개발자들의 요구가 있다면 이를 무시해서는 안 됨
- 리눅스 개발 모델은 그 누구도 예상하지 못했던 규모로 성장하며, 탁월한 엔지니어링 역량을 보여줌
- 이제 Rust 도입을 통해 앞으로 20년 이상의 발전을 위해 나아가야 할 때임
새로운 기술과 아이디어를 받아들이고, 커뮤니티와 함께 성공할 수 있도록 노력해야 함.
러스트 사용자이긴 하지만, r/rust에 올라온 hgwxx7_의 댓글이 인상적이었습니다1.
I think what Greg does really well here is demonstrating technical leadership.Leadership doesn't mean being right. He is right, but that's not the point.
Leadership means bringing along on the path he thinks is best. He doesn't crack the whip, chiding or coercing maintainers who disagree. Instead, he first acknowledges their very valid concerns about maintaining a code base with two languages. This is good, because they're right about that, their lives do get harder before they get easier.
He then ends on an inspirational note, pointing out that they've done much harder things and this is well within their abilities. He gently nudges them to welcome R4L devs.
Absolute masterclass of leadership.
I don't know if the other maintainers will be convinced when they read this. But it's hard for me to imagine a more convincing pitch than this one.
아직 성숙하지 않은 언어를 커널에 포함시키지 않겠다는게 이렇게 지탄받을 일인가 싶습니다. 당장 주위에 러스트 능숙하게 다루는 사람 찾아보라 하면 거의 없지 않나요? 언어가 좀 더 성숙해지고 유저도 레거시 언어 유저만큼은 아니라도 충분히 확보가 되었을때 포함되도 늦지 않을것 같습니다.
러스트 언어가 유용하다는것은 리눅스 커널에 적용되지 않아도 충분히 증명할 수 있을것이라 믿습니다.
러스트가 지금 정도로도 "아직 성숙하지 않은 언어" 소리를 듣는 것 자체도 놀랍습니다만, 그와 별개로, 아직까지도 안전하지 않은 언어를 커널에서 비중을 줄여보겠다는 게 이렇게 지탄받을 일인가 싶습니다. 당장 주위에 C 언어를 커널에 기여 가능할 정도로 능숙하게 안전한 코드 짜실 수 있는 사람 많지 않지 않나요? C언어에 더 이상의 성숙을 기대하기보단 새로운 시대의 요구가 충분히 확보가 된 지금이야말로 늦지 않은 때인 것 같습니다.
러스트는 이미 유용하며, 커널에 포함되려는 건 유용함을 증명하기 위함이 아닐 것입니다.
처음 rust를 도입하기로 했을 때, 논의된 바가 있을 것 같긴 한데.
C 숙련자, rust 숙련자 어느쪽이 더 풀이 큰가 생각해보면 c가 압도적이긴 하겠네요.
도메인 지식이 이미 다 갖춰진 프로그래머가 언어 하나 더 배우는 게 큰일인가 싶기도 한데,
커널 다루시는 분들이 요구하는 숙련도는 또 다른 얘기 일테니...
저도 러스트 사용자지만 러스트 코드와 c 코드가 혼재되면 오픈소스에 어디까지 러스트 코드를 허용한다는 철저한 규약이 없는한 통제 불가능이나 최소한 리뷰와 유지보수 코스트가 엄청 올라갈것 같은데 추가 하지 않고 포크를 뜨는게 제일 현명한 선택으로 봅니다
커널에 러스트를 도입하길 원하는 사람이 이렇게 많다면, 포크해서 새 프로젝트로 가도 되지 않나요? 그러다가 충분히 성숙하면 주요 배포판들이 러스트 기반 커널로 전환할테구요.
왜 서로 싸우고 있는지 잘 모르겠어요.
커널 개발 경험이 있으신 분이신지 제가 잘 몰라서 뭐라 말씀드려야될지 모르겠지만
일단 러스트 언어를 적용하는 것은 커널을 러스트로 바꾸자는게 아닙니다. 분리해서 또 다른 커널을 만들면 되는거 아니냐하실 수 있지만
러스트 언어로 커널을 만들자는게 아니라 커널에서 디바이스 드라이버를 위한 인터페이스만 러스트로 wrapper를 만들어서 디바이스 드라이버만 러스트로
만들 수 있도록 개선해보자는 것입니다. 그래서 새 프로젝트로 간다는 것은 의미가 없습니다.
커널 안정성을 이유로 독성 말투를 정당화해 오던 리눅스 커뮤니티가 이제 와서는 '마음에 안 들면 포크 떠라'는 반응을 합리적인 답변이라고 여기는 게 참 아이러니하네요.
포크한 결과가 마이그레이션이 될지 춘추전국시대가 될지 예상하기 힘든 점이 있을 것 같아요.
포크한 후에도 업스트림 변경사항을 반영하는 게 유쾌한 상황은 아닐 것 같아요.
https://news.hada.io/topic?id=16860
Realtime Linux 포크가 20년만에 병합되었던 걸 보면 포크를 신중하게 결정해야하지 않을까 합니다
저는 이걸 보고 한 이야기였어요.
실시간 기능을 오랫동안 커널과 분리한 프로젝트로 유지할 수 있었고, 필요한 사람은 받아다가 커널에 적용해서 쓰면 됐었으니까요.
러스트 도입은 memory safety를 고려 했을 때 피하기 어려운 변화겠죠. 아마 적당한 절충안을 통해 재봉합을 시도하지 않을까 싶습니다.
그런데, 개인적으로 러스트의 키워드들이 눈에 잘 안 들어오기도 하고 한참 뒤에 봤을 때 다시 기억이 잘 안나기도 해서 영 손에 안 잡히긴 하더라구요 ;;;; 다 필요한 것들인 것은 알겠지만 영어의 불규칙 동사를 억지로 외우는 느낌이 들곤 합니다. 그러면서도 러스트로 작성된 결과물들이 현장에서 문제를 덜 일으키는 것은 또 사실이다 보니.....
Hacker News 의견
- Rust 바인딩이 있으면 커널의 내부 ABI가 자유롭게 진화할 수 없고, 프로젝트가 C 코어와 Rust 측으로 나뉘게 될 위험이 있음. 그러나 내부 API가 안정화되면 Linux에 이익이 될 수 있음
- 커뮤니티와 사람들이 주요 문제임. 현재 커널 작업을 하는 사람들이 이 방향을 좋아하지 않으면 큰 문제임
- Linux 리더십은 사람 문제에 집중하지 않는 것 같음. 현재 커널 개발을 하는 사람들이 이 방향에 동의하는 증거가 어디에 있는지 의문임
- Rust를 수용하는 것이 얻는 이익보다 고통이 더 크다고 생각하는 사람들이 있음. 다른 방법으로도 이익을 얻을 수 있을 것이라고 생각함
- 예를 들어, bounds checking과 RAII와 같은 간단한 할당/해제 단순화가 Rust 없이도 가능할 수 있음
- Clang을 필수 컴파일러로 만들고 이러한 확장을 채택하면 더 쉽게 효과를 얻을 수 있음
- 새로운 코드/드라이버를 Rust로 작성하면 이러한 종류의 버그가 발생하지 않음. 이는 모두에게 이익임
- 대부분의 사람들은 메모리 안전성을 원하지만, 전체적인 유지보수자가 되기를 원하지 않음
- 프로젝트의 실제 목표는 내부 커널 API 표면을 현대화하는 것임. Rust로 이 API를 작성하는 것이 얼마나 견딜 수 있는지가 진행 상황을 측정하는 가장 좋은 척도임
- 지난 15년 동안 거의 모든 커널 버그 수정 및 보안 문제를 본 사람으로서, 대부분의 버그는 C의 작은 코너 케이스에서 발생함. Rust에서는 이러한 문제가 사라짐
- 새로운 코드/드라이버를 Rust로 작성하면 이러한 종류의 버그가 발생하지 않음. C++는 이러한 이점을 제공하지 않음
- Rust는 커널 API를 정의할 때 오류를 거의 불가능하게 만듦. 이는 Linux를 전반적으로 더 좋게 만듦
- Rust 바인딩은 마법처럼 보이지만, 배우고 개발자들과 협력할 의향이 있음
- Rust는 모든 문제를 해결하는 은탄환은 아니지만, 많은 부분에서 도움이 됨
- Linux는 모든 사람들이 문제를 해결하는 도구임. 개발자들이 하드웨어를 위한 코드를 작성할 때 이러한 버그가 발생하지 않기를 원함
- 혼합 언어 코드베이스는 유지보수가 어렵지만, 우리는 커널 개발자임. 새로운 아이디어를 받아들이고 함께 성공하기 위해 노력해야 함
- 이 논의를 앞으로 나아가게 하기 위해 이 성명이 필요했음
- 기술적 장점에 집중하고 있지만, 새로운 프로그래밍 언어/도구 체인을 배우는 노력을 적절히 평가하지 않음
- 새로운 프로그래밍 언어를 마스터하는 것은 쉬운 일이 아니며, 일부 유지보수자는 개인적인 관심/동기 때문에 원하지 않을 수 있음
- C++ 언어 위원회 문제는 모두가 가능한 한 빨리 그 언어를 포기해야 한다고 지적하고 있음.