Linux가 모든 드라이버를 포함하는 이유는 트리 외부 커널 모듈용 안정적 API가 없기 때문이며, 이런 API를 제공하는 데 마이크로커널이 필수인 것은 아님

마이크로커널도 내부 API의 불안정성을 막아주지는 않으며, 단지 프로세스 간 경계를 넘게 될 뿐임
모든 Linux 드라이버를 사용자 공간으로 옮긴다는 가정에서도 내부 API 변경이 어려워진다는 LKML의 불만을 본 기억이 있음

L4 계열 커널은 빠르다고 알려져 있지 않나 싶음. Redox OS나 Fuchsia는 어떤지도 궁금함

L4 커널은 빠를 수 있지만, 실제로는 구성이 매우 고정적인 임베디드 시스템에서나 쓸 만함 Genode는 여러 커널을 지원하지만 seL4 등에서는 우스울 정도로 성능이 나쁨. 동료들이 Linux VM을 부팅해 봤을 때 32비트만 지원됐고, 절반쯤 부팅하는 데도 수분이 걸렸음 NOVA microhypervisor의 Genode 포크가 기본 플랫폼인 데는 실제로 동작하고 성능도 충분하다는 이유가 있음

Redox 문서를 보면 요청 메시지를 조립할 때 여전히 문맥 교환을 수행하며, 아마 검증 단계로 보임
순환 버퍼를 사용하므로 수신자가 다른 코어에서 이미 실행 중이라면 두 번째 문맥 교환은 필요 없을 수도 있음. 문맥 교환 없이 메시지를 해석하면 수신자가 메시지를 검증해야 해서 공격 표면이 지나치게 커질 수 있지만, 커널 제공 동적 라이브러리로 완화할 여지는 있어 보임
전문가는 아니지만 원문이 몇 가지 중요한 고려 사항을 빠뜨린 느낌

QNX는 빠른 마이크로커널로 알려졌는데, 무엇을 제대로 한 것인지 궁금함

직접 써본 QNX는 빠르지 않았음
예전에 친구와 마이크로커널, 특히 QNX의 우아함에 매료돼 FireWire 기반 영상 처리 문제를 구현했음. 코드는 단순하고 멋졌지만 처참하게 느렸음. 당시 Linux용 1394 드라이버에 DMA 기반 등시성 전송 지원을 약 12시간 만에 추가하자 성능이 크게 개선됐고, 이 일을 계기로 회사의 광학 선별 장비에 Linux를 쓰는 데 대한 회의론도 사라졌음
QNX와 마이크로커널, 메시지 전달의 이상은 여전히 훌륭하지만 널리 자리 잡으려면 프로세스 간 데이터 전달 비용을 훨씬 낮춰야 함
지금은 Elixir로 웹 애플리케이션을 만들며 QNX가 내세운 것과 같은 프로세스 격리를 누리고 있음. 광학 처리처럼 성능이 중요한 작업이 아니어서 괜찮지만, Elixir/BEAM도 데이터 복사 문제는 동일함

Mach가 원래 구상만큼 구성 요소를 완전히 독립시키지는 못했더라도 평범한 모놀리식 커널이 된 것은 아니며, 그 아키텍처가 여전히 주는 이점이 있다고 들었음
고전적인 POSIX 파일 목록 벤치마크처럼 모든 항목에 readdir()와 stat()을 호출하면 마이크로커널이 불리할 수밖에 없음. 하지만 io_uring 같은 일괄 처리 API를 사용해 시스템 호출 빈도를 낮추면 높은 지연 시간이 큰 약점이 아닐 수도 있음

Liedtke의 “on μ-Kernel Construction”, 1995는 Mach가 느린 원인을 큰 캐시 사용량, 즉 충분히 작지 않았던 설계에서 찾았음
Linux도 네트워크 패킷마다 시스템 호출을 한 번씩 하면 회선 속도를 따라갈 수 없음. 일괄 처리는 Linux와 마이크로커널 모두에서 중요함