리눅스 환경에서 write()를 호출하면 과연 어떤 일이 발생할까요? 파일에 문자열을 쓰는 단순한 작업일 수도 있고, 프린터로 문서를 출력하거나 사운드 카드로 오디오 스트림을 보내는 일일 수도 있습니다. 놀랍게도 애플리케이션 입장에서는 이 모든 과정이 open(), read(), write(), ioctl()과 같은 동일한 시스템 콜을 통해 이루어집니다.

어떻게 동일한 시스템 콜이 상황에 따라 디스크 파일이나 키보드, 프린터, 사운드 카드 같은 다양한 물리적 장치와 연결될 수 있을까요? 그 명쾌한 해답이 바로 이번 장의 핵심 주제입니다.

이번 장은 크게 다섯 가지 흐름으로 진행됩니다. 첫째, CPU와 장치가 통신하는 경로인 I/O 아키텍처. 둘째, 수많은 버스와 장치, 드라이버를 체계적으로 관리하는 디바이스 드라이버 모델. 셋째, /dev/hda, /dev/null과 같은 디바이스 파일의 진정한 의미. 넷째, 드라이버의 등록과 초기화, I/O 완료 감시 등의 공통 동작. 마지막으로, 비교적 구조가 명확한 문자 장치 드라이버의 구현 원리입니다.

컴퓨터 내부의 CPU, 메모리, 디스크, 키보드 등이 서로 데이터를 주고받으려면 통신 경로가 필요합니다. 우리는 이를 버스(bus)라고 부릅니다. 하나의 시스템 안에는 PCI, ISA, SCSI, USB 등 다양한 버스가 공존하며, 이들은 브리지(bridge)라는 하드웨어를 통해 유기적으로 연결됩니다.

데이터의 흐름을 따라가 볼까요? CPU가 I/O bus를 통해 I/O port에 접근하면, 그 뒤에 있는 I/O interface가 명령을 해석하고, I/O controller가 최종적으로 물리적인 I/O device를 제어합니다. 즉, CPU가 하드웨어에 직접 명령을 내리는 것이 아니라, 단계적인 계층 구조를 거치며 정교하게 소통하게 됩니다.

CPU가 장치와 대화하는 방식은 크게 두 가지입니다. 하나는 독립적인 I/O 주소 공간의 I/O 포트를 읽고 쓰는 고전적 방식이고, 다른 하나는 장치의 레지스터를 물리적 메모리 주소 공간에 매핑하여 일반 메모리처럼 다루는 memory-mapped I/O 방식입니다. 현대의 고성능 장치들은 속도와 DMA 결합 효율성 측면에서 memory-mapped I/O 방식을 더 선호합니다.

I/O 포트는 CPU가 장치에 명령을 내리거나 상태를 확인할 때 접근하는 주소 창구입니다. IBM PC 아키텍처에서는 최대 65,536개의 8비트 포트 공간을 제공하며, 포트를 2개 묶어 16비트로, 4개를 묶어 32비트 크기로 활용할 수도 있습니다. 단, 버스 정렬 규칙에 따라 16비트 포트는 짝수 주소, 32비트 포트는 4의 배수 주소에서만 시작해야 합니다.

80x86 아키텍처에서는 in, out, ins, outs와 같은 어셈블리 명령어를 통해 포트에 접근하며, 커널은 이를 추상화하여 사용하기 편리한 보조 함수들을 제공합니다.

각 I/O 포트는 다양한 역할의 레지스터로 구성됩니다. control register에는 장치에 내릴 제어 명령을 쓰고, status register에서는 장치의 현재 상태를 읽어옵니다. 또한 input register와 output register를 통해 CPU와 장치가 실제 데이터를 주고받게 됩니다.

드라이버가 포트 할당 상태를 모른 채 임의의 포트에 데이터를 쓰게 되면, 이미 그 포트를 선점하여 통신 중인 다른 장치의 동작을 치명적으로 방해할 수 있습니다. 과거 ISA 버스 시절에는 장치를 탐지하기 위해 의심되는 포트에 무작정 값을 써보는 방식도 쓰였는데, 이는 매우 위험하며 잦은 시스템 크래시를 유발했습니다.

