Method, apparatus, and computer-readable medium for generating a dispatching function

The routines to be called by the dispatching function are identified based on the contents of description files associated with the child modules containing the routines to be called. Once the routines to be called by the dispatching function have been identified, an initialization source file is generated that includes source program code for calling each of the identified routines. Once the initialization source file has been generated, the parent program module is built by compiling the individual routines to generate object code and then linking the compiled files to generate the parent program module. The resulting executable parent program module includes the proper calls to execute the identified routines.

TECHNICAL FIELD

The present invention is related to the development of executable program code.

More particularly, the present invention is related to generating a dispatching function in an executable program module in a computer system.

BACKGROUND OF THE INVENTION

In many computing systems, low level instruction code is used as an intermediary between the hardware components of the computing system and the operating software and other high level software executing on the computing system. In some computer systems, this low level instruction code is known as the Basic Input and Output System (“BIOS”). The BIOS provides a set of software routines that allow high level software to interact with the hardware components of the computing system using standard calls.

Because of limitations of the BIOS in many PC-compatible computers, a new specification for creating the firmware that is responsible for booting the computer and for intermediating the communication between the operating system and the hardware has been proposed. The new specification is called the Extensible Firmware Interface (“EFI”) specification and is available from INTEL CORPORATION. The EFI specification describes an interface between the operating system and the system firmware. In particular, the EFI specification defines the interface that platform firmware must implement and the interface that the operating system may use in booting. How the firmware implements the interface is left up to the manufacturer of the firmware. The EFI specification provides protocols for EFI drivers to communicate with each other, and the EFI core provides functions such as allocation of memory, creating events, setting the clock, and many others. This is accomplished through a formal and complete abstract specification of the software-visible interface presented to the operating system by the platform and the firmware.

Development of a BIOS or EFI firmware is a complicated and incredibly time consuming process. Historically, a BIOS firmware was developed as a single executable program. However, as the BIOS firmware became more complex, it became necessary to take steps to simplify the BIOS development process. One way in which this was done was by making the development of a BIOS firmware more modular. In particular, the core of the BIOS firmware was separated from a number of independent support modules. For instance, the BIOS firmware core was separated from the modules that provide support for particular vendor hardware. EFI by its very nature is a modular program.

In order for a BIOS or EFI firmware to utilize the services of the modules external to the core, it is necessary for the firmware to call initialization routines in each of the modules. To accomplish this, a dispatching function is created in the core that calls the initialization routines in each of the modules in a specific order. Typically, the dispatching function uses an explicit list of the initialization routines to be called. However, if the list of initialization routines changes, such as in the case of the addition or deletion of a routine to customize the firmware for a particular hardware configuration, the dispatching function must be manually modified to reflect the change. In the case of an extremely complex BIOS or EFI firmware that must be built many times to support a wide variety of hardware configurations, this can be an extremely frustrating and time consuming task for a firmware programmer.

It is with respect to these considerations and others that the various embodiments of the invention have been made.

SUMMARY OF THE INVENTION

In accordance with the present invention, the above and other problems are solved by providing a method, computer-readable medium, and apparatus for generating a dispatching function. Through the embodiments of the invention, one or more routines to be called by a dispatching function are identified, and the dispatching function is created without requiring a programmer to manually specify the routines.

According to one aspect of the invention, a method is provided for generating a dispatching function in a parent computer program module for calling one or more routines in one or more child modules. The parent computer program module may be a BIOS or EFI firmware core, and the child modules may comprise modules for customizing the operation of the firmware, such as for supporting various hardware devices. The routines within the child modules may comprise initialization routines for initializing the operation of each child module. Alternatively, the parent module may comprise any type of computer program wherein it is necessary to call one or more routines provided by other program modules.

According to one method, the routines to be called by the dispatching function are identified based on the contents of description files associated with the child modules containing the routines to be called. A description file is associated with each child module and includes a routine identifier that identifies the routine to be called within the child module and a parent program module identifier that identifies the parent program module. Child modules associated with description files that include a parent program module identifier that corresponds to a current parent program module are identified as being included with the parent program module.

