한빛출판네트워크

by 데릭 스토리(Derrick Story) & 앨런 노렌(Allen Noren), 역 한빛 리포터 2기 서성용 리눅스 박스에 주변기기를 설치해 본 사람이라면 디바이스 드라이버의 중요성을 알고 있을 것이다. 이것은 리눅스 개발에 있어 중요한 영역이므로, 오라일리의 도서 저자, 조나단 코벳(Jonathan Corbet)과 마주 앉아, 지금의 디바이스 드라이버와 미래에 어떤 것들이 나올지에 대해 이야기한 내용을 소개한다. 조나단은 오라일리의 Linux Device Drivers, 2nd Edition을 알레산드로 루비니(Alessandro Rubini)와 공동 집필했으며, LWN.net의 수석 편집장이다. 1980년대 초에 유닉스 소스를 만지기 시작했는데, 콜로라도 대학의 한 잘 속는 강사가 초기 BSD 페이징 알고리즘을 고치도록 했을 때였다. 그 이후로 시스템 프로그래밍 작업을 해 왔으며, 리눅스는 1993년에 처음 만지기 시작했다. 1997년 무렵 리눅스가 발전해 가고 있는 것이 명백해서 컨설팅 회사를 공동 창립했고, 그것을 홍보하기 위해 전자 회보를 만들었다. 그들에 의하면 그 나머지는 역사라고 한다. 이 인터뷰에서 조나단은 버전 2.0 이후의 디바이스 드라이버의 변화를 논의하고, 어떤 변화가 일어날지 근거 있는 한두 가지 추측을 내놓을 것이며, 이처럼 중요한 도구를 실제 개발하는 과정을 몇 가지 소개할 것이다. 스토리: Linux Device Drivers 2판은 (커널) 버전 2.4까지를 다루고 있습니다. 2.0 이후의 주목할 만한 변화로는 무엇이 있을까요? 코벳: 아마도 가장 큰 변화는 모든 드라이버 제작자들에게 영향을 끼친 커널에서의 fine-grained locking의 혼합일 것입니다. 2.0에서는 모든 것이 “큰 커널 잠금"으로 보호되었고, 디바이스 드라이버가 SMP 시스템에서 병행성(concurrency)을 다룰 필요는 없었습니다. 버전 2.2는 이를 다소 분리하기는 했지만, 2.4 에서만 잠금(locking)이 드라이버 수준에 포함되도록 되어 있습니다. SMP를 고려하지 않고 작성된 디바이스 드라이버는 2.4에서는 정확하지 작동하지 않을 것입니다. 이 외에도 커널의 많은 부분에 변화가 있었습니다. 밑바닥의 절반이 tasklet으로 교체되었고, 스케줄러 큐는 새로운 이벤트 스케줄링 기법으로 교체되었으며, 블록과 네트워크 드라이버 인터페이스도 많이 변화했습니다. 지원되는 디바이스의 수가 증가함에 따라 지원되는 플랫폼의 숫자도 눈에 띄게 증가했습니다. 많은 것이 깨끗하게 다듬어졌습니다. 2.4 드라이버 인터페이스는 이전의 버전보다 훨씬 잘 동작할 것입니다. 스토리: 중요한 변화들이군요. 그렇다면 앞으로는 무슨 변화가 나타날지 궁금한데요? 버전 2.5가 막 릴리즈되려고 하고 있는데요. 코벳: 2.5에서 어떤 일이 일어날지 예측하는 것은 내년의 날씨를 예측하는 것과 비슷합니다. 일반적인 기후가 어떨지는 알 수 있지만, 세세한 것들은 예상 밖이죠. 커널 해커들이 생각하고 있는 건 제가 웹에 올린 kernel summmit write-up에 있는 내용에도 있을 겁니다. 가능해 보이며, 디바이스 드라이버에도 영향을 미칠 몇 가지로 다음과 같은 것이 있습니다.