이를 방지하기 위해 커널은 I/O 포트 영역을 resource라는 개념으로 엄격히 관리합니다. resource 구조체는 소유자의 이름, 영역의 시작과 끝 주소, 플래그를 담고 있으며, 부모·자식·형제 포인터를 통해 전체를 트리(Tree) 구조로 추적합니다. 예를 들어, 특정 IDE 인터페이스가 0xf000~0xf00f 대역을 할당받았다면, 그 안을 다시 마스터 디스크와 슬레이브 디스크 영역으로 분할하여 자식 resource로 편입시키는 식입니다.

I/O 포트 리소스 트리의 루트 노드는 ioport_resource이며, 포트 번호 0번부터 65535번까지의 전체 I/O 주소 공간을 아우릅니다. 잘 짜여진 드라이버라면 반드시 자신이 소유할 범위를 명확히 등록하여 잠재적인 충돌을 미연에 방지해야 합니다.

CPU가 I/O 포트에 명령을 내린다고 해서 디스크 헤드나 모터가 즉각적으로 움직이는 것은 아닙니다. 그 사이에는 명령을 적절히 해석해 줄 I/O interface가 존재합니다. I/O 인터페이스는 포트에 쓰인 값을 장치가 온전히 이해할 수 있는 규격화된 명령과 데이터 패킷으로 변환합니다. 또한, 장치의 상태 변화를 감지하여 상태 레지스터(status register)를 갱신하며, 필요할 경우 IRQ 라인을 타고 PIC(Programmable Interrupt Controller)에 인터럽트를 발생시키기도 합니다.

인터페이스 다음 단계에는 device controller가 기다리고 있습니다. 컨트롤러는 인터페이스로부터 전달받은 논리적이고 고수준인 명령을, 실제 물리 하드웨어가 직접 구동될 수 있도록 저수준의 전기적 신호 시퀀스로 변환하는 핵심 역할을 수행합니다. 예를 들어 디스크 컨트롤러는 "디스크의 N번 블록 데이터를 기록하라"는 운영체제의 논리적 지시를 받아들여서, 디스크의 모터를 회전시키고, 헤드를 목표 트랙으로 이동시킨 뒤 자성으로 데이터를 기록하는 고도의 물리적 조작으로 번역해 냅니다. 현대의 고급 컨트롤러들은 자체적인 온보드 캐시를 지니며 요청 순서를 스스로 재정렬(reordering)하여 처리 효율을 극대화하기도 합니다.

더불어, 그래픽 카드의 프레임 버퍼처럼 특정 하드웨어들은 성능 향상을 위해 자체적인 메모리를 보유하고 있는데, 우리는 이를 I/O shared memory라고 부릅니다. 디스플레이에 출력될 픽셀 정보들이 이 전용 메모리 공간에 저장되며 CPU와 주변 장치들이 고속으로 접근할 수 있도록 개방되어 있습니다.

과거의 구형 커널은 드라이버 관리를 위한 공통 인프라가 상당히 부족했습니다. 그러나 PCI나 USB 같은 현대적인 버스 규격이 속속 등장하면서, 디바이스의 전원 관리나 플러그 앤 플레이, 작동 중 장치를 탈착하는 핫플러깅 처리가 운영체제의 매우 중대한 과제로 떠올랐습니다. 예를 들어 배터리로 구동되는 노트북이 대기 모드(Standby)로 진입할 때, 커널은 하드디스크, 그래픽 카드, 네트워크 컨트롤러를 안전하고 올바른 순서대로 저전력 상태로 전환시켜야만 합니다. 이러한 복잡한 공통 문제들을 일관된 아키텍처로 제어하기 위해 Linux 2.6 버전부터 강력한 device driver model이 도입되었습니다.

