Method, apparatus and computer program product for debugging a computer's boot process

[0002] 1. Field of the Invention

[0003] This invention relates to the field of booting computer systems. Specifically, this invention is a method, apparatus, and computer program product for debugging the operation of the boot process used to start execution of a client program (such as an operating system) within a computer.

[0004] 2. Background

[0005] Most operating systems need to first be loaded into volatile memory prior to execution.

[0006] A typical computer operating system manages computer resources and provides services. For example, the operating system provides controlled access to the computer's resources (such as memory and devices). Usually, a firmware bootstrap program, stored in read-only-memory (ROM), controls a computer between the time the computer is turned on and the time the client program (such as an operating system or a secondary bootstrap program) takes control of the computer. The firmware bootstrap program is responsible for testing and initializing the computer hardware, determining the computer's configuration and devices, invoking the operating system and providing debugging facilities in case of failure.

[0007] A bootstrap process often causes a firmware program to execute to load a primary bootstrap program from a known (and reserved) location in storage (either local disk or network storage) into the computer's memory. The computer then starts execution of this primary bootstrap program. The primary bootstrap program is a very small stand-alone FCode or machine language program (for example, the primary bootstrap program on a Sun Microsystems, Inc., computer is limited to 8K bytes). Thus, its functionality is very limited. Generally, the primary bootstrap program has limited capability to use the computer's devices through FCode drivers (subsequently described in the Detailed Description) supplied with the device and to locate and load a secondary bootstrap program accessible from the boot device. The primary bootstrap program includes services that understand the file structure of the boot device. The primary bootstrap program then locates and loads a specified file from the boot device. This specified file may be a stand-alone program such as a diagnostic, an operating system, or a secondary bootstrap program. These stand-alone programs are client programs of their respective bootstrap programs.

[0008] The interaction between the client program, the FCode services, and the operating system services is complex and occurs while few system services are available to simplify debugging of the booting process. This situation is particularly true because a mixture of machine instructions and FCode instructions are being executed during the boot phase. This problem is exacerbated by the fact that the mix between FCode and machine instruction execution changes during the boot process.

[0009] Thus, the problem is that debugging the bootstrap process is difficult because of the complexity of the bootstrap process, the intermixing of execution modes, and the scarcity of debugging tools during the boot process.

[0010] One prior art approach to this problem is including debugging or tracing code within the secondary bootstrap program. However, this capability is not required in production code and if included increases the complexity of the secondary bootstrap program.

[0011] It would be advantageous to temporarily provide additional capability to the secondary bootstrap program for debugging and development purposes.

[0012] The present invention provides a mechanism for temporarily including bootstrap debugging code for use with a client program. The invention improves a user's ability to debug the computer boot process by providing an efficient mechanism for interposing additional or replacement functionality between the client program and the bootstrap services. A bootstrap service invocation made by the client program is intercepted and the computer performs the interposed functionality before providing the invoked service.

[0013] One aspect of the invention is a computer controlled method for debugging a boot process executing on a computer. The method executes a bootstrap program on the computer. The bootstrap program provides one or more services. The bootstrap program also initiates a bootstrap debug program. The bootstrap debug program intercepts a service invocation of the one or more services. The bootstrap debug program also captures service information that is related to the service invocation of the one or more services and performs the service invocation of the one or more services.

[0014] Another aspect of the invention is an apparatus, having a central processing unit (CPU) and a memory coupled to the CPU, for debugging a boot process executed by the apparatus. The apparatus includes a boot mechanism that is configured to execute, using said CPU and said memory, a bootstrap program providing one or more services. The bootstrap program uses a debug initiation mechanism that is configured to initiate a bootstrap debug program. The bootstrap debug program uses a service interception mechanism that is configured to intercept a service invocation of the one or more services. The apparatus also includes an information acquisition mechanism that is configured to capture service information related to the service invocation of the one or more services. In addition, the apparatus includes a service invocation mechanism that is configured to perform the service invocation of the one or more services.

