US5713009A - Method and apparatus for configuring a computer system - Google Patents

Method and apparatus for configuring a computer system Download PDF

Info

Publication number
US5713009A
US5713009A US08/525,107 US52510795A US5713009A US 5713009 A US5713009 A US 5713009A US 52510795 A US52510795 A US 52510795A US 5713009 A US5713009 A US 5713009A
Authority
US
United States
Prior art keywords
configuration
computer system
file
operating system
computer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
US08/525,107
Inventor
John Anthony DeRosa, Jr.
Benn Lee Schreiber
Peter Chapman Hayden
Scott Wade Apgar
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Development Co LP
Original Assignee
Digital Equipment Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Digital Equipment Corp filed Critical Digital Equipment Corp
Priority to US08/525,107 priority Critical patent/US5713009A/en
Assigned to DIGITAL EQUIPMENT CORPORATION reassignment DIGITAL EQUIPMENT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SCREIBER, BENN LEE, HAYDEN, PETER CHAPMAN, APGAR, SCOTT WADE, DEROSA, JOHN ANTHONY
Priority to US08/908,143 priority patent/US5822565A/en
Application granted granted Critical
Publication of US5713009A publication Critical patent/US5713009A/en
Assigned to COMPAQ INFORMATION TECHNOLOGIES GROUP, L.P. reassignment COMPAQ INFORMATION TECHNOLOGIES GROUP, L.P. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: COMPAQ COMPUTER CORPORATION, DIGITAL EQUIPMENT CORPORATION
Assigned to HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P. reassignment HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: COMPAQ INFORMATION TECHNOLOGIES GROUP, L.P.
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44505Configuring for program initiating, e.g. using registry, configuration files
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/177Initialisation or configuration control