그리고 이 거대한 모델을 커널 밖 사용자 공간(User Space)에서 들여다볼 수 있게 해주는 특별한 파일시스템이 바로 sysfs입니다. 보통 시스템의 /sys 경로에 마운트됩니다. 흔히 쓰이는 /proc 역시 커널의 내부 정보와 프로세스 상태를 노출하지만, sysfs는 디바이스 드라이버 모델 특유의 방대한 계층 관계를 구조적이고 직관적으로 보여준다는 점에서 분명한 목적의 차이가 있습니다.

sysfs는 단순한 항목 나열을 넘어 객체 간의 입체적인 관계를 심볼릭 링크로 엮어냅니다. 이 디렉터리 안의 일반 파일들은 주로 장치나 드라이버가 가진 세부 attribute(속성)를 의미합니다. 일례로 블록 장치 디렉터리 하위의 dev 속성 파일 안에는 해당 장치의 major/minor 번호 정보가 담겨 있습니다.

sysfs 공간의 디렉터리와 파일 구조는 허공에서 마법처럼 생겨나는 것이 아닙니다. 모든 항목은 커널 내부의 실존하는 핵심 자료구조와 단단히 결합되어 있는데, 그 구조체의 이름이 바로 kobject입니다. 버스 객체, 개별 장치 객체, 혹은 드라이버 객체 등 규모가 큰 커널 구조체 내부에 이 조그만 kobject를 삽입(embedding)하게 되면, 해당 부모 객체는 즉시 세 가지의 막강한 기능을 자동으로 획득하게 됩니다. 첫째, 메모리 누수를 막는 체계적인 참조 카운터 관리. 둘째, 복잡하게 얽힌 계층적 리스트 및 집합에의 편입. 셋째, sysfs 파일시스템을 통해 사용자 공간으로 내부 속성을 매끄럽게 노출하는 능력입니다.

kset은 비슷한 성격을 공유하는 kobject들을 한데 묶어 관리하는 컨테이너입니다. 여기서 흥미로운 커널의 설계 철학을 볼 수 있는데, kset 구조체 역시 그 내부에 자신만의 kobject 필드를 품고 있습니다. 덕분에 kset 집합 그 자체도 sysfs의 계층 구조 속 디렉터리로 당당히 승격될 수 있으며, kobject가 제공하는 참조 카운팅 메커니즘을 동일하게 재사용합니다. 한 단계 더 나아가 subsystem은 이런 kset들을 모아 둔 더 거대한 상위 단위이며, 주로 내부적인 읽기/쓰기 세마포어(semaphore)를 포함하여 동시성 제어까지 담당합니다.

Figure 13-3의 흐름도를 참고하여 /sys/bus/pci/drivers/serial/new-id라는 경로를 해체해 보면, 이는 subsystem 객체 안에 kset이 있고, 그 아래 kobject를 거쳐 최종적으로 attribute 파일에 도달하는 완벽한 객체 지향적 계층 결합임을 깨달을 수 있습니다.

복잡한 디바이스 드라이버 모델을 지탱하는 본질적인 핵심 객체는 네 가지로 요약됩니다. 이 네 요소는 "어떤 하드웨어 장치가 어느 물리 버스에 물려 있고, 어떤 드라이버 소프트웨어가 이를 통제하며, 최종적으로 사용자 애플리케이션에는 어떠한 논리적 장치로 보이는가"라는 질문에 완벽하게 답해 줍니다.

여기서 중요한 점은 device_driver 안의 probe 메서드가 하는 역할입니다. 이 메서드는 커널이 새로운 장치를 발견했을 때 "이 하드웨어를 이 드라이버가 제어할 수 있는가?"를 최종 확인하고 초기화할 때 호출됩니다. 반대로 remove 메서드는 작동 중이던 USB 등을 뽑는 핫플러깅 제거나 드라이버 모듈이 언로드될 때 호출되어 자원을 회수합니다. 즉, 여기서의 드라이버 객체는 단순한 연산 함수의 모음이 아니라 장치의 물리적 발견, 제거, 전원 상태 전환 등을 동적으로 제어하는 고차원적 생명주기 관리자입니다.

