리눅스 커널 개발을 위한 Rust 언어의 새로운 기능들

• Rust for Linux 프로젝트가 커널 개발에 필요한 핵심 언어 기능을 추진하며, Rust 언어 자체 발전에 기여하고 있음
• 필드 프로젝션(Field Projection), 제자리 초기화(In-place Initialization), 임의 Self 타입(Arbitrary Self Types) 세 가지가 핵심
• 이 기능들은 스마트 포인터, 고정 메모리(Pin), RCU 등 커널 특유의 구조를 더 자연스럽게 Rust로 표현하게 해줌
• Rust 팀은 설계 안정성을 중시해 개발 속도가 느리지만, Linux 커널이라는 명확한 목표 덕분에 개발 집중도가 높아짐
• 커널 외부의 Rust 생태계에도 파급력을 줄 변화로, 스마트 포인터 처리와 코드 단순화에 큰 도움이 될 전망임

---

Rust 언어 개선과 Linux 커널의 역할

• Rust 언어의 새로운 기능 개발이 느린 이유는 나쁜 설계를 언어에 고착시키지 않으려는 신중함과 "관심의 정렬(alignment in attention)" 문제 때문임
  • Rust 프로젝트는 자원봉사자들에 의해 운영되므로, 특정 기능에 집중하는 사람이 없으면 개발이 지체됨
• Rust for Linux 프로젝트는 많은 사람들이 흥분하는 주제이기 때문에, 커널에 필요한 몇 가지 핵심 기능에 노력을 집중시키는 데 도움이 됨
• Rust 언어팀 공동 리더 Tyler Mandry는 Kangrejos 2025에서 Rust의 다가올 언어 기능을 발표하며, Linux 커널 프로젝트가 Rust 발전의 촉매제 역할을 했다고 언급함
  • 주요 기능: 필드 프로젝션, 제자리(in-place) 초기화, 임의 Self 타입(Arbitrary self types)
  • 커널 개발이 실제 사용 사례와 기술적 요구를 명확히 제시해, Rust의 언어 설계 방향을 구체화하는 데 기여
  • 가장 우선순위는 커널 바인딩에서 이미 사용 중인 불안정(unstable) 기능의 표준화임

Field Projection (필드 프로젝션)

• 구조체 포인터에서 특정 필드 포인터를 추출하는 기능으로, C의 &(r->field) 표현을 Rust에서 일반화하려는 시도임
• 기존에는 참조(&) 와 *포인터(mut) 에서만 가능했으나, 사용자 정의 스마트 포인터에서는 제한이 있었음
• Rust for Linux는 이를 확장해, 모든 포인터 타입에서 동일 문법으로 필드 접근이 가능하도록 추진 중임
• 특히 Pin 타입(이동 불가 구조체)을 다루는 경우, 필드 투영 시 Pin<&mut Field> 또는 &mut Field 로 자동 변환되도록 설계됨
• 이 기능이 구현되면 RCU(Read-Copy-Update) 패턴을 Rust에서 안전하게 지원할 수 있어, 락(lock) 없이도 고성능 데이터 접근이 가능해짐
• 현재 GitHub의 tracking issue에서 논의 중이며, Debian 14(2027) 이전 안정화를 목표로 함

Arbitrary Self Types (임의 Self 타입)

• 스마트 포인터를 수용하는 메서드 정의를 가능하게 하는 기능
• 기존에는 fn method(&self) 형태만 지원했지만, 이제 fn method(self: Pin<&mut MyStruct>) 같은 형태도 가능해짐
• 커널에서는 Arc, Pin, Mutex 등 다양한 포인터 래퍼를 사용하므로 필수적인 기능임
• 구현 과정에서 Deref 트레이트와의 충돌 문제가 있었으나, 새로운 Receiver 트레이트를 도입해 해결 중임
• Receiver는 임의 Self 타입으로 사용될 수 있는 포인터임을 명시하는 역할을 함
• 커널 개발에서는 이를 통해 포인터 체인 호출을 간결하게 유지할 수 있음
• Ding은 Crater 도구를 이용해 기존 Rust 패키지 호환성을 검증 중이며, 1년 내 안정화 가능성을 언급함

In-place Initialization (제자리 초기화)

• 커널에서 사용 중인 pin_init!() 매크로를 언어 차원에서 지원하는 기능임
• 객체를 생성 후 이동하지 않고 메모리 상에서 직접 초기화하는 기능으로, Pin 구조체, Future, dyn 트레이트 등에 유용함
• 세 가지 제안이 병행 논의 중임
  • init 키워드 방식: 최소한의 문법 추가로 기존 PinInit 트레이트 활용
  • &out 참조 방식: C의 out 포인터처럼 쓰기 전용 참조를 추가, 필드 단위 초기화 지원
  • C++ 스타일 최적화 방식: 힙으로 즉시 이동될 객체를 초기부터 힙에 직접 생성
