하드웨어 추상화
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
하드웨어 추상화 계층(HAL)은 컴퓨터의 하드웨어와 소프트웨어 사이에 위치하여 하드웨어의 차이점을 숨기는 추상화 계층이다. HAL은 운영 체제 커널이 다양한 하드웨어에서 작동하도록 하여 이식성을 높이고, 소프트웨어 개발자가 하드웨어 세부 사항에 얽매이지 않고 프로그래밍할 수 있도록 한다. Windows, BSD, macOS, Linux, Android, AS/400 등 다양한 운영 체제에서 HAL이 사용되며, DirectX에서도 그래픽 하드웨어를 추상화하기 위한 HAL 장치가 존재한다.
초기 컴퓨터 시스템은 하드웨어 추상화 개념이 없었기 때문에 소프트웨어 개발자는 모든 하드웨어 장치와 통신하는 방식을 알아야 했다. 이는 소프트웨어 개발의 복잡성을 높이고 호환성 문제를 야기했다.
HAL은 운영 체제 커널과 하드웨어 사이의 인터페이스 역할을 하며, 커널이 하드웨어의 차이를 인식하지 않고도 작동할 수 있도록 한다.
2. 역사
하드웨어 추상화는 프로그램이 하드웨어와 직접 통신하는 대신, 운영 체제에 장치가 무엇을 해야 하는지 통신하고, 운영 체제는 장치에 하드웨어 종속적인 명령을 생성하는 방식이다. 이를 통해 개발자는 특정 장치가 어떻게 작동하는지 알 필요가 없어 프로그램 개발이 쉬워졌고, 호환성 문제도 해결되었다.
"조이스틱" 추상화나 교통 수단의 추상화(자전거 타기, 자동차 운전) 등이 그 예이다. PC에서는 비디오 입력, 프린터, 오디오 입력 및 출력, 블록 장치 등이 추상화의 예로 볼 수 있다.
2. 1. 하드웨어 추상화의 등장
초기 컴퓨터 시스템에는 하드웨어 추상화 형태가 없었다. 이 때문에 소프트웨어 개발자는 시스템의 모든 하드웨어 장치 작동 방식을 알아야 했고, 이는 소프트웨어의 호환성을 보장하는 데 큰 어려움을 주었다. 하드웨어 추상화를 사용하면, 프로그램은 하드웨어 장치와 직접 통신하는 대신 운영 체제와 통신한다. 운영 체제는 장치에 하드웨어 종속적인 명령을 생성한다. 이를 통해 프로그래머는 특정 장치의 작동 방식을 알 필요 없이 프로그램을 개발할 수 있게 되었고, 모든 장치와의 호환성을 확보했다.[4]
예를 들어, "조이스틱" 추상화가 있다. 다양한 물리적 구현을 가진 조이스틱 장치는 API를 통해 읽기/쓰기가 가능하다. 대부분의 조이스틱은 이동 방향을 보고할 수 있고, 많은 조이스틱은 외부 응용 프로그램에서 구성 가능한 민감도 설정을 가진다. 조이스틱 추상화는 하드웨어의 세부 정보(예: 레지스터 형식, I2C 주소)를 숨겨, 추상화된 API를 사용하는 프로그래머는 장치의 물리적 인터페이스를 이해할 필요가 없다. 이는 코드 재사용을 가능하게 한다. "앞으로 밀기"는 전위차계나 정전식 터치 센서에서 가져올 수 있으며, 둘 다 "이동" 관련 신호를 제공하는 한 유효하다.[5]
BSD, 리눅스, 윈도우 NT는 하드웨어 추상화 계층에 기반한다. 이 운영 체제들은 특정한 기능에 대한 하부 시스템을 가지고 있다.
2. 2. 하드웨어 추상화의 발전
AS/400 구조에서는 LIC(Licensed Internal Code) 구현과 인준된 내부 코드를 통해, 하드웨어(프로세서)가 3번이나 바뀌는 큰 변화에도 불구하고 이전 기종인 S/38 소프트웨어를 수정 없이 AS/400에서 실행할 수 있었다.[4]
BSD, 리눅스, 윈도우 NT는 하드웨어 추상화 계층(HAL)을 기반으로 한다. 이들은 특정 기능에 대한 하부 시스템을 가지고 있다. HAL 덕분에 운영 체제는 다른 하드웨어로 쉽게 이식할 수 있는데, 이는 특히 수십 종의 마이크로콘트롤러에서 작동해야 하는 임베디드 시스템에서 매우 중요하다.
윈도우 NT 기반 운영 체제는 커널 공간에 HAL을 가지고 있으며, 커널, 드라이버, 실행 서비스와 하드웨어 사이를 중재한다.[5] 이를 통해 Windows NT의 커널 모드 코드는 여러 메모리 관리 유닛 아키텍처의 프로세서와 다양한 I/O 버스 아키텍처를 가진 시스템으로 이식될 수 있었다. 코드 대부분은 해당 시스템의 명령어 집합 아키텍처로 컴파일하기만 하면 소스 코드를 수정하지 않고도 실행할 수 있다.
BSD, macOS, 리눅스, CP/M, DOS, Solaris와 같은 운영 체제에도 HAL에 해당하는 부분이 존재하지만, 명확하게 HAL로 인식되거나 구분되지는 않는다. 리눅스는 Adeos와 같이 실행 중에 HAL을 삽입할 수 있다. NetBSD는 HAL 계층을 명확하게 구분하며, 이식성이 매우 높다. 이 시스템은 [http://netbsd.gw.com/cgi-bin/man-cgi?uvm+9+NetBSD-current uvm(9)], [http://netbsd.gw.com/cgi-bin/man-cgi?pmap+9+NetBSD-current pmap(9)], [http://netbsd.gw.com/cgi-bin/man-cgi?bus_space+9+NetBSD-current bus_space(9)], [http://netbsd.gw.com/cgi-bin/man-cgi?bus_dma+9+NetBSD-current bus_dma(9)]와 같은 하위 시스템으로 구성된다. ISA, EISA, PCI, PCI-E 등 여러 아키텍처에서 사용되는 I/O 버스도 추상화되어 있으며, 장치 드라이버도 최소한의 수정만으로 이식 가능하다.
System/38과 System i 아키텍처는 HAL의 극단적인 예시이다. 이 시스템의 컴파일러 대부분은 추상화된 기계어 코드를 생성한다. LIC는 이를 시스템 프로세서용 코드로 변환하여 실행한다. LIC 계층 위의 애플리케이션이나 운영 체제(OS) 코드는 System/38에서 AS/400으로 이전할 때 수정하거나 다시 컴파일할 필요가 없었다. (System/38과 AS/400에서는 최소 3가지 종류의 전혀 다른 프로세서가 사용되었다.)
HAL은 커널 대신 하드웨어와 직접 상호 작용하므로, 인터페이스는 운영 체제의 API보다 하위에 있다. 따라서 HAL 처리에 걸리는 시간은 API (시스템 호출)에 걸리는 시간보다 짧아야 한다.
3. 운영 체제에서의 HAL
HAL이 정의된 운영 체제는 다양한 하드웨어에 쉽게 이식 가능하다. 이는 매우 다양한 플랫폼에서 동작할 것을 요구받는 임베디드 시스템에서 특히 중요하다. 다수의 CPU 아키텍처마다 동작 방식의 차이가 있더라도, 적절하게 설계된 HAL을 준비하면 동작할 수 있다. 따라서 시스템을 개발할 때 하드웨어의 차이를 의식하지 않고 설계할 수 있다.
HAL은 커널 대신 하드웨어와 직접 상호 작용하기 때문에, 그 인터페이스는 OS의 API보다 하위에 존재한다. 따라서 HAL의 처리에 걸리는 시간은 API (시스템 호출)에 걸리는 시간보다 짧아야 한다.
CP/M (CP/M BIOS), DOS (DOS BIOS) 또한 HAL을 가지고 있다.
3. 1. Microsoft Windows
Windows NT 커널은 하드웨어와 NTOSKRNL.EXE 파일에 포함된 실행 서비스 사이의 커널 공간에 HAL을 가지고 있으며, 이는 ''%WINDOWS%\system32\hal.dll''에 위치한다. 이는 Windows NT 커널 모드 코드를 다양한 프로세서, 서로 다른 메모리 관리 장치 아키텍처, 다양한 I/O 버스 아키텍처를 가진 시스템으로 이식할 수 있도록 한다. 대부분의 코드는 해당 시스템에 적용 가능한 명령어 집합으로 컴파일될 때 해당 시스템에서 변경 없이 실행된다. 예를 들어, 실리콘 그래픽스(SGI)의 인텔 x86 기반 워크스테이션은 IBM PC 호환 워크스테이션이 아니었지만, HAL 덕분에 윈도우 2000은 해당 워크스테이션에서 실행될 수 있었다.[1]
윈도우 비스타 및 윈도우 서버 2008부터 사용되는 HAL은 윈도우 비스타 부팅 과정 중에 자동으로 결정된다.
다수의 CPU 아키텍처마다 동작 방식의 차이가 있더라도, 적절하게 설계된 HAL을 준비하면 동작할 수 있다. 따라서 시스템을 개발할 때 하드웨어의 차이를 의식하지 않고 설계할 수 있다. 이것들은 NT 기반의 마이크로소프트 윈도우 OS에서 사용되는 기술이다. NT 기반의 OS에는 커널 공간에 HAL이 있으며, 커널, 드라이버, 실행 서비스와 하드웨어의 중재를 한다.[4][5] 이로 인해 Windows NT의 커널 모드 코드는 여러 가지 다른 메모리 관리 유닛 아키텍처의 프로세서로 이식할 수 있으며, 다양한 I/O 버스 아키텍처의 시스템으로 이식할 수 있게 되었다. 코드의 대부분은 해당 시스템에서 단순히 해당 명령어 집합 아키텍처로 컴파일하기만 하면 소스 코드를 수정하지 않고 실행할 수 있다.
3. 2. BSD, macOS, Linux
BSD, macOS, 리눅스와 같은 운영 체제에도 HAL에 해당하는 부분이 존재하지만, 명확하게 HAL로 인식되거나 구분되지는 않는다. 리눅스 등에서는 동작 중인 커널에 대해 Adeos와 같은 HAL을 나중에 삽입할 수 있다. NetBSD는 HAL 계층을 명확하게 구분하며, 매우 이식성이 높다. 이 시스템은 `uvm(9)`, `pmap(9)`, `bus_space(9)`, `bus_dma(9)`와 같은 하위 시스템으로 구성된다. ISA, EISA, PCI, PCI-E 등, 여러 아키텍처에서 사용되는 I/O 버스도 추상화되어 있으며, 장치 드라이버도 최소한의 수정만으로 이식 가능하다.
3. 3. 안드로이드
안드로이드는 버전 8.0 "오레오"에서 "벤더 인터페이스"(코드명 "프로젝트 트레블")라고 알려진 HAL을 도입했다. 이는 안드로이드 OS 프레임워크에서 하위 레벨 코드를 추상화하며, 펌웨어 업데이트 개발을 용이하게 하기 위해 향후 안드로이드 버전을 지원하도록 순방향 호환성을 확보해야 한다.[2] 프로젝트 트레블 이전에는 안드로이드가 다양한 비표준 레거시 HAL에 의존했다.[3]
할리움은 우분투 터치 및 룬OS와 같은 여러 모바일 운영체제에서 안드로이드 기반 HAL을 사용하기 위한 프로젝트이다. 안드로이드가 미리 설치된 스마트폰에서 이들 운영체제를 실행하기 위해 사용된다.
3. 4. AS/400
AS/400 아키텍처는 하드웨어 추상화 계층(HAL)의 극단적인 예시이다. 이 시스템의 대부분의 컴파일러는 추상 머신 코드를 생성하며, 라이선스 내부 코드(LIC)가 이 코드를 실행 중인 프로세서의 네이티브 코드로 변환하여 실행한다. 이를 통해 LIC 계층 위에 있는 응용 소프트웨어 및 운영 체제 소프트웨어는 기본 하드웨어가 크게 변경되어도 수정 및 재컴파일 없이 실행될 수 있었다. 실제로 System/38에서 컴파일된 소프트웨어가 최신 AS/400 시스템에서 문제없이 실행되었으며, 이 과정에서 최소 세 가지 유형의 다른 프로세서가 사용되었다.
4. DirectX에서의 HAL
Windows용 멀티미디어 처리 API인 DirectX에는 하드웨어 추상화 계층(HAL)에 해당하는 구성 요소가 몇 가지 존재한다.
Direct3D는 그래픽스 하드웨어 (GPU)를 추상화하기 위한 HAL 장치를 제공하여, 벤더 공통 API를 통해 하드웨어 기능에 접근할 수 있게 한다.[6] DirectDraw는 드라이버를 사용자 모드에서 에뮬레이션하기 위한 HEL(Hardware Emulation Layer)을 가지고 있었다.[7] DirectSound는 사운드 카드의 하드웨어 지원을 위한 HAL을 포함했지만, Windows Vista 이후 소프트웨어 에뮬레이션으로 대체되었다.[8]
4. 1. Direct3D
DirectX의 구성 요소 중 하나인 Direct3D는 실시간 3차원 컴퓨터 그래픽스 API이다. Direct3D는 비디오 카드 등 그래픽 하드웨어 (GPU)를 추상화하기 위한 HAL 장치[6]를 제공한다. 이 HAL 장치를 통해 벤더 간의 차이를 흡수하여, 벤더 공통의 Direct3D API를 통해 하드웨어 기능에 접근할 수 있다.4. 2. DirectDraw
DirectDraw에는 드라이버를 사용자 모드에서 에뮬레이션하기 위한 HEL (Hardware Emulation Layer)이 있었다.[7]4. 3. DirectSound
DirectX의 구성 요소 중 하나인 DirectSound에도 사운드 카드의 하드웨어 지원을 이용하는 HAL이 있었지만, Windows Vista 이후에는 소프트웨어 에뮬레이션으로 대체되었다.[8]5. HAL의 장점 및 중요성
HAL은 소프트웨어를 다양한 플랫폼에서 쉽게 실행할 수 있게 해주는 중요한 기술이다. HAL 덕분에 소프트웨어 개발자는 특정 하드웨어의 세부 사항을 알 필요 없이 프로그래밍을 할 수 있다. 이는 개발 효율성을 크게 향상시킨다.
특히, 임베디드 시스템 개발에서 HAL의 중요성은 더욱 크다. 임베디드 시스템은 수십 종의 마이크로콘트롤러에서 동작해야 하는 경우가 많기 때문에, HAL을 통해 하드웨어 이식성을 확보하는 것이 필수적이다.[4][5]
HAL은 응용 프로그래밍 인터페이스(API)보다 하위에 존재한다. 따라서 HAL의 처리 시간은 API를 사용하는 것보다 짧아야 한다. 이는 시스템의 전반적인 성능에 영향을 미치는 중요한 요소이다.
NetBSD 운영 체제는 깔끔한 하드웨어 추상화 계층을 가진 것으로 널리 알려져 있다.
참조
[1]
웹사이트
Changing hardware abstraction layer in Windows 2000 / XP – Smallvoid.com
http://smallvoid.com[...]
2020-09-18
[2]
웹사이트
Google's "Project Treble" solves one of Android's many update roadblocks
https://arstechnica.[...]
2017-05-12
[3]
웹사이트
Conventional & legacy HALs
https://source.andro[...]
[4]
웹사이트
Windows NT Hardware Abstraction Layer (HAL)
http://support.micro[...]
Microsoft
2007-08-25
[5]
서적
Inside Windows NT
Microsoft Press
2007-08-25
[6]
문서
DirectX 用語集
https://docs.microso[...]
Microsoft Docs
[7]
문서
Hardware Emulation Layer - Windows drivers
https://docs.microso[...]
Microsoft Docs
[8]
문서
【4Gamer.net】［レビュー］Creative ALchemy
https://www.4gamer.n[...]
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com