유닉스 계열 운영체제를 관통하는 가장 강력한 철학 중 하나는 "모든 것을 파일로 다룬다"는 개념입니다. 바로 이 디바이스 파일(device file)이 커널 내부의 복잡한 물리 I/O 장치를 외부에 일관된 형태의 특수 파일로 추상화시킨 결과물입니다. 애플리케이션 개발자는 디스크든 사운드 카드든 그저 open(), read(), write()라는 익숙한 방식을 사용해 접근하면 됩니다. 예를 들어 /dev/lp0라는 파일 경로에 텍스트 데이터를 쓰게 되면 그 데이터는 고스란히 실제 물리 프린터의 출력으로 이어집니다.

일반 파일 시스템의 파일들과 달리 디바이스 파일의 inode 정보 속에는 디스크 데이터 블록의 물리적 위치값이 들어있지 않습니다. 그 대신, 이 파일이 어떤 하드웨어와 매핑될지를 결정짓는 결정적 단서인 major/minor 번호 쌍이 기록되어 있습니다. 이러한 특수 디바이스 파일은 mknod() 시스템 콜을 통해 생성 가능하며, 놀랍게도 커널 입장에서는 파일의 문자열 이름 그 자체는 아무런 본질적 의미를 지니지 않습니다. 극단적으로 /tmp/my_disk라는 생뚱맞은 이름으로 파일을 만들더라도, 내부에 기록된 major/minor 번호 조합만 디스크 장치 번호와 일치한다면 완벽하게 디스크 장치로 기능합니다.

과거 리눅스 커널에서는 major 번호와 minor 번호가 각각 8비트 크기로 제한되어 있어 표현 가능한 장치의 수용량에 명백한 한계가 존재했습니다. 하지만 Linux 2.6 커널에 접어들며 체계가 대폭 개편되었고, 현재는 major 12비트, minor 20비트로 공간이 확장되어 총 32비트 크기의 dev_t라는 타입 안에 안전하게 인코딩됩니다. 코드 레벨에서는 MAJOR 매크로를 통해 major 번호만을 추출하고, MINOR 매크로로 minor 번호만을 꺼내며, MKDEV 매크로를 조합해 이 두 값을 합쳐 dev_t 값을 완성해 냅니다.

오늘날 시스템 디자인에서 가장 선호되는 흐름은 동적 장치 번호 할당 기법과, 이에 연계된 동적 디바이스 파일 생성 모델입니다. 새로운 디바이스 드라이버가 커널에 진입하며 등록을 시도할 때, "아직 아무도 쓰지 않는 적당한 빈 번호를 임의로 주세요"라고 커널에 요청하면 커널 자원 관리자가 즉석에서 가용한 번호 대역을 배분해 줍니다. 이 획기적인 방식 덕분에 전 세계의 수많은 새 드라이버 개발자들이 고정된 공식 major 번호를 획득하기 위해 중앙 관리 기관의 승인을 하염없이 기다릴 필요가 완전히 사라졌습니다.

현대 PC 환경에서는 부팅이 한참 지난 후에도 장치가 수시로 추가되거나 제거될 수 있습니다. 운영 중인 서버에 USB 저장 장치를 갑자기 꽂거나 새로운 드라이버 커널 모듈(ko)을 동적으로 적재하는 상황이 그 예입니다. 커널은 이러한 핫플러깅(Hotplugging) 하드웨어 이벤트를 민감하게 감지하여 내부 처리를 거친 후 /sbin/hotplug 헬퍼 스크립트를 호출합니다. 그리고 앞서 설명한 udev 데몬 시스템이 이 전체 흐름의 중심에 서서 사용자 공간의 상황에 꼭 들어맞는 /dev 파일들을 마법처럼 즉각 생성하고 파기하는 동적인 대응을 수행합니다.