• 최종적으로 PinInit과 out-reference 방식을 모두 실험해 실제 사용성을 검증할 계획임
• 이 기능이 도입되면, 커널뿐 아니라 비동기 Rust 코드 전반의 구조 단순화에 기여할 것으로 전망됨

Rust for Linux가 Rust에 미치는 영향

• Linux 커널은 Rust 언어 발전에 있어 현실적인 테스트베드 역할을 하고 있음
• 세 가지 기능 모두 스마트 포인터, 고정 메모리, 동시성 구조 같은 커널 특유의 요구에서 출발했지만,
  결과적으로 일반 Rust 개발자들도 혜택을 받게 될 것임
• 이러한 변화들은 커널과 언어 개발 간의 선순환 구조를 보여주는 사례로 평가됨

[GN⁺]

Hacker News 의견

• rust의 lightweight clones 기능에 대한 rfc 문서를 읽고 이해하는 데 시간이 좀 걸렸음. 처음엔 이 기능이 꽤 흥미로웠으나, 결국 rust가 배우기 복잡한 언어란 점이 다시 한 번 느껴짐. 나같이 rust나 C++을 제대로 배우지 않은 사람 입장에서는, modern C++의 모든 개념과 기능이 haskell의 요소와 결합된 듯한 인상임. 그럼에도 사람들이 rust로 유용한 것들을 많이 만드는 걸 보면 뭔가 제대로 된 게 있다는 느낌임. 그래서 조만간 다시 한번 본격적으로 rust를 써볼 생각임. 관련 RFC 링크

  • 내 경험상 C++이 rust보다 훨씬 복잡함. 예를 들어 초기화 방식만 8가지, 값의 타입만 해도 xvalues 등 5가지, 포맷팅과 네이밍 컨벤션도 일관되지 않고, rule of 5, 예외 처리, move assignment 할 때 항상 this != other 체크해야 하고, perfect forwarding, SFINAE, trait 대체물 문제 등 복잡한 점이 너무 많음. C++을 제대로 쓰려면 표준 위에 쌓인 안전하고 빠르게 코딩하기 위한 컨벤션도 같이 익혀야 하고, 예외 처리 같은 방법들이 전부 충돌하거나 비이상적인 방식을 택해야 하는 경우도 많음

  • rust 커뮤니티에서는 이 lightweight clones 제안에 대해 점점 부정적인 분위기임. 왜냐하면 너무 복잡하다는 것 때문임. 설계 방향에 대한 rust 공식 문서에서도 복잡성이 가장 큰 걸림돌임. rust 제안에 어떤 기능이 꼭 단순해야 하는 건 아니지만, lightweight clone은 이미 할 수 있는 걸 조금 쉽게 만들어줄 뿐이고, 사람들이 쉽게 이해하지 못한다면 그건 문제임

  • rust는 멀리서 보면 너무 방대한데 실제로 코딩하면 금방 익숙해짐. 예를 들어 처음에 lifetime 개념을 전혀 이해하지 못해서 Rc<>만 가지고 코딩했음. 기본기 익힌 후에 lifetime을 다시 공부하니까 훨씬 쉬워졌음. 사실 대부분의 사용자들은 lightweight clones 같은 기능은 신경 쓸 일도 없음

  • C에 비하면 매우 복잡하지만 C++에 비하면 훨씬 단순한 언어임. 코드를 이해하려고 문서나 참조서를 뒤질 필요가 거의 없는 수준임. rust는 "너무 복잡해서 머리가 빠질 일도 없고, 너무 단순해서 코드가 복잡해질 일도 없다"는 아주 적당한 포지션임. 게다가 기본적으로 코드가 correctness를 갖게 됨

  • rust의 복잡성은 C++처럼 실수로 잘못 쓸 일도 적음. 그리고 clippy를 쓰면 더 idiomatic 한 코드로 자동 변환해주기 때문에 lightweight clones 같은 새로운 기능도 직접 몰라도 제안받게 됨. 대부분을 clippy의 --fix 옵션만으로 쉽게 적용 가능함. 이런 부분이 c++와 decisively 다르며, c++는 쓰지 않는 기능이 쌓이거나 과하게 복잡하게만 쓰이게 되어 복잡성이 쌓이는 부작용이 계속됨

