QNX RTOS: 1-5. Resource Managers

QNX에서 Resource Manager란 "OS의 일부처럼 동작하는 사용자 프로그램"을 말함. 기술적으로는 그냥 프로세스일 뿐이지만, 파일 시스템의 경로(Pathname Space) 일부를 점유하고 POSIX 표준 인터페이스를 제공함으로써, 마치 운영체제의 커널 서비스인 척 동작함.

1. 정체: Pathname Space의 지배자

Resource Manager는 /(루트)로 시작하는 경로 공간의 특정 지점을 차지함.

• 단일 이름 점유: /dev/ser1 (시리얼 포트)
• 그룹 이름 점유: /dev/con1, /dev/con2 (콘솔 그룹)
• 트리 전체 점유: /sdcard 하위의 모든 파일 및 디렉토리 (파일 시스템)

이렇게 경로를 점유한 뒤, 애플리케이션(Client)에게는 POSIX 인터페이스(open, read, write, lseek 등)를 제공함. 즉, 클라이언트 입장에서는 자신이 접근하는 대상이 하드웨어인지, 가상의 소프트웨어인지, 네트워크 너머의 객체인지 알 필요 없이, 그냥 open()하고 read/write()하면 됨.

• 하드웨어 제어: 시리얼, CAN, 네트워크 카드 드라이버 등 대부분의 QNX 드라이버는 Resource Manager 형태로 구현됨.
• 소프트웨어 서비스: /dev/mqueue(메시지 큐), 시스템 로그, 코어 덤프 핸들러 등.

2. 동작 원리: open() 호출의 여정

클라이언트가 open("/dev/ser1", ...)을 호출했을 때 내부에서 어떤 일이 일어나는지 이해하는 것이 핵심임. 이 과정은 초기 연결 비용은 들지만, 이후 통신 효율을 극대화하는 구조임.

2.1. Process Manager 조회 (Lookup)

1. 클라이언트가 open()을 호출하면 라이브러리는 먼저 Process Manager에게 메시지를 보냄.
2. "이 경로(/dev/ser1)를 누가 담당하고 있냐?"라고 물어봄.
3. Process Manager는 해당 경로를 등록한 Resource Manager의 정보(Process ID, Channel ID)를 알려줌.

2.2. 연결 생성 (Connect)

1. 클라이언트 라이브러리는 획득한 정보를 바탕으로 실제 Resource Manager에게 연결을 시도함(CoID 생성).
2. Resource Manager에게 "내가 너를 어떤 권한(Read/Write)으로 열고 싶다"는 메시지를 보냄.

2.3. 인증 및 완료 (Authentication)

1. Resource Manager는 커널에 "이 요청을 보낸 놈이 누구냐"를 확인하고 권한을 검사함.
2. 하드웨어 상태나 권한에 문제가 없다면 "성공"을 응답함.
3. 클라이언트 라이브러리는 최종적으로 파일 디스크립터(File Descriptor, FD)를 반환함.

 

3. I/O 처리: 직접 메시지 패싱

open() 과정은 Process Manager를 거치느라 단계가 복잡하지만, 한번 FD를 얻고 나면 그 뒤는 아주 단순함.

• Direct Communication: read(), write() 등의 호출은 Process Manager를 거치지 않고, 클라이언트와 Resource Manager 간의 직접적인 메시지 패싱(Send/Receive/Reply)으로 처리됨.
• 예를 들어 write()를 호출하면:
  1. 클라이언트가 데이터를 담아 MsgSend를 함.
  2. Resource Manager는 메시지를 받아 내부 버퍼에 넣거나 하드웨어에 씀.
  3. 작업이 끝나면 MsgReply로 "몇 바이트 썼음"이라고 응답함.

이 구조 덕분에 초기 연결 비용(Open)은 조금 비싸지만, 실제 데이터 전송(I/O)은 매우 빠르고 효율적임.

4. 마이크로커널 구조에서의 장점

드라이버를 커널 내부가 아닌 Resource Manager(사용자 프로세스)로 만드는 QNX의 철학은 다음과 같은 강력한 이점을 줌.

1. 복원력(Resilience): 드라이버가 버그로 죽더라도 커널은 죽지 않음. 단순히 해당 프로세스만 다시 실행(Restart)하면 됨. 심지어 이중화(Redundancy)를 구성해 즉각적인 페일오버도 가능함.
2. 디버깅 용이성: 드라이버도 그냥 "앱"임. printf를 쓸 수도 있고, GDB나 IDE를 붙여서 브레이크 포인트를 걸고 변수를 확인하며 디버깅할 수 있음. 리눅스 커널 모듈 디버깅의 고통과 비교하면 천국임.
3. 유연성: 하드웨어가 없어도 가상의 드라이버를 만들어 테스트할 수 있고, 웹 서버 기능을 내장하여 브라우저로 하드웨어 상태를 보게 만드는 등 창의적인 확장이 가능함.

5. 개발: Resource Manager Framework

Resource Manager를 바닥부터(Scratch) 짜려면 수많은 POSIX 메시지 처리를 직접 해야 해서 매우 힘듦. 그래서 QNX는 C 라이브러리 형태로 Resource Manager Framework를 제공함.

• 기본 동작 제공: open, dup, stat 같은 표준적인 처리는 라이브러리가 알아서 해줌.
• 개발자 역할: 개발자는 자신이 관심을 가지는 기능(예: io_read, io_write, io_devctl)만 함수 포인터로 연결해서 구현(Override)하면 됨. 마치 객체지향 언어에서 부모 클래스의 가상 함수만 재정의하는 것과 비슷함.

---

💡 요약 및 인사이트

1. Resource Manager는 QNX에서 드라이버와 시스템 서비스를 구현하는 표준 방법임.
2. open() 시에만 Process Manager의 도움을 받아 경로를 찾고, 이후에는 1:1 메시지 통신을 함.
3. 사용자 영역에서 돌기 때문에 죽어도 시스템 전체가 셧다운되지 않으며, 일반 앱처럼 디버깅이 가능함.
4. 개발자는 Framework를 이용해 필요한 I/O 핸들러만 구현하면 됨.