애플리케이션이 디바이스 파일을 open()하는 순간, VFS의 정교한 라우팅이 시작됩니다. 파일시스템이 디스크상의 inode 정보를 파싱하다가 "아, 이것은 일반 파일이 아니라 특수 목적의 디바이스 파일이구나"라고 판별하는 순간, 은밀하게 내부 함수인 init_special_inode()를 호출해 냅니다. 이 함수가 수행하는 일은 몹시 핵심적입니다. 우선 inode 구조체 내부의 i_rdev 필드에 하드웨어 매핑의 열쇠인 major/minor 번호를 꼼꼼히 기록해 넣습니다. 그리고 가장 결정적으로, 파일 조작 함수들의 진입점 포인터 집합체인 i_fop (file operations table)를 장치의 성격에 맞춰 완전히 새롭게 교체해 버립니다. 타겟이 블록 장치라면 def_blk_fops 테이블로 갈아끼우고, 문자 장치라면 def_chr_fops 기본 테이블로 바꿔치기합니다.

이 교체 작업이 완료된 직후부터는 상황이 180도 달라집니다. 사용자가 이 파일 객체를 대상으로 익숙한 read(), write(), ioctl() 호출을 날리게 되면, 이 요청은 더 이상 디스크의 일반 파일 블록을 다루는 파일시스템 모듈로 향하지 않습니다. 테이블의 가리킴에 따라 커널 속 깊은 곳에 잠복해 있던 하드웨어 디바이스 전용 드라이버의 특수 제어 함수가 직접 다이렉트로 호출되는 것입니다. 결국 VFS는 겉으로는 사용자가 평범한 텍스트 파일을 여는 것처럼 자연스럽게 속이면서, 뒤로는 내부의 치밀한 포인터 교체 로직을 통해 데이터의 물길을 디바이스 드라이버 쪽으로 매끄럽게 틀어버리는 역할을 완수합니다.

이러한 모범적인 설계 원칙을 준수하기 위해 대다수의 완성도 높은 드라이버들은 내부적으로 정밀한 usage counter (사용 참조 카운터) 변수를 유지하고 운용합니다. 누군가가 디바이스를 쓰기 위해 open 메서드 경로를 통과할 때 카운터 값을 1 증가시키고, 사용을 마치고 release (close) 할 때 카운터를 1 감소시킵니다. 만약 누군가가 open을 시도하는 순간 카운터 값이 0이었다면? 이는 이 장치에 접근하는 최초의 사용자임을 명백히 뜻합니다 — 바로 이 중대한 시점에 드라이버는 무거운 시스템 자원들을 비로소 정식으로 할당받아 배정하고, 잠들어 있던 하드웨어 컨트롤러의 인터럽트 라인과 DMA 엔진 채널을 본격적으로 활성화시킵니다. 그리고 오랜 시간이 흘러 모든 프로세스가 작업을 끝내고 마지막 release가 호출되어 카운터가 다시 0으로 떨어지는 순간, 드라이버는 점유했던 모든 메모리 자원을 깨끗하게 커널 풀에 반환하고 하드웨어 모듈을 즉시 비활성화 상태로 전환시킵니다.

커널 내의 디바이스 드라이버가 I/O 포트를 통해 실제 장치에 특정 명령 지시를 성공적으로 내려보냈다고 가정해 봅시다. 그렇다면 드라이버 소프트웨어는 물리적 세계에서 벌어지는 그 하드웨어적인 작동이 완전히 종료되었다는 사실을 도대체 어떤 수단을 통해 파악할 수 있을까요? 거대한 디스크 헤드가 물리적으로 이동하는 시간, 복잡한 네트워크 케이블을 통해 패킷 데이터가 도달하는 시간, 혹은 인간 사용자가 다음 키보드 버튼을 누르는 데 걸리는 시간 등은 CPU의 연산 주기와 비교하면 그 격차가 너무나도 거대하고 완료 시점을 예측하기가 사실상 불가능에 가깝습니다.