• 제로-카피 네트워킹(zero-copy networking)은 2.4.4. 커널에 이미 포함되어 있습니다. 이 기법은 데이터를 커널에 복사하지 않고 직접 사용자의 버퍼에서 네트워크 인터페이스로 이동시키는 것인데, 하이엔드 시스템에서 성능을 크게 향상시킵니다. 그러나 네트워크 하드웨어(드라이버도)가 이 기법을 지원해야 합니다.
• 네트워크 드라이버 인터페이스의 변화는 트래픽이 아주 높을 때 성능을 향상시키는 데 초점을 두고 있습니다.
• 네트워킹 코드에서 이용하는 제로-카피 기법은 확대될 것으로 보이고, 제로 카피 전송에 대한 보다 일반적인 지원 API가 새로운 방식으로 kiobuf 코드와 조합되어 제공될 것입니다.
• 블록 장치 인터페이스는 한 커널 개발자의 말에 의하면, “회전경운기화(rototilled)" 될 것입니다. 하이엔드 엔터프라이즈 응용프로그램이 필요로 하는 성능을 제공하고 저널링 파일 시스템과 같은 기법을 잘 제공하려면, 이 서브시스템에는 많은 변화가 요구됩니다.
• ACPI 전원 관리에 대한 지원이 포함될 것입니다. 이것은 시스템에 있는 대부분의 디바이스 드라이버에서 지원해야 합니다.
• USB 장치와 같은 hot-pluggable 장치는 2.4에서도 충분히 지원되지만, 이 부분에 대해 더 많은 작업이 이루어질 것입니다. 훨씬 많은 동적 하드웨어 환경이 필요하게 됨에 따라, 장치들을 인식하기 위한 고전적인 유닉스의 “major와 minor 번호"를 사용하지 않게 되거나, 적어도 불만을 느끼게 될 것입니다.
• 장담할 수 없지만, 2.5 버전에서는 리눅스 커널이 보편화될 겁니다. 현재 커널 코드는 프로세서에서 비자발적으로 스케줄될 수 없습니다. 이것은 전통적으로 단순화된 커널 프로그래밍을 보장했으나, 레이턴시(latency) 문제를 발생시켜 시스템이 이벤트에 빠르게 응답할 수 없었습니다. 커널이 보편화되면 이러한 문제는 해결됩니다. 하지만 단일 프로세서 시스템에 새로운 잠금 문제를 발생시킵니다.

스토리: 한 플랫폼에서 다른 플랫폼으로 이식하는 문제에 대해 알려주시죠. 코벳: 커널 코드는 대부분 이식성 문제를 잘 숨겨 줍니다. 정말 필요한 것은 드라이버 작성자가 규칙을 잘 따라 이식성이 있는 드라이버를 작성하는 겁니다. 규칙은 다음과 같습니다. 바이트 정렬에 대해 추측을 하지 않고, I/O 메모리에 직접 de-reference 포인터를 하지 않으며, DMA 등에 작업을 위해 제공되는 인터페이스를 사용하는 것 등입니다. 스토리: 이제는 주제를 옮겨서, 어떤 리눅스 버전에서 다른 것으로 옮겨가는 이식성에 대한 논쟁이 있었는지요? 있었다면 문제는 무엇이고 어떻게 처리해야 할까요?

		Linux Device Drivers, 2nd Edition

코벳: 물론 있었습니다. 리눅스 커널 버전간의 이식성은 하드웨어 플랫폼간의 이식성보다 어렵거든요. 커널 개발자들은 내부 커널 API 상수를 유지할 필요가 없다고 느끼는데, 특히 개발 시리즈동안 더 그렇습니다. API 변화는 보다 나은 기능, 새로운 특징, 그리고 향상된 성능을 제공하기 위해 필요합니다. 호환성을 유지하는 것은 장기적인 안목으로 봤을 때 커널이 오래된 찌꺼기에 파묻혀 버리며 점점 유지할 수 없어질 것입니다. 그래서 변화를 만들고 고통을 즉시 처리하기 위해 엄격한 정책이 필요한 겁니다. 드라이버 작성자에게는 어렵겠지만, 결과는 보다 좋은 커널이 됩니다. 이것을 다루는 것은.... 제 책 광고를 좀 해야겠네요. 제 책을 읽어보세요. 커널 2.0에서 2.4.4까지를 다루고 있고, 모든 버전에서 이식성 있는 코드를 작성하는 법을 알려주고 있습니다. 각각의 비호환성은 개별적으로 해결되어야 하고, 2.4 API에서 이전 커널로 돌아가기 위해서는 보통 매크로와 래퍼(wrapper) 함수를 정의해서 해결하게 됩니다. 다음과 같이 간단할 수도 있구요.