[0015] Yet a further aspect of the invention, is a computer program product embedded on a computer usable medium for causing a computer to debug a boot process executed by the computer. When executed on a computer, the computer readable code causes a computer to effect a boot mechanism, a debug initiation mechanism, a service interception mechanism, an information acquisition mechanism, and a service invocation mechanism. Each of these mechanisms having the same functions as the corresponding mechanisms for the previously described apparatus.

[0016] An additional aspect of the invention is computer program product embodied in a carrier wave. The carrier wave transmits computer readable code therein for causing a computer to debug a boot process executed by the computer. When executed on a computer, the computer readable code causes a computer to effect a boot mechanism, a debug initiation mechanism, a service interception mechanism, an information acquisition mechanism, and a service invocation mechanism. Each of these mechanisms having the same functions as the corresponding mechanisms for the previously described apparatus.

[0017] The foregoing and many other aspects of the present invention will no doubt become obvious to those of ordinary skill in the art after having read the following detailed description of the preferred embodiments that are illustrated in the various drawing figures.

[0018] FIG. 1 illustrates a computer system capable of executing computer readable program code, thus embodying the invention in accordance with a preferred embodiment;

[0019] FIG. 2 illustrates a prior-art boot service dispatch mechanism;

[0020] FIG. 3A illustrates a boot service dispatch mechanism in accordance with a preferred embodiment;

[0021] FIG. 3B illustrates a cascaded boot service dispatch mechanism in accordance with a preferred embodiment;

[0022] FIG. 4A illustrates a debug enabled boot process in accordance with a preferred embodiment;

[0023] FIG. 4B illustrates an intercept service process in accordance with a preferred embodiment;

[0024] FIG. 4C illustrates an intercept service process used with the set-callback service in accordance with a preferred embodiment;

[0025] FIG. 4D illustrates an intercept service process used with the callback service in accordance with a preferred embodiment; and

[0026] FIG. 5 illustrates debug information presentation process in accordance with a preferred embodiment.

[0027] This document incorporates by reference the “definition of terms” (section 2.3) of IEEE except where such terms are superceded by subsequently directly or indirectly defined terms.

[0028] Detailed Description

[0029] The invention uses a computer. Some of the elements of a computer, as indicated by general reference character 100, configured to support the invention are shown in FIG. 1 wherein a processor 101 is shown, having a central processor unit (CPU) 103, a memory section 105 and an input/output (I/0) section 107. The I/O section 107 is connected to a keyboard 109, a display unit 111, a disk storage unit 113 and a CD-ROM drive unit 115. The CD-ROM drive unit 115 can read a CD-ROM medium 117 that typically contains a program and data 119. The computer 100 also includes a network interface 121 that is used to access a network 123. In addition, the computer 100 includes a FCode interpreter ROM 125 that includes computer instructions that enable the computer 100 to interpret FCode programs. The FCode interpreter ROM 125 also includes a FCode program to determine the configuration of the computer 100 and to load a primary bootstrap program from a designated primary boot device using that device's FCode device driver program. Such a FCode device driver program resides in a FCode disk device driver ROM 127. The FCode disk device driver ROM 127 contains a FCode device driver that can be used by the CPU 103 to access data on the disk storage unit 113. The CD-ROM drive unit 115 includes a FCode CD device driver ROM 129 that contains a FCode device driver that can be used by the CPU 103 to access data accessible using the CD-ROM drive unit 115. The network interface 121 contains a FCode network device driver ROM 131 that contains a FCode device driver that can be used by the CPU 103 to access the network 123. In addition, the memory section 105 includes storage for a program storage memory region 133 that contains a portion of a program that causes the computer to perform the inventive process.

[0030] The CD-ROM drive unit 115, along with the CD-ROM medium 117, the disk storage unit 113, and the network 123 comprise a file storage mechanism. Such a computer system is capable of executing applications that embody the invention. One skilled in the art will understand that the computer system illustrated in FIG. 1 includes devices that may not be needed for each embodiment of the invention.

