Programming for EFI:
Why Write for EFI?
by Roderick W. Smith, rodsmith@rodsbooks.com
Originally written: 5/3/2013
I'm a technical writer and consultant specializing in Linux technologies. This Web page is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!
| Donate $1.00 |
Donate $2.50 |
Donate $5.00 |
Donate $10.00 |
Donate another value |
|
|
|
|
|
|
Note: This page is a sub-page of my Programming for EFI document. If a Web search has brought you here, you may want to start at the introductory page.
EFI is a pre-boot environment, meaning that it, and the programs that run under it, work before a full OS has been booted. This fact makes EFI the ideal environment for certain types of programs, and a good environment for others. The fact that a full OS need not boot to run an EFI program means that users can run an EFI program quickly, from computer power-on to running program. More importantly, the EFI environment is devoid of certain complications associated with modern OSes, such as multi-tasking, which can wreak havoc with the precision timing requirements of some scientific and industrial uses of a computer. Consider the following broad classes of programs:
- Boot managers—These programs present a menu of boot
choices. Such programs are almost always written to run before an OS
kernel takes over. On an EFI computer, these programs are written for
the EFI environment.
- Boot loaders—Boot loaders load an OS kernel, and sometimes
associated data, into memory and execute it. Like boot managers, this
means that they're generally written for the EFI environment on
EFI-based computers.
- Firmware setup tools—For decades, PC users have dealt with
the simple, and usually text-based, BIOS setup utilities. The first
couple generations of UEFI PCs have had similar tools, sometimes with
some mouse integration and simple GUI elements. EFI, though, makes it
possible for anybody with sufficient programming skill to write tools
that provide access to at least some of the features controlled by such
tools. The EFI shell is a limited example of such a tool, but much more
could be done along these lines.
- Security tools—The shim and PreBootloader
programs are hard to classify. They enable an EFI computer with Secure
Boot active to boot a third-party boot loader, the goal being to boot
Linux in Secure Boot mode without compromising open source
principles.
- EFI drivers—These programs give the EFI access to a
hardware device or a filesystem. They're often incorporated into
motherboards' or plug-in devices' firmware, but they can be loaded
during the boot process to extend the computer's capabilities for the
benefit of the boot manager, boot loader, or other pre-boot
programs.
- Hardware diagnostics—Tools to check memory, CPU, disk
status, and more could all be written to run under EFI. This would have
the advantage of using fewer system resources than running under a full
multi-tasking OS such as Linux or Windows, which might be important in
finding certain types of faults.
- Scientific and industrial programs—In theory, running a
scientific data-collection program or an industrial program that relies
on precise timing might work better under EFI than under a
multi-tasking OS such as Linux or Windows. In practice, I don't know of
any examples of such programs that run under EFI, and I don't know if
this theoretical advantage would translate into any practical
differences.
- User programs—Tools such as shells, VNC clients, Web
browsers, word processors, and more could all theoretically be written
for EFI. In practice, of course, running such programs under a full OS
is probably advantageous; but there is something to be said for running
some programs from EFI. A dedicated VNC thin-client computer, for
instance, could boot into the thin client very quickly if it were
written for EFI. To the best of my knowledge, such tools are extremely
rare under EFI at the moment.
- Servers—Although there's likely to be little or no
advantage to running a major server such as a mail or HTTP server under
EFI, there is something to be said for running an SSH, VNC, or other
remote-login server under EFI. Namely, such a server could give you
remote access to system configuration options that might otherwise be
accessible only to local users. This could be helpful for network
hosting providers and users of their services.
- Programming tools—In theory, you could write a compiler or
debugger to run under EFI, and doing this might help speed development
of EFI programs. Porting an interpreted language, such as Python or
Perl, to run under EFI would open up a wealth of existing programs to
run under EFI. To the best of my knowledge, no such tools exist, with
the exception of a simple batch processing language included as part of
the EFI shell.
Examples of most of these program categories exist, although some are rather thin on the ground. Some programs also span multiple categories—for instance, GRUB 2 is both a boot manager and a boot loader; and the EFI shell could be considered a firmware setup tool, a user program, and a programming language. In any event, it's clear that the EFI's potential as a platform for a wide variety of programs has barely been tapped. To be sure, the EFI's primary job is to boot a more sophisticated OS, but as time progresses, I'm sure we'll see creative programs emerge to help out during that process or to perform important but seldom-needed functions before an OS boots.
Some of these examples assume the presence of a network stack. Such a stack does exist, and is built into some computers' firmware. If your computer lacks such a stack, though, adding it is difficult at best, since you'll need to track down all its components, including drivers for your network hardware. Of course, if you're a good enough programmer, you could write the necessary components yourself!
Go on to "Preparing a Development Environment"
Return to the "Programming for EFI" main page
copyright © 2013 by Roderick W. Smith
If you have problems with or comments about this Web page, please e-mail me at rodsmith@rodsbooks.com. Thanks.
Return to my main Web page.