International Business Machines Corporation

Michael Stephen Williams

Bruce Gerard Mealey

Randal Craig Swanberg

James William Van Fleet

Mark D Rogers

Mark Elliott Hack

Jeffrey Scott Peek

To emulate an interrupt architecture in a data processing system, interrupt emulation code receives from an operating system a first call requesting access to a first resource in a first interrupt architecture. In response to receipt by the interrupt emulation code of the first call, the interrupt emulation code maps the first resource to a second resource in interrupt hardware of the data processing system. The mapping operation includes determining an identifier of the second resource in a different second interrupt architecture. The interrupt emulation code then initiates access to the second resource implemented by the interrupt hardware.

Method, system and program product for emulating an interrupt architecture within a data processing system

A method and system for memory page protection wherein new stack memory load/store instructions are defined for memory management. A corresponding operating system and compiler utilize these new stack memory load/store instructions. Whenever it is desired to have a block of memory used as a stack memory, the stack memory load/store instructions are used. A stack memory attribute is stored in a page table associated with the block of memory. Memory blocks having a stack memory attribute may be read and written into using only stack memory load/store instructions. If a normal load/store is attempted to a memory block having a stack memory attribute a error condition is indicated. Likewise a stack memory load/store to a block of memory not have a stack memory attribute will cause a error condition. Stack memory load/stores meant for one type of stack memory (e.g., program stack attribute) will also cause a fault if the stack load/store is attempted to another type of stack memory (e.g., processor stack). Stack memory (processor stacks), transparent to a programmer writing code for a processor employing stack memory attributes, would have a processor stack attributes assigned by the processor or CPU. Using this method and system, stack memory may be assigned anywhere in memory without creating wasted protected pages or having data corrupted by stack memory overruns or under runs. The operating system no longer needs to allocate specific space in memory as stack memory and likewise does not have to estimate how much memory will be needed for program stacks and processor stacks (e.g.IA64 register stacks).

Stack memory protection

Testing register bits and in particular bitmask registers is a method employed in many computer architectures (e.g., IBM PowerPC, IA32, VAX, etc.) to manage instruction flow within a processor. Since the testing or scanning of bitmask registers for the first occurrence of a logic state (e.g., logic one) is done quite often, register scanning is implemented in hardware in these processors. Other computer architectures (e.g., Intel IA64) manage instruction flow with alternate methods and therefore do register scanning as a software construct. When software written for the first computer architecture (e.g., IBM PowerPC) is ported to a system with IA64 architecture, the program would execute with reduced speed. The IA64 architecture uses the EPIC instruction protocol and as such executes predicate instructions that employ a predicate register where each bit of the predicate register can be associated as the true or false result of a comparison. To scan a register in the IA64 architecture the register contents are loaded into the predicate register and a sequence of predicate instructions are executed in the order that the bits are to be scanned for the desired condition. The sequence of predicate instruction sequence returns the register bit that passes the predicate condition. In this manner the speed of register scanning necessary for the ported software can be increased over the software scanning of the IA64 architecture.

Register bit scanning

A system, method and computer program are provided for maintaining time accurately and synchronously across a plurality of interconnected processors in a data processing system. Each processor has its own time base register and access to a single time delta variable. Time is reported as the sum of a processor's time base register and the time delta variable. Time base registers are set only at system initialization or boot; thereafter, any system wide time changes are effected by changing only the time delta variable value.

Method and system for keeping time across a multiprocessor platform

A method of changing the functionality of a statically bound device driver, by dynamically extending the static device driver using a registered driver extension. The static device driver has a plurality of handlers or functions (such as input/output functions) used to control a device that is connected to or part of the computer system, and the driver extension modifies at least one of these functions, although it can be used to change several, or even all, of the functions. In the embodiment wherein the computer system is a UNIX-type workstation having a kernel residing in the memory, the static device driver is loaded in the kernel and is dynamically extended by providing at least one entry point for the driver extension.

