리눅스 커널에서의 Rust 실험 (성공적) 종료
(lwn.net)- 리눅스 커널 내 Rust 통합 작업이 실험 단계를 마치고 정식 구성 요소로 인정됨
- 연례 Maintainers Summit에서 개발자들이 Rust 지원을 영구적 기능으로 채택하기로 합의
- 이에 따라 커널 내 Rust 관련 코드에서 ‘experimental’ 태그가 제거될 예정
- LWN 편집자는 “실험은 끝났고, 성공이었다”고 밝히며 Rust for Linux 팀의 성과를 언급
- 이는 커널 개발 언어 확장과 안전성·현대화 방향의 중요한 전환점으로 평가됨
커널 Rust 실험의 종료와 정식 채택
- 연례 Maintainers Summit에서 커널 내 Rust 지원이 논의되었으며, 참석한 개발자들은 Rust가 더 이상 실험적 기능이 아님에 합의
- Rust는 이제 커널의 핵심 일부로 자리 잡음
- 이에 따라 관련 코드에서 ‘experimental’ 표시가 제거될 예정
- LWN 편집자는 게시글에서 “실험은 끝났고, 성공이었다”고 명시
- Rust for Linux 팀의 노고에 대해 축하 메시지를 전달
커뮤니티 반응
- 게시글 제목이 일시적으로 오해를 불러일으켜, 일부 독자들이 Rust 제거로 착각하는 반응을 보임
- 여러 댓글에서 “순간 속았다”, “감정 롤러코스터였다” 등의 반응이 이어짐
- 일부 사용자는 Phoronix의 헤드라인 스타일을 언급하며 유머러스하게 반응
- Phoronix의 벤치마크 활동과 오픈소스 생태계 업데이트가 유용하다는 평가도 함께 제시됨
- 다른 댓글에서는 Microsoft가 Windows 커널에도 Rust를 도입 중임을 언급
- 일부 구성 요소가 이미 Rust로 작성되어 출하 단계에 포함되었다는 의견 제시
Rust 도입의 의미
- 커널 내 Rust 지원이 공식적·지속적 기능으로 전환됨으로써,
메모리 안전성 강화와 현대적 언어 도입이 커널 개발의 일부로 정착 - 커널과 Windows 양쪽에서 Rust가 채택되며, 시스템 프로그래밍 언어의 세대 교체 흐름이 가시화됨
- 커뮤니티는 이번 결정을 성공적인 실험의 완결로 받아들이며, 향후 Rust 기반 커널 모듈 확장을 기대하는 분위기
한글 관련 서적이 딱 한권 나와 있는데, 아쉽게도 리눅스 커널에서 러스트 사용 방식이 여러번 브레이킹 체인지를 겪는 바람에 요즘의 커널과는 완전히 호환 되지 않더라구요. 깃헙 등을 통해 보완이 되면 참 좋겠습니다.
Hacker News 의견들
-
Rust 지원이 지난 2년 동안 정말 많이 발전했음
이제는 거의 보일러플레이트 없이 커널 모듈을 작성할 수 있을 정도임
“experimental” 태그가 제거된 건 큰 이정표라고 생각함
앞으로 배포판들이 Rust 지원이 기본 활성화된 커널을 내놓는 날이 진짜 전환점이 될 것 같음- 이미 일부 배포판은 그렇게 하고 있음
예를 들어 NixOS와 Arch는 Rust로 작성된 QR 코드 커널 패닉 화면을 활성화함
Fedora도 아마 지원하는 걸로 알고 있음 - Fedora 43은
CONFIG_RUST=y로 컴파일된 걸로 알고 있음 - “Rust 지원이 기본 활성화된 커널”이란 표현이 무슨 뜻인지 궁금함
커널이 Rust 사용자 공간을 지원하는 건 아니고, 단지 일부 커널 코드가 rustc로 컴파일된다는 의미로 이해함 - Rust가 GCC에서 완전 지원되기 전까지는 모든 플랫폼에서 가능할지 의문임
- 이미 일부 배포판은 그렇게 하고 있음
-
오랜 저항 끝에 Linux 커널에서 Rust가 공식적으로 채택된 게 감격스러움
Rust for Linux 팀에게 박수를 보냄- 예전에 Asahi 프로젝트 관련 Rust 코드가 유지보수자 거부로 인해 혼란스러웠던 기억이 있음
그 사건이 프로젝트의 첫 번째 도미노였는지 궁금함 -
Phoronix 기사에 따르면
Rust for Linux 공동 유지보수자였던 Alex Gaynor가 공식적으로 물러났다고 함
이제 Miguel Ojeda가 유일한 공식 유지보수자로 남았고, 여러 명의 코드 리뷰어가 있음
- 예전에 Asahi 프로젝트 관련 Rust 코드가 유지보수자 거부로 인해 혼란스러웠던 기억이 있음
-
“experimental” 태그 제거가 모든 유지보수자가 Rust 코드를 깨뜨리지 않도록 의무화된다는 뜻인지 궁금함
- 실제로는 Rust가 커널에 정식으로 자리 잡았다는 신호일 뿐임
개발자들이 Rust 기반 드라이버에 투자해도 된다는 안정감의 표시임
여전히 규칙은 동일하고, Rust 빌드를 깨뜨리는 코드는 Linus에게 보낼 수 없음 - 커널 내에서는 사용자 공간 API 외에는 안정성이 보장되지 않음
즉, 유지보수자가 내부 Rust 코드를 깨뜨려도 규칙 위반은 아님
- 실제로는 Rust가 커널에 정식으로 자리 잡았다는 신호일 뿐임
-
Rust가 지원하지 않는 아키텍처들은 이제 버려지는 것인지 궁금함
- 그렇지 않음. Rust는 현재 드라이버 서브시스템에서만 사용됨
커널의 핵심 부분은 여전히 C로 작성되어야 함 - 어떤 아키텍처가 지원되지 않는지 궁금함
- 농담으로 “그렇다, 다 요리됐다(cooked)”고 표현함
- 그렇지 않음. Rust는 현재 드라이버 서브시스템에서만 사용됨
-
기사 제목이 “The (successful) end of the kernel Rust experiment”로 수정되었다고 함
원래 제목이 과장됐다는 커뮤니티의 피드백 때문임- 수정된 제목이 적절하다고 생각함
Hacker News 가이드라인에 따르면
“원래 제목이 오해의 소지가 있을 때만 수정하라”고 되어 있음 - “successful”이라는 단어는 이미 암시된 것 같음
실패한 실험은 끝나지 않기 때문임 - 농담조로 “Linux devs tried Rust — you won’t BELIEVE the reaction!” 같은 제목을 제안함
- 수정된 제목이 적절하다고 생각함
-
“이거 큰 일인가요?”라는 질문에
- “맞음, 큰 의존성이 추가된 셈임”
- “그렇다”고 짧게 동의함
-
Linux 커널 드라이버가 Rust로 가는 흐름이라면, FreeBSD 같은 BSD 계열도 같은 산화(oxidation) 를 겪을지 궁금함
아니면 저항과 분화가 생길지 주목함 -
새로운 시도를 반기는 입장임
- 하지만 어떤 사람은 “새로운 건 불안정하고 배우기 어렵다”고 반박함
Rust는 메모리 안전성과 표현력 덕분에 그 어려움을 감수할 가치가 있다고 생각함
- 하지만 어떤 사람은 “새로운 건 불안정하고 배우기 어렵다”고 반박함
-
현재 커널에서 Rust로 작성된 부분이 무엇인지 궁금함
- 대표적으로 DRM Panic “Screen of Death” 가 Rust로 작성됨
Phoronix 기사 참고 - 주로 GPU 드라이버 쪽에서 Rust가 사용되고 있음
- 대표적으로 DRM Panic “Screen of Death” 가 Rust로 작성됨
-
커널의 Rust 코드에 unsafe가 얼마나 포함되어 있는지 궁금함
예전엔 unsafe가 너무 불편하다는 불만이 많았음- 대부분의 unsafe 코드는 C API와 상호작용하는 kernel crate 내부에 숨겨져 있음
드라이버 개발자는 거의 unsafe를 쓸 필요가 없음 - unsafe는 본질적으로 경계부 코드(edge) 에서만 쓰이도록 설계된 것임
대부분의 코드는 안전한 Rust로 작성됨 - unsafe가 여전히 어렵긴 하지만, 실제 드라이버 코드에서는 거의 등장하지 않음
예를 들어 pwm_th1520.rs는
Send와Sync를 지원하기 위한 한 줄짜리 unsafe만 포함함 - unsafe 블록은 문서화하고 안전한 인터페이스로 감싸서 다시는 직접 볼 필요 없게 만드는 게 원칙임
- 대부분의 unsafe 코드는 C API와 상호작용하는 kernel crate 내부에 숨겨져 있음