장치 드라이버

특정 하드웨어나 장치를 제어하기 위한 커널의 일부분으로 동작하는 프로그램

장치 드라이버/제어기(문화어: 장치구동기, 장치구동프로그람) 또는 디바이스 드라이버(영어: device driver)는 특정 하드웨어나 장치의 입출력을 제어하기 위해 커널의 일부분으로 동작하는 컴퓨터 소프트웨어다. 컴퓨터를 구성하는 다양한 입출력 장치마다 각각 장치드라이버가 프로그램 되어 커널에 통합되어 실행된다. 높은 수준의 컴퓨터 프로그램들이 컴퓨터 하드웨어 장치와 상호 작용하기 위해 만들어진 하나의 컴퓨터 프로그램이다.

장치드라이버는 커널의 일부분이기는 하나 커널과 통합되는 것은 처음부터 해당 드라이버 프로그램 소스 코드가 커널 전체 소스에 포함되어 컴파일되는 경우도 있고, 별도로 컴파일된 파일(윈도의 *.sys, 리눅스의 *.o)의 형태로 존재하고 부팅 등의 과정에서 필요할 때마다 해당 파일이 로드되어 커널과 통합되기도 한다.

드라이버는 흔히 컴퓨터 버스, 또는 하드웨어와 이어진 하위 시스템을 통해 장치와 통신한다. 요청하는 프로그램이 드라이버의 명령어를 호출하면, 드라이버는 장치에 명령어를 전달한다. 장치가 드라이버에게 데이터를 되돌려 주면, 드라이버는 원래 요청한 프로그램의 명령어로 데이터를 다시 전달한다. 드라이버는 하드웨어에 의존하며 특정한 운영 체제를 따른다. 이러한 드라이버는 비동기 시간에 의존하는 하드웨어 인터페이스에 필요한 인터럽트를 다룰 수 있다.[1]

장치 드라이버는 흔히 장치 칩의 레지스터에 접근하여 하드웨어를 제어하며 하드웨어와 주변 기기를 사용하는 프로그램의 중간 다리 역할을 한다.

MS-DOS의 경우 하드웨어를 제어하기 위한 x86 기계어 명령어 IN,OUT은 응용 프로그램에서 직접 사용할 수 있다. 그러나 본격적인 운영체제가 도입된 경우 (윈도 NT 계열, 유닉스 계열 등), 커널과 응용 프로그램이 분리되어 설계되고 실행된다. 장치 드라이버는 커널의 일부분으로 응용 프로그램에서는 완전히 분리된 자원과 실행 방식을 가진다.

커널은 부팅 시에 시작되어 컴퓨터 종료시 커널이 끝난다. 장치 드라이버는 하드웨어와 밀접하게 연관되고 해당 장치를 제어하는 프로그램이다. 커널 공간에서 이루어지는 작업으로는 입출력, 네트워크 등의 하드웨어 제어, 메모리와 같은 컴퓨터의 리소스 관리, 응용 프로그램의 실행 제어 등이 있다. 커널과는 달리 응용 프로그램은 사용자 요청에 의해 저장장치로부터 메모리에 로드되어 실행한다. 응용 프로그램이 하드웨어를 직접 제어할 수는 없기 때문에, 커널의 장치 드라이버를 사용하기 위해 시스템 호출 방법으로 커널에 접근하여 자료를 처리한다.

전자 제품에서 각각의 주변 기기들을 제어하기 위해 설계된 펌웨어 또한 장치 드라이버로 분류된다. 장치 드라이버의 실제 예는 소스가 공개된 리눅스 커널 소스에서 /driver 디렉터리 밑에 있는 파일들을 참조하여 볼 수 있다.

목적 편집

장치 드라이버는 장치와 응용 프로그램·운영 체제 사이의 해석기 역할을 하며 프로그래밍을 단순하게 한다. 높은 수준의 코드는 코드가 제어하는 하드웨어 장치를 독립적으로 제어할 수 있다. 프린터와 같은 장치는 버전에 따라 고유의 특별한 명령어들을 요구한다. 반면, 파일을 프린터로 보내는 것과 같은, 대부분의 응용 프로그램들은 PRINTLN과 같은 높은 수준의 포괄적인 명령어들을 사용하여 장치를 접근한다. 드라이버는 이러한 포괄적인 명령어들을 받아들이고, 이 명령어들을 장치가 요구하는 낮은 수준의 명령어들로 변환한다.

설계 편집