System for modifying functions of static device driver using a

An exception handler for a computer system, particularly for performance monitoring facilities, employs implementation-dependent steps executed from a kernel extension which is more application level than kernel level. The implementation-independent kernel is involved only at very minimum level for a prologue to the exception handling routine. First a kernel extension registers an exception with the processor by storing the address of a pointer to a first-level interrupt handler; this address is stored in a location in kernel data storage, in non-paged memory. When an exception condition is reached, state is saved and the address location is checked to see if an exception has been registered. If so, the address is used to go to the first-level interrupt handler, which is at the kernel extension level. The first-level interrupt handler may access a second-level interrupt handler. Only the code which is used to save state and check to see if an exception is registered is in the kernel, and this part of the exception handling code is implementation-independent. i.e., the same for all implementations of this processor architecture.

Interupt vectoring for trace exception facility in computer systems

A method of using a debugger for a computer operating system by providing a statically bound debugger driver which can be used early in the boot process, and further providing one or more dynamic debugger drivers which can be loaded after system initialization. The core portion of the operating system, such as the kernel for a UNIX-type workstation, makes a determination of whether any hardware device is connected to the computer that is of the type of debugger devices supported by the statically bound driver; if so, then the debugger can be used early in the boot process, but if not, provision is made for calling the dynamic debugger driver from some other portion of the operating system software, such as from the boot filesystem or PAL. The dynamic debugger driver may be selected from a plurality of dynamic debugger drivers, the particular selected dynamic debugger driver being associated with the particular hardware device that is actually connected to the computer. The computer's firmware may be designed to detect whether a hardware debugger device is connected to the computer that is of the appropriate type, so the firmware can pass this information to the core portion of the operating system. This approach simplifies testing of the operating system by allowing for the temporary connection of a debugger device which is supported by the statically bound driver.

Operating system debugger using kernel and dynamic extension with

A method of providing a dynamic abstraction layer, such as a boot filesystem, for a computer having a particular hardware platform, in order to make a basic operating system more portable. The method includes storing the dynamic boot filesystem in a protected space in the computer before the normal boot sequence, and then retrieving the dynamic boot filesystem from the protected space during the boot sequence and loading the retrieved dynamic boot filesystem. The computer firmware first loads a simulated boot image which contains the dynamic boot filesystem, and then loads an operating system boot image which contains the operating system and instructions for retrieving the dynamic boot filesystem. A default boot filesystem may be used if no previously stored dynamic boot filesystem is found. In a UNIX embodiment, the dynamic boot filesystem includes a hardware-dependent (Portable Assist Layer). The two boot images can be provided on a single media which is scanned twice, or separate media, for example, a floppy diskette and a CD-ROM disk.

Dynamic boot filesystem selection

An improved method of providing an operating system for a computer by defining an interface between the operating system and the computer's firmware. An executable file (soft ROS) is placed in a boot image so as to run, before execution of the real operating system, in response to the firmware seeking the operating system. The soft ROS includes instructions to determine whether the firmware conforms to the standardized interface. If so, then no special action is taken and control is passed to the operating system, but if the firmware is non-conforming in any manner, the soft ROS executes a firmware emulation module which provides the interface with the operating system. The firmware emulation module can provide missing dependencies of the firmware to the operating system, fix a defect in the firmware, or translate functions of the firmware to the pre-defined interface. This method isolates the operating system from firmware dependencies, making the operating system more portable.

Booting an operating system using soft read-only storage (ROS) for

An improved operating system for a computer provides support for specific hardware components. The operating system is loaded by first loading a base portion which initializes the operating system and determines the particular type of hardware components present. Then, appropriate software components are loaded that are specifically associated with the hardware components. The hardware components can be detected by leaving a trace in the memory device that is associated with the software component and later retrieving the trace, or by testing the computer for the hardware component. The hardware component may be a bus architecture selected from a group of bus architectures, and bus-independent interfaces are defined which are mapped to addresses in the kernel. Alternatively, the software component can include a which contains specific instructions for communicating with the hardware component. The is constructed from a plurality of files each associated with the hardware component.

