하드웨어 추상화

하드웨어 추상화(hardware abstraction)는 컴퓨터 소프트웨어에서 프로그램에 컴퓨터 하드웨어 자원에 대한 접근을 프로그래밍 인터페이스를 통해 제공하는 루틴의 집합이다. 프로그래밍 인터페이스는 특정 클래스 C의 하드웨어 장치에 속하는 모든 장치가 동일한 인터페이스를 통해 접근될 수 있도록 하며, C는 각각 다른 하드웨어 인터페이스를 제공하는 장치의 다른 서브클래스를 포함할 수 있다.

하드웨어 추상화는 종종 프로그래머가 표준 운영체제(OS) 호출을 하드웨어에 제공함으로써 장치 독립적인 고성능 애플리케이션을 작성할 수 있도록 한다. 하드웨어 조각을 추상화하는 과정은 종종 CPU의 관점에서 이루어진다. 각 CPU 유형은 특정 명령어 집합 또는 ISA를 가진다. ISA는 어셈블리어 프로그래머 및 컴파일러 작성자가 사용할 수 있는 기계의 원시 작업을 나타낸다. 컴파일러의 주요 기능 중 하나는 프로그래머가 CPU 특정 명령을 신경 쓸 필요 없이 고수준 언어로 알고리즘을 작성할 수 있도록 하는 것이다. 그러면 CPU 특정 실행 파일을 생성하는 것이 컴파일러의 역할이다. 운영체제에서도 동일한 유형의 추상화가 이루어지지만, 이제 OS API는 ISA가 아닌 기계의 원시 작업을 나타낸다. 이를 통해 프로그래머는 다양한 플랫폼에서 이식성을 유지하면서 프로그램에서 OS 수준 작업(예: 태스크 생성/삭제)을 사용할 수 있다.

개요

많은 초기 컴퓨터 시스템은 어떤 형태의 하드웨어 추상화도 가지고 있지 않았다. 이는 그러한 시스템을 위한 프로그램을 작성하는 모든 사람이 각 하드웨어 장치가 시스템의 나머지 부분과 어떻게 통신하는지 알아야 한다는 것을 의미했다. 이는 소프트웨어 개발자에게 상당한 도전이었는데, 그들은 소프트웨어의 호환성을 보장하기 위해 시스템의 모든 하드웨어 장치가 어떻게 작동하는지 알아야 했기 때문이다. 하드웨어 추상화를 통해 프로그램이 하드웨어 장치와 직접 통신하는 대신, 장치가 무엇을 해야 하는지 운영체제에 전달하고, 운영체제는 장치에 하드웨어 종속적인 명령을 생성한다. 이는 프로그래머가 특정 장치가 어떻게 작동하는지 알 필요가 없게 하여 그들의 프로그램이 어떤 장치와도 호환되도록 만들었다.

이의 예시는 조이스틱 추상화가 될 수 있다. 조이스틱 장치에는 많은 물리적 구현이 있으며, 많은 조이스틱과 유사한 장치들이 공유할 수 있는 API를 통해 읽기/쓰기가 가능하다. 대부분의 조이스틱 장치는 이동 방향을 보고할 수 있다. 많은 조이스틱 장치는 외부 애플리케이션에서 구성할 수 있는 민감도 설정을 가질 수 있다. 조이스틱 추상화는 하드웨어의 세부 사항(예: 레지스터 형식, I2C 주소)을 숨겨서 추상화된 API를 사용하는 프로그래머가 장치의 물리적 인터페이스 세부 사항을 이해할 필요가 없도록 한다. 이는 또한 동일한 코드가 "조이스틱" 추상화를 제공하는 어떤 종류의 구현으로부터 표준화된 메시지를 처리할 수 있기 때문에 코드 재사용을 가능하게 한다. "앞으로 미는" 동작은 전위차계에서 오거나 "스와이프" 제스처를 인식하는 정전식 터치 센서에서 올 수 있으며, 둘 다 "움직임"과 관련된 신호를 제공하는 한 동일하다.

물리적 제한(예: 센서 해상도, 시간적 업데이트 빈도)은 하드웨어에 따라 다를 수 있으므로, API는 "최소 공통 분모" 모델을 가정하는 것 외에는 이를 숨기기 위해 할 수 있는 것이 거의 없다. 따라서 구현에서 비롯된 특정 깊은 아키텍처 결정은 추상화의 특정 인스턴스 사용자에게 관련될 수 있다.

좋은 비유는 교통 수단의 추상화이다. 자전거 타기와 자동차 운전 모두 교통 수단이다. 둘 다 공통점(예: 조종해야 함)과 물리적 차이점(예: 발 사용)을 가지고 있다. 항상 "운전하여 ~로 가라"는 추상화를 지정하고 구현자에게 자전거를 타는 것이 최적인지 자동차를 운전하는 것이 최적인지 결정하게 할 수 있다. "바퀴 달린 육상 운송" 기능은 추상화되고 "운전 방법"의 세부 사항은 캡슐화된다.

PC의 "추상화" 예시로는 비디오 입력, 프린터, 오디오 입력 및 출력, 블록 장치(예: 하드 디스크 드라이브 또는 USB 플래시 드라이브) 등이 있다.

운영체제 또는 임베디드 시스템과 같은 특정 컴퓨터 과학 분야에서는 추상화가 약간 다른 모습을 보이지만(예를 들어, 운영체제는 더 표준화된 인터페이스를 가지는 경향이 있음), 복잡성의 추상화 및 캡슐화 개념은 공통적이고 깊다.