인터럽트 기반 모드(interrupt mode)의 동작 예시를 좀 더 구체적으로 추적해 볼까요. 아주 단순한 입력용 문자 장치 드라이버의 foo_read() 함수는 시스템 콜을 타고 진입하면, 먼저 동시성 보호를 위해 시스템 semaphore 락을 획득하고, 이벤트 플래그인 intr 변수를 0으로 안전하게 초기화합니다. 그 직후 제어 포트(control port)에 실제 하드웨어 읽기 명령을 하달합니다. 그리고 나서는 커널 함수인 wait_event_interruptible()을 호출하여 intr 변수값이 1로 뒤바뀔 그 순간까지 대기 상태(잠금)로 진입합니다. 물리 장치가 데이터를 긁어모아 인터럽트 라인에 신호를 발생시키면 별개의 스레드처럼 동작하는 foo_interrupt() 핸들러가 즉각 튀어 올라, 장치의 입력 레지스터에서 도착한 데이터들을 버퍼로 안전하게 쓸어 담고 약속된 intr 변수를 1로 변경시킵니다. 변수가 바뀌는 순간 시스템이 잠들어 있던 foo_read() 경로의 프로세스를 깨워 애플리케이션으로 데이터를 안전하게 돌려보냅니다.

고성능을 요구하는 특정 하드웨어 장치들은 고속 데이터 버퍼링을 위해 기판 위에 자체적인 메모리 칩을 탑재하고 있습니다. 이렇게 디바이스가 자체적으로 보유한 I/O shared memory 공간에 커널 공간의 드라이버 코드가 접근하여 데이터를 읽거나 쓰기 위해서는, 가장 먼저 장치상의 물리적 주소 공간을 커널이 이해하고 접근 가능한 선형 주소 공간으로 매핑하는 까다로운 선행 작업이 요구됩니다. 이 목적으로 ioremap() 혹은 캐시 메커니즘을 배제하는 ioremap_nocache() 함수가 호출되며, 모든 통신이 종료되면 iounmap()으로 매핑을 조심스럽게 해제합니다. 아울러 플랫폼 간의 아키텍처 독립성과 안정성을 굳건히 유지하기 위해, 매핑된 주소에 일반 C 포인터로 섣불리 직접 접근하기보다는 커널이 제공하는 readb(), writeb(), memcpy_fromio() 같은 전용 I/O 접근 매크로 함수들을 사용하는 것이 업계의 강력한 권장 사항입니다.

이제 대규모 데이터 전송의 꽃, DMA (Direct Memory Access) 기술을 살펴보겠습니다. DMA는 놀라운 기법입니다. CPU가 최초에 전송할 데이터의 시작 주소와 바이트 크기만 DMA 전용 회로에 초기 설정해 두면, 영리한 DMA 엔진이 백그라운드에서 독자적으로 시스템 버스를 장악하여 물리 RAM과 외부 I/O 장치 사이의 거대한 데이터 덩어리를 직접 옮겨 담습니다. 전송이 완벽히 끝난 직후에만 DMA 엔진이 CPU에 단 한 번의 인터럽트를 발생시켜 결과를 보고합니다. 덕분에 수십 메가바이트에 달하는 방대한 비디오 프레임 데이터나 네트워크 패킷 전송 상황에서도, 정작 고성능 CPU는 바이트를 일일이 루프 돌며 복사하는 단순 노역에서 벗어나 그 시간에 다른 프로세스의 수학적 연산을 처리할 수 있는 막대한 여유를 얻게 됩니다.

방대하고 다채로운 리눅스 생태계에서 커널이 개별 하드웨어를 인지하고 제어·지원하는 깊이는 장치의 성격에 따라 크게 세 가지 수준으로 뚜렷하게 나뉩니다.