• Rust for Linux 프로젝트가 rust에 큰 도움이 됐다는 말이 있어서, curiosity로 커널 트리에서 "*.rs" 파일을 찾아봤음. 보니까 rust 폴더 아래에 api 호환 레이어가 있고, 커널 트리엔 기존 드라이버를 단순히 rewrite한 proof of concept 드라이버들이 조금 있을 뿐이고 (미완성된 nvidia 드라이버 제외) 사실상 실제 사용되는 건 없는 듯 보임. android binder rust 리라이트도 거의 남아만 있는 수준이라고 느낌. 전체적인 인상은 그냥 아기자기한 실험 프로젝트란 느낌이고, 세계에서 가장 중요한 소프트웨어의 소스 트리에서 이런 언어 공동 개발 실험을 할 필요가 있나 하는 의문이 듦. 차라리 redox 같은 좀 더 실험적인 OS에서 하는 게 더 낫지 않을까 생각임

  • Apple silicon용 gpu 드라이버가 rust로 작성됐고, 작성자 본인이 C로 개발했으면 훨씬 어렵다고 말함. 아직 upstream엔 안 올랐지만, "복잡한 커널 드라이버를 새로 만들다보면 race condition, memory leak, use-after-free 등 온갖 문제가 터지기 마련인데, rust로 짜니까 그런 문제는 거의 없이 안정적으로 동작함. 안전성 기능 덕분에 드라이버가 thread-safe하고 memory-safe하다는 확신이 들고, 설계 자체가 자연스럽게 좋은 방향으로 흘러감. 이게 rust의 마법이라고 생각함"라고 밝힘. 작성자의 경험담 링크 그리고 이런 실험을 커널 트리에서 해도 되냐는 질문에 Torvalds는 동의하지 않는다고 언급함

  • "android binder rust 리라이트가 남아만 있다"는 의견은 사실이 아님. 이 프로젝트는 현재 C 구현을 완전히 대체할 계획임. 관련 기사 M 시리즈 Apple 하드웨어 용 주요 드라이버들도 rust로 작성됐고, 단순 리라이팅이나 proof of concept 가 아님

  • 복잡한 드라이버를 만들려면 그 전에 인터페이스 계층이 필요함. RfL 프로젝트는 그런 인프라 계층을 upstream에 추가하는 작업을 하고 있고, 그 기초가 쌓여야 복잡한 드라이버도 작성 가능함. Redhat에서는 nova, asahi에서는 apple GPU, collabora에서는 ARM Mali용으로 작업 중임. GPU 드라이버 세 개도 복잡한 드라이버가 아니라고 하면 뭐가 복잡한 드라이버인지 의문임

  • rust binder 리라이트가 남아만 있다는 주장에 대해, Linus 트리의 커밋 메시지를 보면 완성도가 높은 상태임. Rust binder가 Android Open Source Project의 binder 테스트를 모두 통과했고, 다양한 앱과 기능이 별다른 문제 없이 동작함. cuttlefish 에뮬레이터와 Pixel 6 Pro에서도 부팅 및 앱 실행에 문제가 없음. 현재 기능도 C binder와 동일하고, 일부 디버깅 기능만 남아 있고 곧 추가될 예정임. 또 rust for linux 프로젝트는 원래 커널 tree 외부에서 출발했지만, 결국 실제 통합을 실험하려면 tree 안에서 실험해봐야 함

  • 이 프로젝트의 목적은 언어 개발 공동 실험이 아니라 linux 커널 개발에 rust를 쓰려는 것이 목적임. 핵심 개발자들이 rust를 쓰고 싶어서 직접 시작한 프로젝트임. 워낙 중요한 소프트웨어라서 신중히 진행 중이고, 기본기를 다지느라 시간이 걸림. rust가 이 프로젝트를 통해 부수적으로 혜택을 얻는 것은 덤임

• <i>field projection 관련 내용에서, 모든 구조체 필드가 이제 구조적으로 pin되어 Pin<&mut Field> 타입 등이 항상 나오도록 결정됐다는 점</i>을 기사에서 봤는데 기존에 이 부분을 놓쳤었음. 기술적으로 복잡한 내용이지만 이 결정이 여러 논의에 발목을 잡던 문제를 풀어서 반가움