[0031] When the computer 100 is initially powered up, programs in the FCode interpreter ROM 125 are invoked to determine the computer's configuration and to load the primary bootstrap from the primary bootstrap device.

[0032] FIG. 2 illustrates a prior art boot service dispatch mechanism, indicated by general reference character 200, used to dispatch service requests for boot time services. A primary bootstrap program 201 obtains a boot-time service by invoking the service through a firmware operation vector 203. The firmware operation vector 203 is used to dispatch a service invocation to the appropriate service routine such as a first service procedure 205 or an nth service procedure 207. One of the one or more service procedures 205, 207 may be configured to invoke other procedures based on arguments provided during the service invocation. These service procedures may comprise FCode or machine instructions. In addition to the primary bootstrap program 201, a secondary bootstrap program 209, that is loaded and invoked from the primary bootstrap program 201, may also use the firmware operation vector 203 to obtain boot-time services. The primary bootstrap program 201 invokes services through the firmware operation vector 203 as indicated by a service invocation 211. The secondary bootstrap program 209 invokes services through the firmware operation vector 203 as indicated by a service invocation 213. The secondary bootstrap program 209 creates a bootstrap service vector 215 that is used by the secondary bootstrap program's client program to invoke procedures within the secondary bootstrap program 209 as indicated by a service dispatch 217. The bootstrap service vector 215 is activated when its address is passed to a stand-alone program 219 that uses the bootstrap service vector 215 to invoke the services provided by the secondary bootstrap program 209 (that may use the services of the one or more service procedures 205, 207) as indicated by a service invocation 221. The stand-alone program 219 is the client program for the secondary bootstrap program 209 and is often an operating system program, a diagnostic program or other independent program. The bootstrap service vector 215 may contain pointers to procedures in the secondary bootstrap program 209 for services indexed through the bootstrap service vector 215. The bootstrap service vector 215 may also contain a pointer to a service dispatch procedure in the secondary bootstrap program 209 that dispatches the invocation to a service procedure dependent on an argument (such as a service name string) provided with the service invocation. This latter mechanism enables the addition of new named services without the need to explicitly resolve links.

