New Ways to Talk to Hardware

Twenty years from now, our desktops and servers will no

longer have the structure they have today. There will be new forms of hardware

and the definition of 'high-end' would have changed many times over. In such

a situation, the specifications drawn up in the last millennium can scarcely be

expected to fulfill the needs of the computing world. Instead, new ways to

interact with our hardware now and then must exist. Limitations of the current

environment are far too many; one of the biggest ones being recursively handed

down from the IBM PC era-that of a difference between the real and protected

mode. Already, OS have to run in protected mode from the start. And they grow

large and unwieldy with a number of drivers bundled in. Problems increase too,

as each vendor writes drivers for a plethora of platforms it must cater to, and

at the same time maintain levels of functionality and performance. A video card

for a PC cannot choose to work only in Windows today (and even in that, only for

a particular version). It needs to work equally well in Linux and UNIX, and any

number of platforms that the user might choose to deploy.

What's the cure?



The solution to this muddle is to close the box and take it back to

'square one', when OS did not carry drivers. Drivers are bundled within

hardware in a platform independent, OS independent, and software independent

manner. And they must be a transparent layer visible to the OS but not a part of

it. Visible to the BIOS of the system, and not a part of that either. It must be

small, not being so large itself that the rest of the system is starved for

memory. And it should do all that from a location where it can be managed and

kept up to date.

Immediate uses



The first immediate use such a technology can bring into effect is

virtualization at the lowest possible level. It would no longer be necessary to

have a middle layer for virtualization to abstract the components and sacrifice

on performance. The hardware driver layer itself could perform this process

transparently. This would be easy because the driver layer would lie between the

different OS running and the BIOS.

It is also theorized that since the drivers for the

hardware would be platform independent, hardware vendors do not need to develop

multiple versions of the same component for different types of systems (for

example, one set for 32 bit and another for 64 bit). The same physical component

would run identically without requiring any modifications to itself or to its

driver software on all platforms, under all OS environments.

This is also being promoted as the technology used to

realize the much-hyped 'Trusted Computing' dream. A pre-boot high-level

environment, that is free from the shackles of lower memory addressability and

limited instruction/function set, can be used to enforce a variety of pro-active

or passive security and protection mechanisms.

EFI based systems can also run specially written EFI

applications before the system is 'booted'. These applications can be for a

variety of purposes, such as enterprise-specific monitoring and management.

Introducing EFI



This is a technological innovation from Intel, called the Extensible

Firmware Interface or EFI for short. This is a specification that allows BIOS

vendors to develop their own implementation of a driver driven model BIOS. The

current version is 1.1 and is licensed from Intel. However, a part of the code

base of EFI has been released to the open source community under a project

called TianoCore (www.tianocore.org). Currently, the only desktop computers to

be shipping with EFI are the Intel-powered Macs. However, this doesn't mean

that the PC world will never see them, because the 64 bit editions of Win XP,

Server 2003, as well as the upcoming

Vista

releases are already EFI aware and fully support it. In fact,

Vista

is EFI-only, working with traditional ACPI and SMBIOS systems through something

called a CSM (Compatibility Support Module). The Linux world is on the EFI track

too. The RHEL, for instance, is already EFI ready. Servers such as those from

the 'Integrity' range from HP already feature the EFI BIOS. And to take

advantage of this, the HP-UX OS is also EFI aware. American Megatrends, the

vendor of 'AMIBIOS', has released their implementation of EFI 1.1 under the

name 'Aptio'.Aptio features support for abilities such as hidden system

partitions on hard disks, pre-boot environments, and an OS-less shell with a

variety of features (like disaster recovery, update over the Net and system

management). The system partition, for instance, can be used to store the

hardware drivers and the pre-boot environment software. And all of this is very

extensible, since developers can build their own features using a high-level C

language and hook into the EFI system using 32-bit API.

For BIOS-based systems, each hardware would require a driver at the OS level. This makes the software bulky and also necessitates separate drivers for each OS being run. With EFI, the drivers are integrated into the pre-OS environment removing such problems

EFI file system



The technology mandates the presence of at least one special partition on

the hard disk called the EFI partition. There are two kinds of EFI partitions

— one is the system partition, and other are regular partitions that contain

other EFI data. These partitions would contain a specific set of files. This FS

is based on the FAT format. The system partitions would use the FAT-32 system,

while any USB and removable media used will have the FAT-16 or FAT-12. The

partition contains bootable EFI images, config files and other directories.

These partitions would by definition have a '\EFI' and a TOOLS

sub-directory. The EFI engine would search within this tree for bootable images

after POST. EFI partitions cannot be mounted by the OS. This also prevents data

in the EFI from being corrupted.

Implications



As computers become more powerful with per-system resources being heavily

under-utilized in an average working day, technologies such as EFI would enable

off-the-shelf desktops to be better utilized. It would also reduce the burden of

providing several systems for competing platforms for the workers that need

them. Software developers can take advantage of this by having to produce only a

single version of products without worrying about platform and architectural

differences. The gap between x86, ia64, ppc and other architectures is now set

to close completely in the coming years.

Sujay V Sarma