systemd는 Rust를 사랑한다

systemd가 Rust 지원을 병합해 개별 바이너리를 C뿐 아니라 Rust로도 작성할 수 있게 됨. 핵심 공유 라이브러리는 당분간 C로 유지함 공통 C 코드를 Rust 크레이트로 감싸는 방식으로 핵심 API를 공유하며, 구현 언어와 관계없이 옵션 처리, 도움말, 오류 메시지의 동작을 동일하게 유지함 Rust 빌드에도 기존 meson을 사용하고 cargo와 Rust 표준 라이브러리는 사용하지 않음. 외부 크레이트 의존성 도입에도 보수적인 정책을 적용함 메모리 할당 실패를 처리하는 자체 할당자 크레이트를 제공하며, 안정적인 C 코드를 단순히 언어를 바꾸기 위해 재작성하지 않음 Rust는 선택 사항으로 남아 기존 기능과 Rust 없는 빌드의 지원을 유지함. 핵심 공유 라이브러리까지 도입하려면 Rust의 공유 라이브러리 지원 문제가 먼저 해결돼야 함 Rust 도입 범위와 공유 라이브러리의 제약 systemd가 Rust 지원을 병합해 개별 바이너리인 말단 구성요소에 Rust를 허용함 기반 공유 라이브러리인 libsystemd-shared.so 자체에 Rust를 도입하는 것은 현재 허용하지 않음 두 영역은 도입 범위와 요구사항이 크게 다름 규모가 크고 오래된 프로젝트에 새로운 핵심 언어를 도입하는 일에는 논쟁이 따름. Linux 커널의 Rust 도입도 같은 과정을 거쳤으며, 지금까지는 대체로 성공적이었음 핵심 구성요소에 Rust를 사용하려면 공유 라이브러리에 대한 일급 지원이 필요함 Rust 커뮤니티에서 흔히 안정적 ABI 문제라고 부르는 오래된 과제와 연결됨 이를 해결하지 않고 도입하면 공유 라이브러리와 다수 바이너리에 Rust 코드가 중복돼 크기가 커짐 systemd는 현재 180개가 넘는 바이너리로 나뉘어 있어 정적 링크가 실용적이지도 바람직하지도 않음 정적 링크는 운영체제의 말단 구성요소에는 적합할 수 있지만, 핵심부에는 다른 요구사항이 있음 허용된 방식에서는 공유 코드를 C로 유지하고 그 기능을 Rust 크레이트로 감싸 Rust 바이너리에서 사용함 C와 Rust 구성요소 모두 동일한 핵심 API를 이용할 수 있음 핵심 API와 사용자 동작의 일관성 Rust 도입에 적용하는 설계 원칙은 핵심 API 접근의 통일을 요구함 systemd 공유 라이브러리의 도우미 함수는 libc나 Rust 크레이트를 넘어서는 기능과 보안을 제공함 대표적인 chase*() 함수군은 코드베이스 전반에서 사용하는 순수 파일 디스크립터(fd...