Loadable hardware support

An exception handler for a computer system, particularly for performance monitoring facilities, employs implementation-dependent steps executed from a kernel extension which is more application-level than kernel level. The implementation-independent kernel is involved only at very minimum level for a prologue to the exception handling routine. First, a kernel extension registers an exception with the processor by storing the address of a pointer to a first-level interrupt handler; this address is stored in a location in kernel data storage, in non-paged memory. When an exception condition is reached, state is saved and the address location is checked to see if an exception has been registered. If so, the address is used to go to the first-level interrupt handler, which is at the kernel extension level. The first-level interrupt handler may access a second-level interrupt handler. Only the code which is used to save state and check to see if an exception is registered is in the kernel, and this part of the exception handling code is implementation-independent. i.e., the same for all implementations of this processor architecture.

Interrupt vectoring for instruction address breakpoint facility in

A computer system has volatile random access memory ('RAM') and nonvolatile auxiliary storage, a virtual memory operating system with some pages of virtual memory resident in RAM and other pages resident in a paging space in auxiliary storage. A time varying operating state for the computer is definable by reference to contents of the memory. A space in auxiliary storage (a 'hibernation space') is allocated for storing a portion of RAM as a hibernation image. A first group of the RAM-resident virtual memory pages is stored in the paging space. A second group of the RAM-resident virtual memory pages is stored in the hibernation space. A hibernation state is entered where the computer system is powered off with the system at a certain operating state. The computer system is returned to operation at the certain operating state, which includes powering on the computer system and reading the second group of pages into the RAM.

Method and apparatus for conserving power and system resources in a

An exception handler for a computer system, particularly for performance monitoring facilities, employs implementation-dependent steps executed from a kernel extension which is more application-level than kernel level. The implementation-independent kernel is involved only at very minimum level for a prologue to the exception handling routine. First a kernel extension registers an exception with the processor by storing the address of a pointer to a first-level interrupt handler; this address is stored in a location in kernel data storage, in non-paged memory. When an exception condition is reached, state is saved and the address location is checked to see if an exception has been registered. If so, the address is used to go to the first-level interrupt handler, which is at the kernel extension level. The first-level interrupt handler may access a second-level interrupt handler. Only the code which is used to save state and check to see if an exception is registered is in the kernel, and this part of the exception handling code is implementation-independent. i.e., the same for all implementations of this processor architecture.

Interrupt vectoring for optionally architected facilities in computer

A method and apparatus for enabling AIX device driver (DD) created for a uniprocessor (UP) system to run unchanged on a symmetrical multiprocessor system (SMP). Device drivers are processed by a funnelling mechanism so that UP device drivers always runs on a 'Master' processor in a multi-processor system. New device drivers written for the SMP system are permitted to bypass the funneling mechanism and proceed directly to execution on any available processor in the SMP system. Device registration services are provided which examine DD flags looking for a new unique flag indicating that the device driver is SMP enabled. If the flag is not present, then emulating a uniprocessor environment for execution of that device driver.

Method and apparatus for device driver funnelling

Hardware subsystems detect fault condition events in a computer system. The hardware determines, in response to each detected event, an appropriate corresponding behavior. A message is then communicated to the operating system identifying the desired responsive behavior. In response, the operating system executes appropriate preselected subroutines to cause the desired responsive behavior. New hardware, fault conditions, and behaviors may thereby be supported without necessitating corresponding modification and testing of the operating system software per se. Desired behavior of the operating system responsive to new hardware subsystems or system modifications are communicated to the operating system as behavior messages rather than events. The operating system is thereby not burdened with maintaining an appropriate behavioral responses corresponding to widely ranging and changing events associated with a plurality of different hardware systems supported by the same operating system.

Growing community of inventors

Austin, TX, United States of America

Michael Stephen Williams