1. Field of the Invention
This invention relates to the field of data processing, and, more particularly, to an improved method and apparatus that allows an operating system to participate in the process of setting the configuring of the system, through use of an operating system definition file.
2. Description of Related Art
IBM PS/2 personal computers are based on the 80xxx family of microprocessors that operate bimodally in real and protected modes. In accordance with PS/2 architecture, various hardware devices are connected into the system by adapters having a Programmable Option Select (POS) function used to define or provide settings for the assignment of system resources to the system board and to various adapters. The POS Function is generally described in "IBM Personal System/2 Hardware Interface Technical Reference", First Edition (May 1988) and updates, published by International Business Machines Corporation, to which reference may be had for a more detailed description thereof.
Adapters provide the means by which various data processing system devices and options can be connected into and operated as part of a personal computer system. In accordance with the above mentioned architecture, an adapter has a group of programmable registers which, by convention, store predetermined information. Two of these registers store an adapter ID that uniquely identifies the specific adapter relative to other adapters. From one to four additional registers, known as the POS registers, store information known as the POS settings. Before an adapter can be used, an adapter description file (ADF) must be created by the supplier of the adapter. The ADF contains data necessary for the operation of the adapter and its related option or device, the data defining the resources the adapter can use, and the associated POS register settings that indicate the resources assigned.
An ADF contains various fields of information including the following: adapter ID; adapter name; the number of POS registers to be included; an optional field indicating that an adapter option will be specified next; a prompt keyword; a choice keyword including the choice name, a POS setting which programs the adapter appropriately, and a resource setting which identifies the resources used for the particular choice; and a help keyword.
A Set Configuration Program, found on a PS/2 System Reference Diskette or a PS/2 System Reference Diskette Image in the System Partition in a protected partition on the hardfile, gathers information from the hardware system and resident adapters from special data files. These special files associated with adapters are the ADFs. The PS/2 Micro Channel System also has associated special files. They are called planar description file and system ADF. Another file associated with either planar or adapter is the Adapter Description Program or ADP. An ADP allows the associated adapter to use programming logic during the configuration process to make dynamic decisions based on the configuration of the system.
The set configuration program is run when the system is initially setup and when the system indicates a configuration error. This program assigns system resources, particularly those portions of the memory address space assigned to system memory and to non-system memory, and resolves any resource request conflicts between ADFs. The execution of the program stores configuration information in a non-volatile random access memory (NVRAM). Thereafter, whenever the system is started up or reset, this configuration information is accessed for testing whether a configuration change has occurred, programming the adapter's POS registers, providing information to the operating system indicating what resources are assigned to the various devices, and operating such devices.
At this point, it is helpful to define what is meant by "memory address space", "system memory", "non-system memory", and "memory regions". These terms have arisen as a result of the evolution of microprocessors and operating systems, and particularly the availability of larger address spaces due to increases in the number of address bits used with different microprocessors. A fuller discussion is made by Rick Dayan, "Memory Address Space", IBM Personal Systems Technical Solutions, October 1992, Pages 21-26, which is incorporated herein by reference. Briefly, "memory address space" is defined to be the maximum number of address locations accessible with a given number of address bits. Microprocessors used in IBM personal computers have evolved using 20-bit, 24-bit, and 32-bit addressing, which respectively provide memory address spaces of 1 MB (megabyte), 16 MB, and 4 GB (gigabyte).
FIG. 9 is similar to FIG. 4 of the above identified article by R. Dayan, and illustrates a four GB memory address space 600 of an 80386 DX processor having 32-bit memory addressing. The memory address space is occupied by both system memory and non-system memory. "System" memory is that part of the memory address space that is owned, managed, and allocated by the operating system. System memory is used for the storage of operating system code, application code, and data. "Non-system" memory is any portion of the memory address space that is available for exclusive use by either a feature adapter and/or a software program such as a device driver. Non-system memory is not owned by the operating system and the operating system cannot store programs or data therein. Non-system memory commonly is dedicated to interfacing with feature adapters and provide programming interfaces, device control and data buffers. System memory uses only read/write memory technology, typically RAM, while non-system memory uses not only read/write technology but other memory technologies such ROM, flash memory, NVRAM, etc. During configuration of the memory address space, allocation of non-system memory takes precedence over allocation of system memory. Relative to RAM, system memory is allocated whatever portion of RAM that is not allocated to the non-system memory.
The term "memory regions" refers to the original memory address space for 20-bit addressing, and to the added spaces resulting from 24-bit and 32-bit addressing. Memory region 1 starts at address OH (hex) and is the lowest 1 MB address space. The system memory occupies the lowest 640 KB of region 1 and non-system memory is allocated, to maintain compatibility with a DOS environment. Memory region 2 is from 1 MB to (16 MB-1), and memory region 3 is from 16 MB to (4 GB-1). Within a region, system memory must be contiguous and start at the lowest address. Non-system memory need not be contiguous in a region. The manner in which the address space is managed varies, particularly as to size and location of non-system memory, dependent on which regions are supported by an operating system. The size of the address space between the system memory and the non-system memory in region 2 and 3 depends upon how much RAM memory is installed in the system.
While PS/2 computers run under different operating systems, such as the commercially available PC/DOS (disk operating system), AIX/PS/2, and OS/2 operating systems, the hardware has been developed independently of any particular operating system. (PS/2, AIX/PS/2 and OS/2 are trademarks of International Business Machines Corporation) The above configuration process is also independent of the operating system environment. However, such independence leads to limitations in the configuration process.
Since the configuration process is independent of the operating environment, the configuration program assumes a default one megabyte (1 MB) PC/DOS operating environment in most cases. This means that system configuration is optimized for a restrictive and old operating environment. Users choosing contemporary operating system environments such as OS/2, AIX/OS/2, or other multitasking operating systems, are constrained to the PC/DOS optimized environment. Thus, a device may not be successfully configured or it may incur a performance degradation due to non-optimal configuration for the contemporary operating systems. Without operating system input, the set configuration program cannot make the correct decisions on how to customize the configuration.
Two possible solutions to this problem are (1) manual configuration and (2) operating system configuration. Manual configuration is really not an answer. This requires the customer to completely understand the operating environment and the individual options (parameters) for each adapter or device. Most of the adapters do not publish all the parametric information, nor explain its impact on the operating environment. Most users would be confused and probably not make the appropriate decisions to produce an optimal configuration for the operating environment.
An operating system performing the configuration is the ideal solution. What else could better define the optimal configuration for the environment created by the operating system? However, in the PS/2 and personal computer industry, none of the operating systems currently perform system configuration. It may be a long time before operating system configuration occurs, and, if it does, probably not all the operating systems will migrate to performing their own configuration. In addition, Multiboot, a product that enables more than one operating system to be booted in a system, creates a problem with allowing the operating system to configure the system. The problem is that all operating environments utilized on the system may not be the same. This may mean that if one operating system configures the system for its environment, the environment may not be optimal for the other operating systems. For example, a hardfile may change drive letters from one environment to another. This is not tolerable, especially if the customer desires to share data between the environments. The second operating system configuration may interfere with the first operating system configuration.
Another problem with multiple operating system environment is that if one operating system performs configuration and the second does not. In that case, the operating system performing configuration must take into consideration the operating system incapable of performing configuration. There are too many technical and implementation problems with relying on the operating system(s) to perform configuration in today's environment. This is the ideal situation, but until all problems are solved, use of an operating system definition file in accordance with the invention, is a good compromise.
USPTO Backgrounds
USPTO Backgrounds