18.3 uORB 코어 매니저 및 OS(NuttX/POSIX) VFS 통합 구현체

지금까지 18.2절을 통해 통신의 대상이 되는 “메시지(명사)” 들이 파이프라인을 거쳐 완벽한 메모리 레이아웃을 갖춘 C++ 객체와 메타데이터로 형태를 갖추는 과정을 살펴보았다. 이번 18.3절부터는 이 메시지들을 싣고 나르는 런타임 통신망, 즉 시스템의 “동사“를 담당하는 uORB 코어 매니저(Core Manager) 의 심부 구조를 파헤친다.

uORB(Micro Object Request Broker) 코어는 단순히 여러 모듈 사이에서 데이터를 이리저리 옮겨주는 단순한 큐(Queue) 집합체가 아니다. PX4 아키텍트들은 “모든 것은 파일이다(Everything is a file)“라는 유닉스(UNIX)의 철학을 계승하여, uORB를 하부 운영체제(주로 NuttX RTOS, 혹은 SITL을 위한 Linux/macOS 등 POSIX 호환 OS)의 가상 파일 시스템(VFS, Virtual File System) 깊숙이 통합하는 대담한 설계를 채택했다.

이러한 VFS 기반 통합 구현체 설계가 지니는 아키텍처적 의의와 이어지는 하위 절들의 학습 흐름은 다음과 같다.

1. uORB 코어의 VFS 통합 철학

비행 제어 시스템에서는 수백 개의 태스크(Thread)와 인터럽트(ISR)들이 동시다발적으로 데이터를 쏟아내고 읽어 들인다. 이 혼미한 환경에서 데이터 레이스(Data Race)를 막고 동기화를 맞추려면 극도로 정교한 락(Lock) 메커니즘과 이벤트 알림 시스템이 필요하다.

PX4 설계자들은 이 복잡한 병렬 처리 시스템을 바닥부터 새로 작성하는 대신, 수십 년간 검증된 운영체제 커널(Kernel)의 VFS 인프라에 통신 스택을 기생(Piggyback)시키는 방법을 택했다.

• 토픽의 파일화(Device Node): 발행자(Publisher)가 특정 토픽을 개설하면, uORB 매니저는 RAM 상의 메모리 블록을 할당하는 동시에 VFS 트리의 /obj 경로 하위에 해당 토픽 이름으로 장치 노드(예: /obj/sensor_gyro0, /obj/vehicle_gps_position0)를 동적으로 장착(Mount)시킨다.
• 표준 POSIX API의 활용: 구독자(Subscriber)와 발행자는 고유한 통신 API 대신 open(), read(), write(), ioctl()과 같은 완전히 표준화된 파일 입출력 함수를 통해 장치 노드에 접근한다.
• OS 커널 수준의 동기화: 메시지가 도착했을 때 구독자 태스크를 깨우는 임무는 uORB 코어가 직접 수행하지 않는다. 운영체제 커널이 제공하는 범용 poll() 혹은 select() 시스템 콜(System Call)을 이용함으로써, 커널 스케줄러 레벨에서 가장 빠르고 안전하게 이벤트를 구동시킨다 (18.6절에서 상술).

요약하자면, uORB 코어 매니저는 복잡한 통신 로직을 직접 구현한 거대한 괴물이 아니라, C++ struct와 운영체제 파일 시스템 사이를 가볍고 영리하게 연결짓는 심리스(Seamless) 어댑터 브릿지에 가깝다.

이어지는 18.3.x 하위 절들에서는 이 거대한 단일 브릿지(Singleton)가 부팅 시점에 어떻게 초기화되고(18.3.1절), 구체적으로 어떤 VFS 인터페이스 메커니즘을 통해 장치(Device Node)로 등록되며 토픽의 트래픽을 관장하는지 깊이 있게 탐구해 나갈 것이다.