2025. 11. 25. 16:19ㆍ운영체제/QNX
1. Process Manager의 정체와 통신 방식
- 구성: procnto는 proc(Process Manager)와 nto(Neutrino Microkernel)로 이루어져 있음.
- 위치: 두 컴포넌트는 커널의 동일한 주소 공간을 공유함.
- 통신 메커니즘:
- 애플리케이션은 메시지 패싱(Message Passing)을 통해 Process Manager와 통신함.
- 흔히 쓰는 C API(예: open(), fork())는 내부적으로 Process Manager에게 보내는 메시지로 변환되어 처리됨.
2. 핵심 역할 I: 프로세스 및 스레드 관리 (Lifecycle)
Process Manager의 가장 기본적인 역할은 프로세스의 탄생부터 죽음까지를 관장하는 것임.
- 패키징: 프로세스 내의 모든 스레드를 하나로 묶어 관리함.
- 생명주기 관리:
- 프로세스 생성 (spawn, fork, exec)
- 디스크나 플래시 메모리로부터 로딩
- 프로세스 종료 및 정리
- 메모리 보호: 프로세스 생성 시, 해당 프로세스만이 사용할 수 있는 고유한 가상 주소 공간(Virtual Address Space)을 할당하고 보호함.

3. 핵심 역할 II: 메모리 관리 (Memory Management)
QNX에서 메모리 관리는 가상 주소(Virtual Address) 모델을 따름. Process Manager는 물리 메모리를 추상화하여 각 프로세스에게 "자신만의 메모리 공간"을 제공함.
3.1. 가상 주소 공간 (Virtual Address Space)
- Process View: 각 프로세스는 시스템 전체 메모리가 아닌, 자신에게 할당된 가상 메모리만을 볼 수 있음.
- 구성 요소:
- 프로세스 전용 메모리 (Code, Data, Stack)
- 공유 메모리 (Shared Memory)
- 커널 관리 영역
- 단편화 해결: 물리 메모리(Physical Memory)가 실제로는 조각나 있더라도(Fragmented), Process Manager는 이를 연결하여 프로세스에게는 연속된(Contiguous) 가상 메모리 블록처럼 보이게 만듦.
3.2. 하드웨어 접근과 mmap()
임베디드 시스템 개발 시 가장 중요한 부분임. 특정 하드웨어 레지스터에 접근하려면 물리 주소가 필요함.
- 문제: 애플리케이션은 물리 주소에 직접 접근할 수 없음.
- 해결: mmap() 함수를 호출하여 Process Manager에게 요청함.
- 동작: Process Manager는 물리 주소(하드웨어 위치)를 프로세스의 가상 주소 공간에 매핑하고, 그 포인터를 반환해 줌.
3.3. 커널 공간의 분리
- User Space: 하위 주소 영역 (예: 512GB 미만).
- Kernel Space: 상위 주소 영역. 커널과 마이크로커널이 상주함.
- 장점: 애플리케이션이 커널 호출(Kernel Call)을 할 때, MMU 테이블을 완전히 교체할 필요 없이 권한(Privilege)만 스위칭하면 되므로 컨텍스트 스위칭 속도가 매우 빠름.

4. 핵심 역할 III: 경로 이름 공간 관리 (Pathname Space Management)
QNX가 다른 OS(Linux, Windows)와 차별화되는 가장 큰 특징은 Pathname Management 방식임.
4.1. 모든 것은 경로로 통한다
Process Manager는 시스템의 루트 디렉토리(/)를 포함한 전체 경로 공간(Pathname Space)을 총괄함.
- /proc: 현재 실행 중인 프로세스 정보를 보여주는 가상 파일 시스템.
- /dev/shmem: 공유 메모리 객체들.
- /dev/sem: 세마포어 객체들.
이러한 경로들은 실제 디스크에 있는 파일이 아니라, Process Manager가 제공하는 가상 자원(Pseudo Files)에 대한 뷰(View)임.

4.2. 경로 해석 우선순위 (Resolution Logic)
Process Manager는 경로 요청이 들어왔을 때, 가장 구체적인(Most Granular) 이름을 가진 관리자에게 요청을 연결함. (Longest Prefix Match 방식)
[예시 시나리오] 시스템에 다음과 같은 리소스 매니저들이 등록되어 있다고 가정함.
- procnto (Process Manager): / (루트 소유)
- devc-con (Console Driver): /dev/con1
- devb-eide (Disk Driver): / (루트 마운트 포인트)
[요청 처리 과정]
- Case A: 사용자가 /dev/con1을 open() 요청
- Process Manager는 등록된 목록 중 가장 길게 일치하는 devc-con에게 연결함.
- Case B: 사용자가 /etc/usr/file.txt를 open() 요청
- /dev/con1이나 다른 특수 드라이버와 일치하지 않음.
- 결국 가장 기본이 되는 devb-eide(디스크 드라이버)로 요청이 전달됨.

4.3. 통합된 뷰 (Unified View)
결과적으로 사용자가 ls 명령어를 치면, 프로세스 정보(/proc), 하드웨어 디바이스(/dev/ser1), 그리고 실제 디스크 파일(/home/user)이 마치 하나의 파일 시스템 트리에 있는 것처럼 통합되어 보임.
이것이 QNX가 마이크로커널 구조임에도 불구하고, 디바이스 드라이버와 파일 시스템을 유연하게 결합할 수 있는 핵심 원리임.
'운영체제 > QNX' 카테고리의 다른 글
| QNX RTOS: 1-8. OS Service (0) | 2025.11.25 |
|---|---|
| QNX RTOS: 1-7. Shared Objects (0) | 2025.11.25 |
| QNX RTOS: 1-6. System Library (0) | 2025.11.25 |
| QNX RTOS: 1-5. Resource Managers (0) | 2025.11.25 |
| QNX RTOS: 1-3. 스케줄링 (0) | 2025.11.17 |