하드웨어 추상화(Hardware Abstraction)
하드웨어 추상화(hardware abstraction)는 특정 플랫폼의 구체적인 부분과 하드웨어의 자원을 직접 접근을 흉내내는 소프트웨어들의 집합이다.
하드웨어 추상화는 프로그램 인터페이스를 통해 하드웨어 리소스에 대한 액세스 권한을 프로그램에 제공한다.
프로그래머가 장치 독립적인 프로그램을 작성하도록 하고 운영 체제의 하드웨어 호출을 무시함으로써 고성능의 응용 프로그램 작성을 허용한다
하드웨어 추상화 계층 (HAL, Hardware Abstraction Layer)
2.1 HAL (Hardware Abstraction Layer, 하드웨어 추상화 계층)
- 컴퓨터에서 프로그램이 수많은 하드웨어를 별 차이 없이 다룰 수 있도록 하는 추상화 계층
- OS가 컴퓨터 하드웨어와 소프트웨어 사이에 만들어주는 가교 역할
- 부팅 시 커널 영역 중에서 드라이버를 불러오는 커널의 영역이다.
2.2 특징
1. API처럼 사용
2. 특정 디바이스에 종속되지 않는 프로그래밍을 해줌
3. 비슷한 기능을 하는 디바이스라면 제조사에 따른 세세한 차이까지 프로그램이 직접 신경 쓸 필요 없음
4. 필요한 기능을 OS에 요청하면 나머지는 OS가 알아서 해줌
5. 대부분의 운영체제들은 HAL을 커널에 내장하고 있음
6. 어플리케이션이 PC의 시스템 메모리 CPU, 또는 기타 하드웨어 장치에 직접 접근하는 것을 막아줌
ex) GPS라는 API는 어플리케이션이 직접 하드웨어에 명령하지 않아도 하드웨어 정보를 얻을 수 있도록 도와줌
API처럼 사용하며 프로그래밍을 할땐 특정 디바이스에 종속되지 않는 프로그래밍을 하도록 해 준다. 비슷한 기능을 하는 디바이스라면 제조사에 따른 세세한 차이까지 프로그램이 직접 신경쓸 필요가 없이, 응용프로그램들이 HAL을 통해 호스트 시스템의 하드웨어를 발견하고 필요한 기능을 OS에 요청하면 나머지는 OS가 알아서 해 준다는 것이다.
과거에는 OS Kernel이 하드웨어를 조작하기 위한 추상적 인터페이스를 제공하였다. 시스템콜 인터페이스로 하드웨어 I/O를 디바이스 노드에 실행했는데, 하드웨어 종류가 다양하지 않을 때에는 괜찮은 방법이었다.
그러나 시간이 지나면서 하드웨어 종류는 수없이 늘어났고, Kernel은 새로운 장치들을 인식하거나 변화된 상태를 인식하는데 많은 어려움이 따랐다. 그래서 하드웨어 차이에 상관이 없는 하드웨어 인식 방법을 개발하고자 HAL이 개발되었다.
HAL은 하드웨어의 공급 업체에서 구현해야 하는 표준 인터페이스를 정의하며 OS에서 하위 수준의 드라이버 구현을 고려하지 않아도 되게 해준다. Driver(하드웨어)는 바뀌어도 APP쪽에서 사용하는 API는 그대로 사용하는 것이다. 따라서 하드웨어의 변경에 따라 APP단이 변경되지 않고, 상위 수준 시스템을 수정하거나, 시스템에 영향을 주지 않고도 하드웨어 관련 기능을 구현할 수 있다.
현재 HAL에서 한 걸음 더 나아가 API가 사용된다. 소프트웨어는 이미 구성되어 있는 API를 가지고 하드웨어를 작동시키면 된다. API는 직접 또는 HAL를 통해 하드웨어를 컨트롤 한다. 예로, GPS라는 API는 어플리케이션이 직접 하드웨어에 명령 하지 않아도 하드웨어 정보를 얻을 수 있도록 도와준다.
2.3 동작 원리
하드웨어들은 각각 D-Bus 객체라고 정의되어 고유 주소를 식별자로 사용하며, 어플리케이션들은 D-Bus IPC 라는 작동방식으로 하드웨어를 조작한다. HAL은 카메라가 연결되거나 DVD가 돌아가거나 노트북 덮개가 닫히는 등 하드웨어의 변화를 Signal로 감지하여 어플리케이션들이 그에 따라 반응 할 수 있도록 한다.
BSD, 리눅스, 윈도우NT는 하드웨어 추상화 계층에 기반하고 있다. 이 운영 체제들은 하드웨어 추상화 계층을 다른 하드웨어로 쉽게 이식할 수 있게 해준다. 이것은 특히 수십 종의 마이크로컨트롤러에서 작동할 임베디드 시스템에 중요하다.
리눅스에서는 HAL 소프트웨어가 현재 deprecated 되었는데, HAL 관련 기능을 담당하는 소프트웨어가 udev로 바뀐 것 뿐 관련 개념이 사라진 것은 아니다. 그리고 udev는 이후 systemd에 코드가 merge되었다.
2.4 HAL 구조체 정의 위치
Project/hardware/libhardware/include/hardware
2.5 HAL 모듈 빌드
HAL 구현은 모듈(.SO) 파일로 빌드되며 적절한 경우 Android에 의해 동적으로 링크됩니다.
각 HAL의 구현의 Android.mk파일을 생성하고 소스파일을 가리키는 방식으로 모듈을 빌드할 수 있습니다.
일반적으로 공유 라이브러리는 제대로 찾아서 로드할 수 있도록 특정 형식으로 이름이 지정되어야합니다.
이름 지정 체계는 모듈마다 다르지만 모두 일반적인 패턴인 <module_type>.<device_name>을 따릅니다
2.6 HIDL
HAL은 인터페이스 정의 언어 또는 HIDL은 HAL과 사용자간의 인터페이스를 지정하는 인터페이스 설명 언어이다.
이를 통해 인터페이스 및 패키지로 수집되는 유형 및 메서드를 호출할 수 있다.
HAL은 프로세스간 통신(ipc)에 사용하기 위한 것이다.
프로세스간 통신을 가리켜 "바인더화"라고 한다.
2.7 HAL이 해결하는 문제들
1. 상호운용성
다양한 아키텍처, 도구 모음, 빌드 구성으로 컴파일 할 수 있는 프로세스 간에 안정적으로 상호운용 가능한 인터페이스를 만든다.
2. 효율성
HIDL은 복사 작업 수를 최소화하기 위해
3. 직관적 실행
in 매개변수만 사용하여 전송을 위해 HIDL에서 데이터를 수신해도 데이터 소유권은 변경되지 않는다.
'Android OS' 카테고리의 다른 글
Android Boot & Init (3) | 2024.11.01 |
---|---|
Android Binder (1) | 2024.11.01 |
Android.mk (0) | 2024.10.31 |
Android Platform 구조 (0) | 2024.10.31 |
ADB : 안드로이드에 APK파일 설치하기 (0) | 2024.10.31 |