리눅스 커널에서 하드웨어/소프트웨어 인터페이스가 동작하는 원리

• 결론부터 말하면, 핵심은 메모리임. 유저스페이스 앱 → 커널 드라이버 → 하드웨어 디바이스, 이 3단 스택이 전부임

• 리눅스 커널은 하드웨어 디바이스를 /dev 가상 파일시스템의 파일로 노출함. 유저스페이스에서 open, read, write, mmap 같은 일반 시스콜을 그대로 쓸 수 있고, 디바이스별 특수 기능은 ioctl로 접근함

• 이 파일들을 만드는 건 커널 드라이버인데, 드라이버의 존재 이유는 딱 하나 — 하드웨어를 추상화해서 OS나 유저스페이스가 쓸 수 있게 만드는 것임. I2C, SPI 같은 커널 내부 드라이버 프레임워크 위에 구현됨. /dev 파일에 접근하면 드라이버의 콜백 핸들러가 프로세스 컨텍스트에서 바로 실행됨

드라이버는 하드웨어랑 어떻게 통신하나

• 요즘은 대부분 메모리 매핑 I/O(MMIO) 방식임. 디바이스 하드웨어가 특정 물리 주소에 "나타나는" 거고, CPU의 load/store 명령어로 디바이스가 정의한 "API"를 통해 통신함. 센서 데이터를 읽으려면 물리 주소를 읽기만 하면 되는 거임

• MMIO 말고 다른 주요 인터페이스는 인터럽트임. 폴링 대신 인터럽트 기반 I/O 처리를 하는 건데, 드라이버가 특정 IRQ 번호에 핸들러를 등록하면 커널의 인터럽트 인프라가 호출해줌

• MMIO 쓰는 건 PIC나 Arduino(AVR)에서 하는 베어메탈 프로그래밍이랑 거의 똑같음. 커널 드라이버의 최하위 레벨은 사실상 임베디드 베어메탈 프로그래밍이라는 거임

실제 코드로 보면

• ARM 플랫폼의 UART(시리얼 포트) 드라이버 예시(amba-pl011.c)에서 진짜 마법이 일어나는 부분은 이거임:

  cr = readb(uap->port.membase + UART010_CR);

  디바이스 베이스 주소에 레지스터 오프셋을 더해서 읽는 것 뿐임. UART010_CR은 0x14로 정의된 컨트롤 레지스터임

• 디바이스마다 레지스터가 몇 개에서 수십 개까지 다양함

물리 주소 매핑은 어떻게 구현되나

• 디바이스가 특정 물리 주소에 매핑되는 건 CPU 바깥의 디지털 로직이 담당함. 임베디드 시스템에서는 SoC 위에, PC에서는 마더보드 위에 구현됨

• CPU의 물리 인터페이스는 주소 버스, 데이터 버스, 컨트롤 버스로 구성됨. 주소 버스의 비트를 디지털 로직이 디코딩해서 해당 디바이스를 배타적으로 활성화(enable)함. 컨트롤 버스에서 읽기/쓰기 비트를 설정하고, 데이터 버스로 실제 데이터가 오감

• 실제 구현 문서는 SoC 제조사 고객이 아니면 구하기 어렵지만, Tegra 2 SoC 같은 오래된 칩은 블록 다이어그램이 공개되어 있음. Motorola Atrix 4G 등에 탑재됐던 그 칩임

• 고전적인 PIC 마이크로컨트롤러가 SoC 구조를 이해하기에 훨씬 접근성이 좋음. 하나의 MIPS 코어에 주변 장치들이 페리페럴 버스로 연결된 구조가 한눈에 보임. 심지어 "Peripheral Bridge"를 통해 I2C, SPI 같은 장치들이 두 번째 버스에 붙어있는 계층 구조까지 확인 가능함