http://julipedia.blogspot.com/2006/02/calling-bios-from-within-kernel.htmlCalling the BIOS from within the kernel
NetBSD/i386's bioscall(9)
trampoline is one of those interesting and tricky things you come
across from time to time when reading kernel code. This apparently
simple kernel function lets the caller execute BIOS functions and
retrieve their results.
The BIOS (Basic Input/Output System) is the PCs "firmware". It initializes the hardware, starts the boot process (in a primitive way) and provides a set of utility functions in the form of software interrupts. These interrupts can be used by applications to do tasks such as reading disk sectors, gathering information about the hardware or switching the video mode, among many other things. This "library" is what concerns us now. x86 processors start their operation in real mode (MMU-less, 16-bit addressing) for compatibility reasons with the 8086. As the BIOS contains the very first code executed by the system, it has to be callable from real mode. The BIOS cannot either switch to protected mode due to compatibility reasons again: all the boot code is real mode code (not to mention some legacy OSes such as DOS). This means that all the functions it offers to applications were designed to be called from real mode and with 16-bit addressing. (N.B. I'm not sure if this is completely true; the BIOS could provide 32-bit functions to be executed in protected mode, but anyway this is not what we are interested in now.) Sometimes, these functions can be a very useful resource for the operating system, specially before it has set up its own device drivers. But... virtually all OS kernels now work in protected mode with 32-bit addressing. In such configuration, it's impossible to call real mode code because of its 16-bit addressing and its direct access to the hardware. So is it impossible to use those functions once the kernel has started? Of course not. But only if the kernel has not thrashed important memory regions nor put the hardware in an unknown status to the BIOS. (That is, the subset of available operations once the switch has happened is quite limited.) Assuming everything is OK, the kernel can switch back to real mode (non-trivial), issue the call to the BIOS function, grab the results, return to protected mode and feed those results (if any) to the caller. And you guessed right, this is what bioscall(9) does in an automated way. The manual page contains some more details and sample codes. By the way, the EFI (Extensible Firmware Interface) is Intel's replacement for the BIOS. All these compatibility issues should be gone, something that is certainly good to make the i386 platform better and free it from obsolete design issues. 
3 comments:
|