Definitions

  • This invention relates generally to computer systems, and more particularly to configuring computer system resources.
  • a computer system generally includes system resources available for use, and system devices which may use the system resources.
  • an operating system executes in the computer system providing an environment for efficiently using the system resources and the system devices.
  • System resources include, for example, direct memory access (DMA) channels, sections of system memory, and interrupt lines or signals.
  • System devices include, for example, a device on an input/output (I/O) bus.
  • One technique for configuring a computer system includes executing a configuration utility to perform resource allocation prior to booting an operating system in the computer system.
  • the configuration utility may obtain resource requirements of a system device is through reading a configuration file associated with a specific system device.
  • the configuration file generally describes resource requirements of the system device and any available options in granting its resource requirements.
  • a device vendor supplies a generic version of the configuration file which can be modified in accordance with a computer system and an operating system.
  • One technique used to obtain the configuration file corresponding to a system device includes the configuration utility mapping a unique identifier that denotes a system device to a corresponding configuration filename.
  • the unique identifier is typically stored in a special location, such as a device register or a hardwired circuit on a component card, associated with a system device.
  • the configuration utility retrieves the contents of the special location containing the unique identifier specifying the system device, maps the unique identifier to the corresponding configuration filename, and retrieves the contents of the configuration file.
  • the configuration utility By retrieving the unique identifier of each system device and the contents of a corresponding configuration file, the configuration utility obtains the resource requirements of the system devices in a computer system. Similarly, the configuration utility obtains information describing the system resources available for use by reading a system identifier, for example, from a special location on a central processing unit (CPU) board, determining a corresponding system configuration file, and retrieving the contents of the corresponding system configuration file describing the system resources available for allocation to the system devices.
  • CPU central processing unit
  • the configuration utility obtains the resource requirements of system devices, and the system resources available. In addition, the configuration utility obtains the added constraints imposed by the operating system. Thus, the configuration utility allocates the system resources accordingly among the system devices.
  • the configuration utility needs to account for additional factors, such as additional constraints, requirements, and additional system resources, that affect resource allocation. While the configuration utility can adequately acquire the hardware or system device constraints and the resources available for use, inadequate techniques are typically used to acquire and incorporate additional factors, such as operating system constraints imposed by one of several different operating systems that execute in the computer system.
  • One technique includes an interactive dialogue between the configuration utility and a user manually entering appropriate responses in accordance with cumbersome release notes or other documentation for each device detailing the operating system constraints.
  • This technique has several drawbacks. Data entry is typically performed by manually entering data using an input device, such as a keyboard. It involves a time consuming and cumbersome task of reading detailed written documentation and entering appropriate responses. Additionally, this data entry process is typically repeated each time the computer system needs to be reconfigured due to an addition or modification of a system device, or upon booting a different operating system in the computer system.
  • a second technique used to incorporate operating system constraints includes a computer system vendor supplying one set of configuration files for each operating system supported by that computer system vendor for a particular hardware platform or model. Each set of operating system specific configuration files are premodified to properly reflect operating system constraints. Typically, each set is placed on a single computer disk or floppy and includes one file per device supported by the computer system vendor.
  • This second technique has several drawbacks. There are added manufacturing costs for computer system vendors associated with providing multiple disks, one for each operating system supported by the computer system vendor. Additionally, the number of disks may increase further if the computer vendor has several different hardware models or platforms for each operating system, each platform requiring a different configuration file for an operating system. Another drawback with this second technique is the additional costs of maintaining and updating the numerous files on the multiple computer disks. Product reliability and quality may decrease since both maintaining the numerous configuration files on multiple computer disks, and also requiring the user to use a correct operating system disk for a particular operating system increase the chance for human error. The latter may result in additional vendor support costs due to increased customer problems and complaints.
  • a third technique used to incorporate the operating system constraints includes modifying the configuration utility so that a portion of the operating system constraints or dependencies are embedded within the configuration utility in accordance with operating systems and devices supported by a particular vendor. Difficulties arise since the configuration utility is typically owned and maintained by independent vendor other than the computer system vendor. The computer system vendor usually has no control over the content and development of the configuration utility.
  • the configuration utility is typically modified by the independent vendor or the computer system vendor to incorporate the necessary modifications per operating system in the configuration utility incurring added costs and complications.
  • the former alternative generally incurs added costs and increased reliance upon the independent vendor to incorporate modifications correctly and as needed.
  • the latter alternative typically incurs additional costs including development and maintenance costs. It is desirable to minimize dependencies on the configuration utility since computer system vendors may frequently add support for new devices requiring additional modifications to the configuration utility. Embedding changes within the configuration utility creates an undesirable dependency since the computer vendor does not typically own and maintain the configuration utility. Such a dependency may delay and complicate added support for new devices, in addition to increasing costs.
  • an apparatus comprising a means for obtaining computer specific information and a configuration utility.
  • the means for obtaining computer specific information includes a means for producing a file identifier corresponding to a configuration file by using input parameter values comprising a portion of the computer specific information.
  • the configuration utility configures the computer system by performing resource allocation using configuration data from a configuration file.
  • the filename of the configuration file is constructed, using the file identifier, by a filename constructing means included in the configuration utility.
  • the method includes the steps of obtaining computer system specific information and producing a file identifier using input parameters describing a portion of the computer specific information.
  • the file identifier is transmitted to a configuration utility which constructs a filename corresponding to a configuration file containing configuration data used by the configuration utility to allocate system resources.
  • a computer system may be configured in a cost and time efficient manner without adversely incurring additional costs and simultaneously increasing quality and system reliability.
  • the arrangement is flexible so that a computer system vendor may optimally customize underlying system software and a configuration utility by applying one of a wide range of different variations.
  • a computer system vendor may minimize external dependencies by implementing functions subject to modifications in the firmware program which is under the control of the computer system vendor. Modifications may be performed efficiently with a minimal amount of associated cost and time and without imposing undue restrictions on a computer system vendor and customer, such as encumber the computer system vendor with additional costs and dependencies and require a customer to wait for additional device support.
  • FIG. 1 is a simplified computer system
  • FIG. 2 depicts the configuration utility and underlying system software interaction
  • FIG. 3 is a flowchart outlining steps for obtaining a configuration file
  • FIG. 4 is a flowchart outlining steps for constructing a configuration filename
  • FIG. 5 is a flowchart outlining steps for locating a configuration file
  • FIG. 6 is a flowchart depicting steps performed during rebooting of a computer system.
  • a computer system 10 is shown to include a central processing unit (CPU) 11, a computer disk drive 12, a system bus (first bus) 13, another system device 14 (which may be an input device, such as a keyboard connected to a terminal), and a main memory 16 each interconnected by system bus 13 via bus interfaces 18a-18d.
  • the CPU, disk drive, other system device, second bus and main memory communicate over the system bus 13.
  • Machine executable programs, such as a configuration utility 20 and underlying system software 22 are loaded in the main memory 16 for execution by the CPU.
  • a machine executable program typically contains machine instructions to be executed by the CPU which reads in the machine executable program from memory over the bus and executes the machine instructions.
  • a configuration utility 20 is generally a machine executable program comprising machine instructions that are loaded into memory, for example, from a computer disk using the disk drive 12.
  • the underlying system software 22 is generally a machine executable program loaded into memory for execution during computer system startup prior to booting a particular operating system. Both the configuration utility and the underlying system software will be discussed in greater detail below.
  • performing resource allocation for a computer system includes configuring bus interfaces, such as bus interfaces 18a-18e coupled to system bus 13 of FIG. 1, in accordance with system devices, system resources and operating system constraints.
  • bus interfaces such as bus interfaces 18a-18e coupled to system bus 13 of FIG. 1
  • a system device on an I/O bus may require a particular address space in memory or certain DMA channels.
  • the operating system may impose further constraints, such as require reservation of a portion of system address space beginning at a particular address, or not accommodate interrupt sharing among multiple system devices.
  • the configuration utility is used to configure the devices on the system bus.
  • the configuration utility is usually a machine executable program stored on a computer disk and produced by compiling source code with a compiler producing object files which are linked with a linker producing the configuration utility machine executable program.
  • the source files typically contain source statements written in a programming language, such as "C", or an assembly language.
  • a computer system vendor usually licenses and distribute a machine executable copy of the configuration utility which is typically owned and maintained by an independent vendor other than the computer system vendor.
  • the configuration utility is generally executed when a computer system, as depicted in FIG. 1, needs to be initially configured or reconfigured.
  • the computer system is initially configured and then reconfigured when there is a modification to the computer system which may affect system resource allocation.
  • a modification includes, for example, when a different operating system is booted, when there is a modification to the computer system resources, such as the addition of a system device, or when there is a change in the allocation of system address space.
  • the configuration utility is initially executed to determine resource allocation information which is saved in non-volatile memory. Upon rebooting the computer system, the saved resource allocation information is read from the non-volatile memory. The configuration utility is subsequently re-executed upon a change in system configuration, such as the addition of a new system device, to reconfigure the computer system.
  • the configuration utility is capable of executing with minimal underlying system software generally stored as firmware in read-only memory (ROM).
  • a preferred implementation embodying the invention will now be described which automates computer system configuration by modifying the configuration utility and the underlying system software to include information dependent on operating system constraints.
  • a preferred implementation embodying the invention incorporates or embeds a portion of the operating system constraint information within the underlying system software to minimize the amount of operating system dependent information embedded within the configuration utility for efficiency and cost effectiveness.
  • the configuration utility 20 and underlying system software 22 are typically loaded into main memory when a system configuration is performed.
  • the underlying system software When the underlying system software is executed in the computer system, it provides information to the configuration utility 20 enabling the configuration utility to identify a particular operating system.
  • the configuration utility determines the configuration files 24 needed for the particular operating system identified by the underlying system software.
  • the underlying system software is loaded (at step 32) into memory and executed.
  • An operator may interact with the underlying system software, for example, using a keyboard, to obtain (at step 34) computer system specific information including identifying the particular operating system used in the computer system.
  • the underlying system software stores (at step 36) the computer system specific information in non-volatile memory for subsequent use, such as when rebooting an operating system or when executing the configuration utility.
  • the configuration utility is loaded (at step 38) into memory for execution during system configuration, as in FIG. 2.
  • the configuration utility interacts (at step 40) with the underlying system software to obtain a string identifier incorporating a portion of the computer system specific information previously stored in non-volatile memory, such as the particular operating system which may be subsequently executed.
  • the configuration utility constructs (at step 42) a configuration filename using the string identifier.
  • the configuration utility may also use other information, such as a device identifier corresponding to a system device or a system identifier corresponding to the particular computer system CPU board, to construct the configuration filename.
  • the configuration utility locates and obtains (at step 44) data from the configuration files needed to properly configure the computer system.
  • the configuration utility configures the computer system using the configuration data and produces resource allocation results describing which system resources have been allocated to which system devices.
  • a device identifier is typically an alphanumeric string comprising two (2) concatenated portions--a computer system vendor identifier and a device number.
  • a computer system vendor supports various devices in a computer system that includes a bus, such as an Extended Industry Standard Architecture (EISA) bus.
  • EISA Extended Industry Standard Architecture
  • a computer system vendor is usually assigned a vendor identifier, such as vendor identifier "DEC" for Digital Equipment Corporation, typically by registering with a designated group that allocates vendor identifiers. The vendor further assigns a specific digit sequence to each particular device supported in the vendor's computer system.
  • a system identifier is typically an alphanumeric string including the vendor identifier and a computer system model number designating a particular hardware model of the computer system.
  • the resource allocation results may be stored in non-volatile memory for subsequent use, for example, during rebooting the computer system.
  • the configuration utility may directly store the results in non-volatile memory or the results may be communicated to the underlying system software which, in turn, stores the configuration results.
  • Configuration files may be obtained from configuration files stored on a computer disk.
  • the configuration data read by the configuration utility may also be stored in memory, such as non-volatile memory.
  • the configuration files may exist on one or more computer disks or "floppies" in an organization that facilitates search and retrieval of configuration information by the configuration utility.
  • There are many possible organizations for the configuration files which depends on the number and type of specific files, the file directory structure and filenaming conventions.
  • One possible organization includes placing all the configuration files on a single computer disk.
  • the configuration file may be stored on a computer disk with the configuration utility.
  • the configuration file contains statements or configuration data written in a description language that is part of a standard or specification used to describe resource requirements of a system device.
  • a computer system may include an EISA bus or a Peripheral Component Interconnect (PCI) bus that has a corresponding standard specification which includes a description language used to identify and describe, in configuration files, the resource requirements for system devices using that particular bus.
  • PCI Peripheral Component Interconnect
  • Configuration files in a preferred organization on a single disk are generally be divided into one or more categories.
  • the number and type of categories may vary with the actual configuration files, as will be described below.
  • One organization includes two categories, “common” and “platform specific”.
  • a second preferred organization includes the categories “operating system specific", and "common”.
  • “Common” configuration files are industry standard files typically supplied by a computer vendor that have not been modified for any specific operating system.
  • "Operating system specific” configuration files are common configuration files which have been modified in accordance with particular operating system constraints.
  • “Platform specific” configuration files are common configuration files which have been modified for a particular hardware platform or system model, such as Digital Equipment Corporation's Venturis 575 computer system or AlphaStation 250 computer system incorporating Digital's Alpha architecture. Additional categories are possible, such as a category which combines both a computer platform and a particular operating system. For example, system device "123" may be supported by a computer vendor on the OpenVMS Operating System and Windows NT Operating System on hardware platforms “plat1" and “plat2". If the configuration file is different for each combination of operating system and platform, a computer system vendor may provide four different configuration files for each device, thereby having four categories, each category representing a platform and operating system combination.
  • a hierarchical directory structure comprises multiple levels of directories and subdirectories whose organization inherently represents a hierarchy or grouping. Opposing the hierarchical structure is the flat directory structure typically comprising one directory at a single level.
  • each directory may contain all files of a particular category further organized into multiple subdirectories, such as operating system specific files or platform specific files.
  • a flat directory structure may also be used in which all files comprising a category include a predefined prefix string and are placed in a single directory.
  • the flat directory structure generally embeds the file organization in the filename rather than in a hierarchical directory structure.
  • a configuration file name for the Windows NT operating system begins with the prefix string "NT”.
  • a configuration file name for "common” configuration files begins with the prefix string "
  • Both the common and operating system specific configuration files are placed in a single directory in a flat directory structure organization.
  • a separate directory includes Windows NT operating system designated configuration files and another directory includes the common configuration files.
  • a combination of the flat and the hierarchical directory structures and file naming conventions may be used depending on the particular file system and its corresponding restrictions.
  • Information regarding the structure of the foregoing file organization is generally embedded in the configuration utility and underlying system software. More particularly, in steps 40, 42, and 44 of FIG. 3 the configuration utility and underlying system software work harmoniously to locate and retrieve the needed configuration files in the file organization. A preferred implementation minimizes modifications and dependencies on the configuration utility by partitioning, for example, those tasks subject to frequent modifications to the underlying system software.
  • the underlying system software performs a string computation producing the string identifier used by the configuration utility to formulate a filename for a configuration file using one or more inputs or parameters.
  • the input values parameterize criteria by which consumed system resources vary.
  • Both type and number of the inputs used by the underlying system software to produce the string identifier may vary depending on the task partitioning between the underlying system software and the configuration utility for a particular implementation embodying the invention.
  • the underlying system software obtains one or more input values using the information stored in non-volatile memory. For a first example, if a computer system vendor only supports one computer platform or model, the underlying system software may produce a string identifier that only varies with operating system.
  • the underlying system software may have only one input value, the operating system type previously saved in non-volatile memory.
  • the underlying system software may produce the string identifier using two or more input values. These input values may include operating system type and the platform or model number of the computer system being configured. The underlying system software may read both input values from the non-volatile memory accordingly producing a string identifier including these input values.
  • the underlying system software may use only one input parameter value for the operating system type and allocate the task of encoding the particular platform in the filename to the configuration utility.
  • the optimal allocation of tasks between the configuration utility and the underlying system software may vary with each implementation depending on, for example, the configuration utility, the computer system, and its vendor. However, the configuration utility and the underlying system software functionally complement each other.
  • the underlying system software may obtain input values from more than one source and the form of the information may vary. As previously described, for example, the underlying system software obtains an input value, such as the particular operating system, from non-volatile memory. Each string in a predefined set of alphanumeric or alphabetic strings identifies a corresponding operating system similar to the prefix string, such as "VMS" identifying the OpenVMS Operating System, as previously described in file organization and naming conventions.
  • VMS OpenVMS Operating System
  • the string identifier at step 40 may be communicated to the configuration utility from the underlying system software using an application programming interface (API).
  • API is an interface which corresponds to a called routine.
  • the API is used by a calling routine to invoke the called routine and communicate data in input and output parameters between the called and calling routines as needed.
  • the called routine corresponds to a routine in the underlying system software that is invoked by the configuration utility.
  • the data communicated includes an output parameter corresponding to the string identifier transmitted from the underlying system software to the configuration utility to identify, for example, the particular operating system.
  • the output parameter received by the configuration utility may be the string identifier identifying the operating system.
  • the configuration utility uses the string identifier to construct 42 a configuration filename for each device.
  • step 42 usually includes the configuration utility using a unique system identifier to construct a system resources configuration filename and using a device identifier to construct a device configuration filename.
  • the configuration utility receives (at step 46) the string identifier, for example, from the underlying system software as a routine return value or output parameter.
  • the configuration utility gets (at step 47) the system identifier identifying the computer system from, for example, the CPU board.
  • the string identifier is concatenated (at step 48) with the system identifier corresponding to the particular computer system to construct the system resource configuration filename.
  • the system resource configuration file is located (at step 49) and its data retrieved.
  • the configuration utility constructs a file name and locates the corresponding configuration file for each device in the computer system.
  • a test is performed (at step 50) to determine if all needed configuration files have been retrieved. If so, the utility stops (at step 51). Otherwise, the configuration utility retrieves a device identifier (at step 52) and the string identifier returned from the underlying system software is concatenated (at step 53) with the device identifier to form a device configuration filename. The device configuration data file is located (at step 54) and its contents read by the configuration utility. The loop that includes steps 50-54 is performed for each device in the computer system.
  • a graphics board is a system device 14 in the computer system 10. Its unique identifier specifies the manufacturer and model number of the graphics board.
  • the configuration utility retrieves the graphics board identifier, maps it to a filename identifying the corresponding configuration file, and retrieves the contents of the corresponding configuration file describing the resource requirements of the graphics board.
  • the graphics board or card may require one (1) megabyte of system memory that begins on a particular address boundary, as described in the configuration file.
  • the configuration utility may perform the steps of FIG. 4 in a different order, for example, by performing steps 48 and 49 after performing the loop of steps 50-54.
  • steps 48 and 53 another embodiment may form a final string for a configuration filename using additional input strings besides the system identifier and the device identifier.
  • the configuration utility may concatenate a string suffix for the file extension, such as ".CFG".
  • the string suffix may vary with, for example, operating system.
  • the configuration utility may map a particular operating system as designated by an output parameter from the underlying system software, to a corresponding file extension.
  • a final string for the configuration filename is formed by concatenating:
  • the second string may be determined by the configuration utility.
  • the second string may also be determined by the underlying system software and passed as another output parameter of a procedure call to the configuration utility.
  • the configuration files describing system resources for a particular computer system and the configuration files for system devices co-exist on the same computer disk.
  • the configuration utility employs a method at steps 49 and 54 for locating the configuration file.
  • FIG. 5 one method for locating a configuration file in a hierarchical directory structure arrangement is depicted.
  • the directory structure includes an operating system specific subdirectory and a common subdirectory at the same level.
  • the configuration filename is formed (at step 56).
  • the configuration utility may search for a device's configuration file for a particular operating system by first attempting to locate the configuration file in the appropriate operating system specific directory (at step 58). If the configuration file is found, the search stops (at step 60) and the contents of the file are read. If no file is found, the configuration utility may default to retrieving the configuration file in the common directory (at step 62).
  • a configuration utility may not employ any particular algorithm if the string identifier returned by the underlying system software contains a complete filename and directory specification for the particular computer system and operating system.
  • the configuration utility may search for the configuration file in a set of directories in a predetermined order typically referred to as a search order.
  • the search order may be communicated to the configuration utility, for example, from the underlying system software as an output parameter.
  • the search order may also be fixed and encoded within the logic of the configuration utility.
  • a particular search order designation may apply to both hierarchical directory and flat directory organizations.
  • the search order may designate particular directory and subdirectory paths to be search in a predetermined order to locate a particular configuration file.
  • the search order may specify a portion of a filename, such as a subsequent string prefix, to be used to formulate an alternate filename.
  • the configuration utility may search for file "VplatX123.CFG" in which the "V" prefix designates an OpenVMS configuration file, and "platX” designates a particular Alpha hardware platform.
  • search order may specify that the next file to search for is "Va123.CFG", designating an OpenVMS Alpha configuration file but not for a particular Alpha hardware platform. Lastly, if "Va123.CFG” is not found, the search order may specify to retrieve a default unmodified industry standard configuration file "123.CFG”.
  • Parameters in one or more API may transmit information, including the string identifier and search path, from the underlying system software to the configuration utility.
  • the following API represented in a pseudocode notation transmits the string identifier to the configuration utility when placed as a procedure call in the configuration utility with the routine "call -- underlying -- system -- software -- api -- ONE" included in the underlying system software.
  • string -- identifier is a character string, as used in step 48 of FIG. 4, to form the system resource configuration filename.
  • string -- identifier may include alphanumeric characters specifying a particular operating system executing in the computer system.
  • a subsequent call to the following API transmits the search path to the configuration utility:
  • the parameter "num -- search” is an integer numeric value identifying the number of elements in the string array "search -- path" which is an ordered list of strings. Each element in the list is a string representing a successive location, such as a directory in a hierarchical configuration file organization, in which the configuration utility attempts to locate the correct configuration data file. "num -- search” is typically used by the configuration utility during a search for the configuration file. For example, in a hierarchical configuration file directory structure, if the parameter "search -- path" has three string elements as follows: “PLAT1", “OS1” and “COMMON”, "num -- search” is 3. Each element of the "search -- path" array identifies the name of a directory to search for the configuration data file.
  • search -- path is a zero-based array comprising an integer number of ⁇ N ⁇ elements, as denoted by "num -- search”, designated as elements "search -- path 0!, “search -- path 1!, . . . "search -- path N-1!.
  • the configuration utility may execute an algorithm as follows using the parameter values returned by the two foregoing APIs to locate the system resource configuration file:
  • inventions may include variations of the previous APIs.
  • an implementation may use only a single API to transmit needed information to the configuration utility.
  • the foregoing technique and examples used to formulate a device configuration filename, and locate the device configuration file may also be employed in a preferred embodiment to formulate a system resource filename and locate the corresponding system resource configuration file.
  • An advantage of embedding any of the foregoing methods or information in the underlying system software rather than the configuration utility allows the computer system vendor freedom to, for example, modify the file organization, or add files to the existing file structure without requiring changes in the configuration utility typically owned and maintained by an outside independent vendor as previously described.
  • Another advantage afforded by the invention is the great flexibility provided to computer system vendors to partition complementary tasks between the configuration utility and underlying system software. Using the foregoing invention decreases the overall cost incurred by a computer system vendor and increases customer satisfaction.
  • An advantage provided by the invention to the purchaser of a computer system is the ease and efficiency in initial configuration and reconfiguration of a computer system.
  • FIG. 6 a flowchart sets forth steps that may be performed during rebooting a computer system after the initial configuration embodying the invention is performed.
  • the underlying system software reads 64 the configuration information results previously stored by the configuration program or the underlying system software in non-volatile memory.
  • the underlying system software then allocates the computer system resources in accordance with the configuration information results incorporating the operating system constraints.
  • the underlying system software proceeds to booting 68 the operating system.
  • Prior art techniques include using manual data entry to incorporate operating system constraints, or relied upon the configuration utility vendor to incorporate the ongoing support required by the computer system vendor.
  • a preferred implementation embodying the invention automates computer system configuration by minimizing the amount of required user interaction and specifically by reducing the manual data entry. The amount of external dependencies are limited so that the computer vendor retains control over the mechanism, the underlying system software, by which she may add or modify support for additional hardware devices is provided. This results in reduced costs, and increased product quality and reliability.
  • the foregoing technique affords a flexible and efficient way of performing an automated configuration of a computer system in a cost and time efficient manner. Additionally, a preferred implementation accomplishes this without adversely affecting the reliability and quality of a computer system and its ability to correctly and efficiently use supported devices. A preferred implementation embodying the invention neither impedes the computer system vendor's ability to add support for new devices or operating systems, nor her ability to provide corrections for presently supported devices.