이제 ioctl()이라는 아주 유연하고 독특한 시스템 콜을 조명해 보겠습니다. 앞서 다룬 일반적인 open(), read(), write()라는 단순한 스트림 읽기/쓰기 시스템 콜만으로는 온전히 표현해내기 불가능에 가까운 장치별 기상천외한 특수 명령들을 일괄 처리하는 데 동원되는 만능 도구입니다. CD-ROM 드라이브 장치를 향해 모터 트레이를 강제로 뱉어내라는 명령(Eject)을 하달하거나, 그래픽 어댑터 장치 내부의 숨겨진 상태 레지스터 값을 은밀히 진단하거나, 사운드 카드 하드웨어의 세밀한 출력 볼륨 게인을 조절하는 작업 등이 모두 이 함수 하나의 범주에 해당합니다. 사용법 또한 유연하여 조작할 대상의 파일 디스크립터와 약속된 요청 번호(커맨드)를 인자로 던지고, 필요시 세 번째 가변 인자를 통해 장치별 맞춤 설정값과 추가 메모리 포인터를 자유자재로 넘겨주며 제어할 수 있습니다.

커널 내부에서 문자 장치(Character Device) 드라이버의 실체는 구조적으로 struct cdev라는 콤팩트한 구조체로 명확히 표현됩니다. 이 cdev 구조체 안에는 sysfs 연결을 위한 임베디드 kobject가 박혀 있으며, 드라이버 커널 모듈을 가리키는 포인터, 장치의 동작을 정의하는 파일 연산 테이블(file_operations)로 향하는 포인터 매핑, 현재 이 장치에 연결되어 열려 있는 모든 관련 inode들의 리스트, 할당받은 초기 major/minor 번호 세트, 그리고 마지막으로 이 드라이버가 커버할 수 있는 장치 번호의 수용 크기 범위 등 필수 정보들이 밀도 있게 응축되어 들어갑니다. 여기서 주목할 만한 흥미로운 점은, 하나의 드라이버 모듈이 고작 단 하나의 특정한 장치 번호에만 1:1로 묶여 작동하는 것이 아니라, 필요에 따라 광활한 장치 번호의 연속된 범위(Range) 전체를 한꺼번에 배정받아 통제하고 처리할 수 있는 유연성을 갖추고 있다는 사실입니다.

문자 장치 하위 시스템 내면에는 수많은 드라이버들을 번호로 찾기 위해 cdev_map이라는 특별한 kobject 매핑 도메인이 거대한 해시 테이블 형태로 촘촘히 구축되어 있습니다. 주요 탐색 기준점은 major 번호이며, VFS가 파일을 열 때 kobj_lookup()이라는 탐색 함수에 특정 장치 번호(dev_t)를 입력값으로 던져주면, 이 함수는 쏜살같이 해시 맵을 뒤져 해당 번호 범위 대역의 합법적인 소유자인 cdev 구조체의 kobject 객체를 정확하게 찾아내어 반환해 줍니다 — 한마디로 시스템이 던지는 "지금 넘어온 이 생소한 major/minor 번호 조합은, 도대체 수많은 문자 장치 드라이버 모듈 중에서 어떤 녀석이 담당하고 책임지는 구역이지?"라는 근본적인 질문에 명확하게 해답을 찾아내 응답해 주는 핵심 자료구조인 것입니다.

