Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent
5793979
Lichtman , ; et al.
August 11, 1998
Title
System for allocating the resources of a computer system
Abstract
A system for allocating resources for use by devices of a computer system. A possible configuration of elements of a resource is obtained. This possible configuration defines the resource elements that are appropriate for operating the devices within the computer system. For a selected device, a determination is made whether a particular resource element is available for use by this device. If not, another possible configuration is obtained and the process begins anew. In contrast, if the particular resource element is available, then this resource element is assigned for use by the selected device. This resource allocation process continues until resource elements have been assigned to the remaining devices.
Inventors:
Lichtman; Moshe
(Bellevue,
WA
)
, Enstrom; Mark R.
(Redmond,
WA
)
, Lennon; Thomas E.
(Seattle,
WA
)
, Lipe; Ralph A.
(Woodinville,
WA
)
, Santerre; Pierre-Yves
(Bellevue,
WA
)
, Short; Robert T.
(Kirkland,
WA
)
, Voth; David W.
(Redmond,
WA
)
Assignee:
Microsoft Corporation
(Redmond,
WA
)
Appl. No.:
476636
Filed:
June 7, 1995
Current U.S. Class:
709/226
709/229
710/17
710/8
Field of Search:
395/828,837,200.59,835,200.56,162
U.S. Patent Documents
4268901
May 1981
Subrizi et al.
4317183
February 1982
Shimizu et al.
4562535
December 1985
Vincent et al.
4589063
May 1986
Shah et al.
4660141
April 1987
Ceccon et al.
4727475
February 1988
Kiremidjian
4730251
March 1988
Aakre et al.
4974151
November 1990
Advani et al.
4982325
January 1991
Tignor et al.
5038294
August 1991
Arakawa et al.
5109484
April 1992
Hughes et al.
5136709
August 1992
Shirakabe et al.
5157384
October 1992
Greanias et al.
5197093
March 1993
Knuth et al.
5247682
September 1993
Kondou et al.
5249270
September 1993
Stewart et al.
5252951
October 1993
Tannenbaum et al.
5257368
October 1993
Benson et al.
5257379
October 1993
Cwiakala et al.
5257387
October 1993
Richek et al.
5263148
November 1993
Jones, Jr. et al.
5289372
February 1994
Guthrie et al.
5297262
March 1994
Cox et al.
5319790
June 1994
Kumagai
5335350
August 1994
Felderman et al.
5359713
October 1994
Moran et al.
5371492
December 1994
Lohrbach et al.
5379431
January 1995
Lemon et al.
5386551
January 1995
Chikira et al.
5386567
January 1995
Lien et al.
5408618
April 1995
Aho et al.
5412798
May 1995
Garney
5420987
May 1995
Reid et al.
5428748
June 1995
Davidson et al.
5432941
July 1995
Crick et al.
5450570
September 1995
Richek et al.
5452454
September 1995
Basu et al.
5454078
September 1995
Heimsoth et al.
5459867
October 1995
Adams et al.
5459869
October 1995
Spilo
5469545
November 1995
Vanbuskirk et al.
5471675
November 1995
Zias
5485460
January 1996
Schrier et al.
5491813
February 1996
Bondy et al.
5517636
May 1996
DeHart et al.
5517646
May 1996
Piccirillo et al.
5553281
September 1996
Brown et al.
5581261
December 1996
Hickman et al.
Other References
"CardWare.TM. User Manual 1.50A," released on Oct. 8, 1993 by Award Software International, Inc., pp. 1-33..~
Primary Examiner:
Lee; Thomas C.
Assistant Examiner:
Perveen; Rehana
Attorney, Agent or Firm:
Jones & Askew, LLP
Parent Case Text
This is a division of application Ser. No. 08/250,698, filed May 27, 1994 still pending.
Claims
We claim:
1. In a system having a plurality of resources, each resource having a plurality of resource elements, a method for allocating said resource elements of said resources for use by devices of a computer system, said method comprising the steps of:
(a) obtaining a possible configuration of said resource elements, said possible configuration defining said resource elements of a selected one of said resources that are appropriate for operating a selected one of said devices with said computer system;
(b) determining for said selected device whether a particular one of said appropriate resource elements is available for use by a selected one of said devices;
(c) if said particular appropriate resource element is not available for use by said selected device, then repeating steps a-b;
(d) if said particular appropriate resource element is available for use by said selected device, then assigning said particular appropriate resource element for use by said selected device;
(e) repeating steps a-d until said appropriate resource elements have been assigned to remaining ones of said devices; and
(f) repeating steps a-e for each of said remaining resources.
2. A method for allocating a plurality of elements of a resource for use by devices of a computer system, said method comprising the steps of:
(a) obtaining a possible configuration of said resource elements, said possible configuration defining said elements of said resource that are appropriate for operating a selected one of said devices with said computer system;
(b) examining whether said particular appropriate resource element has been assigned for use by another one of said devices;
(c) if said particular appropriate resource element has been assigned for use by another one of said devices, then repeating steps a-b;
(d) if said particular appropriate resource element has not been assigned for use by another device, then examining whether said particular appropriate resource element has been reserved for use by another one of said devices;
(e) if said particular appropriate resource element has been reserved for use by another one of said devices, then repeating steps a-d;
(f) if said particular appropriate resource element has not been reserved for use by another one of said device, then assigning said particular appropriate resource element for use by said selected device; and
(g) repeating steps a-d until said appropriate resource elements have been assigned to remaining ones of said devices.
3. A system having a plurality of resources, each resource having a plurality of elements, for allocating elements of said resources for use by devices of a computer system, said system comprising:
for each resource, means responsive to at least one possible configuration of said resource elements, each possible configuration defining said elements of said resource that are appropriate for operating said devices with said computer system, for determining whether a particular one of said appropriate resource elements for a selected one of said devices is available for use by said selected device; and
means for assigning said particular appropriate resource element for use by said selected device in response to determining that said particular appropriate resource element is available for use by said selected device.
4. The method of claim 1, wherein said step of determining whether said particular appropriate resource element is available comprises the step of examining whether said particular appropriate resource element has been assigned for use by another one of said devices.
5. The method of claim 4, wherein said step of determining whether said particular appropriate resource element is available further comprises the step of examining whether said particular appropriate resource element has been reserved for use by another one of said devices.
6. The method of claim 5, wherein said particular appropriate resource element is assigned for use by said selected device only if said particular appropriate resource element is neither assigned nor reserved for another one of said devices.
7. The system of claim 3, wherein said determining means comprises:
means for examining whether a particular one of said appropriate resource elements has been assigned for use by another one of said devices,
said examining means further operative to determine whether said particular appropriate resource element for said selected device has been reserved for use by said another one of said devices.
8. The system of claim 3, wherein each device includes device information having a device identification code that uniquely identifies the corresponding device and logical configuration data that supplies configuration requirements comprising the resource elements appropriate for operating the corresponding device with the computer system.
9. The system of claim 8, wherein the logical configuration data comprises computer resource requirement information and computer resource constraint information,
said computer resource requirement information defining certain resources of said computer system that are necessary for operation of said corresponding device with said computer system, and
said computer constraint information defining particular ones of said resource elements which are necessary for operation of said corresponding device with said computer system.
10. The system of claim 8 further comprising means for calculating at least one possible configuration of the resource elements based on the device identification code and the logical configuration data for the devices of the computer system.
11. The system of claim 8, wherein the determining means determines whether the particular appropriate resource element is available without manual intervention by analyzing whether the devices require a potential conflicting use of the particular appropriate resource element for operation with the computer system and,
if at least two of said devices require use of said particular appropriate resource element for operation with said computer system, then the determining means attempts to resolve the potential conflicting use of the particular appropriate resource element.
12. The system of claim 7, wherein the assigning means assigns said particular appropriate resource element to said selected device in the event that said particular appropriate resource element is neither assigned nor reserved for use by another one of the devices.
13. A computer-readable medium on which is stored a computer program for allocating a plurality of elements of a resource for use by devices of a computer system without manual intervention, the computer program comprising instructions, which when executed by a computer, perform the steps of:
(a) obtaining a possible configuration of said resource elements, said possible configuration defining said elements of said resource that are appropriate for operating a selected one of said devices with said computer system;
(b) examining whether said particular appropriate resource element has been assigned for use by another one of said devices;
(c) if said particular appropriate resource element has been assigned for use by another one of said devices, then repeating steps a-b;
(d) if said particular appropriate resource element has not been assigned for use by another device, then examining whether said particular appropriate resource element has been reserved for use by another one of said devices;
(e) if said particular appropriate resource element has been reserved for use by another one of said devices, then repeating steps a-d;
(f) if said particular appropriate resource element has not been reserved for use by another one of said device, then assigning said particular appropriate resource element for use by said selected device; and
(g) repeating steps a-d until said appropriate resource elements have been assigned to remaining ones of said devices.
14. In a computer having a plurality of resources, an apparatus for allocating elements of the resources for use by devices of the computer without manual intervention, comprising:
a configuration manager that develops a list of device configurations for each of the resources, each device configuration defining a requirement for one of the resource elements of one of the resources to support the operation of a corresponding one of the devices with the computer, and
an arbitrator, responsive to the list of device configurations, for each of the resources, that determines whether the resource elements are available to satisfy the resource element requirements defined by the device configurations, wherein the arbitrator allocates the available resource elements in the event that resource elements are available to satisfy the resource element requirements defined by the device configurations.
15. The apparatus of claim 14, wherein the arbitrator sends to the configuration manager an error message representing configuration failure in the event that the arbitrator fails to determine that resource elements are available to satisfy the resource element requirements defined by the device configurations.
16. The apparatus of claim 15, wherein the resource elements include nonreserved resource elements and reserved resource elements, the reserved resource elements representing a set of the resource elements that are held in reserve for possible use by selected devices, and the nonreserved resource elements representing the remaining resource elements.
17. The method of claim 2, wherein the possible configuration of said resource elements is calculated based upon a device identification code and logical configuration data for the selected device.
18. The computer-readable medium of claim 13, wherein the possible configuration of said resource elements is calculated based upon a device identification code and logical configuration data for the selected device.
Description
TECHNICAL FIELD
The present invention relates to data processing systems and, more particularly described, relates to configuring devices for operation with a computer system without user intervention.
BACKGROUND OF THE INVENTION
The process of installing a peripheral device or an add-on type adapter board for use with a personal computer system can be a relatively frustrating experience for the typical computer user. Nevertheless, a computer typically will not operate with a newly installed component until the user has completed a proper allocation of resources. Computer resources are allocated during a configuration process to permit the conflict-free use of the limited resources. To configure the computer, the user often must complete a relatively complex series of technical tasks. Thus, the difficulties faced by many users during the configuration process are emphasized by the absence of an automated process for resolving resource conflicts.
For many personal computer systems, neither the operating system nor the application programs running on the computer can determine which hardware components are connected to the computer. Likewise, the various hardware components connected to the computer system often fail to detect the occurrence of a conflict between different hardware devices that attempt to share the same resource. Accordingly, a user typically must resolve a resource conflict by first identifying the problem and thereafter experimenting with hardware and software configurations in an attempt to correct the resource conflict.
When attempting to tackle hardware and software integration issues, the user is exposed to technical concepts that can be somewhat confusing for those without technical training, such as computer architecture issues, including hardware interrupts, direct memory access (DMA) channels, memory addresses, and input/output (I/O) ports. Likewise, many common configuration tasks require the user to be familiar with the finer details of the computer's operating system, including system configuration files, such as Autoexec.Bat, Config.Sys, and *.Ini files. In view of these technical concepts, some users find the configuration process so intimidating that they refuse to consider upgrading a component of their personal computer or connecting a new peripheral device to add a new capability to their computer system.
Unlike today, early personal computers required minimum coordination between the computer hardware and software components. Users were presented with few difficult configuration issues after the initial installation of the computer system. A limited number of peripheral devices were commercially available for supplementing the processing functions of the personal computer. In addition, early personal computers were primarily used for dedicated tasks, such as word processing or calculating financial information with a spreadsheet program, at a fixed desktop location.
In contrast, present computers are often portable systems that can be regularly connected to different peripheral devices and external systems. There exists many more computer peripheral devices that require the use of resources during computer operation than the limited quantity of available resources. Furthermore, a user can harness the powerful computing operations of a present personal computer to complete numerous tasks outside the traditional realm of word processing and financial calculations, such as graphics, audio, and video. For example, numerous peripheral devices and add-on systems are now commercially available to enable the user to customize the functions and operating characteristics of a personal computer. Docking-type computer systems enable a user to operate a mobile computer at either a base station or in remote locations. Thus, the rapid acceptance of portable computing and the multi-faceted uses of the personal computer emphasize the need for supplying a "user friendly" system that configures new hardware or software devices for use with the computer system.
The Industry Standard Architecture (ISA) standard is a widely used bus architecture for personal computer systems. The ISA expansion bus, which is commonly associated with the IBM Personal Computer AT and other compatible computers, provides a
16-bit bus that supports the connection of adapter boards within the computer. The ISA bus structure requires allocation of resources, such as hardware interrupts, DMA channels, memory addresses, and I/O ports, among multiple ISA-compatible adapter boards connected to the ISA expansion bus. However, the ISA standard does not define a hardware or software mechanism for allocating those resources for use by the installed adapter boards. Consequently, configuration of the ISA adapter boards is typically completed by connecting jumper cables or changing switch settings on the boards to change the decode maps for memory and I/O ports and to direct the DMA channels and interrupt signals to various pins along the expansion bus.
Furthermore, system configuration program files of the operating system may need to be updated to reflect any modifications to the resource allocation.
Alternative expansion bus standards, such as the Micro Channel Architecture (MCA) and the Extended Industry Standard Architecture (EISA) standards, have limited hardware and software mechanisms to identify resources requested by a peripheral device and to resolve resource conflicts. However, these mechanisms are not implemented by the computer's operating system and are not compatible with the large installed base of personal computers based on the ISA standard. Furthermore, computer systems implementing the MCA and EISA standards are generally more expensive than ISA-compatible computers and lack the variety of add-on adapter boards and peripheral devices available for use with ISA-compatible computers.
To address the issue of configuration management, the computer industry is at present offering full-featured computer systems having preconfigured hardware and preinstalled software, thereby eliminating the need for a user to conduct the installation and configuration tasks for the purchased computer system. However, this is a somewhat limited solution because vendors typically market a computer system having a standard configuration of hardware and software components. Thus, this approach defeats the flexibility offered by the ISA bus expansion structure because users cannot obtain a computer capable of performing a customized function through this standardized configuration approach.
To overcome the frustration of users with present complicated configuration processes, it would be desirable to provide a system for automatically configuring a peripheral device or adapter board for a computer system. A system is needed to enable a user to simply connect a device to the computer, turn on the computer, and have the device properly work with the computer. There is a further need for a system that determines the optimal configuration for its resources and enables application programs to fully utilize the available resources.
In recognition of the problems of prior configuration processes, the present invention provides a system that permits easy installation and configuration of devices which are capable of identifying themselves and declaring their services and resource requirements to the computer. The device identification and resource requirement information enable the system to determine and establish a working configuration for all devices connected to the computer, and to load the appropriate device drivers. In this manner, the present invention supports a variety of computer bus architectures and device classes. Accordingly, the present invention efficiently allocates system resources between the devices of the computer system without substantial user intervention.
SUMMARY OF THE INVENTION
The problems associated with the manual installation and configuration of adapter boards and peripheral devices for computer systems are solved by the principles of the present invention. The present invention provides a system for configuring the hardware and software components of a computer system by optimally allocating system resources for use by computer devices.
The present invention enables a user of a computer system to install a new device by connecting the device to the computer, powering the computer, and using the computer to take advantage of the function supplied by the new device. Likewise, the present invention permits a user to insert a mobile computer into a base station while both the mobile computer and the base station are powered and to reconfigure the mobile computer for operation with the devices connected to the base station. Thus, the present invention addresses the needs of computer users by supplying a computer-implemented process for configuring devices for a computer system and for accommodating seamless dynamic configuration changes of the computer system.
A system constructed in accordance with the present invention configures devices of a computer system by identifying the devices, determining the desired usage of the resources of the computer system, detecting and resolving potential conflicting uses of the resources, and allocating resources for use by the devices. An operating system runs on the computer system and supports these configuration tasks.
The computer system includes various resources, including interrupts, direct memory access (DMA) channels, memory addresses, and input/output (I/O) ports, at least one system bus, and devices. System busses are components that supply physical connections to devices. Each of the devices is connected to one of the system busses of the computer system.
The system busses can be compatible with a variety of bus architectures, including the Industry Standard Architecture (ISA), Micro Channel Architecture (MCA) and Extended Industry Standard Architecture (EISA) bus standards, as well as Personal Computer Memory Card International Association (PCMCIA), Small Computer Systems Interface (SCSI), Personal Computer Interface (PCI), Enhanced Capabilities Parallel (ECP), Vesa Local Bus (VL), Integrated Drive Electronics (IDE), and other bus standards. Typical devices supply the functions of system-level components, such as fixed and floppy disk controllers, display, keyboard, and mouse controllers, and serial and parallel controllers, and implement the functions offered by numerous add-on type adapter boards and peripheral devices.
Briefly described, the method for configuring the devices of the computer system is started by collecting device information for each of the devices of the computer system. This device information acquisition process permits the unique identification of the devices and the description of device characteristics associated with the operation of devices with the computer. A device driver, which enables communications between a corresponding device and the computer system, is thereafter identified for each of the devices in response to the device information. The resources, which support the functions of the devices within the computer, are allocated based upon the device information. This allocation process prevents any potential conflicting use of the resources by the devices. In response to resource allocation, the devices are configured and device drivers for the devices are loaded. The devices are thereafter activated for operation with the computer.
More particularly described, the present invention configures devices of a computer system based upon the collection of information about the devices and their connections to the system busses of the computer system. To collect the device information, a particular device is detected on the system bus of interest and thereafter assigned a device identification code that identifies the particular device as being connected to the selected system bus. At least a portion of the device identification code, specifically an identification code, uniquely identifies the detected device. Logical configuration data, which supplies configuration requirements for operating the particular device with the computer system, is also obtained for the detected device. This collection process is repeated until device information is eventually collected for each of the devices for all system busses of the computer system.
The device information is stored within computer system memory, such as volatile memory, to support the present configuration operation. At least a portion of the system memory is allocated for the storage of device information within a tree-like structure of device nodes. Each device connected to the computer system is represented by a device node that stores associated device information. Furthermore, if an identified device represents a newly installed device for the computer system, then this device information also can be stored in nonvolatile computer memory, such as a fixed disk, to supply an archival source of such information for future configuration tasks. A computer database having a hierarchical data arrangement is typically used to store this archival device information.
The collection of device information, which is also described as enumeration, is initiated in response to dynamic events that cause an asynchronous change in the operating state of the computer system. These events typically affect the use of the resources by the devices of the computer system and include: powering the computer system; connecting another device to a system bus; removing a device from a system bus; and inserting the computer system into or removing the computer system from an expansion unit or a docking station.
The collection of device information supplies data that supports the identification of device drivers for the identified devices. A device driver can be obtained from one of several alternative sources of the computer system, including selected files of the operating system installed on the computer system, the device itself, a computer database maintained by the computer, or from the user via a disk containing the device driver. In general, the device driver for a device is often obtained by accessing a selected program file stored on either a fixed disk or another type of mass memory storage device of the computer system.
The computer database can contain device information associated with a particular device, including information for that particular device, which is also described as a primary device, and information for devices that are "compatible" with the primary device. For example, a first manufacturer's device may be compatible with a second manufacturer's device because both devices perform the same function and conform to an industry standard for operations. If the devices are compatible, a device driver for the first device often can be used to enable the operations of the second device and, likewise, a device driver for the second device can be used with the first device. Thus, a compatible device driver, if available, may be used to enable communications of the particular device with the computer system.
The stored device information for a particular device typically can be accessed by searching in the computer database for a location or a record that contains the identification code for the desired device. Thus, the identification code can be used as an entry key to search the records of the computer database. If the device information in a selected record describes the primary device, then the device driver intended for primary use with that device is maintained by the computer system and is available to support the device operations. Likewise, a compatible device driver is maintained by the computer system if compatible device information is stored within the selected record and associated with the particular device.
By convention, the primary device driver is typically selected to support the computer operations of the primary device over any of the device drivers for compatible devices. However, if the device driver for the primary device is not available, then a device driver for a compatible device is selected. In this event, if the compatible device information lists more than one device that is compatible with the particular device, then the compatible device having the highest priority or ranking is selected and used to support the operations of the particular device.
If neither the primary device driver nor a compatible device driver is available on the computer system, then the user can be requested to supply a substitute device driver that supports the operation of the device with the computer system. This request is typically supplied as a textual statement displayed on a display or monitor for the computer system or as an audio prompt generated by the computer system. In response to the request, the user can insert within the proper computer drive a flexible disk or other appropriate electronic media containing the device driver, thereby permitting the computer to access the device driver. The device driver then can be stored within an appropriate mass memory storage device and used to enable the communications between the particular device and the computer.
Resources, which typically include a finite set of resource elements, are allocated by first analyzing the device information to detect whether the devices require a potential conflicting use of resource elements for operation of the devices with the computer system. The desired resource element is assigned for use by a device if this resource assignment does not conflict with the use of that particular resource by another device. A resource element is available for use by a device if this element is neither reserved nor assigned for use by another device. Some resource elements are typically reserved for use by selected devices to insure the compatibility of the present invention with existing devices. Thus, if at least two of the devices require use of an identical resource element, then this potential resource conflict is arbitrated and resolved in an iterative manner based upon the device information and the finite resources of the computer. The resources are then assigned for use by the devices based upon this conflict-free solution.
In response to allocating the assigned resources to the devices, the devices are configured for operation with the computer system. Each device driver is loaded for use by the corresponding devices and the devices are activated for operation with the computer.
Focusing upon another aspect of the present invention, a system is provided for supporting the bus-specific operations of devices connected to a system bus of a computer system. This system, which is alternatively referred to as an enumerator or a bus driver, is assigned to operate with a specific system bus and is programmed to recognize the operating parameters of the assigned bus. Each system bus typically requires a unique configuration process that is based upon the architecture of the bus. The enumerator, which can be part of an operating system, directly supports the configuration of devices on its assigned bus by accessing device information for those devices and storing this data with a central memory. This enables an operating system for the computer system to be independent of the characteristics of a computer bus architecture because bus-specific information is handled by an abstraction layer, in this case, the enumerator.
The enumerator can perform three primary operations, specifically (1) detecting dynamic events causing an asynchronous change in the operating state of the computer system; (2) enumerating each of the devices connected to the assigned system bus in response to the detection of a dynamic event; and (3) supplying assigned resources to each of the devices in response to an allocation of resources. To implement these operations, the enumerator can include one or more elements that are responsible for those functions, namely an enumerate element, a configure element, and an event detect element. These functions are typically defined by the characteristics of its assigned system bus.
The enumerate element includes a detection module for detecting a particular device on the system bus and a collection module for retrieving device information from the particular device. The collection module obtains device information from the detected device and stores this data within device nodes of the computer memory to maintain an up-to-date inventory of the devices on the assigned system bus. Thus, the detection and collection modules operate in tandem to enumerate these devices. The computer memory can be a hierarchical database structure formed by a tree-like structure containing the device nodes, which represent each of the detected devices.
The configure element can include a receive module for receiving the allocation of assigned resource elements, an assigned resource storage module for storing the assigned resources within the device nodes of the computer memory, and a transmit module for supplying instructions about the assigned resources to the appropriate devices. In response to the assigned resources, the configure element accesses the device nodes in the computer memory and stores the appropriate resource element assignments.
The event detect element typically can detect the installation of a new device on the assigned system bus or the removal of an existing device. For example, device installation or removal can be detected by intercepting a particular interrupt signal or by periodically polling all of the available sockets of the bus to determine the installed devices. Likewise, the event detect element can detect the insertion of a computer system into or the removal of a computer system from a docking station. The event detect element is further responsive to booting the computer or the power state for the computer. In response to one of these events, the event detect element can supply the event detection information to the enumerate element, thereby initiating the enumeration process. The event detect element also can be responsive to certain query-type instruction signals containing commands for actions by the enumerator. These commands typically include: delete device information in a designated device node because the associated device has been removed from the computer, stop a present operation, and start a new operation.
Turning now to the enumeration process, a method is provided for identifying devices connected to a system bus of a computer system having resources. First, a particular device is detected on the system bus. For example, for the widely used ISA bus, devices are detected by instructing each of the devices to enter an inactive state, thereby disabling the function of the device. The detected device on the ISA bus is then isolated from the remaining devices to enable interference-free communication with the detected device. In contrast, for the PCMCIA bus, a particular device is detected by selecting the socket supplying the connection for that device. Thus, it can be seen that device detection is a bus-dependent operation and may vary among different bus architectures.
A device identification code is thereafter assigned to the detected device. The device identification code, which includes an identification code and a system bus code appended to the identification code, typically identifies this device as a certain device type that is connected to the system bus. The identification code typically contains a string of characters, such as American Standard Code for Information Interchange (ASCII) characters, which uniquely define the particular device. The identification code is useful for defining both the manufacturer of the associated component and the type of device, and for distinguishing between identical types of devices connected to the same system bus. The system bus code uniquely identifies the system bus associated with the connected device.
Logical configuration data is also obtained for the particular device to acquire the configuration requirements for operating the particular device with the computer system. The resources of a computer system generally offer a range of options or elements for using the resources. The logical configuration data includes resource requirement information that defines certain resources of the computer system which are necessary for proper operation of the particular device with the computer system. For example, resource requirement information for a modem may define a resource requirement for an interrupt within the range of interrupts 7-12. The logical configuration data also includes resource dependency information, which defines a particular combination of resource elements that are necessary for device operation. For a modem, typical resource dependency information may define the combination of interrupt IRQ4 with I/O3F8 (COM PORT 2).
The above-described steps of the identification process are repeated for each of the remaining devices connected to the system bus to permit the collection of device information from all connected devices. In the event that a device itself is implemented as a system bus, it may be necessary to identify device drivers, allocate resources, and load the identified device drivers prior to identifying any devices connected to this new system bus. For example, these tasks are typically completed prior to identifying a device connected to the PCMCIA bus which, in turn, is connected to an integrated expansion bus of the computer's system board, such as an ISA bus.
To assign the device identification code, the identification code can be accessed by reading the identification code from a memory storage device, such as read only memory (ROM) or a resister, which is typically mounted on the interface board for the device. The system bus code is subsequently added to the identification code to complete the formation of the device identification code. The device identification code is thereafter typically stored within computer memory to support the configuration process.
Similarly, the logical configuration data can be retrieved from the particular device by reading the logical configuration data from the memory storage device for that device. The logical configuration data is thereafter stored within the computer memory and is associated with the device identification code for the particular device. In the event that the logical configuration data is not available from the particular device, at least a portion of the logical configuration data often can be retrieved from a selected file of the computer operating system, such as a configuration file, e.g., an .INF file.
The resource allocation process is supported by arbitrators that operate to determine the assignment of resource elements to the devices of the computer. An arbitrator is assigned to each resource of the computer system and is responsive to the resource requirement information and resource dependency information related to its resource to produce a conflict-free allocation of the resource elements. The arbitrator for a selected resource is programmed to recognize the characteristics of its resource. For example, the arbitrator for a interrupt resource of a conventional personal computer recognizes that this resource includes 16 interrupt elements.
An arbitrator includes an analysis element that is responsive to a possible configuration which defines the set of resource elements that are appropriate for operating the devices with the computer system. In response, the analysis element determines whether a particular resource element for a selected device is available for use by the selected device. The arbitrator also includes an assignment element for assigning the particular resource element for use by the selected device in response to determining that the particular resource element is available for use by the selected device.
Focusing upon yet another aspect of the present invention, a method is provided for obtaining a device driver to enable a device to communicate with a computer system. The computer system includes a database containing a set of records. Each record contains both a device identification field for storing the identification code of a primary device and a compatible device identification field for storing identification codes for compatible devices and at least one type of compatible device-related data.
Reviewing the data structure for a database record, the device identification field permits the recording of an identification code that identifies a primary device for operation with the computer. Likewise, the compatible device identification field permits the recording of both an identification code that identifies the primary device and identification codes that identify compatible devices. If the compatible device identification field contains an entry for the primary device, then a device driver specifically intended to support the computer operations of that primary device is available on the computer system. Likewise, compatible device drivers are available to support computer operations for both the primary device and other associated compatible devices if the compatible device identification field contains identification codes for compatible devices.
As an option, the compatible device identification field also permits the recording of priority data to permit a further distinction between the devices represented by the compatible device identification codes. The priority data supports the selection for a device driver of one of the compatible devices over another compatible device driver based upon the assigned rankings of the compatible devices. For example, the priority data can include a preferred use ranking or priority assigned by the vendors for the compatible devices. The compatible device having the highest priority ranking is typically selected for installation.
To obtain the device driver for a certain primary device, the computer database is searched to locate a selected record which is associated with that device. The identification code for this device is used as the entry key for the database because it identifies the desired device. Upon locating the selected record, the compatible device identification field is reviewed to determine if this field contains the identification code for the certain primary device.
If the identification code for the certain primary device is located within the compatible device identification field of the selected record, then the corresponding primary device driver is selected for use with the computer system. Upon identifying the proper device driver, the task of retrieving the desired device driver from its storage location is controlled by the operating system in a conventional manner. The identified primary device driver often can be retrieved from the mass memory storage device of the computer system.
However, in the event that the compatible device identification field does not contain the identification code for this primary device, then this field is examined to determine if it contains one or more of the identification codes for compatible devices. If so, then the compatible device having the highest priority is selected and the corresponding device driver is retrieved from the computer system.
In the event that the compatible device identification field does not contain an identification code for a compatible device, then the computer system supplies to the user an indication of the absence of the necessary driver for associated device. This indication can be a text-based or a combined text/graphics message, which is displayed by the computer monitor or supplied to a printer, or an audio prompt or statement.
In furtherance of these principles, it is an object of the present invention to provide a system for configuring devices of a computer system.
It is a further object of the present invention to provide a system for configuring a new device connected to a computer system.
It is a further object of the present invention to provide a system for identifying the devices connected to a computer system.
It is a further object of the present invention to provide a system that identifies the resource usage and system resource options for a device by obtaining such information from the device.
It is a further object of the present invention to provide a system that optimally allocates resources for use by the devices of the computer system.
It is a further object of the present invention to provide a system that identifies the devices of the computer system, determines a working configuration for the devices, and loads the appropriate device drivers.
It is a further object of the present invention to provide a system that accommodates seamless dynamic configuration of resources by enabling the configuration of devices in response to docking a mobile computer to a base station, removing the mobile computer from the base station, adding a new device to a computer, or removing a device from the computer.
It is a further object of the present invention to supply remote and local access to information directed to the present configuration of the computer system and the types of devices connected to the computer system.
That the present invention accomplishes these objects and offers the above-described advantages will be apparent to those skilled in the art from the following description, the appended claims, and the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is an overall block diagram of a computer system in which the preferred embodiment of the present invention is operative.
FIG. 2 is a block diagram that illustrates the preferred embodiment of the present invention.
FIG. 3 is a flow chart diagram that illustrates the steps of a method for configuring the devices of a computer system.
FIG. 4A-C are flow chart diagrams that illustrate the preferred steps of a method for configuring the devices of a computer system in accordance with the preferred embodiment of the present invention.
FIG. 5 is a flow chart diagram that illustrates the preferred steps for a method for obtaining a compatible device driver for use with a device of the computer system.
FIG. 6 is a block diagram that illustrates the components of the preferred embodiment of the present invention.
FIGS. 7A and 7B are diagrams that illustrate one of the components of the preferred embodiment of the present invention, specifically a hardware tree comprising device nodes for storing device-related information for the present configuration of the computer system.
FIG. 8 is a diagram that illustrates one of the components of the preferred embodiment of the present invention, specifically a registry for storing archival device-related information for the computer system.
FIG. 9 is a block diagram that illustrates the elements of a component of the preferred embodiment of the present invention, specifically an enumerator.
FIG. 10 is a flow chart diagram that illustrates the preferred steps for a method for numerating devices of a computer system.
FIGS. 11A and 11B are flow chart diagrams that illustrate the preferred steps for responding to dynamic events that affect the operating state of a computer system.
FIG. 12 is a block diagram that illustrates the elements of a component of the preferred embodiment of the present invention, specifically an arbitrator.
FIG. 13 is a flow chart diagram that illustrates the preferred steps for a method for assigning a resource for conflict-free use by a device of a computer.
DETAILED DESCRIPTION
To overcome the frustration of users with the present complicated and technical configuration processes for personal computers, the present invention provides a system for automatically configuring a peripheral device or an add-on type adapter board for use with a base or mobile computer system. The present invention enables a user to simply connect a new device to the computer, power the computer, and have the device properly work with the computer without user intervention. To provide this capability, the present invention determines the optimal configuration for the resources and enables the devices and the application programs to fully utilize the available resources. This can be accomplished for numerous computer bus architectures and types of devices.
The detailed description which follows is presented largely in terms of algorithms and symbolic representations of operations by conventional computer components, including a processor and memory storage devices. These algorithmic descriptions and symbolic representations are the means used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art.
An algorithm is generally conceived to be a self-consistent sequence of steps leading to a desired result. These steps generally require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, or otherwise manipulated. It is convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, records, files or the like. It will be appreciated that all of these terms, as well as similar terms, are associated with appropriate physical quantities and are merely convenient labels applied to these quantities.
AUTOMATED CONFIGURATION SYSTEM
FIG. 1 shows a block diagram of the preferred operating environment, a computer system 8, for the preferred embodiment of the present invention. The present invention is based upon computer-implemented processes that can be embodied in one or more computer programs for a data processing system, such as the computer 8, to carry out the methods and functions described herein. This computer-implemented process operates upon electrical or other physical signals to generate the desired physical results. Referring now to FIG. 1, the computer system 8 runs an operating system 10 that operates with a central processing unit (CPU) 12, resources 14, system busses 18, devices 20, and a computer control system 21. The resources 14 include memory addresses for a memory 22, interrupts 24, direct memory access (DMA) channels 26, and input/output (I/O) ports 28. The system busses 18 typically include a local bus 13, an integrated bus 15, such as a system-level expansion bus, and at least one interface bus 17. The computer 8 represents a typical configuration for a conventional personal computer and it will be understood that the present invention is not limited to operations with the disclosed configuration for the computer 8.
The operating system 10 comprises a set of computer programs that control the internal functions of the computer system 8, thereby allowing the computer 8 to run application software (not shown). For the preferred embodiment, the operating system 10 is a graphic-based operating system, such as the "WINDOWS" operating system available from the assignee for this application, Microsoft Corporation, Redmond, Wash. The operating system 10 is preferably installed on a mass memory storage device, such as a fixed disk drive, of the computer 8. During computer operations, the operating system 10 is also allocated a portion of the memory 22 to support operations with the other components of the computer system 8.
The CPU 12 is typically implemented as a microprocessor, such as the models 80386 or 80486 that are available from Intel Corporation, Santa Clara, Calif. The CPU 12 operates in combination with computer software, such as the operating system 10
and application programs, to control the operations of the computer 8. One or more of the system busses 18 support communications of control, address, and data signals between the CPU 12 and the remaining components of the computer 8.
The resources 14 represent the resources of a conventional personal computer, such as the computer 8. The memory 22 is typically implemented by dynamic or volatile memory modules, such as random access memory (RAM), and static or nonvolatile memory modules, such as read only memory (ROM) units. The memory 22 preferably includes a conventional memory, which is the first 1024 kilobytes of dynamic memory in a personal computer, and an extended memory that extends above the 1024 kilobytes range. The interrupts 24, also referred to as the interrupt request lines, are signal paths within the computer 8 that carry signals informing the recipient that the sender is ready to transmit or to receive data. The DMA channels 26 enable the devices
20 or a computer program running on the computer 8 to access the memory 22 without involvement by the CPU 12, thereby supporting relatively fast data transfers. The I/O ports 28 represent ports used by the devices 20, such as peripheral devices or adapter boards, to communicate with the CPU 12.
The computer database 16 provides a central location for storage of archival information that supports the configuration of the devices 20. Specifically, the computer database 16 stores general system hardware and software parameters, as will be described in more detail below with respect to FIG. 8. The computer database 16 is preferably implemented by nonvolatile memory, such as a fixed disk or another type of mass storage memory device.
Each system bus 18 can be viewed as a "parent" capable of having "children" because a system bus provides a mechanism for connecting devices 20 to the computer 8. The system busses 18 typically supply the signal paths for the exchange of data, control signals, and addressing information among the components of the computer 8 and peripheral components, including the devices 20. The system busses 18 can be implemented as various bus architectures, such as the Industry Standard Architecture (ISA), Micro Channel Architecture (MCA), and Extended Industry Standard Architecture (EISA) standards, as well as Personal Computer Memory Card International Association (PCMCIA), Small Computer Systems Interface (SCSI), Personal Computer Interface (PCI), Enhanced Capabilities Parallel (ECP), Vesa Local Bus (VL), Integrated Drive Electronics (IDE), and other bus standards. The system busses 18 also can include local or personal computer (PC) busses, serial busses, and parallel busses. However, it will be understood that the present invention is not limited to operation with the above-described busses and that these busses are listed as representative of existing bus architectures.
The system busses 18 include the local bus 13, the integrated bus 15, and a pair of interface busses 17 and 17'. The integrated bus 15 is preferably an integrated or "fixed" expansion-type bus that enables the direct connection of peripheral devices or adapter boards to the computer 8. In contrast, the interface busses 17 and 17' are typically supplied by vendors as separate accessory or optional components that can be attached to the computer 8 via the local bus 13 or the integrated bus
15. Nevertheless, both the interface busses 17 and 17' permit the connection of additional devices to the computer 8.
For the representative computing environment shown in FIG. 1, the integrated bus 15 is implemented as an ISA bus and is connected to the local bus 13 on the system board of the computer 8. In addition, the interface busses 17 and 17' are respectively implemented as a SCSI bus and a PCMCIA bus. In particular, the SCSI bus is connected to the local bus 13 and the PCMCIA bus is connected to the integrated bus 15.
The devices 20, which are connected to the system busses 18, represent the logical functions of components that can be connected to a personal computer. The devices 20 include components typically located on or connected to a system board of a personal computer, including system-level devices, such as I/O controllers (fixed and flexible disk controllers), keyboard controller, serial and parallel controllers, system timer, display controller, programmable interrupt controller (PIC), and DMA controller. The devices 20 further include the functional devices for peripheral adapter boards and interface boards. Thus, for the representative computing environment shown in FIG. 1, the devices 20 include system-level devices (not shown), a modem card, and a network card.
A device 20 also can be implemented as a system bus 18 that is connected to another system bus. For example, in the computer 8, the PCMCIA bus is connected to the ISA bus and is capable of supplying a connection to the computer 8 for other devices. Thus, the PCMCIA bus represents both a system bus 18 and a device 20 within the computer 8. Likewise, both the ISA bus and the SCSI bus may be viewed as a system bus 18 and a device 20. Following the earlier analogy to "parent" and "child" components, it will be appreciated that a system bus 18 may be both a "parent" and a "child" within the preferred operating environment of the computer 8.
Although each of the devices 20 are shown in FIG. 1 as separate physical components, it will be understood that a computer component can contain more than one function and, accordingly, that component can contain more than one of the devices 20. Thus, it will be useful to consider the device 20 as a logical device rather than as a physical device. It will be understood that the devices 20 supply the building blocks that are required to harness the computing power offered by the CPU 12 and the resources 14.
With the exception of system-level devices, which are typically supplied as part of the system board of the computer 8, a device 20 can be connected to a memory storage device 29, such as a ROM or a register, for storing information about the associated device 20. The memory storage device 29 is useful for storing device-related information that supports the configuration of the devices within the computer 8. This device information typically includes a string of characters for uniquely identifying a corresponding device and resource usage data. For devices on adapter boards, the memory storage device 29 is preferably mounted on the board itself.
The inventors believe that the actual implementation of the memory storage device 29 can be any type of circuit or component that allows the device information to be accessed to support configuration operations. Typical data storage components include ROMs, registers, and other conventional memory components. Furthermore, the device-related information also can be "stored" by constructing circuitry that represents a "hard-wired" version of such information. Device information can be stored in a device-dependent fashion. Accordingly, it will be understood that the memory storage device 29 is not limited to the above-described implementations.
The computer control system 21 conducts initialization and test functions, as well as device configuration functions, when the computer 8 is first powered or "booted." Upon booting the computer 8, one or more start-up programs begin to run to implement necessary initialization and test functions. These start-up programs may be implemented as stand-alone programs or are integrated to function within the framework of the operating system 10.
The start-up programs typically include a basic input/output system (BIOS) program and a power-on self-test (POST) program. The BIOS program supplies device-level control or support services for the primary input/output devices of the computer during the boot "initialization" process. Furthermore, after boot, the BIOS program accepts requests from application programs or the operating system running on the computer and performs input/output services as requested by those programs. The POST program conducts a sequence of tests for certain system-level devices and resources, including memory, to verify the proper operation of the computer components that are required to be active upon completion of the boot process. The programs associated with the computer control system 21 are preferably stored in ROM located within the computer 8, typically on the computer motherboard. The functions and operations of conventional BIOS and POST programs are well known and will not be further described herein. However, as described in more detail below, the computer control system 21 preferably includes a modified BIOS program that is further capable of (1) configuring the boot-level devices of the computer 8 and, if required, (2) detecting the insertion or removal of the computer 8 from a docking station or an expansion system. This modified BIOS program can be viewed as a type of system bus because it supplies connections to the system-level devices on the motherboard to support the configuration of such devices.
When viewed collectively, the CPU 12, the resources 14, a fixed disk including the computer database 16, the system busses 18, and the devices 20 represent the hardware components for a typical personal computer as embodied by the computer 8. The devices 20, which are connected to system busses 18 that are organized in a hierarchical manner, perform their respective functions by operating with the resources 14. Nevertheless, with the exception of certain types of the peripheral devices or adapter boards, the typical user is rarely exposed to the technical aspects of computer operations. In view of the relative technical complexity of the typical personal computer, it will be appreciated that there is a need for a system for configuring the devices of a personal computer without substantial support by the user. The inventors' solution for this problem is a system that permits a user to simply connect or attach a desired device to a computer, power-on the computer, and thereafter use the function associated with the device. This configuration system is supported by the hardware components of its computing environment and the computer-implemented processes of the operating system 10 and the computer control system 21.
FIG. 2 is a block diagram that illustrates the basic building blocks for the preferred embodiment of the configuration system. Referring now to FIGS. 1 and 2, the configuration system is useful for configuring the computer system 8 to insure that the devices 20 have conflict-free access to the resources 14. Configuration logic 30, which can be implemented as a portion of the operating system 10, controls the configuration tasks. Specifically, the configuration logic 30 is supported by the operating system 10, the computer control system 21, and the processing and storage functions offered by the computer 8.
In response to an event causing an asynchronous change in the operating state of the computer system 8, the configuration logic 30 operates to collect device information from each of the devices 20. For devices that have been designed to support the preferred operating system, this device information can be accessed by reading at least a portion of the data from a data storage mechanism associated with the device 20, such as the memory storage device 29. The configuration logic 30 thereafter allocates the resources 14 for the devices 20 in response to the collected device information. This prevents a conflicting use of the resources 14 by the devices 20 within the computer system 8.
To collect device information from a selected device 20 on one of the system busses 18, the configuration logic 30 includes a detection module 31 for detecting a selected device on that bus and a collection module 32 for collecting device information from the detected device. Each system bus 18 in the computer 8 is preferably represented by a combination formed by a detection module 31 and a collection module 32. This combination defines the enumeration function of a component of the operating system 10 that will be described in more detail below with respect to FIG. 6, specifically an enumerator.
A driver identification module 33 responds to the device information by identifying a device driver for each of the devices 20 that supplied device information to the collection module 32. The collected device information is then analyzed by an arbitration module 34 to determine whether the selected device requires a potential conflicting use of the resources 14.
The arbitration module 34 assigns elements of the resources 14 by searching for available resource elements. As required, the arbitration module 34 resolves any potential conflicting use of an element of the resources 14 to enable the conflict-free allocation of a resource element to the selected device 20. Each resource 14 can be represented by a self-contained component of the arbitration module 34 to permit the efficient addition of arbitration capabilities for new resources. A driver loading module 35 thereafter loads the identified device drivers for use by the devices 20 in response to the allocation of the necessary elements of the resources 14.
FIG. 3 generally shows the steps for a method for configuring the devices 20 for operation with the computer system 8. Turning now to FIGS. 1 and 3, the computer-implemented process is started and device information is collected at step 37 for each of the devices 20. For each device 20, the device information includes identity data for uniquely identifying the corresponding device and resource allocation data for defining the resource requirements of the particular device. This device information is preferably associated with or otherwise linked with information for the corresponding system bus 18.
The resulting product of this data collection process can be viewed as an inventory of the devices 20 connected to the system bus 18 of the computer 8.
For the devices that are designed to take advantage of the present inventive concept, at least a portion of the device information can be acquired by accessing the memory storage device 29. However, certain system-level components and existing "legacy" boards containing devices 20 may not include a memory storage device 29 for storing such device-level information. In this event, the device-level information is preferably acquired from other sources, such as the BIOS program of the computer control system 21 or configuration files of the operating system 10. For the legacy devices, certain device-level information can also be acquired by examining the signature-like responses output by these devices in response to command signals supplied to the I/O ports 28.
A device driver is thereafter obtained at step 38 for each of the devices 20 in response to the device information. At step 39, the resources 14, which are used by the devices 20 during computing operations, are allocated based upon the device information. Resource allocation is preferably an iterative routine that attempts to identify and resolve potential resource conflicts prior to an actual conflicting use of the resources 14 by the devices 20 during operation of the computer 8. In response to this allocation of the resources 14, the device driver for each of the devices is loaded at step 40 and the devices 20 are subsequently activated for operation with the computer 8, thereby terminating this configuration process.
Device information is preferably acquired for each of the devices 20, including all devices 20 supported by peripheral devices, add-on type adapter boards, system-level devices, and certain system busses. However, in the event that one of the devices 20 itself is implemented as a system bus, it may be necessary to complete the configuration tasks for the identified devices 20 connected to the system bus 18 prior to detecting any devices on the newly identified system bus. These tasks include identifying device drivers, allocating resources, and loading identified device drivers for the remaining devices 20 on the first system bus prior to identifying any of the devices connected to this newly identified second system bus.
For the computer 8, the steps shown in FIG. 3 are preferably first conducted for the devices 20 on the integrated bus 15 and thereafter repeated to permit the identification of the additional devices connected to the interface bus 17'. This enables the devices 20 connected to the "parent" component represented by the ISA bus to be configured prior to the devices 20 on the "child" component of the PCMCIA bus. It will be understood that this type of configuration sequence is defined by the connection of second system bus (the PCMCIA bus) to a first system bus (the ISA bus).
In this manner, the devices 20 of the computer 8 are identified and associated with each of the system busses 18. In addition, the resources 14 are efficiently allocated based upon the device information, and the device drivers are assigned and loaded to enable the operations of the devices 20 with the computer 8. It will be understood that the proper configuration of the computer 8 is necessary for the devices 20 to use the resources 14 of the computer 8 and to communicate with the application programs (not shown) running on the computer 8. Accordingly, the computer 8 is typically configured prior to using the devices 20 for the desired computing functions.
Although it is desirable to configure all of the devices 20 during the power-up or boot processes, particularly prior to completing the test and initialization routines of the computer control system 21, many resource conflicts cannot be fully resolved without complete knowledge of all resource requirements for the devices 20. Nevertheless, the preferred system supports the configuration process during the computer start-up sequence for a limited set of the devices 20, specifically those boot-level devices that are required to "come-up" active during the boot process. Thus, this pre-boot configuration process is completed for the "fixed" system-level devices on the computer's system board, which is also described as a motherboard. Likewise, the pre-boot configuration process is completed for the set of devices 20 that are connected to integrated expansion board, specifically the integrated bus 15, and are required for boot-level operations. The remaining devices 20, which also may require resource allocation, are preferably configured only after the computer 8 has completed the boot process.
FIGS. 4A-C are flow chart diagrams illustrating the preferred steps of a method for configuring the devices of a computer system. Referring now to FIGS. 4A-C, which are collectively described herein as FIG. 4, and to FIG. 1, the configuration process is initiated in step 41 by powering-up the computer 8.
In step 42, certain devices 20 on the system board, which are also described as system-level devices, are configured in response to powering the computer 8. These system-level devices, which are configured based upon power-on default configuration settings, typically include I/O interfaces, the keyboard controller, the serial and parallel interfaces, the display controller, the system timer, the PIC, and the DMA controller. It will be appreciated that many of these components are mounted on the motherboard of a conventional personal computer. The system-level devices are preferably configured based upon default configuration parameters stored in the computer control system 21. The default configuration parameters for the system-level devices in the computer 8 are defined by the resource requirements and resource dependencies for such devices.
The preferred configuration process is based upon the collection of device-specific information from each of the devices 20 of the computer 8 to support the allocation of the resources 14 to those connected devices. Thus, still referring to FIGS. 1 and 4, the preferred configuration process continues for the devices 20 that are connected to the system-level expansion bus of the computer 8, specifically the integrated bus 15. In step 44, the integrated bus 15 is selected and an enumerator (not shown) is loaded for the ISA bus. In subsequent steps, each of the devices 20 connected to the ISA bus of the computer 8 is examined to obtain device information.
In step 46, one of the devices 20 on the selected ISA bus is detected to enable the communication of device information from the detected device 20. For the ISA bus, the detected device is isolated from the remaining devices on the bus to permit interference-free communications with that device. Nevertheless, it will be appreciated that other types of system busses do not require isolation of the detected device to enable communications with that device. The preferred system for detecting the interface boards associated with the devices 20, isolating a particular interface board, and collecting device information is described in a related application, U.S. patent application Ser. No. 08/023,689, filed Feb. 25, 1993, entitled "System and Method for Computer Interface Board Identification," which is assigned to the assignee for this application and hereby incorporated by reference. The system described in the referenced application automatically determines which interface boards are connected to a computer bus and automatically assigns parameter selections to ensure proper operation of the boards within the computer.
At step 48, the detected device 20 is assigned a device identification code that preferably identifies the particular device as a certain device type connected to a selected bus, in this case, the integrated bus 15. The device identification code comprises an identification code and a system bus code. The identification code comprises a data string which uniquely define the corresponding device. The identification code can include characters defined by the well known American Standard Code for Information Interchange (ASCII) or a combination of ASCII and non-ASCII data bytes. Similarly, the system bus code, which also can be implemented as a string of ASCII characters or a combination or ASCII and non-ASCII data, uniquely identifies a corresponding system bus. The identification code is typically supplied by the device 20, whereas the system bus code is associated with the system bus 18 and is generated external to the device 20. For example, a modem is preferably assigned an identification code that is different from the identification code for a printer, and different architecture expansion busses, such as ISA and MCA busses, are preassigned different system bus codes. Thus, the identification code defines the detected device and the system bus code defines the selected system bus that supplies the connection for the detected device.
For the preferred embodiment, the identification code is used to identify the class or the type of the device 20. The vendor of the peripheral device associated with the device 20 typically defines the unique identification code for that device. Nevertheless, it will be appreciated that the identification code does not need to contain any information about the class or the type of the device 20. Indeed, the only requirement for the device identification code is that the data string formed by this combination of the system bus code and the identification code should be consistently used each time the computer 8 boots to uniquely identify the particular device 20 on the selected bus 18.
The collection of device information continues at step 50. Specifically, logical configuration data is obtained for the detected device 20. The logical configuration data is preferably logically linked to the device identification code for the particular device 20. This device information is preferably stored in nonvolatile memory that is allocated for such use by the operating system 10. In addition, if the particular device 20 represents a newly installed device for the computer 8, then the device information is also stored within the computer database 16 to maintain an archival record of all of the devices 20 that have been installed for operation with the computer 8.
The logical configuration data defines the set of resources 14 necessary for operation of the particular device 20 with the computer 8. Specifically, the logical configuration data comprises both resource requirement information and resource dependency information. The resource requirement information defines certain resources 14 which are necessary for operation of the particular device 20. It will be appreciated that computer resources, such as the resources 14, include multiple resource options or elements, such as allocated memory ranges and a predefined set of interrupts, DMA channels, and I/O ports. Thus, the resource requirement information preferably defines a range of elements for each of the resources 14 required for the operation of the associated device. For example, a printer may require a communications port within a range of the I/O ports 28. In contrast, the resource dependency information defines a particular combination of resource elements which are necessary for the operation of the particular device 20. For example, the resource dependency information for a modem may define a specific combination of an interrupt and an I/O port for the operation of that device.
Upon completing the collection of device information from the detected device 20, an inquiry is conducted at step 52 to determine whether device information has been obtained from all of the devices 20 on selected bus, in this case, the integrated bus 15. If the answer is negative, the "NO" branch is followed to the step 46 to continue the collection of device information from the remaining devices 20 on the integrated bus 15. In contrast, the "YES" branch is followed to the step 54
if device information has been acquired from all such devices 20. At this point, the device identity data and resource usage information have been obtained for each device 20 that either is a system-level device or is directly connected to the integrated bus 15.
In step 54, an inquiry is conducted to identify the subset of the devices 20 that must be active upon completion of the boot process. For the devices 20 that do not require a default-type configuration during the power-up sequence, the "NO" branch is followed to the step 56 and those devices preferably remain inactive during the power-up sequences. In contrast, the "YES" branch is followed from the step 54 to the step 58 for the devices 20 that must be activated during the boot process. Based upon this inventory of the identified devices 20 requiring activation during the boot process, a boot-level device driver for each of those devices is obtained in step 58 to enable communications between the boot-level devices and the computer 8. These boot-level devices typically include the system-level devices 20 on the system board of the computer 8 and certain adapter boards connected to the integrated bus 15, such as a display controller or a mass memory storage device controller, i.e., a fixed disk controller.
In step 60, an inquiry is conducted to determine if the resources 14 required by the set of identified devices 20 requiring enablement for the boot process are conflict-free. If so, the "YES" branch is followed to step 64. The resources required by these devices 20 are allocated during the step 64 and the required device drivers are subsequently loaded to permit boot-level operations. Alternatively, if the response to the inquiry in step 60 is negative, then the "NO" branch is followed to step 62 and the user is preferably supplied an error message based upon the detection of a resource conflict during the boot process. In response, the user may be required to power down the computer and manually reconfigure the computer 8. However, it is not anticipated that a resource conflict for boot-level devices will be a common occurrence because the configurations for many of the boot-level devices mounted on the system board are typically pre-defined to be conflict-free by the computer vendor.
The above-described configuration steps 42-64 are preferably supported by software routines for the modified BIOS program of the computer control system 21. The modified BIOS program supports the identification of each of the boot-level devices, including system-level devices and the boot-level devices on the integrated bus 15, and stores device-related information within computer memory to support the configuration tasks for those devices. With the exception of the system-level devices, the configuration support supplied by the modified BIOS program concludes after the POST process is completed. Specifically, after POST, the control of the configuration process for all remaining devices 20 is preferably maintained by the operating system
10 rather than by the computer control system 21.
Upon completion of this portion of the configuration process, the conventional POST and BOOT routines are then conducted for the computer 8 during the steps 66 and 68, respectively. As a result of loading the operating system 10, selected configuration files of the operating system 10, such as Config.Sys and the Autoexec.Bat files, are processed by the computer 8. The Config.Sys file is a system configuration file that contains parameters which determine how the computer will operate. The Autoexec.Bat file supports user customization of computer operations, particularly the handling of application programs. The operations of both Config.Sys and Autoexec.Bat files for conventional operating systems are well known and will not be described herein.
Although FIG. 4 shows a specific sequence for the POST and BOOT routines, it will be understood that the configuration process can be adapted to operate with a different sequence of those routines. For example, at least a portion of the task operations of the POST routine can be completed after power-up and prior to the configuration of system-level devices in step 42.
Unlike the system board devices and the boot-level devices connected to the integrated bus 15, which are respectively configured during steps 42 and 64, the remaining devices 20 connected to the integrated bus 15 are configured only after the boot operations for the computer 8 have been completed. However, the configuration operations for the nonboot-level devices on the integrated bus 15 are supported by the collection of device information that occurred prior to the BOOT process of step
68. In particular, this configuration process is supported by the current inventory of both the system board devices and the set of devices 20 connected to the integrated bus 15.
At step 70, the device drivers for this set of nonboot-level devices are identified in response to the device information collected during the preboot operation. The device drivers are typically identified by accessing corresponding device-related information that is stored in the computer database 16 or by accessing a predefined file of the operating system 10. The process for identifying and obtaining the device drivers will be described in more detail below with respect to FIG.
5.
The device information collected during the preboot operation further supports the allocation and the assignment of the resources 14 required by the nonboot-level devices on the integrated bus 15. In step 72, the resource requirements and dependencies for each of the nonboot-level devices 20 on the integrated system bus 15 are compared to the available resources 14. This comparison permits a determination of whether a potential resource conflict exists. In an iterative fashion, potential resource conflicts are arbitrated and resolved prior to resource allocation. In step 74, the resources 14 are allocated to the nonboot-level devices 20 based upon the arbitration results of the step 72 and those devices are configured in step
76. In view of the allocated resources, the identified device drivers are loaded in step 78 and the devices are enabled for operation with the computer 8. This arbitration process is described in more detail below with respect to FIG. 13.
For the system board devices and the set of devices directly connected to the integrated bus 15, device information has now been collected and stored in volatile computer memory and, as required for newly installed devices, in the nonvolatile memory of the computer database 16. The device information for the devices 20 on the integrated bus 15 may identify one or more of the devices as another system bus 18 capable of supporting other connected devices 20. Device information has not yet been collected for the "children" devices of each system bus 18 connected to the integrated bus 15. Nevertheless, for the preferred embodiment, the tasks of identifying device drivers, arbitrating and allocating the resources 14, and loading the identified device drivers for the set of nonboot-level devices 20 on the integrated bus 15 enable the subsequent collection of device information from these children devices. Thus, at step 80, an inquiry is conducted to determine whether any of the devices 20 on the selected integrated bus 15 are operable as system busses. If not, the "NO" branch is followed to step 82 and the automated configuration operation for the computer 8 is completed. In contrast, if another system bus is connected to the computer 8, then the "YES" branch is followed to step 84 to continue the data collection process.
Referring still to FIGS. 1 and 4, in step 84, another one of the system busses 18 is selected to support the configuration of the set of the devices 20 connected to that selected bus. For the illustrative example of FIG. 1, the interface bus 17' is selected and the enumerator for that bus is loaded. One of the devices 20 on the interface bus 17' is subsequently detected in step 86. At step 88, the detected device 20 is assigned a device identification code comprising the identification code for the detected device and the system bus code for the interface bus 17'. Likewise, logical configuration data is obtained for the detected device 20 during the step 90 to define the resources 14 necessary for operation of the device.
Upon completing collection of device information from the detected device 20, an inquiry is conducted at step 92 to determine whether device information has been obtained from all of the devices connected to the interface bus 17'. If the answer is negative, the "NO" branch is followed to the step 86 to continue the collection of device information from those remaining devices 20. In contrast, the "YES" branch is followed to the step 70 to enable the sequence of identifying device drivers, arbitrating and allocating the resources 14, and loading the identified device drivers for the detected devices 20 of the interface bus 17'. This process will be repeated until all of the system busses 18 within the computer 8 are detected.
It will be understood that the device information collection process has now been completed for the existing devices 20 of the computer 8. Specifically, the device identification code and the logical configuration information have been collected from each of the devices 20. This device information is preferably stored in the computer memory 22 to support any additional configuration operations that are necessitated by another asynchronous event affecting the operating state of the computer 8.
It will be appreciated that existing personal computers generally do not include a modified BIOS program to implement the specific sequence defined by the steps 42 through steps 64 for the configuration process shown in FIG. 4. Accordingly, for computers with a conventional BIOS program, the system board devices are configured by the BIOS program and the initialization processes performed by the POST and BOOT routines are conducted in a known manner in response to powering the computer system. After the completion of the boot sequences, an embodiment of the present invention supports the automated configuration of the remaining devices connected to this computer system.
Specifically, upon booting the computer, this postboot configuration process for a conventional computer starts at step 84 by selecting one of the system busses 18. However, unlike the previously-described configuration operation, the integrated bus 15 is selected only after the completion of the BOOT routine. In this manner, the sequence of tasks starting at step 84 of FIG. 4 are completed to identify and characterize the existing devices 20 of the computer 8, to identify the associated device drivers, to allocate the resources 14, and to load the device drivers.
Referring now to FIG. 1, a device driver for an associated device 20 can be obtained from one of several alternative sources of the computer system 8, including the operating system 10, the device 20 itself, or indirectly from the user via a disk containing the device driver. The preferred operating system 10 includes one or more files that contain device drivers for supporting the most commonly used peripheral devices and add-on type adapter boards. Similarly, the memory storage device 29
located on certain adapter boards also can be used for storing device drivers for operating the associated device with a personal computer. In addition, conventional peripheral devices and adapter boards are often times supplied by vendors with one or more computer disks containing installation software programs and supporting software programs, including device drivers. Upon loading a device driver for use by the computer 8, the device driver is typically stored on the computer's mass storage memory device, such as a fixed disk.
To maintain an archival record for each device 20 installed on the computer 8, the device information for a particular device is stored within a corresponding record of the computer database 16. Thus, the central database 16 preferably maintains a set of records containing a listing of the identification codes for the devices 20 of the computer 8 and a listing of compatible device information. Each record contains a device identification field for storing an identification code associated with a certain primary device and a compatible device identification field for storing identification codes associated with both a primary device and corresponding compatible devices. A compatible device is a device that performs the same functions to achieve the same results in the same manner as the primary device. For example, a first modem card may be compatible with a second modem card because both cards perform the same function and conform to an industry standard for modem communications.
The compatible device identification field also permits the recording of priority data to permit a further distinction between the devices compatible with a primary device. For example, this priority data can include vendor-assigned ranking data and is supplied by ranking the identification codes for compatible devices in the preferred order of use. In this manner, priority data is supplied by the order in which the identification codes within the compatible device identification field are listed.
Table 1 shows a several of the data fields for a record of the computer database 16. The first field, which is labeled "Device Identification", contains identification codes for the devices 20. The second field, which is labeled "Compatible Device Identification", contains identification codes and related information for compatible devices. This information represents at least a portion of the data stored in typical record in the computer database 16.
TABLE 1 ______________________________________ Device Compatible Device Identification Identification Identification Code Identification Code ______________________________________ Audio B3 Audio B3 Sblast Windows Sound ______________________________________
As shown in Table 1, each identification code in the device identification field has one or more corresponding entries in the compatible device identification field, namely entries for identification codes and installation dates. A primary device is identified in the device identification field by the identification code "AudioB3". The compatible device identification field also contains the same identification code. When the device identification field and the compatible device identification field contain the same identification code, a device driver specifically designed for use with the identified device is available on the computer 8. This type of device driver is also described as a primary device driver. Thus, for the example shown in Table 1, the primary device driver is available to support the operations of the particular device 20 identified by the entry "Audio B3" in the device identification field.
The primary device driver, if available, is preferably obtained to support the operations of the corresponding device 20. If the primary device driver is not available, then the compatible device identification field is preferably searched for an entry representing a compatible device. If at least one compatible device entry is present, then a device driver that is compatible with the primary device is available on the computer 8. It is well known that a device driver may support the operations of both the intended primary device and one or more other compatible devices sharing similar operating characteristics with the primary device. Thus, a "compatible" device driver, if available, may be used to enable communications of the particular device 20 with the computer system 8 in the absence of the primary device driver for that particular device. It will be understood that the primary device driver is intended to support the computer operations of the primary device, whereas each compatible device driver supports computer operations for the primary device and other compatible devices.
The compatible device identification field in Table 1 further shows a pair of identification codes associated with devices that are compatible with the "AudioB3" device, namely the devices identified by the codes "Sblast" and "Windows Sound". Compatible devices are identified by identification codes having names that are dissimilar to the identification code for the primary device.
For the preferred embodiment, the selection of a device driver corresponding to a compatible device is determined by the following convention: if a primary device driver is not available to support the particular device, then the device driver for the compatible device having the highest priority ranking is selected from the compatible device driver candidates. The identification code for the compatible device having the highest priority ranking is preferably listed within the compatible device identification field prior to any of the remaining identification codes. Thus, the identification codes for compatible devices are ordered based upon priority ranking assigned to those devices. Assuming the absence of the identification code for that primary device in the compatible device information field, this convention indicates that the "Sblast" device driver should be selected to support the "Audio B3" device based upon the order of the identification codes for the listed devices.
FIG. 5 is a flow chart diagram that illustrates the preferred steps for a method of obtaining a device driver for use with a device of the computer system. Turning now to FIGS. 1 and 5, a computer-implemented process for obtaining a device driver is started in step 100 and proceeds to step 102, where a determination is made whether the records of the computer database 16 contain an entry designating that a primary device driver corresponding to the particular device 20 is available on the computer 8. To locate the record associated with the particular device 20, the computer database 16 is searched by using the identification code for the particular device 20 as the entry key. If the identification code for the particular device 20 is found in both the device identification and compatible device identification fields of a selected record, then the "YES" path is followed to step 104. This affirmative response indicates that the primary device driver for the particular device 20 can be obtained on the computer 8. A device driver maintained by the computer 8 typically can be retrieved by accessing a corresponding file on the fixed disk of the computer 8 and reading the stored device driver. For the preferred operating system 10, certain device-related information, including the identity of device drivers for the corresponding device, is stored within information files called .INF files. In the step 104, the device driver corresponding to the primary device is selected and assigned for use by the particular device 20. The process concludes if the primary device driver is available. In contrast, if a positive match is not achieved, then the "NO" path is followed to the step 106.
If the primary device driver for the device 20 is not available, then the compatible device identification field for the selected record is preferably searched in step 106 for an identification code that corresponds to a device that is "compatible" with the particular device 20. If one or more of the identification codes representing compatible devices are contained in this field, then the "YES" branch is followed to the step 108. In step 108, the compatible device identification field is also searched for the identified compatible device having the highest priority ranking. The preferred compatible device is listed first within the compatible device identification field. Upon finding the preferred compatible device, the process proceeds to the step 110. In the step 110, the device driver corresponding to the compatible device having the highest priority ranking is selected and assigned for use with the particular device 20, thereby concluding the search for a compatible device driver.
If the response to the step 106 is negative, then the "NO" branch is followed to the step 112. The user is requested in step 112 to supply a substitute device driver for the supporting operation of the device with the computer system 8. This request is typically supplied as a text-based statement displayed on a display or monitor for the computer system 8 or as an audio prompt generated by the computer system 8. In response to the request, the user can insert within the appropriate computer drive a flexible disk or another form of appropriate electronic media containing the device driver program, thereby permitting the computer 8 to access the device driver program. In response to reading the disk, in step 114, the computer 8 stores the device driver program on a selected mass storage memory device.
In step 116, the substitute device driver is obtained and instructed to enable the particular device 20 for operation with the computer 8. In addition, to maintain the records on the computer database 16, the identification code for the device associated with the new substitute device driver is listed in the appropriate record(s) of the computer database 16. This database update is achieved by adding the identification code for the device driver within the compatible device identification field for the record associated with the particular device 20. In this manner, the archival record indicates that the substitute device driver supports the operations of the particular device 20 and has been installed for use on the computer 8.
AUTOMATED CONFIGURATION SYSTEM COMPONENTS
FIG. 6 is a block diagram that illustrates the components and their structural communications links for the referred embodiment of the operating system 10. Referring to FIGS. 1 and 6, the operating system 10 comprises numerous software programs or modules, including enumerators 150, a hardware tree 152, a registry 153, arbitrators 154, device drivers 156, a configuration manager 158, and a device configuration database 160. The enumerators 150, the registry 153, the arbitrators 154, and the device drivers 156 are associated with the configuration manager 158. It will be understood that the operating system 10 also preferably interacts with a modified BIOS program of the computer control system 21 and various hardware components of the computer 8, including the system busses 18 and the devices 20, to support the configuration system.
These components are generally described within sections headed by their respective identifying legends and are best shown in FIGS. 6-8. A more detailed review of certain components, namely the enumerator 150 and the arbitrator 154, is also supplied below with respect to FIGS. 9-13.
Enumerators
The enumerators 150 operate to report the identities of detected devices 20 on the system busses 18 in response to certain events that affect the operating state of the computer 8. These events include changes to the state of power supplied to the computer 8, including the states Power-on, Standby, Suspend, or Resume. The events also include the insertion of a device onto or the removal of a device from a system bus, or the insertion into or the removal of a computer system from a docking station or an expansion chassis. It will be appreciated that this connection (or removal) of a device 20 to the computer 8 can be completed by a physical connection or as a logical connection via a wireless communication link or a network. In addition, for certain devices 20, the enumerators 150 also can transmit assigned resource elements from the configuration manager 158 for use by the devices 20 in response to an allocation of the resources 14.
Each enumerator 150 is assigned to a component of the computer 8 that is capable of having children, namely, those components that provide a connection for yet another hardware component. It will be understood that computer busses, such as the system busses 18, represent a common mechanism for connecting adapter boards and peripheral devices to a personal computer. In similar fashion, for the preferred computer control system 21, the modified BIOS program represents a mechanism for providing a central connection for the system-level devices of a personal computer, including the interfaces for the keyboard controller, the display controller, the I/O controller, and the serial and parallel controllers. Thus, for a typical personal computer, the enumerators 150 can be assigned to the computer busses and to the modified BIOS program that supports the configuration of boot-level devices. For the computer 8 shown in FIG. 1, individual enumerators 150 are assigned to the system busses 18, including the local bus, the ISA bus, SCSI bus, and the PCMCIA bus, and to the modified BIOS program of the computer control system 21.
For each system bus 18, the associated enumerator 150 is programmed to recognize the operating characteristics of its assigned computer bus and to support the configuration of the devices 20 connected to that computer bus. Specifically, these enumerators obtain device-related information from the devices 20 and subsequently store such information within a central memory location of the hardware tree 152. As outlined above, this collection of device information is initiated in response to the events affecting the enumerator's assigned system bus 18, such as the insertion or removal of a device or a change in the power state of the computer 8. It will be understood that this collection of device information from the devices 20 in the computer
8 is described as an enumeration process.
Likewise, for the computer control program 21, an enumerator 150 can be programmed to recognize the system-level devices of the computer 8 and to support the configuration of those system-level devices. The enumerator 150 assigned to the modified BIOS program accesses the default-type configuration parameters for the system-level devices from the modified BIOS in response to events affecting the computer's operating state, including the power-on event, and stores this information within the hardware tree 152. Furthermore, the enumerator 150 for the modified BIOS program can be programmed to detect the insertion of the computer into or the removal of the computer from a docking station and outputs an indication of these events to the configuration manager 158.
A unique system bus code is associated with each of the enumerators 150. For example, the ISA bus enumerator has a particular system bus code that is different from the system bus code assigned to the MCA bus enumerator. An enumerator 150 forms a device identification code for each device 20 connected to the assigned system bus 18 by appending its system bus code to the identification code for the device 20. The device identification code also can include an instance number that is assigned by the enumerator 150 to distinguish identical devices 20 connected to the same system bus 18.
An instance number can be obtained by the enumerator 150 from the device 20 itself, if available, or is assigned to the device 20. By way of example, for the ISA bus, the ISA bus enumerator assigns an instance number to a logical device based upon a serial number that is stored in the memory storage device 29 associated with that device. If no serial number is available for the device 20, then the enumerator 150 is required to use some other unique attribute to generate an uniquely addressable instance number. For the PCMCIA bus, an alternative scheme for assigning an instance number is based upon the use of the slot number for the bus socket connected to the device 20.
The enumerator 150 also obtains logical configuration data for each of the devices 20 of the computer 8. Logical configuration data is preferably linked to corresponding device information to maintain a logical link with the represented device
20. For a typical device, the device identification code and the logical configuration data, which are collectively referred to as device information, are preferably stored within a device node associated with that device. Each device node is preferably maintained in the tree-like memory structure of the hardware tree 152, as described below.
As a result of the resource assignment process, the enumerators 150 receive data packets containing assigned resource elements for the devices 20. In response to receiving an assignment of the resources 14 for a particular device, the enumerator
150 accesses the appropriate device node to store the resource assignment. In this manner, the assigned resource information is maintained in a central memory location that is accessible by the device and, as required, by the device driver corresponding to that device. Thus, it will be appreciated that the assigned resources for the each of the devices 20 are stored within corresponding device nodes.
The enumerators 150 provide an abstraction layer that effectively separates the controller portion of the operating system 10, the configuration manager 158, from the underlying bus structures of the computer 8. By placing the system bus-level information within the inventive concept of the driver-like enumerators 150, the operating system 10 can be adapted to operate with a variety of present and future computer bus architectures. Thus, unlike conventional operating systems, the configuration manager 158 can communicate with a variety of system busses without any knowledge of the characteristics of those system busses because such information is supplied by the abstraction layer of the enumerators 150. The structure and operations of the enumerators 150 are described in more detail below with respect to FIGS. 9 through 11.
Hardware Tree
The hardware tree 152 supplies a hierarchical representation of the device identities, the resource usage requirements, and the resource assignments for the present devices 20 operating with the computer 8. The data structure for the hardware tree 152 is maintained in a hierarchical arrangement of device nodes within an allocated portion of the nonvolatile memory supplied by the computer memory 22. This stored information can be accessed by the operating system 10, specifically the