Abstract

A method and apparatus for configuring a computer system is presented. Underlying system software communicates information to a configuration utility. The information identifies a particular operating system that executes in the computer system. Using this information, the configuration utility formulates configuration filenames and retrieves data from the configuration files describing system resources, system device requirements, and operating system constraints. The configuration utility performs the system configuration by allocating system resources to system devices in accordance with the operating system constraints and system device requirements.

Description

BACKGROUND OF THE INVENTION
This invention relates generally to computer systems, and more particularly to configuring computer system resources.
As it is known in the art, a computer system generally includes system resources available for use, and system devices which may use the system resources. Generally, an operating system executes in the computer system providing an environment for efficiently using the system resources and the system devices. System resources include, for example, direct memory access (DMA) channels, sections of system memory, and interrupt lines or signals. System devices include, for example, a device on an input/output (I/O) bus.
For a computer system to function properly, it is generally necessary to configure the computer system. This is typically done by examining the system resources available for use and resource requirements of system devices. Resource allocation of the system resources among the system devices is performed in accordance with constraints of both the operating system and the system devices.
One technique for configuring a computer system includes executing a configuration utility to perform resource allocation prior to booting an operating system in the computer system.
One way in which the configuration utility may obtain resource requirements of a system device is through reading a configuration file associated with a specific system device. The configuration file generally describes resource requirements of the system device and any available options in granting its resource requirements. Usually, a device vendor supplies a generic version of the configuration file which can be modified in accordance with a computer system and an operating system.
One technique used to obtain the configuration file corresponding to a system device includes the configuration utility mapping a unique identifier that denotes a system device to a corresponding configuration filename. The unique identifier is typically stored in a special location, such as a device register or a hardwired circuit on a component card, associated with a system device. The configuration utility retrieves the contents of the special location containing the unique identifier specifying the system device, maps the unique identifier to the corresponding configuration filename, and retrieves the contents of the configuration file.
By retrieving the unique identifier of each system device and the contents of a corresponding configuration file, the configuration utility obtains the resource requirements of the system devices in a computer system. Similarly, the configuration utility obtains information describing the system resources available for use by reading a system identifier, for example, from a special location on a central processing unit (CPU) board, determining a corresponding system configuration file, and retrieving the contents of the corresponding system configuration file describing the system resources available for allocation to the system devices.
The configuration utility obtains the resource requirements of system devices, and the system resources available. In addition, the configuration utility obtains the added constraints imposed by the operating system. Thus, the configuration utility allocates the system resources accordingly among the system devices.
Generally, besides considering system device requirements, the configuration utility needs to account for additional factors, such as additional constraints, requirements, and additional system resources, that affect resource allocation. While the configuration utility can adequately acquire the hardware or system device constraints and the resources available for use, inadequate techniques are typically used to acquire and incorporate additional factors, such as operating system constraints imposed by one of several different operating systems that execute in the computer system.
Currently, acquiring and incorporating the additional constraints, such as those associated with an operating system, during system configuration may be handled using several different techniques.
One technique includes an interactive dialogue between the configuration utility and a user manually entering appropriate responses in accordance with cumbersome release notes or other documentation for each device detailing the operating system constraints. This technique has several drawbacks. Data entry is typically performed by manually entering data using an input device, such as a keyboard. It involves a time consuming and cumbersome task of reading detailed written documentation and entering appropriate responses. Additionally, this data entry process is typically repeated each time the computer system needs to be reconfigured due to an addition or modification of a system device, or upon booting a different operating system in the computer system.
A second technique used to incorporate operating system constraints includes a computer system vendor supplying one set of configuration files for each operating system supported by that computer system vendor for a particular hardware platform or model. Each set of operating system specific configuration files are premodified to properly reflect operating system constraints. Typically, each set is placed on a single computer disk or floppy and includes one file per device supported by the computer system vendor.
This second technique has several drawbacks. There are added manufacturing costs for computer system vendors associated with providing multiple disks, one for each operating system supported by the computer system vendor. Additionally, the number of disks may increase further if the computer vendor has several different hardware models or platforms for each operating system, each platform requiring a different configuration file for an operating system. Another drawback with this second technique is the additional costs of maintaining and updating the numerous files on the multiple computer disks. Product reliability and quality may decrease since both maintaining the numerous configuration files on multiple computer disks, and also requiring the user to use a correct operating system disk for a particular operating system increase the chance for human error. The latter may result in additional vendor support costs due to increased customer problems and complaints.
A third technique used to incorporate the operating system constraints includes modifying the configuration utility so that a portion of the operating system constraints or dependencies are embedded within the configuration utility in accordance with operating systems and devices supported by a particular vendor. Difficulties arise since the configuration utility is typically owned and maintained by independent vendor other than the computer system vendor. The computer system vendor usually has no control over the content and development of the configuration utility.
Using this third approach, the configuration utility is typically modified by the independent vendor or the computer system vendor to incorporate the necessary modifications per operating system in the configuration utility incurring added costs and complications. The former alternative generally incurs added costs and increased reliance upon the independent vendor to incorporate modifications correctly and as needed. The latter alternative typically incurs additional costs including development and maintenance costs. It is desirable to minimize dependencies on the configuration utility since computer system vendors may frequently add support for new devices requiring additional modifications to the configuration utility. Embedding changes within the configuration utility creates an undesirable dependency since the computer vendor does not typically own and maintain the configuration utility. Such a dependency may delay and complicate added support for new devices, in addition to increasing costs.
SUMMARY OF THE INVENTION
In accordance with the present invention is an apparatus comprising a means for obtaining computer specific information and a configuration utility. The means for obtaining computer specific information includes a means for producing a file identifier corresponding to a configuration file by using input parameter values comprising a portion of the computer specific information. The configuration utility configures the computer system by performing resource allocation using configuration data from a configuration file. The filename of the configuration file is constructed, using the file identifier, by a filename constructing means included in the configuration utility.
Further, in accordance with the invention is a method for configuring a computer system. The method includes the steps of obtaining computer system specific information and producing a file identifier using input parameters describing a portion of the computer specific information. The file identifier is transmitted to a configuration utility which constructs a filename corresponding to a configuration file containing configuration data used by the configuration utility to allocate system resources.
With such an arrangement, a computer system may be configured in a cost and time efficient manner without adversely incurring additional costs and simultaneously increasing quality and system reliability. The arrangement is flexible so that a computer system vendor may optimally customize underlying system software and a configuration utility by applying one of a wide range of different variations. Additionally, with such an arrangement, a computer system vendor may minimize external dependencies by implementing functions subject to modifications in the firmware program which is under the control of the computer system vendor. Modifications may be performed efficiently with a minimal amount of associated cost and time and without imposing undue restrictions on a computer system vendor and customer, such as encumber the computer system vendor with additional costs and dependencies and require a customer to wait for additional device support.
BRIEF DESCRIPTION OF THE DRAWINGS
The above-mentioned and other features of the invention will become more apparent by reference to the following description taken in connection with the accompanying drawings in which:
FIG. 1 is a simplified computer system;
FIG. 2 depicts the configuration utility and underlying system software interaction;
FIG. 3 is a flowchart outlining steps for obtaining a configuration file;
FIG. 4 is a flowchart outlining steps for constructing a configuration filename;
FIG. 5 is a flowchart outlining steps for locating a configuration file; and
FIG. 6 is a flowchart depicting steps performed during rebooting of a computer system.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
Referring now to FIG. 1, a computer system 10 is shown to include a central processing unit (CPU) 11, a computer disk drive 12, a system bus (first bus) 13, another system device 14 (which may be an input device, such as a keyboard connected to a terminal), and a main memory 16 each interconnected by system bus 13 via bus interfaces 18a-18d. A second bus 17, which may be an I/O bus or another system bus, is also connected to the system bus 13 via bus interface 18e. The CPU, disk drive, other system device, second bus and main memory communicate over the system bus 13. Machine executable programs, such as a configuration utility 20 and underlying system software 22 are loaded in the main memory 16 for execution by the CPU. A machine executable program typically contains machine instructions to be executed by the CPU which reads in the machine executable program from memory over the bus and executes the machine instructions. A configuration utility 20 is generally a machine executable program comprising machine instructions that are loaded into memory, for example, from a computer disk using the disk drive 12. The underlying system software 22 is generally a machine executable program loaded into memory for execution during computer system startup prior to booting a particular operating system. Both the configuration utility and the underlying system software will be discussed in greater detail below.
Generally, performing resource allocation for a computer system includes configuring bus interfaces, such as bus interfaces 18a-18e coupled to system bus 13 of FIG. 1, in accordance with system devices, system resources and operating system constraints. For example, a system device on an I/O bus may require a particular address space in memory or certain DMA channels. The operating system may impose further constraints, such as require reservation of a portion of system address space beginning at a particular address, or not accommodate interrupt sharing among multiple system devices.
Typically, the configuration utility is used to configure the devices on the system bus. The configuration utility is usually a machine executable program stored on a computer disk and produced by compiling source code with a compiler producing object files which are linked with a linker producing the configuration utility machine executable program. The source files typically contain source statements written in a programming language, such as "C", or an assembly language.
A computer system vendor usually licenses and distribute a machine executable copy of the configuration utility which is typically owned and maintained by an independent vendor other than the computer system vendor.
The configuration utility is generally executed when a computer system, as depicted in FIG. 1, needs to be initially configured or reconfigured. The computer system is initially configured and then reconfigured when there is a modification to the computer system which may affect system resource allocation. A modification includes, for example, when a different operating system is booted, when there is a modification to the computer system resources, such as the addition of a system device, or when there is a change in the allocation of system address space.
Generally, the configuration utility is initially executed to determine resource allocation information which is saved in non-volatile memory. Upon rebooting the computer system, the saved resource allocation information is read from the non-volatile memory. The configuration utility is subsequently re-executed upon a change in system configuration, such as the addition of a new system device, to reconfigure the computer system. Typically, the configuration utility is capable of executing with minimal underlying system software generally stored as firmware in read-only memory (ROM).
Due to the limited functionality provided by the underlying system software, the machine executable code comprising the underlying system software is generally much less than the machine executable code comprising a typical operating system. The underlying system software also has control of the computer system prior to booting similar to the control an operating system may have subsequent to booting the computer system.
A preferred implementation embodying the invention will now be described which automates computer system configuration by modifying the configuration utility and the underlying system software to include information dependent on operating system constraints. Generally, a preferred implementation embodying the invention incorporates or embeds a portion of the operating system constraint information within the underlying system software to minimize the amount of operating system dependent information embedded within the configuration utility for efficiency and cost effectiveness.
Referring now to FIG. 2, the configuration utility 20 and underlying system software 22 are typically loaded into main memory when a system configuration is performed. When the underlying system software is executed in the computer system, it provides information to the configuration utility 20 enabling the configuration utility to identify a particular operating system. The configuration utility determines the configuration files 24 needed for the particular operating system identified by the underlying system software.
Referring now to FIG. 3, the particular method steps for obtaining configuration files of the preferred implementation of FIG. 2 are shown. Initially when a computer system is "powered" on (at step 30), the underlying system software is loaded (at step 32) into memory and executed. An operator may interact with the underlying system software, for example, using a keyboard, to obtain (at step 34) computer system specific information including identifying the particular operating system used in the computer system. The underlying system software stores (at step 36) the computer system specific information in non-volatile memory for subsequent use, such as when rebooting an operating system or when executing the configuration utility. Typically, the configuration utility is loaded (at step 38) into memory for execution during system configuration, as in FIG. 2. The configuration utility interacts (at step 40) with the underlying system software to obtain a string identifier incorporating a portion of the computer system specific information previously stored in non-volatile memory, such as the particular operating system which may be subsequently executed. The configuration utility constructs (at step 42) a configuration filename using the string identifier. The configuration utility may also use other information, such as a device identifier corresponding to a system device or a system identifier corresponding to the particular computer system CPU board, to construct the configuration filename. The configuration utility locates and obtains (at step 44) data from the configuration files needed to properly configure the computer system. The configuration utility configures the computer system using the configuration data and produces resource allocation results describing which system resources have been allocated to which system devices.
A device identifier is typically an alphanumeric string comprising two (2) concatenated portions--a computer system vendor identifier and a device number. Generally, a computer system vendor supports various devices in a computer system that includes a bus, such as an Extended Industry Standard Architecture (EISA) bus. A computer system vendor is usually assigned a vendor identifier, such as vendor identifier "DEC" for Digital Equipment Corporation, typically by registering with a designated group that allocates vendor identifiers. The vendor further assigns a specific digit sequence to each particular device supported in the vendor's computer system. Similarly, a system identifier is typically an alphanumeric string including the vendor identifier and a computer system model number designating a particular hardware model of the computer system.
Typically, the resource allocation results may be stored in non-volatile memory for subsequent use, for example, during rebooting the computer system. The configuration utility may directly store the results in non-volatile memory or the results may be communicated to the underlying system software which, in turn, stores the configuration results.
Information or configuration data contained in configuration files may be obtained from configuration files stored on a computer disk. The configuration data read by the configuration utility may also be stored in memory, such as non-volatile memory.
The configuration files may exist on one or more computer disks or "floppies" in an organization that facilitates search and retrieval of configuration information by the configuration utility. There are many possible organizations for the configuration files which depends on the number and type of specific files, the file directory structure and filenaming conventions. One possible organization includes placing all the configuration files on a single computer disk.
The configuration file may be stored on a computer disk with the configuration utility. Generally, the configuration file contains statements or configuration data written in a description language that is part of a standard or specification used to describe resource requirements of a system device. For example, a computer system may include an EISA bus or a Peripheral Component Interconnect (PCI) bus that has a corresponding standard specification which includes a description language used to identify and describe, in configuration files, the resource requirements for system devices using that particular bus.
Configuration files in a preferred organization on a single disk are generally be divided into one or more categories. The number and type of categories may vary with the actual configuration files, as will be described below. One organization includes two categories, "common" and "platform specific". A second preferred organization includes the categories "operating system specific", and "common".
"Common" configuration files are industry standard files typically supplied by a computer vendor that have not been modified for any specific operating system. "Operating system specific" configuration files are common configuration files which have been modified in accordance with particular operating system constraints. "Platform specific" configuration files are common configuration files which have been modified for a particular hardware platform or system model, such as Digital Equipment Corporation's Venturis 575 computer system or AlphaStation 250 computer system incorporating Digital's Alpha architecture. Additional categories are possible, such as a category which combines both a computer platform and a particular operating system. For example, system device "123" may be supported by a computer vendor on the OpenVMS Operating System and Windows NT Operating System on hardware platforms "plat1" and "plat2". If the configuration file is different for each combination of operating system and platform, a computer system vendor may provide four different configuration files for each device, thereby having four categories, each category representing a platform and operating system combination.
The organization of the categories may be reflected in the file naming convention and directory structure in many different ways, such as a hierarchical directory structure and a flat directory structure. Generally, a hierarchical directory structure comprises multiple levels of directories and subdirectories whose organization inherently represents a hierarchy or grouping. Opposing the hierarchical structure is the flat directory structure typically comprising one directory at a single level. Using a hierarchical directory structure, each directory may contain all files of a particular category further organized into multiple subdirectories, such as operating system specific files or platform specific files. A flat directory structure may also be used in which all files comprising a category include a predefined prefix string and are placed in a single directory. The flat directory structure generally embeds the file organization in the filename rather than in a hierarchical directory structure. For example, in a flat directory structure, a configuration file name for the Windows NT operating system begins with the prefix string "NT". Also, a configuration file name for "common" configuration files begins with the prefix string "|". Both the common and operating system specific configuration files are placed in a single directory in a flat directory structure organization. However, in a hierarchical directory structure, for example, a separate directory includes Windows NT operating system designated configuration files and another directory includes the common configuration files. Also, a combination of the flat and the hierarchical directory structures and file naming conventions may be used depending on the particular file system and its corresponding restrictions.
Information regarding the structure of the foregoing file organization is generally embedded in the configuration utility and underlying system software. More particularly, in steps 40, 42, and 44 of FIG. 3 the configuration utility and underlying system software work harmoniously to locate and retrieve the needed configuration files in the file organization. A preferred implementation minimizes modifications and dependencies on the configuration utility by partitioning, for example, those tasks subject to frequent modifications to the underlying system software.
Referring to 40, 42, and 44 of FIG. 3, the particular steps performed by the underlying system software and the configuration utility, and the particular string identifier communicated from the underlying system software to the configuration utility will be discussed in greater detail below.
Referring to step 40 of FIG. 3, generally the underlying system software performs a string computation producing the string identifier used by the configuration utility to formulate a filename for a configuration file using one or more inputs or parameters. Functionally, the input values parameterize criteria by which consumed system resources vary. Both type and number of the inputs used by the underlying system software to produce the string identifier may vary depending on the task partitioning between the underlying system software and the configuration utility for a particular implementation embodying the invention. Typically, the underlying system software obtains one or more input values using the information stored in non-volatile memory. For a first example, if a computer system vendor only supports one computer platform or model, the underlying system software may produce a string identifier that only varies with operating system. The underlying system software may have only one input value, the operating system type previously saved in non-volatile memory. Alternatively, in a second example, if a computer system vendor supports multiple computer platforms or models, the underlying system software may produce the string identifier using two or more input values. These input values may include operating system type and the platform or model number of the computer system being configured. The underlying system software may read both input values from the non-volatile memory accordingly producing a string identifier including these input values. In a third example, if a computer vendor supports multiple platforms, the underlying system software may use only one input parameter value for the operating system type and allocate the task of encoding the particular platform in the filename to the configuration utility. The optimal allocation of tasks between the configuration utility and the underlying system software may vary with each implementation depending on, for example, the configuration utility, the computer system, and its vendor. However, the configuration utility and the underlying system software functionally complement each other.
The underlying system software may obtain input values from more than one source and the form of the information may vary. As previously described, for example, the underlying system software obtains an input value, such as the particular operating system, from non-volatile memory. Each string in a predefined set of alphanumeric or alphabetic strings identifies a corresponding operating system similar to the prefix string, such as "VMS" identifying the OpenVMS Operating System, as previously described in file organization and naming conventions.
The string identifier at step 40 may be communicated to the configuration utility from the underlying system software using an application programming interface (API). Generally, an API is an interface which corresponds to a called routine. The API is used by a calling routine to invoke the called routine and communicate data in input and output parameters between the called and calling routines as needed. In the instant example, the called routine corresponds to a routine in the underlying system software that is invoked by the configuration utility. The data communicated includes an output parameter corresponding to the string identifier transmitted from the underlying system software to the configuration utility to identify, for example, the particular operating system. For example, the output parameter received by the configuration utility may be the string identifier identifying the operating system.
The configuration utility uses the string identifier to construct 42 a configuration filename for each device. As previously described, step 42 usually includes the configuration utility using a unique system identifier to construct a system resources configuration filename and using a device identifier to construct a device configuration filename.
Referring now to FIG. 4, one method for constructing the foregoing resource and device configuration filenames of step 42 is depicted. The configuration utility receives (at step 46) the string identifier, for example, from the underlying system software as a routine return value or output parameter. The configuration utility gets (at step 47) the system identifier identifying the computer system from, for example, the CPU board. The string identifier is concatenated (at step 48) with the system identifier corresponding to the particular computer system to construct the system resource configuration filename. The system resource configuration file is located (at step 49) and its data retrieved. The configuration utility constructs a file name and locates the corresponding configuration file for each device in the computer system. A test is performed (at step 50) to determine if all needed configuration files have been retrieved. If so, the utility stops (at step 51). Otherwise, the configuration utility retrieves a device identifier (at step 52) and the string identifier returned from the underlying system software is concatenated (at step 53) with the device identifier to form a device configuration filename. The device configuration data file is located (at step 54) and its contents read by the configuration utility. The loop that includes steps 50-54 is performed for each device in the computer system.
For example, a graphics board is a system device 14 in the computer system 10. Its unique identifier specifies the manufacturer and model number of the graphics board. The configuration utility retrieves the graphics board identifier, maps it to a filename identifying the corresponding configuration file, and retrieves the contents of the corresponding configuration file describing the resource requirements of the graphics board. The graphics board or card may require one (1) megabyte of system memory that begins on a particular address boundary, as described in the configuration file.
Other methods or variations for constructing the configuration filename are possible. The configuration utility may perform the steps of FIG. 4 in a different order, for example, by performing steps 48 and 49 after performing the loop of steps 50-54. As a variation to steps 48 and 53, another embodiment may form a final string for a configuration filename using additional input strings besides the system identifier and the device identifier. For example, the configuration utility may concatenate a string suffix for the file extension, such as ".CFG". The string suffix may vary with, for example, operating system. The configuration utility may map a particular operating system as designated by an output parameter from the underlying system software, to a corresponding file extension. In another example, at step 53, a final string for the configuration filename is formed by concatenating:
i) a first string representing the file identifier as supplied by the underlying system software;
ii) a second string representing a model number for the particular computer system; and
iii) a ".CFG" file extension.
The second string may be determined by the configuration utility. The second string may also be determined by the underlying system software and passed as another output parameter of a procedure call to the configuration utility.
Typically, the configuration files describing system resources for a particular computer system and the configuration files for system devices co-exist on the same computer disk.
The configuration utility employs a method at steps 49 and 54 for locating the configuration file. Referring now to FIG. 5, one method for locating a configuration file in a hierarchical directory structure arrangement is depicted. Specifically, the directory structure includes an operating system specific subdirectory and a common subdirectory at the same level. The configuration filename is formed (at step 56). The configuration utility may search for a device's configuration file for a particular operating system by first attempting to locate the configuration file in the appropriate operating system specific directory (at step 58). If the configuration file is found, the search stops (at step 60) and the contents of the file are read. If no file is found, the configuration utility may default to retrieving the configuration file in the common directory (at step 62).
A configuration utility may not employ any particular algorithm if the string identifier returned by the underlying system software contains a complete filename and directory specification for the particular computer system and operating system. In a hierarchical directory structure, the configuration utility may search for the configuration file in a set of directories in a predetermined order typically referred to as a search order. The search order may be communicated to the configuration utility, for example, from the underlying system software as an output parameter. The search order may also be fixed and encoded within the logic of the configuration utility.
A particular search order designation may apply to both hierarchical directory and flat directory organizations. For example, in a hierarchical directory arrangement, the search order may designate particular directory and subdirectory paths to be search in a predetermined order to locate a particular configuration file. However, in a flat directory arrangement, such as a single directory, the search order may specify a portion of a filename, such as a subsequent string prefix, to be used to formulate an alternate filename. For example, for device "123" with a flat directory structure in a computer system with the OpenVMS operating system and multiple hardware platforms, the configuration utility may search for file "VplatX123.CFG" in which the "V" prefix designates an OpenVMS configuration file, and "platX" designates a particular Alpha hardware platform. If no such file is found, the search order may specify that the next file to search for is "Va123.CFG", designating an OpenVMS Alpha configuration file but not for a particular Alpha hardware platform. Lastly, if "Va123.CFG" is not found, the search order may specify to retrieve a default unmodified industry standard configuration file "123.CFG".
Parameters in one or more API may transmit information, including the string identifier and search path, from the underlying system software to the configuration utility. For example, the following API represented in a pseudocode notation transmits the string identifier to the configuration utility when placed as a procedure call in the configuration utility with the routine "call-- underlying-- system-- software-- api-- ONE" included in the underlying system software.
______________________________________                                    
call.sub.-- underlying.sub.-- system.sub.-- software.sub.-- api.sub.--    
ONE (                                                                     
char *string.sub.-- identifier)                                           
______________________________________                                    
The parameter "string-- identifier" is a character string, as used in step 48 of FIG. 4, to form the system resource configuration filename. As previously mentioned, "string-- identifier" may include alphanumeric characters specifying a particular operating system executing in the computer system.
A subsequent call to the following API transmits the search path to the configuration utility:
______________________________________                                    
call.sub.-- underlying.sub.-- system.sub.-- software.sub.-- api.sub.--    
TWO (                                                                     
integer num.sub.-- search;                                                
char *search.sub.-- path   !)                                             
______________________________________                                    
The parameter "num-- search" is an integer numeric value identifying the number of elements in the string array "search-- path" which is an ordered list of strings. Each element in the list is a string representing a successive location, such as a directory in a hierarchical configuration file organization, in which the configuration utility attempts to locate the correct configuration data file. "num-- search" is typically used by the configuration utility during a search for the configuration file. For example, in a hierarchical configuration file directory structure, if the parameter "search-- path" has three string elements as follows: "PLAT1", "OS1" and "COMMON", "num-- search" is 3. Each element of the "search-- path" array identifies the name of a directory to search for the configuration data file. In the following example, "search-- path" is a zero-based array comprising an integer number of `N` elements, as denoted by "num-- search", designated as elements "search-- path 0!", "search-- path 1!", . . . "search-- path N-1!". The configuration utility may execute an algorithm as follows using the parameter values returned by the two foregoing APIs to locate the system resource configuration file:
______________________________________                                    
/*                                                                        
 * Formulate filename                                                     
 */                                                                       