장치 드라이버는 논리 계층과 물리 계층으로 나뉜다. 논리 계층은 이더넷 포트 또는 디스크 드라이브와 같은 장치의 클래스를 위한 데이터를 처리한다. 물리 계층은 특정한 장치 인스턴스와 통신한다. 예를 들어, 직렬 포트는 모든 시리얼 포트 하드웨어에 일반적으로 쓰이는 XON/XOFF와 같은 표준적인 통신 프로토콜을 다루는데, 직렬 포트 논리 계층이 이것을 관리한다. 논리 계층은 특별한 직렬 포트의 칩과 통신해야 한다. 16550 UART 하드웨어는 PL-011과 다르다. 물리 계층은 이러한 칩의 특정한 차이를 번지로 매긴다. 그 동안 해 온 것 같이, 운영 체제의 요청은 먼저 논리 계층으로 이동한다. 차례대로, 논리 계층은 물리 계층 위에서 하드웨어가 이해할 만한 용어로 운영 체제의 요청을 추가할 것을 요청한다. 거꾸로, 하드웨어 장치가 운영 체제에 응답해야 할 때, 논리 계층을 사용하여 연역 레이어에 응답한다.

리눅스 장치 드라이버는 운영 체제 커널 안에 만들어진다. 그러므로 적절한 비트 대역폭을 위해 자동으로 만들어진다. 충분한 기술적인 하드웨어 정보를 사용할 수 있으면, 리눅스 커널 팀은 아무런 대가 없이 이를 쓸 것이다. 이로써 하드웨어 제공 업체와 최종 사용자 둘 다 드라이버에 대해 걱정하지 않게 도와 준다.

게다가, 장치 드라이버는 커널의 일부로 만들어지거나, 불러 올 수 있는 모듈로 따로 만들어질 수 있다. 마이크로소프트 윈도우의 .sys 파일과 리눅스의 .ko 모듈은 불러올 수 있는 장치 드라이버이다. 불러올 수 있는 장치 드라이버의 이점은 필요할 때만 불러오고, 뒤에는 사용하지 않을 수도 있으므로 커널 메모리를 아낄 수 있다는 것이다.

개발 편집

장치 드라이버를 기록하려면 하드웨어와, 주어진 플랫폼 기능의 소프트웨어를 깊이 있게 이해해야 한다. 장치들은 "... 높은 권한을 가진 환경에서 작동하며 잘못 사용되면 심각한 문제를 일으킬 수 있다..." [1] Archived 2007년 9월 27일 - 웨이백 머신 반대로, 현대의 운영 체제들 위에서 돌아가는 사용자 수준의 대부분의 소프트웨어는 시스템에 큰 영향을 미치지 않고 사용이 중지될 수 있다. 사용자 모드로 실행하는 드라이버들도, 장치가 잘못 프로그래밍되어 있을 경우, 시스템과 충돌할 수 있다. 이러한 요인들은 문제를 진단 하는 데에 가장 어렵고 위험하게 만든다.

그러므로 장치 드라이버는 하드웨어를 개발하는 회사에 다니는 소프트웨어 엔지니어들이 작성한다. 그 까닭은, 그들이 하드웨어를 설계하지 않는 대부분의 사람들보다 더 알맞은 정보를 가지고 있기 때문이다. 게다가, 전통적으로 하드웨어 제조업체에서 제공업체들의 관심이 "그들의 손님이 그들의 하드웨어를 최적으로 사용한다"에 맞춰져 있다. 보통, 논리 장치 드라이버 (LDD)는 운영 체제 판매자가 작성하는 반면, 물리 장치 드라이버 (PDD)는 장치 제공 업체가 추가한다. 그러나 최근 장치 드라이버를 제공하지 않는 업체들은 자유 운영 체제를 위한 수많은 장치 드라이버를 사용해 왔다. 이 때, 하드웨어 제공업체는 장치 통신 정보를 제공하는 것이 중요하다. 리버스 엔지니어링을 통해 이러한 정보를 알 수 있지만, 소프트웨어 보다 하드웨어 쪽에선 훨씬 배우기가 어렵다.

마이크로소프트는 제대로 쓰이지 않는 장치 드라이버에서 비롯되는 시스템의 불안을 줄이고자 했다. 그리하여 드라이버 개발을 위한 새로운 뼈대인 윈도우 드라이버 파운데이션 (WDF)을 창조했다. 윈도 드라이버 파운데이션에는 사용자 모드 드라이버 프레임워크 (UMDF)가 있는데, 특정한 드라이버, 주로 사용자 모드 드라이버로서의, 장치와 통신하기 위한 메시지 기반의 프로토콜을 추가하는 드라이버를 개발하는 데 힘을 준다. 이러한 드라이버가 기능을 잘못 쓰더라도, 시스템은 불안해지지 않는다. 커널 모드 드라이버 프레임워크 (KMDF) 모델 덕에 커널 모드의 장치 드라이버를 지속적으로 개발할 수 있다. 그러나 입출력 기능, 전원 관리, 플러그 앤 플레이 장치 지원의 취소와 더불어, 문제들을 일으킨다고 알려진 기능들이 표준으로 제공될 수 있다.