사용자 공간(User Space)에서 특정 문자 장치 파일에 대해 open() 시스템 콜을 호출하게 되면, 커널 내부에서는 문자 장치 전용의 기본 파일 연산 테이블인 def_chr_fops 내에 자리 잡은 초기 진입점 chrdev_open() 함수가 가장 앞서서 호출되며 톱니바퀴를 돌리기 시작합니다. 이 함수는 곧바로 대상 파일의 inode 정보를 들여다봅니다. 만약 inode 내부의 i_cdev 필드 포인터가 이미 누군가에 의해 설정되어 유효한 cdev를 가리키고 있다면, 이 장치는 이미 열려 있는 것이므로 다중 접속 처리를 위해 단순하게 내부 참조 카운터 수치만을 1 증가시키고 가볍게 지나갑니다. 하지만 비어있다면 이야기가 달라집니다. 시스템은 즉시 내부 탐색기인 kobj_lookup() 함수를 강제로 발동시켜 해당 장치 번호를 소유권으로 품고 있는 등록된 범위를 맹렬하게 추적해 냅니다. 무사히 추적에 성공하여 cdev 포인터를 찾아내게 되면, 이를 텅 비어있던 i_cdev 필드에 당당히 꽂아 설정하고, 추가로 i_cindex 필드에는 할당받은 범위 대역 안에서의 위치를 나타내는 상대 인덱스 번호를 기입해 넣으며, 현재 열리는 파일의 inode 구조체 자체를 cdev 모체의 관리 inode 리스트 그룹에 소속시켜 추가합니다. 그리고 이 대장정의 마지막 하이라이트로, 열리고 있는 file 구조체 객체의 두뇌에 해당하는 기본 연산 테이블 f_ops 포인터를 완전히 들어내고, 방금 찾은 cdev 안에 담겨있던 드라이버 제작자의 정교한 맞춤형 ops 연산 테이블로 과감하게 교체(Swap)해 버립니다. 비로소 드라이버 제작자가 직접 정의해둔 전용 open 루틴 코드가 이 시점에서 마침내 실행되는 극적인 순간을 맞이하게 됩니다.

장치와 통신하며 데이터를 주고받는 버퍼링(Buffering) 전략 또한 장치의 물리적 특성과 데이터의 성질에 따라 천차만별로 설계되어야 합니다. 구형 PS/2 키보드나 마우스처럼 인간의 느릿한 동작에 기반하여 한 번에 고작 수 바이트 단위의 적은 양의 신호 데이터만을 간헐적으로 읽어 들이는 단순한 인터페이스 장치는 전략 또한 단순 담백합니다. 포트의 입력 레지스터 구역에서 한 문자(바이트)씩 차례로 조심스레 읽어 들여 커널 큐 자료구조에 누적 보관하다가, 애플리케이션의 read 요청이 떨어지면 사용자 메모리 공간으로 가볍게 복사해 넘겨주면 그만입니다. 이처럼 찰나의 순간 소량의 데이터를 다루는 환경에서는 굳이 거창한 DMA 칩을 세팅하고 깨우고 제어하는 부가적인 오버헤드 비용이 순수한 데이터의 물리적 이동 비용보다 훨씬 크게 다가올 수 있기 때문에 의도적으로 무거운 DMA 기술을 배제하고 단순 전송 기법을 채택하는 경우가 다반사입니다.

하지만 전문적인 스튜디오 사운드 카드 장비나 기가비트 네트워크 카드처럼 미리 정해진 고정 샘플링 속도나 대역폭으로 수백 메가바이트의 대량의 스트림 데이터 파도가 폭포수처럼 지속적으로 끊임없이 쏟아져 들어오는 헤비급 장치는 전략의 차원이 완전히 다릅니다. 운영체제가 스케줄링 등의 사유로 잠시 다른 무거운 프로세스 연산 작업을 처리하느라 CPU 점유율을 돌리는 그 짧은 찰나의 순간에도 외부 장치는 하염없이 거대한 오디오나 패킷 데이터를 밀어 넣고 있기 때문입니다. 이런 극한의 가혹한 환경에서 데이터 유실 없는 안정적인 스트림을 방어해 내기 위해 커널 엔지니어들은 최고급 하드웨어 제어 기술 두 가지를 영리하게 결합해 냅니다.

이 길고 험난했던 장을 마무리 짓는 하나의 핵심 관통 메시지입니다: 디바이스 드라이버는 온갖 복잡한 규격과 기괴한 타이밍으로 파편화된 물리적 하드웨어의 야생적인 특성들을 깊은 커널 내부에서 매끄럽게 흡수해 버리고, 그 위에 서 있는 연약한 사용자 애플리케이션들에게는 '파일'이라는 지극히 통일되고 평화로우며 단순 명쾌한 인터페이스만을 제공해 주는 가장 우아하고 위대한 커널의 번역가이자 마술사입니다.