filename = concatenate                                                    
            (string.sub.-- identifier,                                    
            system.sub.-- identifier,                                     
            ".CFG");                                                      
/*                                                                        
 * Initialize loop variable counter "index", and                          
 * boolean variable "file.sub.-- found"                                   
 */                                                                       
index = 0;                                                                
file.sub.-- found = FALSE;                                                
/*                                                                        
 * loop through the search path array concatenating                       
 * different directories specified in "search.sub.-- path" as             
 * the prefix to the filename                                             
 */                                                                       
while ((index < num.sub.-- search) AND (file.sub.-- found == FALSE))      
temp.sub.-- filename = concatenate                                        
                  (search.sub.-- path index!,                             
                  filename);                                              
/*                                                                        
 * if file exists, stop search and file found                             
 */                                                                       
if(temp.sub.-- filename) exists then                                      
  file.sub.-- found = TRUE;                                               
else                                                                      
/*                                                                        
 * Examine next directory                                                 
 */                                                                       
  index = index + 1;                                                      
}                                                                         
/*                                                                        
 * error condition if no file found and each directory                    
 * searched                                                               
 */                                                                       
If ((index == num.sub.-- search) AND (file.sub.-- found == FALSE))        
 handle error condition                                                   
______________________________________                                    
Other embodiments of the invention may include variations of the previous APIs. For example, an implementation may use only a single API to transmit needed information to the configuration utility. The foregoing technique and examples used to formulate a device configuration filename, and locate the device configuration file may also be employed in a preferred embodiment to formulate a system resource filename and locate the corresponding system resource configuration file.
There are a variety of ways to specify a search order to the configuration utility in a preferred implementation embodying the invention. The optimal method may depend on the underlying directory structure and file organization.
An advantage of embedding any of the foregoing methods or information in the underlying system software rather than the configuration utility allows the computer system vendor freedom to, for example, modify the file organization, or add files to the existing file structure without requiring changes in the configuration utility typically owned and maintained by an outside independent vendor as previously described.
Another advantage afforded by the invention is the great flexibility provided to computer system vendors to partition complementary tasks between the configuration utility and underlying system software. Using the foregoing invention decreases the overall cost incurred by a computer system vendor and increases customer satisfaction.
An advantage provided by the invention to the purchaser of a computer system is the ease and efficiency in initial configuration and reconfiguration of a computer system.
Referring now to FIG. 6, a flowchart sets forth steps that may be performed during rebooting a computer system after the initial configuration embodying the invention is performed. The underlying system software reads 64 the configuration information results previously stored by the configuration program or the underlying system software in non-volatile memory. The underlying system software then allocates the computer system resources in accordance with the configuration information results incorporating the operating system constraints. The underlying system software proceeds to booting 68 the operating system.
Although the foregoing preferred implementation discloses a particular complementary division of function between the configuration utility and the underlying system software, different complementary divisions are possible in other preferred implementations embodying the invention.
Prior art techniques include using manual data entry to incorporate operating system constraints, or relied upon the configuration utility vendor to incorporate the ongoing support required by the computer system vendor. A preferred implementation embodying the invention automates computer system configuration by minimizing the amount of required user interaction and specifically by reducing the manual data entry. The amount of external dependencies are limited so that the computer vendor retains control over the mechanism, the underlying system software, by which she may add or modify support for additional hardware devices is provided. This results in reduced costs, and increased product quality and reliability.
The foregoing technique affords a flexible and efficient way of performing an automated configuration of a computer system in a cost and time efficient manner. Additionally, a preferred implementation accomplishes this without adversely affecting the reliability and quality of a computer system and its ability to correctly and efficiently use supported devices. A preferred implementation embodying the invention neither impedes the computer system vendor's ability to add support for new devices or operating systems, nor her ability to provide corrections for presently supported devices.
Having described preferred embodiments of the invention, it will now become apparent to those of skill in the art that other embodiments incorporating its concepts may be provided. It is felt therefore that this invention should not be limited to the disclosed embodiments but rather should be limited only by the spirit and scope of the appended claims.