#define ioremap vremap

아니면 PCI 버스 계층의 방대한 이전과 같이 복잡할 수도 있습니다. 스토리: 리눅스 장치 드라이버가 윈도우나 맥 플랫폼만큼 풍부해지고 있습니까? 즉, 리눅스 사용자들이 컴퓨터 활동의 대부분에 필요한 드라이버를 찾을 수 있을까요? 코벳: 다른 플랫폼에서 어떤 것이 사용 가능한지 자세한 내용을 말씀드릴 수는 없어요. 결국 저도 리눅스 사용자거든요, 하지만 노력해보죠. 최첨단의 새로운 하드웨어에 대한 지원은 아마도 윈도우가 훨씬 좋을 것 같네요. 윈도우와 같은 지배적인 플랫폼에서 동작여부를 확인하지 않고 부품을 만들어 내는 벤더는 거의 없으니까요. 하지만 리눅스도 윈도우를 따라잡고 있고, 리눅스 사용자들은 예전처럼 오랫동안 지원을 기다릴 필요도 없습니다. 업체들은 리눅스 개발에 보다 협조적이고(드라이버를 제공하든가, 적어도 하드웨어 문서를 이용 가능하도록 함으로써), 개발 공동체가 더 커졌습니다. 코벳씨의 다른 질문에 답변을 하자면, 리눅스 사용자들은 필요로 하는 하드웨어 지원을 거의 언제나 찾을 수 있을 것입니다. 스토리: 개발 공동체에 대해 언급하셨는데, 저는 OS 공동체가 새로운 드라이버의 요청에 대해 어떻게 대응해야 할지에 대한 코벳씨의 관점이 궁금합니다. 어떻게 해서 유명하고, 유명하지 않은 하드웨어의 드라이버를 제작하는 좋은 일을 해낼 수 있는 것입니까? 코벳: 새로운 드라이버를 작성하는 데는 두 가지 방법이 있습니다.

1. 누군가가 특정 주변기기를 가지고 있고, 그것이 리눅스에서 작동하기를 원합니다. 전통적인 “가려운 곳 긁기(scratching an itch)"라고 하는 방식인데, 자유 소프트웨어 코드 베이스의 많은 부분을 만들어 냈습니다.
2. 업체가 드라이버를 제작하여 커널에 기고합니다. 보다 많은 코드가 이런 식으로 입수되고 있습니다. 만약 코벳씨가 하드웨어를 제작한다면, 그것을 리눅스에서 작동하도록 하는 것은 코벳씨의 관심에 달려 있는 것입니다. 그리고 많은 제조업체들이 이를 이해하기 시작했습니다. 많은 수의 리눅스 회사들(하드웨어 업체와 배포자들) 역시 리눅스 해커들을 고용해서, 특히 드라이버를 작업하도록 하고 있습니다. 그들에게도 역시 리눅스에서 하드웨어를 보다 잘 지원하도록 하는 것이 돈을 버는 길이 됩니다.

