Hardware abstraction
Hardware abstractions are sets of routines in
Hardware abstractions often allow programmers to write
Overview
Many early computer systems did not have any form of hardware abstraction. This meant that anyone writing a program for such a system would have to know how each hardware device communicated with the rest of the system. This was a significant challenge to software developers since they then had to know how every hardware device in a system worked to ensure the software's compatibility. With hardware abstraction, rather than the program communicating directly with the hardware device, it communicates to the operating system what the device should do, which then generates a hardware-dependent instruction to the device. This meant programmers didn't need to know how specific devices worked, making their programs compatible with any device.
An example of this might be a "Joystick" abstraction. The
As physical limitations (e.g. resolution of sensor, temporal update frequency) may vary with hardware, an API can do little to hide that, other than by assuming a "least common denominator" model. Thus, certain deep architectural decisions from the implementation may become relevant to users of a particular instantiation of an abstraction.
A good metaphor is the abstraction of transportation. Both bicycling and driving a car are transportation. They both have commonalities (e.g., you must steer) and physical differences (e.g., use of feet). One can always specify the abstraction "drive to" and let the implementor decide whether bicycling or driving a car is best. The "wheeled terrestrial transport" function is abstracted and the details of "how to drive" are encapsulated.
Examples of "abstractions" on a PC include video input, printers, audio input and output, block devices (e.g. hard disk drives or USB flash drive), etc.
In certain computer science domains, such as operating systems or embedded systems, the abstractions have slightly different appearances (for instance, Operating Systems tend to have more standardized interfaces), but the concept of abstraction and encapsulation of complexity are common, and deep.
The hardware abstraction layer reside below the
In operating systems
A hardware abstraction layer (HAL) is an
Operating systems having a defined HAL are more easily portable across different hardware. This is especially important for embedded systems that run on dozens of different platforms.
Microsoft Windows
The
Since
AS/400
An "extreme" example of a HAL can be found in the
Android
Halium is an Android-based HAL used by several mobile operating systems such as Ubuntu Touch and LuneOS to run on smartphones with Android pre-installed.
See also
- Basic Input/Output System(BIOS)
- Unified Extensible Firmware Interface(UEFI)
- Firmware
- Advanced Configuration and Power Interface(ACPI)
- Device tree
- Board support package (BSP)
- DeviceKit
- Haiku Device Kit
- HAL (software)
- Hardware-dependent software (HDS)
- Nanokernel
- Picokernel
- Protection ring
References
- ^ "Portability and supported hardware platforms". The NetBSD Foundation. Retrieved 12 May 2009.
- ^ "Windows NT Hardware Abstraction Layer (HAL)". Microsoft. 31 October 2006. Retrieved 25 August 2007.
- Bibcode:1993iwn..book.....C
- ^ "Changing hardware abstraction layer in Windows 2000 / XP – Smallvoid.com". 15 January 2001. Retrieved 18 September 2020.
- ISBN 978-0-7356-2530-3.
- ^ ISBN 978-1-882419-66-1.
- ^ "Google's "Project Treble" solves one of Android's many update roadblocks". Ars Technica. 12 May 2017. Retrieved 12 May 2017.
- ^ "Conventional & legacy HALs". Android Open Source Project.
Further reading
- "Advanced RISC Computing Specification" (PDF). MIPS Technologies. p. 23. Retrieved 26 February 2013.
- Silberschatz, Abraham; Galvin, Peter Bear; Gagne, Greg (2002). Operating System Concepts (6 ed.). ISBN 0-471-41743-2.