Claims (25)

What is claimed is:
1. An apparatus for configuring a computer system, said apparatus comprising:
A) means for obtaining computer system specific information, said means further including:
means for producing a file identifier corresponding to a configuration file using one or more input parameter values comprising a portion of said computer system specific information; and
B) a configuration utility, responsive to said means for obtaining computer specific information, for configuring said computer system by performing resource allocation, said means for obtaining computer specific information communicating said file identifier to said configuration utility, said configuration utility further including:
filename constructing means, responsive to said means for producing a file identifier, for producing a filename using said file identifier and corresponding to a configuration file comprising configuration data used to configure said computer system.
2. The apparatus of claim 1, wherein said computer system includes a bus to be configured and at least one system resource to be allocated for use by at least one system device on said bus, and the apparatus further comprising:
one or more configuration files containing configuration data, at least one of said configuration files corresponding to a system device used in said computer system, at least one of said configuration files is a system resource file describing the system resources available in said computer system.
3. The apparatus of claim 2, wherein said configuration data comprising said configuration files is customized corresponding to said computer system.
4. The apparatus of claim 3, wherein said computer system specific information includes an operating system type representing an operating system that executes in said computer system, and wherein said input parameter values comprising a portion of said computer system specific information including said operating system type.
5. The apparatus of claim 4, wherein said configuration data is customized in accordance with said operating system type.
6. The apparatus of claim 4, wherein one of said system resource files corresponds to said operating system that executes in said computer system.
7. The apparatus of claim 4, wherein said configuration files are organized in a flat directory structure, said configuration files having a filenaming convention including a first prefix string corresponding to said operating system, a second prefix string corresponding to another different operating system that executes in said computer system, a third prefix string corresponding to a first hardware platform, and a fourth prefix string corresponding to industry standard configuration files not customized for a particular computer system or operating system.
8. The apparatus of claim 4, wherein one of said input parameter values describes said operating system.
9. The apparatus of claim 2, wherein said configuration files are organized in a hierarchical directory structure including a first directory corresponding to an operating system that executes in said computer system, a second directory corresponding to a hardware platform, and wherein said first directory comprises at least one configuration file customized for said operating system, and said second directory comprises at least one configuration file customized for said hardware platform.
10. The apparatus of claim 2, wherein said configuration files are organized in a hierarchical directory structure of configuration data files including a common directory corresponding to industry standard files containing generic configuration data that is not customized for a particular operating system or hardware platform of a computer system.
11. The apparatus of claim 2, wherein said configuration data comprising said configuration files is customized in accordance with one or more hardware platforms that may comprise said computer system.
12. The apparatus of claim 2, wherein said configuration file corresponds to one of said system devices, said configuration file including configuration data specifying allocation requirements for a corresponding system device.
13. The apparatus of claim 2, wherein said filename constructing means produces a filename corresponding to said system resource file describing system resources available for allocation in said computer system.
14. The apparatus of claim 1, wherein one of said input values describes a hardware platform of said computer system.
15. The apparatus of claim 1, wherein said computer system includes a read-only memory and said means for obtaining computer specific information is underlying system software stored in said read-only memory.
16. The apparatus of claim 1, wherein said computer system includes a memory, and said configuration utility includes configuration result means for producing configuration result information describing the resource allocation in said computer system, said configuration result information being stored in said memory, and said apparatus further includes rebooting means for retrieving said configuration result information from said memory and then rebooting said computer system.
17. The apparatus of claim 1 further comprising a procedural interface communication means used by said means for producing a file identifier to communicate said file identifier to said filename constructing means.
18. The apparatus of claim 1 further including search path generation means for generating and transmitting to said configuration utility a search path identifying a predetermined search order used by said configuration utility to locate said configuration file.
19. The apparatus of claim 18, wherein said search path identifies directories in a hierarchical directory structure including an operating system directory comprising a configuration data file customized for a particular operating system, a hardware platform directory comprising a configuration data file customized for a particular hardware platform, and a common directory comprising an uncustomized configuration data file.
20. The apparatus of claim 18, wherein said search path identifies files in a flat directory structure including an operating system file comprising configuration data customized for a particular operating system, a hardware platform file comprising configuration data customized for a particular hardware platform, and a common file comprising uncustomized configuration data.
21. The apparatus of claim 1, wherein said file identifier is a string and wherein said filename constructing means concatenates said string with another string producing said filename corresponding to said configuration file.
22. The apparatus of claim 21, wherein said string identifies an operating system that executes in said computer system.
23. A method for configuring a computer system including system resources, said method comprising the steps of:
obtaining, using underlying system software, computer specific information describing said computer system;
producing, using said underlying system software, a file identifier using input parameters describing a portion of said computer specific information;
transmitting, using said underlying system software, said file identifier to a configuration utility that configures said computer system; and
constructing, by said configuration utility using said file identifier and in response to said transmitting step, a filename corresponding to a configuration file including configuration data used by said configuration utility to allocate said system resources.
24. The method of claim 23, wherein said computer system includes a bus to be configured and at least one system resource to be allocated for use by at least one system device on said bus, and wherein one of said input parameters is an operating system type identifying an operating system that executes in said computer system.
25. The method of claim 24, wherein said configuration file is a system resource configuration file describing said system resources in said computer system, said producing step uses said operating system type to produce said file identifier, and said constructing step uses said file identifier and a system identifier uniquely identifying said computer system to construct said filename, and the method further includes the steps of:
constructing, for each of said system devices, a device configuration filename using said file identifier and a device identifier uniquely identifying said each system device, each of said device configuration filenames corresponding to a device configuration file comprising allocation requirements for each said system device;
retrieving configuration data from said device configuration files and said system resource configuration file; and
allocating said system resources to said system devices in accordance with said configuration data producing configuration results describing the system resource allocation.
US08/525,107 1995-09-08 1995-09-08 Method and apparatus for configuring a computer system Expired - Lifetime US5713009A (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US08/525,107 US5713009A (en) 1995-09-08 1995-09-08 Method and apparatus for configuring a computer system
US08/908,143 US5822565A (en) 1995-09-08 1997-08-06 Method and apparatus for configuring a computer system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US08/525,107 US5713009A (en) 1995-09-08 1995-09-08 Method and apparatus for configuring a computer system

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US08/908,143 Continuation US5822565A (en) 1995-09-08 1997-08-06 Method and apparatus for configuring a computer system

Publications (1)

Publication Number Publication Date
US5713009A true US5713009A (en) 1998-01-27

Family

ID=24091955

Family Applications (2)

Application Number Title Priority Date Filing Date
US08/525,107 Expired - Lifetime US5713009A (en) 1995-09-08 1995-09-08 Method and apparatus for configuring a computer system
US08/908,143 Expired - Lifetime US5822565A (en) 1995-09-08 1997-08-06 Method and apparatus for configuring a computer system

Family Applications After (1)

Application Number Title Priority Date Filing Date
US08/908,143 Expired - Lifetime US5822565A (en) 1995-09-08 1997-08-06 Method and apparatus for configuring a computer system

Country Status (1)

Country Link
US (2) US5713009A (en)

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5809331A (en) * 1996-04-01 1998-09-15 Apple Computer, Inc. System for retrieving configuration information from node configuration memory identified by key field used as search criterion during retrieval
US5848231A (en) * 1996-02-12 1998-12-08 Teitelbaum; Neil System configuration contingent upon secure input
US5913218A (en) * 1995-11-06 1999-06-15 Sun Microsystems, Inc System and method for retrieving and updating configuration parameter values for application programs in a computer network
WO1999038070A1 (en) * 1998-01-26 1999-07-29 Intel Corporation An interface for ensuring system boot image integrity and authenticity
US5961611A (en) * 1996-12-27 1999-10-05 Lg Semicon Co., Ltd. Automatic option setting circuit
US5991546A (en) * 1996-09-17 1999-11-23 Cmd Technology, Inc. System and method for interfacing manually controllable input devices to a universal computer bus system
US6029196A (en) * 1997-06-18 2000-02-22 Netscape Communications Corporation Automatic client configuration system
US6038399A (en) * 1997-07-22 2000-03-14 Compaq Computer Corporation Computer manufacturing architecture with two data-loading processes
US6059842A (en) * 1998-04-14 2000-05-09 International Business Machines Corp. System and method for optimizing computer software and hardware
US6125408A (en) * 1997-03-10 2000-09-26 Compaq Computer Corporation Resource type prioritization in generating a device configuration
US6175390B1 (en) * 1996-12-23 2001-01-16 Lg Electronics Inc. Module TV and control method thereof
US20020138600A1 (en) * 2001-03-26 2002-09-26 International Business Machines Corporation Method, apparatus and program for multi-machine network install using writeable media
US20030009747A1 (en) * 2001-06-25 2003-01-09 International Business Machines Corporation Apparatus and method for porting applications to different platforms
US6510521B1 (en) 1996-02-09 2003-01-21 Intel Corporation Methods and apparatus for preventing unauthorized write access to a protected non-volatile storage
US6622248B1 (en) * 1998-06-25 2003-09-16 Sharp Kabushiki Kaisha File data retrieving device and recording medium containing computer program for controlling the same
US6636961B1 (en) 1999-07-09 2003-10-21 International Business Machines Corporation System and method for configuring personal systems
US6662284B2 (en) * 2001-02-20 2003-12-09 Hewlett-Packard Development Company, L.C. Computer apparatus, method and memory including license key
US20040187110A1 (en) * 2003-02-20 2004-09-23 Julian Boyfield Method and apparatus for specifying properties using regular expression parameterization
US20040250056A1 (en) * 2003-06-03 2004-12-09 Christopher Chang System boot method
US20050149722A1 (en) * 2003-12-30 2005-07-07 Intel Corporation Session key exchange
US6920555B1 (en) * 2001-03-10 2005-07-19 Powerquest Corporation Method for deploying an image into other partition on a computer system by using an imaging tool and coordinating migration of user profile to the imaged computer system
US6934956B1 (en) * 1997-09-09 2005-08-23 Micron Technology, Inc. Method and apparatus for installing an operating system
US20050216720A1 (en) * 2004-03-10 2005-09-29 Michaelis Scott L System and method for managing configuration data for a multi-cell computer system
US20070100968A1 (en) * 2005-10-27 2007-05-03 Nokia Corporation Proprietary configuration setting for server to add custom client identity
CN110325992A (en) * 2017-02-27 2019-10-11 微软技术许可有限责任公司 Long-range management to original computer operating system setting options

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6077315A (en) * 1995-04-17 2000-06-20 Ricoh Company Ltd. Compiling system and method for partially reconfigurable computing
US6096094A (en) * 1997-10-03 2000-08-01 National Instruments Corporation Configuration manager for configuring a data acquisition system
US6360263B1 (en) * 1998-02-25 2002-03-19 International Business Machines Corporation Dynamic resource allocation for user management in multi-processor time shared computer systems
US6397327B1 (en) * 1999-03-19 2002-05-28 Ati International Srl Method and apparatus for configuring a computer system
US5968138A (en) * 1999-04-23 1999-10-19 Hewlett-Packard Company Method and apparatus for peripheral system management, using multiple object interfaces
AU7611300A (en) * 1999-11-23 2001-06-04 Microsoft Corporation Content-specific filename systems
AU1405000A (en) * 1999-12-15 2001-06-25 Sun Microsystems, Inc. Preparation of a software configuration using an xml type programming language
US6598057B1 (en) * 1999-12-22 2003-07-22 Cisco Technology, Inc. Method and apparatus for generating configuration files using policy descriptions
US6957437B1 (en) * 1999-12-23 2005-10-18 Intel Corporation Selecting a device driver for a peripheral device adapted to operate on a network and simplifying secondary printer installation
US7933968B1 (en) * 2000-06-20 2011-04-26 Koninklijke Philips Electronics N.V. Token-based personalization of smart appliances
US6671802B1 (en) * 2000-04-13 2003-12-30 Hewlett-Packard Development Company, L.P. Performance optimization of computer system by dynamically and immediately updating a configuration setting based on detected change in preferred use
US6823508B1 (en) * 2000-04-27 2004-11-23 Microsoft Corporation Automatic computer program customization based on a user information store
DE60117676T2 (en) * 2000-12-29 2006-11-16 Stmicroelectronics S.R.L., Agrate Brianza A method for easily extending the functionality of a portable electronic device and associated portable electronic device
JP4134536B2 (en) * 2001-07-27 2008-08-20 株式会社日立製作所 Transaction method of information equipment
US7100160B2 (en) * 2001-10-19 2006-08-29 Hewlett-Packard Development Company, L.P. Method and system for implementing host-dependent SCSI behavior in a heterogeneous host environment
US20030097510A1 (en) * 2001-11-20 2003-05-22 Francis Joseph System-On-Chip architecture that utilizes FeRAM and re-configurable hardware
US20030131145A1 (en) * 2002-01-09 2003-07-10 International Business Machines Corporation Passing parameters to an external command via the command environment
US20030145137A1 (en) * 2002-01-27 2003-07-31 Huckins Jeffrey L. Partially integrating components of processor-based systems
JP4190789B2 (en) * 2002-04-05 2008-12-03 日本電気株式会社 Method and system for automatically concealing PCI expansion card in computer system
US20030204714A1 (en) * 2002-04-24 2003-10-30 Rothman Michael A. Methods and apparatuses for uniform configuration for a computer system
US7228405B2 (en) * 2002-06-25 2007-06-05 Intel Corporation Methods and apparatuses for allowing users to dynamically interact with configurable devices or hardware during a preboot stage
US6907420B2 (en) 2002-11-14 2005-06-14 Vibren Technologies, Inc. Parameterizing system and method
US20040128651A1 (en) * 2002-12-31 2004-07-01 Michael Lau Method and system for testing provisioning and interoperability of computer system services
US7107441B2 (en) * 2003-05-21 2006-09-12 Intel Corporation Pre-boot interpreted namespace parsing for flexible heterogeneous configuration and code consolidation
US7420694B2 (en) * 2003-05-29 2008-09-02 Hewlett-Packard Development Company, L.P. Method of tracking a file processing status with a file name
US20050071624A1 (en) * 2003-09-29 2005-03-31 Rothman Michael A. Providing a self-describing media for a computer system
US7877746B2 (en) * 2006-09-21 2011-01-25 Vringo Inc. Personalized installation files
US20080107042A1 (en) * 2006-11-03 2008-05-08 Varadachari Rengarajan System and Method for Configuring a Computing Device
US7805635B2 (en) * 2007-04-09 2010-09-28 International Business Machines Corporation Constraint programming for reduction of system test-configuration-matrix complexity
US8799423B2 (en) 2009-07-15 2014-08-05 Consumer Software International, Inc. System and method for optimizing and digitally correcting errors on a computer system
US20110023028A1 (en) * 2009-07-27 2011-01-27 Alcatel-Lucent Usa Inc. Virtualization software with dynamic resource allocation for virtual machines
CN105094529B (en) * 2015-06-29 2018-09-04 小米科技有限责任公司 operating system configuration method and device

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4589063A (en) * 1983-08-04 1986-05-13 Fortune Systems Corporation Data processing system having automatic configuration
US5161102A (en) * 1988-09-09 1992-11-03 Compaq Computer Corporation Computer interface for the configuration of computer system and circuit boards
US5257387A (en) * 1988-09-09 1993-10-26 Compaq Computer Corporation Computer implemented method and apparatus for dynamic and automatic configuration of a computer system and circuit boards including computer resource allocation conflict resolution
US5263148A (en) * 1988-09-09 1993-11-16 Compaq Computer Corporation Method and apparatus for configuration of computer system and circuit boards
US5353432A (en) * 1988-09-09 1994-10-04 Compaq Computer Corporation Interactive method for configuration of computer system and circuit boards with user specification of system resources and computer resolution of resource conflicts
US5450570A (en) * 1988-09-09 1995-09-12 Compaq Computer Corp. Computer implemented method and apparatus for dynamic configuration of a computer system and circuit boards including computer resource allocation conflict resolution
US5515524A (en) * 1993-03-29 1996-05-07 Trilogy Development Group Method and apparatus for configuring systems
US5537596A (en) * 1993-02-19 1996-07-16 Apple Computer, Inc. Method and apparatus for overriding resource maps in a computer system
US5586219A (en) * 1994-09-30 1996-12-17 Yufik; Yan M. Probabilistic resource allocation system with self-adaptive capability

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4589063A (en) * 1983-08-04 1986-05-13 Fortune Systems Corporation Data processing system having automatic configuration
US5161102A (en) * 1988-09-09 1992-11-03 Compaq Computer Corporation Computer interface for the configuration of computer system and circuit boards
US5257387A (en) * 1988-09-09 1993-10-26 Compaq Computer Corporation Computer implemented method and apparatus for dynamic and automatic configuration of a computer system and circuit boards including computer resource allocation conflict resolution
US5263148A (en) * 1988-09-09 1993-11-16 Compaq Computer Corporation Method and apparatus for configuration of computer system and circuit boards
US5353432A (en) * 1988-09-09 1994-10-04 Compaq Computer Corporation Interactive method for configuration of computer system and circuit boards with user specification of system resources and computer resolution of resource conflicts
US5450570A (en) * 1988-09-09 1995-09-12 Compaq Computer Corp. Computer implemented method and apparatus for dynamic configuration of a computer system and circuit boards including computer resource allocation conflict resolution
US5537596A (en) * 1993-02-19 1996-07-16 Apple Computer, Inc. Method and apparatus for overriding resource maps in a computer system
US5515524A (en) * 1993-03-29 1996-05-07 Trilogy Development Group Method and apparatus for configuring systems
US5586219A (en) * 1994-09-30 1996-12-17 Yufik; Yan M. Probabilistic resource allocation system with self-adaptive capability

Cited By (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5913218A (en) * 1995-11-06 1999-06-15 Sun Microsystems, Inc System and method for retrieving and updating configuration parameter values for application programs in a computer network
US6510521B1 (en) 1996-02-09 2003-01-21 Intel Corporation Methods and apparatus for preventing unauthorized write access to a protected non-volatile storage
US5848231A (en) * 1996-02-12 1998-12-08 Teitelbaum; Neil System configuration contingent upon secure input
US5809331A (en) * 1996-04-01 1998-09-15 Apple Computer, Inc. System for retrieving configuration information from node configuration memory identified by key field used as search criterion during retrieval
US5991546A (en) * 1996-09-17 1999-11-23 Cmd Technology, Inc. System and method for interfacing manually controllable input devices to a universal computer bus system
US6175390B1 (en) * 1996-12-23 2001-01-16 Lg Electronics Inc. Module TV and control method thereof
US5961611A (en) * 1996-12-27 1999-10-05 Lg Semicon Co., Ltd. Automatic option setting circuit
US6125408A (en) * 1997-03-10 2000-09-26 Compaq Computer Corporation Resource type prioritization in generating a device configuration
US6029196A (en) * 1997-06-18 2000-02-22 Netscape Communications Corporation Automatic client configuration system
US6038399A (en) * 1997-07-22 2000-03-14 Compaq Computer Corporation Computer manufacturing architecture with two data-loading processes
US6934956B1 (en) * 1997-09-09 2005-08-23 Micron Technology, Inc. Method and apparatus for installing an operating system
WO1999038070A1 (en) * 1998-01-26 1999-07-29 Intel Corporation An interface for ensuring system boot image integrity and authenticity
US6560706B1 (en) 1998-01-26 2003-05-06 Intel Corporation Interface for ensuring system boot image integrity and authenticity
USRE38865E1 (en) * 1998-04-14 2005-11-01 International Business Machines Corporation System and method for optimizing computer software and hardware
US6059842A (en) * 1998-04-14 2000-05-09 International Business Machines Corp. System and method for optimizing computer software and hardware
US6622248B1 (en) * 1998-06-25 2003-09-16 Sharp Kabushiki Kaisha File data retrieving device and recording medium containing computer program for controlling the same
US6636961B1 (en) 1999-07-09 2003-10-21 International Business Machines Corporation System and method for configuring personal systems
US6662284B2 (en) * 2001-02-20 2003-12-09 Hewlett-Packard Development Company, L.C. Computer apparatus, method and memory including license key
US6920555B1 (en) * 2001-03-10 2005-07-19 Powerquest Corporation Method for deploying an image into other partition on a computer system by using an imaging tool and coordinating migration of user profile to the imaged computer system
US20020138600A1 (en) * 2001-03-26 2002-09-26 International Business Machines Corporation Method, apparatus and program for multi-machine network install using writeable media
US6941547B2 (en) * 2001-06-25 2005-09-06 International Business Machines Corporation Apparatus and method for porting applications to different platforms
US20030009747A1 (en) * 2001-06-25 2003-01-09 International Business Machines Corporation Apparatus and method for porting applications to different platforms
US20040187110A1 (en) * 2003-02-20 2004-09-23 Julian Boyfield Method and apparatus for specifying properties using regular expression parameterization
US7206928B2 (en) * 2003-06-03 2007-04-17 Digi International Inc. System boot method
US20040250056A1 (en) * 2003-06-03 2004-12-09 Christopher Chang System boot method
US20050149722A1 (en) * 2003-12-30 2005-07-07 Intel Corporation Session key exchange
US7526649B2 (en) * 2003-12-30 2009-04-28 Intel Corporation Session key exchange
US20050216720A1 (en) * 2004-03-10 2005-09-29 Michaelis Scott L System and method for managing configuration data for a multi-cell computer system
US7451302B2 (en) * 2004-03-10 2008-11-11 Hewlett-Packard Development Company, L.P. System and method for managing configuration data for a multi-cell computer system
US20070100968A1 (en) * 2005-10-27 2007-05-03 Nokia Corporation Proprietary configuration setting for server to add custom client identity
CN110325992A (en) * 2017-02-27 2019-10-11 微软技术许可有限责任公司 Long-range management to original computer operating system setting options
CN110325992B (en) * 2017-02-27 2023-11-07 微软技术许可有限责任公司 Remote management of initial computer operating system setup options

Also Published As

Publication number Publication date
US5822565A (en) 1998-10-13

Similar Documents

Publication Publication Date Title
US5713009A (en) Method and apparatus for configuring a computer system
KR100563823B1 (en) Generation method of compatibility order of computer system and system
US6763454B2 (en) System for allocating resources in a computer system
US5748980A (en) System for configuring a computer system
US8464242B2 (en) Virtualization of configuration settings
US5574915A (en) Object-oriented booting framework
US5655148A (en) Method for automatically configuring devices including a network adapter without manual intervention and without prior configuration information
CA2178581C (en) Automatic booting framework
US5353432A (en) Interactive method for configuration of computer system and circuit boards with user specification of system resources and computer resolution of resource conflicts
US4589063A (en) Data processing system having automatic configuration
US5634058A (en) Dynamically configurable kernel
US7971047B1 (en) Operating system environment and installation
EP0358304A2 (en) Method and apparatus for configuration of computer system and circuit boards
JPH07244579A (en) Data processing system with operating system definition file
US5418960A (en) Transparently self-configured option board using an option board protocol PROM
KR20020085872A (en) Translating and Executing Object-Oriented Computer Programs
EP0814403B1 (en) Computer system with context switch and program development therefor
US7043715B1 (en) Method and apparatus for customizing software
JP2004503866A (en) Modular computer system and related methods
US6199117B1 (en) Generalized control for starting of tasks (processes and threads)
US20080141219A1 (en) Multiple inheritance facility for java script language
KR100578955B1 (en) Method and apparatus for determining the drive letter assignment of a CD ROM drive during initial system setup of a computer system
CA2021833C (en) Data processing method and apparatus for verifying adapter description file choices
JPH036615A (en) Boot system of data processing system
US7155701B1 (en) System for dynamically constructing an executable computer program

Legal Events

Date Code Title Description
AS Assignment

Owner name: DIGITAL EQUIPMENT CORPORATION, MASSACHUSETTS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:APGAR, SCOTT WADE;DEROSA, JOHN ANTHONY;HAYDEN, PETER CHAPMAN;AND OTHERS;REEL/FRAME:007782/0222;SIGNING DATES FROM 19950822 TO 19950907

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: COMPAQ INFORMATION TECHNOLOGIES GROUP, L.P., TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DIGITAL EQUIPMENT CORPORATION;COMPAQ COMPUTER CORPORATION;REEL/FRAME:012447/0903;SIGNING DATES FROM 19991209 TO 20010620

FPAY Fee payment

Year of fee payment: 8

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

AS Assignment

Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS

Free format text: CHANGE OF NAME;ASSIGNOR:COMPAQ INFORMATION TECHNOLOGIES GROUP, L.P.;REEL/FRAME:018231/0040

Effective date: 20021001

FPAY Fee payment

Year of fee payment: 12