Once the routines to be called by the dispatching function have been identified, an initialization source file is generated that includes source program code for calling each of the identified routines. Generating the initialization source file includes collecting the routine identifier from each identified child module into a list of routines to be executed, generating a macro for producing the initialization source file for calling each routine in the list of routines, and executing the macro to produce the initialization source file. The identifying and generating operations may be performed by a visual development environment. Additionally, the macro may comprise a “makefile” macro utilized by a make utility to build the initialization source file.

Once the initialization source file has been generated, the parent program module is built by linking the initialization source file with the source code of the parent program module. In this manner, the identity of each routine to be called is included in the source code of the parent program module. When the source code of the parent program module is built, therefore, the parent program module is linked with the appropriate child modules. The executable parent program module includes the proper calls to execute the identified routines.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the present invention provide methods, systems, apparatus, and computer-readable media for generating a dispatching function in a parent program module. In the following detailed description, references are made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments or examples. Referring now to the drawings, in which like numerals represent like elements through the several figures, aspects of the present invention and the exemplary operating environment will be described.

FIG. 1and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. While the invention will be described in the general context of program modules that execute in conjunction with a visual development environment that runs on an operating system on a computer system, those skilled in the art will recognize that the invention may also be implemented in combination with other program modules.

Turning now toFIG. 1, an illustrative computer architecture for practicing the embodiments of the present invention will be described. It should be appreciated that although the embodiments of the invention described herein are discussed in the context of a conventional desktop or server computer, the embodiments of the invention may be utilized with virtually any type of computing device.FIG. 1shows an illustrative computer architecture for a computer100that is operative to provide a visual development environment for creating executable computer programs, including programs that include a dispatching function. A dispatching function is a function that calls one or more routines located in the same or other program module.

In order to provide the functionality described herein, the computer100includes a baseboard, or “motherboard”, which is a printed circuit board to which a multitude of components or devices may be connected by way of a system bus or other electrical communication path. In one illustrative embodiment, a central processing unit (“CPU”)102operates in conjunction with a chipset104. The CPU102is a standard central processor that performs arithmetic and logical operations necessary for the operation of the computer.

The chipset104includes a north bridge106and a south bridge108. The north bridge106provides an interface between the CPU102and the remainder of the computer100. The north bridge106also provides an interface to the random access memory (“RAM”)114and, possibly, an on-board graphics adapter112. The north bridge106may also include functionality for providing networking functionality through a gigabit Ethernet adapter110. The gigabit Ethernet adapter110is capable of connecting the computer100to another computer via a network. Connections which may be made by the network adapter110may include local area network (“LAN”) or wide area network (“WAN”) connections. LAN and WAN networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. The north bridge106is connected to the south bridge108.

The south bridge108is responsible for controlling many of the input/output functions of the computer100. In particular, the south bridge108may provide one or more universal serial bus (“USB”) ports116, a sound adapter124, an Ethernet controller134, and one or more general purpose input/output (“GPIO”) pins118. The south bridge108may also provide a bus for interfacing peripheral card devices such as a graphics adapter130. In one embodiment, the bus comprises a peripheral component interconnect (“PCI”) bus. The south bridge108may also provide a system management bus132for use in managing the various components of the computer100. Power management circuitry126and clock generation circuitry128may also be utilized during the operation of the south bridge108.

The south bridge108is also operative to provide one or more interfaces for connecting mass storage devices to the computer100. For instance, the south bridge108may include a serial advanced technology attachment (“ATA”) adapter for providing one or more serial ATA ports120and an ATA 100 adapter for providing one or more ATA 100 ports122. The serial ATA ports120and the ATA 100 ports122may be, in turn, connected to one or more mass storage devices storing an operating system and application programs. As known to those skilled in the art, an operating system comprises a set of programs that control operations of a computer and allocation of resources. An application program is software that runs on top of the operating system software and uses computer resources made available through the operating system to perform application specific tasks desired by the user.

The mass storage devices connected to the south bridge108, and its associated computer-readable media, provide non-volatile storage for the computer100. Although the description of computer-readable media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable media can be any available media that can be accessed by the computer100. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, DVD, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer.