스토리: 그러한 드라이버를 만드는 오픈 소스 과정에 대해 알려주시겠습니까? 코드 작성시 모든 사람이 지키는 단일성이 있는 겁니까, 아니면 필요한 누군가가 코드를 작성해서 공유하는 것인가요? 만약 후자라면, 사용자들이 새로운 드라이버가 자신의 시스템에 “안정적인지”를 어떻게 알 수 있을까요? 코벳: 보통 드라이버가 작성되는 경우는 업체가 원하거나, 어느 곳의 누군가가 그것을 원하기 때문이지요. 일부 리눅스 시스템 업체와 배포자들은 디바이스 드라이버 개발에 노력을 하고 있습니다. 리누스 토발즈는 코딩 표준 문서를 커널 소스에 포함시키지만, 잘 지켜지지는 않습니다. 특히 드라이버 코드는 코딩 형식과 질에 따라서 매우 다양하게 변할 수 있어요. “안정적인지”를 알기 위해서는 말이죠... 드라이버를 포함한 새로운 커널 코드가 있으면 보통 커널 메일링 리스트에 사용 가능하다고 알리는 것이죠. 그 시점부터 사람들은 자주 그것을 들여다보고 문제가 있어 보이는 부분을 지적합니다. 직접 돌려보기도 하고, 실험 결과를 제출하는 사람도 있구요. 만약 드라이버에 문제가 있는데 원작자가 언급하지 않는다면, 다른 누군가가 코드를 가져다가 수정해서 릴리즈할 겁니다. 그 결과 대부분의 드라이버는 “안정적”이 됩니다. 문제는 신속히 수정되고, 대개 애당초 잘못될 가능성이 있는 것들만 남게 됩니다. 그렇게 해서 드라이버는 비교적 신속하게 주 커널에 포함됩니다. 이러한 드라이버는 검증하기 쉽고, 어떠한 경우에도 이를 사용하지 않는 사람들의 일을 망치지 않을 것이기 때문입니다. 스토리: 이런 것을 고려한다면, 요즘엔 드라이버 작성이 쉬울까요, 어려울까요? 코벳: 쉽기도 하고 어렵기도 합니다. 기본 커널 서브시스템의 많은 부분이 재설계되어 보다 간단하고 안정적인 방식으로 동작한다는 면에서는 쉽습니다. 예를 들자면, 시스템 버스와 DMA 작업을 설정하는 인터페이스는 훨씬 깨끗하고 사용하기 쉽습니다. 디버깅 툴의 질도 역시 향상되고 있구요. 그러나 병행성과 잠금 처리는 별개의 문제입니다. 경쟁 상태와 다른 병행성 관련 버그를 피하는 것은 매우 어렵고, 이러한 유형의 버그를 추적하는 것도 재미없습니다. Fine-grained locking은 매우 복잡하지만, 그것이 없이 커널을 대형 시스템으로 배율화(scaling)하는 것은, 가능하다고 해도 어렵습니다. 스토리: 마지막으로, 특이한 드라이버를 찾기 위해서는 어디를 찾아 봅니까? 뉴스그룹? 온라인 디렉토리? 추전할 만한 리소스가 있나요? 코벳: 사실 드라이버에는 단일 리소스가 없어요. 만약 아주 특이한 무엇인가를 찾는다면, 구글이나 커널 메일링 리스트 아카이브를 뒤져봅니다. 찾는 게 있기만 하다면, 이 중 한곳에 나타날 겁니다. 하지만 보다 구체적으로 작업하고 있다면 확실한 곳이 있습니다. USB 디바이스에 대한 것을 작업하고 있다면, www.linux-usb.org가 정보를 찾기에 가장 좋을 것이고, 랩탑 시스템과 씨름하고 있다면, www.linux-laptop.net이 궁극적인 리소스가 되겠구요. 최신의 ALSA 사운드 시스템(커널 2.5 시리즈에 포함될 것으로 보이는)은 www.alsa-project.org에서 많은 정보를 찾아볼 수 있습니다. 스토리: 조나단, 시간을 내주셔서 감사합니다. 이번 인터뷰에서 많은 것을 배웠습니다. Linux Device Drivers, 2nd Edition이 크게 성공하길 바라고, 다른 것들도 모두 잘되길 빌겠어요. 코벳: 고마워요, 즐거웠습니다!

---

데릭 스토리(Derrick Story)는 오라일리 네트워크의 편집자이다. 앨런 노렌(Allen Noren)은 오라일리 웹 마케팅장이다. 서성용님은 한빛 리포터 1기에 이어 2기로 활동 중이며, 서울대학교 컴퓨터공학부 3학년에 재학중입니다. 현재 학부 체계 관리자 그룹 ACCESS의 UNIX Team Chief이며, 리눅스, 커널, 네트워크, 컴퓨터 아키텍처에 관심이 많다고 합니다.