• <i>최종 설계는 C++에서 영감을 받아, 값을 heap에 할당하기 위해 새 값을 만들고 즉시 옮길 때 처음부터 heap에 생성되도록 하는 예상 최적화 기법</i>에 대해 사람들이 논의 중임. 여기서 '최적화'라는 이름은 오해 소지가 있어서, 이름 변경 관련 논의가 있음

  • 내가 문제의 복잡도를 제대로 이해하지 못한 걸 수도 있지만, 적당한 calling convention만 정하면 쉽게 해결 가능하지 않나 생각함. 구조체 크기가 x보다 크거나 marker type이 있으면, caller가 outref로 버퍼를 넘기고 callee가 직접 구조체를 그 버퍼에 써주는 방식임. 그렇게 하면 일반적인 코드를 작성해도 힙 할당 중복을 막을 수 있고, 다른 상황에서도 불필요한 복사가 줄어듦. 이미 많은 노력이 들어진 주제라서, 오히려 제안된 해결책들이 왜 더 불편한지 궁금함

  • 이런 기능을 내부 최적화로 처리하지 말고 new 같은 함수로 명확하게 만들면 모두에게 더 직관적일 거라고 생각함

  • C++에서 이런 semantic을 elision이라고 부름

  • 'coalesced heap construction'이나 'coalesced heap allocation' 같은 이름이 어떨지 제안함

• rust의 각종 기능 얘기를 들을 때마다 "tokio를 커널에 넣는 짓만큼은 절대 하지 맙시다"라는 농담을 하게 됨. 만약 rust가 충분히 발전하고 direct composition renderer가 등장해서 커널 전체에서 돌아가는 앱이 가능해지면 그것도 꽤 흥미로운 상황이 될 수 있을 것 같음

  • 커널 내에서 async runtime을 구현하는 건 정말 trivial함. 사실 kernel의 workqueue 자체가 이미 runtime임

  • 농담이 아니라면, rust(그리고 C)로 커널 코드를 짤 때의 구조를 근본적으로 오해하고 있는 것임. 커널에서 코딩할 땐 C stdlib처럼 rust도 no_std로 동작하고, cargo나 crates도 못 씀. tokio를 쓰려면 반은 다시 짜서 socket 등 OS와 인터랙션 전부 커널 방식으로 교체해야 함

• Linux에 들어가는 rust 관련 이번 기능들은 커널에 국한되지 않고 rust 언어에 폭넓게 유용한 첫 기능들이라고 생각함. 커널 중심 기능 개발이 다른 언어/라이브러리 기능 개발을 좀 막았던 듯한 인상임

  • 내가 알기론 systems programming이 rust의 우선 적용 분야임. OS, embedded나 복잡한 C기반 시스템 등에서 interoperability가 핵심임. 이번 기능들은 사실 커널 전용이 아니라 현실 시스템 프로그래밍에 꼭 필요한 일반적 유틸리티처럼 보임

  • 커널/펌웨어 개발을 위한 발전이 여러 군데서 이루어지고 있지만, 모두의 관심사에 항상 오르내리는 건 아님. Philipp이 특히 이 분야에서 큰 변화를 이끌고 있음

  • rust의 주된 역할은 low level 시스템 프로그래밍임. 그 외의 영역은 userspace 컴파일 managed 언어들이 훨씬 더 좋은 선택이고, Self나 Inferno, Android 구조처럼 구성된 시스템에선 이런 low level C 스타일 기능에 집중해도 문제 없다고 생각함

• 이런 기능들은 커널뿐 아니라 다른 영역에도 도움될 만큼 멋진 기능임(특히 generalized projections). Linux가 rust 언어 발전을 이끈다는 점이 매우 만족스러움

• LLM을 활용해서 자동으로 c 코드를 rust로 변환해주는 연구/툴이 있는지 궁금함. LLM에게 chat, usb, i2c, GPU driver 등의 rust 코드를 만들어 빌드/테스트까지 시키는 게 가능할지, 또는 sqlite, apache, nginx 같은 '더 작은' 프로젝트로도 해볼 수 있는지 생각해봄

  • LLM 기반이 아닌 연구로는 실제 사례도 있는 c2rust 프로젝트가 있음. LLM은 기본적으로 approximation에 머물러서 정확하게 못하고, subtle 버그가 너무 많이 나옴. formal method 같은 걸 결합하지 않으면 실용적이지 않음. 단위 테스트만으론 발견 안 되는 문제도 많음. 그리고 '더 작은' 프로젝트로 제시한 예시들도 실제로는 크기가 충분히 작지 않음. 실제 적용 사례 참고 바람

  • Darpa에서도 이런 연구에 관심이 있어서 펀딩에 나섰지만, 아직 결과물이 있는 단계는 아님

[ahwjdekf]

광신의 정렬 (alignment in dogmatism)