애플은 맥 오에스 텐 위에서 돌아가는 오픈 소스 프레임워크, 입출력 키트를 가지고 있다.

장치 드라이버 응용 프로그램 편집

현대의 하드웨어와 운영 체제들이 다양하기 때문에, 드라이버를 사용하는 방법이 많이 있다. 드라이버는 다음과 같은 인터페이스를 사용한다:

장치 드라이버를 일반적으로 가져오는 수준으로는

  • 하드웨어에서:
    • 직접 상호 작용
    • 높은 수준의 인터페이스를 사용 (예: 비디오 바이오스)
    • 또다른, 낮은 수준의 장치 드라이버 사용 (예: 디스크 드라이버를 사용하는 파일 시스템 드라이버)
    • 완전한 다른 무언가를 하는 동안 하드웨어와의 작업을 시뮬레이트
  • 소프트웨어에서:
    • 운영 체제가 하드웨어 자원에 직접 접근
    • 원시 컴퓨터만 추가
    • 드라이버가 아닌 소프트웨어를 위한 인터페이스 추가 (예: 트웨인)
    • 가끔씩 매우 높은 수준의 언어 추가 (예: 포스트스크립트)

주어진 하드웨어에 올바른 장치 드라이버를 선택하고 설치하는 것이 컴퓨터 시스템 구성에서 중요하다.

오픈 드라이버 편집

API와의 관계 편집

드라이버는 운영 체제의 일부이다. 사용자의 프로세스의 자격인 API 호출로 비롯하여, 드라이버의 코드를 불러 오지만, 드라이버의 코드 자체는, 사용자 프로세스가 아닌 커널 코드의 일부로 동작한다.

추상화된 API는 현대의 운영 체제에서 대부분 "열기, 읽기, 쓰기, IOCTL, 닫기"를 처리하는 API에 통합되어 있다.

  • 열기: 장치와 입출력을 준비한다.
  • 읽기: 장치로부터 데이터를 받는다.
  • 쓰기: 장치에 데이터를 보낸다.
  • IOCTL: 장치에 특별한 처리를 한다.
  • 닫기: 입출력을 마친다.

역사적으로 이러한 API는 기억 장치 안에 있는 파일에 접근하기 위한 API이지만, 장치에도 접근할 수 있는 것처럼 확장된 형태로 제공되고 있는 것이 일반적이다.

읽기, 쓰기는 장치마다 역할이 다르다. 예를 들면, 프린터에 '쓰기'를 실행하면 인쇄되지만, 사운드 카드에 '쓰기'를 실행하면 소리가 나온다. 마우스에 대해서 '읽기'를 실행하면 마우스가 이동한 위치 등을 읽을 수 있다. 그러나 프린터에 대해서 '읽기'를 실시하면, 보통 아무 일도 일어나지 않는다.

가상 장치 드라이버 편집

특별한 장치 드라이버로 가상 장치 드라이버가 있다. 마이크로소프트 윈도우가 설치된 컴퓨터에서 MS-DOS 프로그램을 돌린다든지, Xen 호스트와 같은 게스트 운영 체제를 실행하는 것과 같은, 가상화 환경에서 쓰인다. 하드웨어와 대화하기 위해 게스트 운영 체제를 사용하는 대신, 가상 장치 드라이버를 사용하여 하드웨어의 일부를 가상으로 구현(emulate)한다. 이리하여 가상 머신 안에서 돌아가는 게스트 운영 체제와 시스템 드라이버들은 실제 하드웨어를 받아들인 것 같은 착각을 일으킨다. 게스트 운영 체제가 하드웨어를 받아들이는 시도들은 기능 요청들을 위해 호스트 운영 체제의 가상 장치 드라이버로 전향된다. 가상 장치 드라이버는 가상 머신으로의 인터럽트와 같은, 시뮬레이트된, 프로세서 수준의 이벤트들을 보낼 수 있다.

같이 보기 편집

각주 편집

  1. EMC Education Services (2010). 《Information Storage and Management: Storing, Managing, and Protecting Digital Information》. John Wiley & Sons. ISBN 9780470618332. 2021년 2월 13일에 원본 문서에서 보존된 문서. 2020년 11월 10일에 확인함. 

외부 링크 편집