QNX RTOS: 1-8. OS Service

앞서 QNX가 마이크로커널임을 강조했는데, 이는 곧 시스템 서비스의 대부분이 커널 내부가 아닌 사용자 영역의 프로세스(Process)로 동작한다는 것을 의미함.

전통적인 모놀리식 커널(Monolithic Kernel)에서는 파일 시스템이나 네트워킹 스택이 커널의 일부로 컴파일되어 돌아가지만, QNX는 다름. 드라이버, 파일 시스템, 유틸리티 등이 모두 개별 프로세스로 분리되어 있음.

1. "Pay for what you use" 철학

이 구조의 가장 큰 장점은 필요한 것만 실행한다는 점임.

• 선택적 실행: 특정 기능(서비스)이 필요하면 해당 프로세스를 실행하면 됨. 반대로 필요 없으면 실행하지 않으면 됨.
• 리소스 최적화: 사용하지 않는 서비스의 코드와 데이터가 메모리를 점유하지 않으므로 오버헤드를 줄일 수 있음.
• 동적 구성: 시스템이 돌아가는 도중에도 서비스를 추가하거나 제거할 수 있음.

2. 실전 예제: Pipe 서비스 죽이기 실험

영상에서는 이 개념을 증명하기 위해 유닉스/리눅스 시스템에서 흔히 쓰는 파이프(|) 기능을 예로 듦.

2.1. Pipe의 동작

보통 셸에서 pidin | less 처럼 파이프를 쓰면 앞 프로그램의 출력을 뒤 프로그램의 입력으로 넘겨줌. QNX에서 이 기능은 커널이 제공하는 게 아니라, pipe라는 시스템 서비스 프로세스가 담당함.

2.2. 실험 과정

1. pidin으로 프로세스 목록을 보면 pipe라는 프로세스가 실행 중인 것을 확인할 수 있음.

 

2. kill 명령어로 이 pipe 프로세스를 강제 종료시킴.

 

3. 다시 pidin | less 명령을 입력하면? 파이프를 생성할 수 없어 명령이 실패함.

 

4. 하지만 시스템은 죽지 않음. 단지 파이프 기능만 사라진 것임.

 

5. 다시 pipe 프로그램을 실행함.

6. 이제 파이프 기능이 복구되어 명령어가 정상 작동함. (새로 실행했으므로 PID는 변경됨)

 

2.3. 시사점

임베디드 장비가 최종 배포되어 쉘 접근이 필요 없는 상황이라면 pipe 프로세스를 뺴버려서 메모리를 아낄 수 있음. 반대로 디버깅이 필요할 때만 동적으로 띄워서 쓸 수도 있다는 뜻임.

3. 프로세스로 구현된 주요 OS 서비스들

QNX에서는 우리가 흔히 OS의 기능이라고 생각하는 것들이 대부분 독립된 프로세스로 존재함.

• Random: /dev/random 같은 난수 생성 기능도 random이라는 프로세스가 제공함.
• Message Queues: POSIX 메시지 큐 기능도 mqueue 프로세스가 담당함.
• File Systems: 플래시 메모리(NAND, NOR), 회전형 미디어 등을 다루는 것도 각각의 파일 시스템 프로세스(fs-*)가 처리함.
• Networking: TCP/IP 스택은 io-sock이라는 프로세스가 제공함. (SDV에서 이더넷 통신할 때 핵심이 되는 부분임)
• Bus Management: PCI 버스, USB 버스 관리도 서버 프로세스가 담당함.
• Core Dumper: 프로그램이 죽을 때 코어 덤프(Core Dump)를 남기는 기능조차 dumper라는 프로세스임.
  • 만약 코어 덤프 생성으로 인한 지연시간(Latency)이 안전 요구사항을 위반한다면? 그냥 dumper 프로세스를 실행 안 하면 됨.

---

💡 정리 및 인사이트

1. 마이크로커널의 진수: QNX의 시스템 서비스는 커널 코드가 아니라 언제든 켜고 끌 수 있는 프로세스임.
2. 경량화와 최적화: SDV나 임베디드 시스템 설계 시, 불필요한 서비스(예: 디버깅용 파이프, 코어 덤퍼)를 제외하여 부팅 속도를 높이고 메모리를 확보할 수 있음.
3. 장애 격리: 만약 네트워킹 스택(io-sock)에 버그가 있어 죽더라도, 커널 패닉이 발생하는 게 아니라 그냥 네트워크 기능만 잠시 멈출 뿐임. 워치독(Watchdog)이 해당 프로세스만 다시 살리면 시스템은 계속 유지됨. 이는 자율주행이나 차량 제어 시스템의 가용성(Availability) 측면에서 매우 유리한 구조임.