18.3.2.1 /obj 루트 가상 디렉토리 마운트 및 파일 시스템 네임스페이스 격리
uORB가 토픽을 VFS 상의 문자 디바이스 노드로 변환한다는 원리를 이해했다면, 다음으로 던져야 할 질문은 “그렇다면 이 가짜 디바이스 파일들은 OS의 어디에 저장되는가?” 이다.
리눅스나 NuttX와 같은 유닉스 계열 운영체제는 물리적인 하드웨어 장치(UART, I2C, SPI 등)를 사용자 공간(User Space)에 노출시키기 위해 전통적으로 /dev 디렉토리를 사용한다 (예: /dev/ttyS0). 만약 uORB가 자신이 만들어낸 소프트웨어 토픽 노드들마저 /dev 폴더에 마구잡이로 등록한다면, 실제 물리적 드라이버와 가상 미들웨어 토픽 간의 네임스페이스(Namespace) 충돌이 일어나 시스템의 복잡도가 걷잡을 수 없이 높아질 것이다.
1. /obj 네임스페이스의 신설과 격리(Isolation)
PX4 설계자들은 이 문제를 근본적으로 차단하기 위해, VFS 트리 상에 /obj (Object의 약자) 라는 완전히 새로운 독립적 네임스페이스를 신설하여 격리하는 방식을 택했다.
18.3.1.1절에서 다루었던 uORB::Manager::initialize() 초기화 과정의 가장 첫 번째 줄에는 물리적 하드웨어의 마운트가 아닌, 다음과 같은 가상 디렉토리 마운트 로직이 숨겨져 있다.
- VFS 루트(
/) 아래에/obj라는 논리적인 폴더 노드가 생성된다. - 이 경로는 SD 카드나 플래시 메모리(ROM) 같은 비휘발성 저장 매체에 기록되는 실제 파일이 아니다. 커널의 메모리 힙(Heap) 어딘가에 존재하는 논리적 매핑일 뿐이며, 기체의 전원이 차단되면 흔적도 없이 사라진다 (TMPFS와 유사한 개념).
2. 자동 경로 접두사(Prefix) 변환 및 인스턴스 맵핑
이제 비행 제어기 프로그래머가 코드 상에서 다음과 같이 특정 토픽을 구독하려 한다고 가정해 보자.
// 개발자는 경로를 모른 채 그저 토픽 이름만 넘긴다.
int fd = orb_subscribe(ORB_ID(vehicle_gps_position));
uORB 내부 핵심 엔진은 ORB_ID 매크로를 통해 넘겨받은 메타데이터(18.2.3.1절의 o_name 즉, "vehicle_gps_position")를 활용해 가상 파일 경로를 동적으로 합성(Synthesis)해 낸다.
- 접두사 결합: 모든 토픽 이름 앞에 강제로
/obj/접두사가 덧붙는다. - 인스턴스 번호 스탬핑: 다중 센서(예: GPS 2대 장착)를 지원하기 위해 경로 맨 끝에 인스턴스 번호가 붙는다 (첫 번째 장치는
0). - 최종 합성: 생성된 문자열 네임스페이스는 최종적으로
/obj/vehicle_gps_position0이 된다.
결과적으로 시스템 관리자 단말기(NuttShell, NSH)에서 ls /obj 명령어를 입력해 보면, 마치 수십 개의 파일이 들어 있는 폴더처럼 /obj/sensor_gyro0, /obj/sensor_mag0, /obj/vehicle_status0 등의 리스트가 눈앞에 펼쳐지게 된다.
이처럼 철저하게 격리된 /obj 네임스페이스 정책 덕분에, PX4는 수백 개의 VFS 디바이스 노드를 보유하고도 코어 파일 시스템의 무결성을 완벽하게 지켜내며 우아한 파일 입출력 라우팅을 수행할 수 있다.