[0033] Often, the bootstrap program is written in a computer independent interpreted language such as the FCode programming language (defined by IEEE Standard for Boot(Initialization Configuration) Firmware: Core Requirements and Practices, IEEE std 1275-1994, © 1994 Institute of Electrical and Electronic Engineers, Inc., ISBN 1-55937-426-8 and incorporated herein by reference in its entirety (hereinafter referred to as IEEE). Use of a computer independent language for the bootstrap program allows devices to include their own device drivers (a “plug-in drive”) that are independent of the computer or the computer's operating system. These device drivers may also provide information about the device such that the bootstrap program can automatically configure the computer's devices. Such devices include memory allocation drivers. More information about booting is provided in Annex F of IEEE.

[0034] The firmware bootstrap program can access the device driver firmware stored with the device to perform operations on the device. For efficiency reasons, these firmware device drivers are generally not used when the final operating system program is executing. Instead, the operating system uses device drivers that provide complete functionality, that have been compiled to the computer's native instruction set and optimized for performance.

[0035] Some computers use the firmware bootstrap program to directly load the computer's operating system, diagnostic program or other stand-alone program. Other computers use the firmware bootstrap program to load a primary bootstrap program from a well-known location on a specified device. The loaded primary bootstrap program then loads and executes the client program (such as an operating system or a more complex bootstrap program). The primary bootstrap program may use the firmware device drivers until the client program is stable.

[0036] The secondary bootstrap program includes capabilities used to boot the operating system's kernel and initialize other operating system services. Generally, the secondary bootstrap program contains procedures that access a limited number of boot time services. The secondary bootstrap program loads the relevant portions of the operating system into the computer, and stages and directs the steps used in the booting process. The secondary bootstrap program generally includes complete file system and memory allocation capability. The secondary bootstrap program may also determine or verify the computer system's configuration (including such things as the number of CPUs, accessible devices, size of cache and other configuration information as is understood by one skilled in the art).

[0037] The secondary bootstrap program uses the firmware device drivers until the operating system (or other client program) is sufficiently operational to provide those services. Thus, the secondary bootstrap program uses FCode boot services and operating system services to boot the computer. This interaction between the FCode services and the operating system services is controlled through the use of client callback services.

[0038] FIG. 3A illustrates a boot service dispatch mechanism, indicated by general reference character 300, that captures service invocations. Here a bootstrap debug program 301 is loaded by the secondary bootstrap program 209 instead of the stand-alone program 219. When required, the bootstrap debug program 301 accesses services provided by the secondary bootstrap program 209 through the bootstrap service vector 215 as indicated by a service invocation 303. In addition, the bootstrap debug program 301 can directly access the one or more service procedures 205, 207 through the firmware operation vector 203 as indicated by a service invocation 305. The bootstrap debug program 301 may also contain replacement code corresponding to the one or more service procedures 205, 207 or services provided by the secondary bootstrap program 209 such that the bootstrap debug program 301 could replace some or all of the functionality provided by the secondary bootstrap program 209 and the one or more service procedures 205,207. The bootstrap debug program 301 may also contain debugging procedures that gather and save information about requested services. One skilled in the art will understand that the “bootstrap debug program” terminology does not limit the functionality provided by the bootstrap debug program 301. The “bootstrap debug program” term includes, without limitation, a subsequent bootstrap program, an operating system program, a utility program, a debugging program, a tracing program, a filesystem extension program, a network protocol stack program, and a diagnostic program.

[0039] The bootstrap debug program 301 loads and invokes its client program (the stand-alone program 219). The bootstrap debug program 301 activates a debug service vector 307 by passing it to the stand-alone program 219. Thus, the stand-alone program 219 will use the debug service vector 307 instead of the bootstrap service vector 215 to invoke services as indicated by the service invocation 221. The debug service vector 307 passes the service invocation to the bootstrap debug program 301 (as indicated by a service dispatch 309) where the request is processed. The bootstrap debug program 301 captures service information about the service request, saves this information for later presentation to the user, and then performs the requested service by invoking the requested service using the bootstrap service vector 215 or the firmware operation vector 203. One skilled in the art will understand that other approaches exist in the art for providing the previously discussed vectors.

[0040] As is subsequently described, the bootstrap debug program 301 generally gathers information about the service invoked by the debug program's client program (such as the stand-alone program 219). This information can be saved for later presentation to the user, used to trigger on-line debugging functions, or used by custom procedures within the bootstrap debug program 301 to modify the invocation. One preferred embodiment maintains a trace of which services were invoked by the stand-alone program 219. Another preferred embodiment provides interactive debugging capabilities that are triggered when a service is invoked by the client program. Another preferred embodiment provides replacement code that, when executed, provides new or modified services normally provided by the bootstrap's parent program. Debug programs can be cascaded to allow the user to select specific combinations of debugging features.

[0041] FIG. 3B illustrates a cascaded boot service dispatch mechanism, indicated by general reference character 330, that captures specific service invocations. Here a first bootstrap debug program 331 is loaded by the secondary bootstrap program 209. The first bootstrap debug program 331 accesses services provided by the secondary bootstrap program 209 through the bootstrap service vector 215 as indicated by a service invocation 333. In addition, the first bootstrap debug program 331 can directly access the one or more service procedures 205, 207 through the firmware operation vector 203 as indicated by a service invocation 305. The first bootstrap debug program 331 may also contain replacement code corresponding to the one or more service procedures 205, 207 or the secondary bootstrap program 209 such that the first bootstrap debug program 331 could replace some or all of the functionality provided by the secondary bootstrap program 209 and the one or more service procedures 205, 207. The first bootstrap debug program 331 may also contain debugging procedures that gather and save information about requested services.

[0042] The first bootstrap debug program 331 loads a second bootstrap debug program 335 as its client program passing a first debug operation vector 337. The first debug operation vector 337 passes service invocations to the first bootstrap debug program 331 as indicated by a service dispatch 339. The second bootstrap debug program 335 invokes services through the first debug operation vector 337 as indicated by a service invocation 341. The second bootstrap debug program 335 then loads its client program, the stand-alone program 219, activating a second debug operation vector 343 by passing it to the stand-alone program 219 for service invocations. These service invocations are indicated by a service invocation 345. These service invocations are passed to the second bootstrap debug program 335 as indicated by a service dispatch 347. In addition, the second bootstrap debug program 335 can directly access the one or more service procedures 205, 207 through the firmware operation vector 203 as indicated by a service dispatch 342.

[0043] The cascaded boot service dispatch mechanism 330 allows a user to include combinations of debugging programs that are targeted to specific problems that interest the user. Thus, the first bootstrap debug program 331 could be configured to capture information about a first service and the second bootstrap debug program 335 could be configured to capture information about a second service. The cascaded boot service dispatch mechanism 330 also allows a user to write a particular targeted debugging program that operates in addition to a more general debugging program such as a service trace program. In addition, new or modified boot services can be easily inserted, tested and removed. Once tested, the new or modified boot service can be included in the secondary bootstrap program 209 using traditional methods.

[0044] FIG. 4A illustrates a debug enabled boot process, indicated by general reference character 400, used to perform debugging operations on the bootstrap loading process. The debug enabled boot process 400 initiates at a ‘start’ terminal 401 and continues to an ‘invoke primary bootstrap’ procedure 403. The ‘invoke primary bootstrap’ procedure 403 is performed when the computer is powered up or in response to a start or restart command. This causes execution of code in the FCode interpreter ROM 125 that locates, loads and executes the primary bootstrap program from a well-known location on the boot device. The primary bootstrap program then loads the secondary bootstrap program at a ‘load secondary bootstrap’ procedure 405. Next, the secondary bootstrap program loads a debug program (as its client program) at a ‘load bootstrap debug program’ procedure 406. The secondary bootstrap program invokes the debug program's initialization procedure at an ‘invoke bootstrap debug program initialization’ procedure 407. The debug program's initialization procedure allocates a new service vector (or in some embodiments, may copy the contents of the original operation vector used by the primary bootstrap program to a re-vector vector and then replace the original operation vector with a second operation vector at the same location).

[0045] Once the new service vector is created, the debug program loads its client program into memory at a ‘load client program’ procedure 409. The client program includes (without limitation) a subsequent bootstrap program, an operating system program, a utility program, a debugging program, a tracing program, a filesystem extension program, a network protocol stack program, and a diagnostic program. Next, a ‘specify service vector’ procedure 411 specifies that the client program is to use the new service vector. A preferred embodiment passes the address of the service vector to the client program as an argument at an ‘invoke client program’ procedure 413 thus activating the new service vector. The client program then executes. Each service invocation through the provided service vector invokes procedures within the debug program as is subsequently described with respect to FIG. 4B. Eventually, the client program signals that the boot process is complete by invoking a termination service at a ‘client signals boot complete’ procedure 415. The termination service causes the debug program to perform any cleanup required for its termination at a ‘boot program cleanup’ procedure 417. The termination service also invokes the corresponding termination service in the secondary bootstrap program The debug enabled boot process 400 then completes through an ‘end’ terminal 419. The debug procedure also captures callback invocations, as is subsequently described.

[0046] FIG. 4B illustrates an intercept service process, indicated by general reference character 430, for intercepting and processing a service request from a client program. The intercept service process 430 initiates at a ‘start’ terminal 431 and continues to an ‘intercept service invocation’ procedure 433 that receives a service request via the appropriate operation vector or callback. The intercept service process 430 then saves service invocation information state at a ‘save service invocation state’ procedure 435 by saving information such as the stack pointer, status conditions, registers, and other information as required. In particular, this information may include (without limitation) a memory address, an invocation parameter, a data value, a time value, and a service identification. This saved service invocation state can be used when providing the requested service.

[0047] Next, the intercept service process 430 continues to a ‘gather service related information’ procedure 437 that gathers machine state information of interest to the author of the debug program and/or as related to the invoked service.

[0048] Machine state information is the state of the entire computer system or any portion of the computer system that can be determined by a computer program. Thus, the machine state information includes (without limitation) device state, memory usage, memory mapping state, and CPU state.

[0049] The bootstrap debug program is designed and programmed to gather such information as appropriate. The machine state information includes information that can be used to debug the service. Thus, if the operation is a memory allocation or deallocation operation, the bootstrap debug program could obtain the allocation state of the computer's memory. For services that are directly invoked through an address in a service vector, the invoked procedure saves its identification and the supplied arguments. For services invoked using a service dispatch procedure, the name of the requested service (provided as an argument) and the other arguments are saved. A ‘store state and information’ procedure 439 saves the service invocation information gathered by the ‘save service invocation state’ procedure 435 and the machine state information gathered by the ‘gather service related information’ procedure 437. This information can be saved by displaying the information on the console terminal, storing the information in non-volatile RAM, passing the information to the client program via a callback procedure, or by use of other mechanisms known to those skilled in the art. Next, the intercept service process 430 continues to a ‘restore service invocation state’ procedure 441 that restores the information gathered by the ‘save service invocation state’ procedure 435 and then provides the service requested by the client program at a ‘provide requested service’ procedure 443. The debug enabled boot process 400 can provide this service by performing a procedure that implements the service, or by invoking a service through the provided service vector. A ‘capture and save result’ procedure 444 then captures, saves and returns the result of the requested service and the intercept service process 430 completes through an ‘end’ terminal 445. Example details of the intercept service process 430 are subsequently provided for callback operations with respect to FIG. 4C and FIG. 4D.

[0050] FIG. 4C illustrates a set-callback service process, indicated by general reference character 450, for intercepting invocations of the set-callback service. The client program may use the set-callback service to specify that the bootstrap program (or the bootstrap debug program) calls a client procedure in response to some condition. The set-callback service process 450 initiates at a ‘start’ terminal 451 as a result of a set-callback invocation from the client. The set-callback service process 450 continues to a ‘receive set-callback invocation’ procedure 453 that receives the set-callback service request. Then, a ‘save service invocation state’ procedure 455 saves the set-callback invocation information. Next, a ‘gather service related information’ procedure 457 gathers machine state information of interest to the author of the debug program and/or as related to the invoked service. This information and the invocation information are stored by a ‘store information’ procedure 459. Next, the set-callback service process 450 determines whether the requested callback service exists in this (the local) debug program at a ‘local callback service exists’ decision procedure 461. If the callback service is locally provided by this debug program, the set-callback service process 450 continues to a ‘restore service invocation state’ procedure 462 that restores the service invocation state saved by the ‘save service invocation state’ procedure 455. Then the set-callback service process 450 continues to a ‘perform set-callback’ procedure 463 that satisfies the set-callback invocation. The set-callback service process 450 then completes through an ‘end’ terminal 465.

[0051] However, if the callback service is not local to the instant debug program, as determined at the ‘local callback service exists’ decision procedure 461, the set-callback service process 450 continues to a ‘restore service invocation state’ procedure 467. The ‘restore service invocation state’ procedure 467 restores the invocation state stored by the ‘save service invocation state’ procedure 455. Then a ‘pass set-callback’ procedure 469 passes the set-callback invocation to the program that invoked the instant debug program (the parent program) with modified arguments that specify that the callback be returned to the instant debug program instead of the client program. On return from the set-callback service invocation of the instant debug program's parent, the set-callback service process 450 continues to a ‘setup callback tracking’ procedure 471 that performs any required preparation necessary to receive the callback from the instant debug program's parent. Such preparation may include, without limitation, specifying dispatch tables or programmed-methods for handling the callback invocation from the parent program. The set-callback service process 450 completes through the ‘end’ terminal 465. Thus, as shown in FIG. 4D, when the parent program invokes the callback, the instant debug program receives the callback, saves information about the callback, and passes the callback to the client program. One skilled in the art will understand that the instant debug program may independently invoke the set-callback service of its parent program as well as passing set-callback service invocations from the client program to the parent program.

[0052] FIG. 4D illustrates a callback service intercept process, indicated by general reference character 480, for receiving a callback from a parent program, saving information related to the callback, and passing the callback to the client program. The callback service intercept process 480 initiates at a ‘start’ terminal 481 when the parent program invokes a callback routine specified by a set-callback service as described in FIG. 4C. A ‘receive callback’ procedure 483 in the debug program receives the callback from the parent program. The callback service intercept process 480 then saves the invocation state of the callback at a ‘save callback invocation state’ procedure 485 and gathers service related information at a ‘gather service related information’ procedure 487. Next, a ‘store gathered information’ procedure 489 presents the information to the user or stores the information for later retrieval. The callback service intercept process 480 then determines whether the callback invocation is to be serviced by the instant debug program or the client program at a ‘local callback service’ decision procedure 491. The ‘local callback service’ decision procedure 491 uses information saved at the ‘setup callback tracking’ procedure 471 of FIG. 4C to determine whether the callback is serviced by the instant debug program or the client program.

[0053] If the callback is to be serviced by the instant debug program, the callback service intercept process 480 continues to a ‘restore callback invocation state’ procedure 492 that restores the callback invocation state that was saved by the ‘save callback invocation state’ procedure 485 and performs the requested callback service at a ‘perform callback service’ procedure 493. Then the callback service intercept process 480 completes through an ‘end’ terminal 495.

[0054] However, if the callback is to be serviced by the client program, a ‘restore callback invocation state’ procedure 497 restores the invocation state saved by the ‘save callback invocation state’ procedure 485. Then information stored by the ‘setup callback tracking’ procedure 471 is used to pass the callback invocation to the client program at a ‘pass callback invocation’ procedure 499 and the callback service intercept process 480 completes through the ‘end’ terminal 495.

[0055] The callback mechanism illustrated by FIG. 4C and FIG. 4D and previously described allows the callback capability to be intercepted by each interposed debug program.

[0056] FIG. 5 illustrates a debug information presentation process, indicated by general reference character 500, for providing service information, stored by the ‘store state and information’ procedure 439 and the ‘capture and save result’ procedure 444, to a user. This process need not be performed if the debugging information was presented on the console as the computer system booted. This process is used when information about the boot process is stored for later retrieval. The debug information presentation process 500 initiates at a ‘start’ terminal 501 and continues to an ‘obtain user options’ procedure 503. The ‘obtain user options’ procedure 503 obtains user options from the boot command line or from information stored in non-volatile RAM or preference file. Next, an ‘access debug data’ procedure 505 retrieves the data stored by the ‘store state and information’ procedure 439. This data is organized and processed by an ‘organize debug data’ procedure 507 and presented to the user at an ‘present debug data’ procedure 509. The debug information presentation process 500 completes through an ‘end’ terminal 511.

[0057] One skilled in the art will understand that the invention provides additional functionality for the bootstrap process. In particular, the invention allows a user to include additional debugging, diagnostic, and execution tracing functionality (among others) during a computer's boot process.

[0058] From the foregoing, it will be appreciated that the invention has (without limitation) the following advantages. The invention:

[0059] 1) allows tracing of bootstrap services provided by a secondary bootstrap program;

[0060] 2) allows a system developer to replace the standard boot service with a new service for development and testing purposes;

[0061] 3) allows debugging operations to be triggered when a client program invokes a bootstrap service;

[0062] 4) allows callback operations to be monitored; and

[0063] 5) allows additional services to be added to a bootstrap process. These services include new filesystem services for non-native filesystem devices and network protocol stacks for specialized network access.

[0064] Although the present invention has been described in terms of a selection of presently preferred embodiments, one skilled in the art will understand that various modifications and alterations may be made without departing from the scope of the invention. Accordingly, the scope of the invention is not to be limited to the particular invention embodiments discussed herein, but should be defined only by the appended claims and equivalents thereof.