하드웨어 추상화 계층은 소프트웨어 스택의 응용 프로그래밍 인터페이스(API) 아래에 위치하며, 응용 프로그램 계층(종종 고수준 언어로 작성됨)은 API 위에 위치하며 API의 함수를 호출하여 하드웨어와 통신한다.

운영체제에서

하드웨어 추상화 계층(HAL)은 컴퓨터의 물리적 하드웨어와 해당 컴퓨터에서 실행되는 소프트웨어 사이에 소프트웨어로 구현된 추상화 계층이다. 그 기능은 대부분의 운영체제 커널에서 하드웨어의 차이를 숨겨서 대부분의 커널 모드 코드가 다른 하드웨어를 가진 시스템에서 실행되기 위해 변경될 필요가 없도록 하는 것이다. 마이크로소프트 윈도우에서 HAL은 기본적으로 메인보드의 드라이버로 간주될 수 있으며, 상위 수준 컴퓨터 언어의 명령이 하위 수준 구성 요소와 통신할 수 있도록 하지만 하드웨어에 대한 직접적인 접근은 방지한다.

CP/M (CP/M BIOS), 도스 (DOS BIOS), 솔라리스, 리눅스, BSD, macOS, 그리고 일부 다른 이식 가능한 운영체제도 명시적으로 그렇게 지정되지는 않지만 HAL을 가지고 있다. 리눅스와 같은 일부 운영체제는 실행 중에 적응형 도메인 환경처럼 하나를 삽입할 수 있는 능력을 가지고 있다. NetBSD 운영체제는 깨끗한 하드웨어 추상화 계층을 가지고 있어 매우 이식성이 뛰어나다고 널리 알려져 있다.^[1] 이 시스템의 일부로는 uvm(9) /pmap(9) , bus_space(9) , bus_dma(9) , 기타 서브시스템이 있다. 둘 이상의 아키텍처에서 사용되는 인기 있는 버스(예: ISA, EISA, PCI, PCIe 등)도 추상화되어 드라이버가 최소한의 코드 수정으로도 매우 이식성이 높도록 한다.

정의된 HAL을 가진 운영체제는 다른 하드웨어 간에 더 쉽게 이식할 수 있다. 이는 수십 가지의 다른 플랫폼에서 실행되는 임베디드 시스템에 특히 중요하다.

마이크로소프트 윈도우

윈도우 NT 아키텍처의 하드웨어 추상화 계층

윈도우 NT 커널은 %WINDOWS%\system32\hal.dll 아래의 파일 ntoskrnl.exe^[2][3]에 포함된 하드웨어와 실행 서비스 사이에 커널 공간에 HAL을 가지고 있다. 이를 통해 윈도우 NT 커널 모드 코드를 다양한 프로세서, 다른 메모리 관리 장치 아키텍처, 그리고 다른 I/O 버스 아키텍처를 가진 다양한 시스템으로 이식할 수 있다. 해당 시스템에 적용 가능한 명령어 집합으로 컴파일될 때 해당 코드의 대부분은 해당 시스템에서 변경 없이 실행된다. 예를 들어, SGI 인텔 x86 기반 워크스테이션은 IBM PC 호환기종 워크스테이션이 아니었지만, HAL 덕분에 윈도우 2000은 이들에서 실행될 수 있었다.^[4]

윈도우 비스타 및 윈도우 서버 2008부터 사용되는 HAL은 시작 시 자동으로 결정된다.^[5]

AS/400

HAL의 "극단적인" 예시는 현재 IBM i 운영체제에 구현된 System/38 및 AS/400 아키텍처에서 찾을 수 있다. 이들 시스템의 대부분의 컴파일러는 추상 머신 코드를 생성한다. Licensed Internal Code(LIC)는 이 가상 머신 코드를 실행 중인 프로세서의 네이티브 코드로 변환하고 결과 네이티브 코드를 실행한다.^[6] (예외는 LIC 자체를 생성하는 컴파일러이며, 이 컴파일러는 IBM 외부에서는 사용할 수 없다.) 이는 LIC 계층 위의 응용 프로그램 소프트웨어 및 운영체제 소프트웨어가 원래 S/38에서 컴파일된 상태로 최신 AS/400 시스템에서도 수정 없이 재컴파일 없이 실행될 정도로 성공적이었다. 이는 기본 하드웨어가 극적으로 변경되었음에도 불구하고 적어도 세 가지 다른 유형의 프로세서가 사용되었다.^[6]

안드로이드

안드로이드는 버전 8.0 "오레오"에서 "벤더 인터페이스"(코드명 "Project Treble")로 알려진 HAL을 도입했다. 이는 안드로이드 OS 프레임워크에서 저수준 코드를 추상화하며, 펌웨어 업데이트 개발을 용이하게 하기 위해 향후 안드로이드 버전을 지원하도록 전방 호환성을 가져야 한다.^[7] Project Treble 이전에는 안드로이드는 다양한 비표준화된 레거시 HAL에 의존했다.^[8]

Halium은 우분투 터치 및 LuneOS와 같은 여러 모바일 운영체제가 안드로이드가 사전 설치된 스마트폰에서 실행되도록 사용되는 안드로이드 기반 HAL이다.

같이 보기

• 펌웨어
• BSP (임베디드)
• HAL (소프트웨어)
• 보호 링