Once your computer finishes the boot process and you’re firmly inside the operating system buzzing along, is there anything left for the BIOS to do?
The Role of the BIOS
With modern OSs, practically none. Linus Torvalds reportedly said its task is to “just load the OS and get the hell out of there”.
Older operating systems like MS-DOS relied on the BIOS for many tasks (e.g. disk access), by calling interrupts.
With modern OSs, the bootloader quickly switches into 32- or 64-bit mode and executes the OS kernel. The kernel can register its own interrupt handlers, which can be called by user-space applications. The kernel’s routines can be more portable (since they don’t depend on the specific hardware), more flexible (OS vendors can change them on demand rather than having to use whatever came with the hardware), more sophisticated (they can execute arbitrarily complex code rather than what was programmed into the BIOS), and more secure (since the OS can control access to shared resources and prevent programs from clobbering each other, implementing its own arbitrary permissions schemes).
To interact with specific hardware, OSs can load and use its own device drivers. So there’s no need for the OS or applications to call most BIOS routines at all. In fact, for security reasons, BIOS interrupts are even disabled. Since the BIOS lives in 16-bit real mode it’s harder to call for modern OSs.
While use of the BIOS is very limited while the OS runs, its functions are still peripherally used. For example, when a computer sleeps, the OS is not running and it ultimately falls to the firmware to set the hardware to the correct state to pause and resume the OS. These uses are generally limited to ACPIcalls rather than calls to the full BIOS interface. ACPI is a BIOS extension that brings power management under the control of the operating system (OSPM), as opposed to the previous BIOS-central system, which relied on platform-specific firmware to determine power management and configuration policy.
Note that officially “BIOS” refers to a particular firmware interface, but the term is commonly used to refer to computer firmware in general. Some recent computers (especially Apple ones) have replaced BIOS (sensu strictu) with UEFI, which of course then is what is called to implement these functions.
For more information about how the role of the BIOS has diminished over time, see Wikipedia.
Another SuperUser contributor, Simon Richter, gives us an overview of the things the BIOS still does:
The BIOS and Power Management
The BIOS provides a number of services to the Operating Systems, most of which are related to power management:
- modifying the CPU and bus clocks
- enabling/disabling mainboard devices
- expansion port power control
- suspend-to-disk and suspend-to-RAM
- resume event settings
Suspend-to-disk is implemented in the OS most of the time as the OS can restore its state faster (only the kernel state is reloaded, and program state swapped in when required, which is significantly faster than reloading the entire RAM), but the feature remains in the specification.
Suspend-to-RAM can not be implemented by the OS, as it relies on the BIOS skipping the RAM initialization and test, so the OS needs an API to tell the BIOS that it intends to be resumed with the current RAM contents. In order to provide this service, the BIOS asks the OS to leave a certain RAM area intact.
The interface for the OS for all BIOS services is a piece of virtual machine code that needs to be run on an emulator, and which generates the necessary I/O operations into the hardware. For suspend, this is generally implemented so that executing one of the hardware writes then triggers an interrupt, which transfers control to the BIOS.
0 comments:
Post a Comment