QNX RTOS: 1-6. System Library

QNX 시스템 라이브러리는 크게 두 가지로 구성됨. 하나는 QNX 특화 함수들이고, 다른 하나는 POSIX나 Unix 표준을 따르는 함수들임. 이들이 내부적으로 어떻게 연결되어 있고, 왜 표준 함수를 써야 하는지 알아보자.

1. 라이브러리 구조: POSIX와 커널 호출의 연결

대부분의 표준 라이브러리 함수들은 QNX의 커널 호출(Kernel Call) 위에 얹혀진 얇은 레이어(Thin Layer) 형태로 구현됨.

• 역할: 주로 인자(Argument)의 포맷을 변환하거나, 여러 표준 함수를 하나의 강력한 커널 호출로 매핑하는 역할을 함.
• 예시: timer_settime()
  • 이것은 POSIX 표준 함수임.
  • 내부적으로 QNX 커널 호출인 TimerSettime()을 호출함. (QNX 커널 호출은 대소문자가 섞인 CamelCase 등을 주로 사용함)
  • 이 과정에서 라이브러리는 POSIX 방식의 시간(초 + 나노초)을 커널이 사용하는 64비트 나노초 단위로 변환해서 넘겨줌.

2. 권장 사항: "표준 함수(POSIX)를 사용하라"

QNX는 마이크로커널 특화 기능을 많이 제공하지만, 가능하다면 직접적인 커널 호출보다는 **표준 함수(Portable Function)**를 사용할 것을 강력히 권장함.

이유 1: 이식성 (Portability)

• 코드가 리눅스나 다른 유닉스 시스템에서도 동작할 수 있음.
• 개발 단계에서 리눅스 머신에서 로직을 테스트하고, 타겟인 QNX 보드에 올리는 식의 교차 개발이 용이해짐.
• 타 OS의 코드를 QNX로 포팅하거나 그 반대의 경우에도 유리함.

이유 2: 가독성 및 유지보수 (Maintainability)

• 이것이 더 중요한 이유일 수 있음.
• read(), open() 같은 함수는 모든 C 개발자가 아는 "공용어"임.
• QNX 전용 커널 호출을 사용하면, 동료 개발자나 코드 리뷰어가 해당 함수의 스펙을 일일이 찾아봐야 함.
• 표준 함수를 쓰면 코드의 의도가 명확해지고 리뷰와 유지보수가 쉬워짐.

3. 마이크로커널에서의 동작 방식: System Call vs Message Passing

일반적인 모놀리식 커널(Monolithic Kernel) OS와 QNX의 가장 큰 차이점이 여기서 드러남.

• 전통적인 OS: read(), open() 등을 호출하면 커널 내부로 진입하는 시스템 호출(System Call)이 발생함.
• QNX (마이크로커널): 이 함수들은 **메시지 전송(Message Passing)**으로 변환됨.

동작 메커니즘

1. 사용자가 read(), fork(), posix_spawn() 같은 표준 함수를 호출함.
2. 라이브러리(Cover Function)는 QNX 메시지 패싱 포맷에 맞게 메시지를 생성(Build)함.
3. 생성된 메시지를 MsgSend() 계열 함수를 통해 적절한 서버로 전송함.
   • read() -> 파일 시스템이나 드라이버를 담당하는 Resource Manager에게 메시지 전송.
   • fork() -> 프로세스 생성을 담당하는 Process Manager에게 메시지 전송.

4. 결론: 바퀴를 다시 발명하지 말 것

read()나 fork()가 내부적으로 결국 메시지를 만들어 보낸다는 사실을 알았다고 해서, 개발자가 직접 메시지를 조립해서 보낼 필요는 없음. (오히려 권장하지 않음)

• 직접 메시지를 구성하면 실수할 확률이 높고 코드가 복잡해짐.
• 이미 검증되고 최적화된 표준 래퍼(Wrapper) 함수를 사용하는 것이 가장 안전하고 효율적인 방법임.