A low pin count (“LPC”) interface may also be provided by the south bridge108for connecting a “Super I/O” device138. The Super I/O device138is responsible for providing a number of input/output ports, including a keyboard port, a mouse port, a serial interface, a parallel port, and other types of input/output ports. The LPC interface may also connect a read-only memory (“ROM”) device for storing a firmware136, such as an extensible firmware interface (“EFI”) firmware or a BIOS firmware that includes program code containing the basic routines that help to start up the computer100and to transfer information between elements within the computer100. The LPC interface may also be utilized to connect a non-volatile random access memory (“NVRAM”)137to the computer100. The NVRAM137may be utilized by the firmware136to store configuration data for the computer100.

It should be appreciated that the computer100may comprise other types of computing devices, including hand-held computers, embedded computer systems, personal digital assistants, and other types of computing devices known to those skilled in the art. It is also contemplated that the computer100may not include all of the components shown inFIG. 1, may include other components that are not explicitly shown inFIG. 1, or may utilize an architecture completely different than that shown inFIG. 1.

Referring now toFIG. 2, additional details will be provided regarding the operation of a dispatching function. As shown inFIG. 2, a parent program module200may include a dispatching function204for calling routines208A-208C in the child program modules202A-202C. In particular, the dispatching function204typically includes function calls206A-206C for calling each of the routines208A-208C in a particular order.

The function calls206A-206C have previously been manually coded by the programmer of the parent program module200. However, as described briefly above, this can be problematic when additional child modules must be added to the parent or when child modules are removed. In these cases, the function calls in the dispatching function204must be manually recoded by the programmer. This, however, can be time consuming and frustrating for a programmer, especially where the dispatching function204contains calls to many routines and where the parent program module200must be frequently rebuilt.FIGS. 3-4illustrate how the embodiments of the invention generate the dispatching function204without requiring that a programmer manually modify the dispatching function204when the routines to be included in the dispatching function204change.

Referring now toFIG. 3, details will be provided regarding the embodiments of the invention for generating a dispatching function. In particular,FIG. 3illustrates several software components that are executed by the computer100in order to generate a dispatching function204. The visual development environment302is graphical application that enables the creation of software projects from a collection of modules. Through the use of the visual development environment302, a new project may be created by simply assembling components, such as the modules202A-202C, from a library of components. The visual development environment302also provides the functionality described herein for generating a dispatching function204. It should be appreciated, however, that the embodiments of the invention are not limited to use within a visual development environment302, and that other types of development environments may be utilized in conjunction with the embodiments of the invention.

As shown inFIG. 3, a number of child program modules202A may be utilized in conjunction with a parent program module200. Each of the child modules202A-202C includes an initialization routine208A-208C, respectively, that is called by the dispatching function204. Other types of routines within the child modules202A-202C may also be called within the dispatching function204. Additionally, it should be appreciated that although three child program modules202A-202C are illustrated inFIG. 3, virtually any number of child modules may be utilized with the embodiments of the present invention.

According to embodiments of the invention, each child program module202A-202C has an associated module description file314A-314C. Each module description file314A-314C contains a routine identifier316A-316C that identifies the routine to be called from the dispatching function204. In one embodiment, the routine identifier316A-316C comprises an identifier for the initialization routine of the corresponding child program module. Each module description file314A-314C also contains a parent program module identifier318A-318C that identifies the parent program module that the corresponding child program module should be utilized with. As will be described in greater detail below, the visual development environment302utilizes the parent program module identifier318to determine which child program modules should be included with the current parent module being built. It should be appreciated that the module description files314A-314C are expressed using the system description language (“SDL”) in one embodiment of the invention. However, other types of languages such as the extensible markup language (“XML”) may be utilized to create the module description files314A-314C.

As will be described in greater detail below with respect toFIG. 4, the visual development environment302is operative to examine the parent program module identifiers318A-318C to identify modules202A-202C that should be included with the parent program module200currently being built. If the parent program module identifier for a particular child program module matches the current parent program module, then the routine identified by the routine identifier is added to the dispatching function204in the parent program module. If the parent program module identifier for a child program module does not match the current parent program module, then the routine identified by the routine identifier is not added to the dispatching function204in the parent program module. In this manner, only child program modules having data in the corresponding description file identifying the parent program module are included in the build.

