Why we need device drivers when we already have BIOS services

Question

I have a question in some quiz which I was unable to answer. Can anyone tell me:

Why are device drivers necessary given that BIOS already has code that communicate with the hardware?

Answer 1

Assuming you are talking about the traditional x86 BIOS, there are a couple of big issues:

1. The BIOS only has code to communicate with a limited subset of devices required to boot the system (storage controllers, Ethernet, USB keyboard/mouse, USB mass storage). The BIOS does not have a driver for your USB printer or webcam. Nor would it be practical. There are thousands of devices out there that need drivers. A BIOS cannot contain them all. It would also mean that every new hardware device would require a BIOS update.

2. The BIOS INT calls are sloooow and impractical for modern hardware. They are setup to read/write small chunks of data (read a few bytes from the disk, print a character on the screen). They do not have a mechanism to read several megabytes from a disk using DMA into a buffer. Keep in mind the original BIOS INT calls were developed for floppy drives and text mode displays.

3. The BIOS INT layer lives in real mode. Any modern OS is protected mode. To do a BIOS call in a modern OS, you have to drop to real mode, do the work, and then return to protected mode. This is a hugely expensive operation.

But what about UEFI? New PCs (pretty much anything designed for Windows 7 x64 and later) use UEFI firmware, not the legacy x86 assembly language BIOS. Although the UEFI firmware it is often still referred to as "the BIOS".

When UEFI first emerged, there was hope that it would lead to OS-independent drivers. UEFI provides a modern C-based API that is a little easier to work with. It has a concept of installable drivers. There are mechanisms for a modern OS to call UEFI services. However, this has not gained much traction. UEFI "drivers" are pretty much for pre-boot stuff. Once the OS takes over it does its own thing.

Using UEFI drivers in the OS would still impose performance overhead. Plus it would be difficult to integrate an "opaque" UEFI driver into the existing OSes. Each OS has layers of disk/filesystem drivers, networking stacks, USB, etc. They all do it a little bit differently, and it would be hard to get a UEFI driver to fit. (Ask again in about 10 years.)

Note that there is one other OS-independent "driver" layer that is used quite a bit in a modern laptop: ACPI. Many platforms have "drivers" in their ASL/AML code to provide simple event notification to your OS. The most common example would be the "special" buttons on your laptop above the keyboard for launching apps or controlling volume. Those buttons usually trigger an event handler that the OS responds to. It is a pretty simplistic notification system, though.