Once the visual development environment302has identified the module description files314A-314C that are to be included with the current parent module, the visual development environment302creates a list of routines304. The list of routines304includes the data from the routine identifiers316A-316C of the matching description files314A-314C. In this manner, a list of routines304to be executed from within the dispatching function204is generated. The visual development environment302then generates a makefile macro306for producing an initialization source file307that includes source code for calling each of the routines in the list304. As known to those skilled in the are, “make” is a utility that automates the process of converting files from one form to another, doing dependency tracking and invoking external programs to do additional work as necessary. The make utility is used most frequently for compiling source code into object code, joining and then linking object code into executables. The Make utility uses “makefiles” to determine the dependency graph for a given output and the build scripts that need to be passed to the shell to build them. Makefile macros may also be utilized by a compiler to facilitate the creation of source code.

When the makefile macro306is executed during the build process308, the initialization source file307is generated. The initialization source file307includes program code to build an array of initialization routines retrieved from the external makefile macro306, and program code to call every function in the array. The parent module source code310comprises the source code for the executable parent program module200. The parent module source code310includes invocation of the program code to call every function in the array of initialization routines retrieved from the external initialization source file307. Accordingly, when the parent module source code310is linked with the initialization source file307, the appropriate function calls206A-206C are created in the dispatching function204. In this manner, when compiled, the parent module source code310results in an executable parent program module200that calls all of the routines208A-208C necessary for the operation of the parent.

It should be appreciate that, according to embodiments of the invention, the parent program module200comprises a BIOS firmware program. Alternatively, the parent program module200may comprise a firmware compatible with the EFI specification. Each of the child program modules202A-202C may provide support functionality to a core firmware program.

Turning now toFIG. 4, an illustrative routine400will be described illustrating the operation of the computer100and the visual development environment302for generating a dispatching function according to one embodiment of the invention.

It should be appreciated that the logical operations of the various embodiments of the present invention are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance requirements of the computing system implementing the invention. Accordingly, the logical operations ofFIG. 4, and making up the embodiments of the present invention described herein, are referred to variously as operations, structural devices, acts or modules. It will be recognized by one skilled in the art that these operations, structural devices, acts and modules may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof without deviating from the spirit and scope of the present invention as recited within the claims attached hereto.

The routine400begins at operation402, where the description files314A-314C are generated for each of the child modules202A-202C. In particular, the routine identifier316A that identifies the routine to be called from the dispatching function204and the parent program module identifier318A-318C are specified for each child program module. From operation402, the routine400continues to operation404, where the visual development environment302identifies the child modules202A-202C to be included in the build of the current parent program module200based on the contents of the description files314A-314C. As described above, if the parent program module identifier for a particular child program module matches the current parent program module, then the routine identified by the routine identifier is added to the dispatching function204in the parent program module.

From operation404, the routine400continues to operation406, where the visual development environment302creates a list of routines304that includes the routine identifiers for each of the child program modules202A-202C that are to be included in the build of the parent program module200. The routine400then continues to operation408, where the visual development environment302creates the makefile macro306for producing the initialization source file307that includes code for calling each of the routines identified in the list304.

Once the makefile macro306has been generated, the routine400continues to operation410, where the build process308is performed. The build process308includes executing the makefile macro306to produce the initialization source file307. The initialization source file307and the parent module source code310are compiled and then linked, thereby producing the executable parent program module200, that includes calls206A-206C to each of the routines208A-208C. Once the build process308has completed, the routine400continues to operation412, where it ends.

It will be appreciated that embodiments of the present invention provide methods, systems, apparatus, and computer-readable medium for generating a dispatching function. Although the invention has been described in language specific to computer structural features, methodological acts and by computer readable media, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific structures, acts or media described. Therefore, the specific structural features, acts and mediums are disclosed as exemplary embodiments implementing the claimed invention.