DE69405408T2 - OBJECT-ORIENTED SYSTEM AND METHOD FOR HARDWARE CONFIGURATION - Google Patents

Description

BACKGROUND OF THE INVENTION Field of the invention

The present invention relates generally to configuration of hardware in a computer system and more particularly to an object-oriented system and method for hardware configuration in a computer system.

State of the art

The term "hardware configuration" has many meanings. In the user space of a computer system, hardware configuration refers to the configuration of computer components that are generally visible to users (this is called user-oriented hardware configuration). This includes tasks such as setting the double-click speed for a mouse, formatting a floppy disk, connecting a modem to a serial port, or replacing an existing port.

In the input/output (I/O) area of a computer system, hardware configuration refers to low-level services that control or regulate access to integrated circuits (ICs) and other low-level hardware resources (this is called I/O hardware configuration)

European patent application 0 398 644 entitled Data Processing System Comprising System Configuration Means describes a means for configuring a operating system using an object-oriented database. This application discloses a dynamically configurable system that minimizes initial program loaders (IPL) and kernel updates for the purpose of setting the system configuration. This is accomplished by providing a means to perform dynamic binding/debinding of device drivers to/from the kernel during the IPL. The application describes a system that does not use class hierarchies. Instead, device information is stored in a master configuration database 15 (FIG. 1). Although the reference describes the databases as "object-oriented," they are actually "object-based" collections of objects. A first object class is one that is a predefined object class 300 (FIG. 1) and contains objects that represent all hardware devices possible in the hardware "universe." It also describes a second object class, which is a custom object class 500, and which consists of a set of appropriately predefined objects tailored to represent the current facility configurations in a particular system (i.e., it represents the current facilities used by the universe).

During system IPL, a configuration manager 10 (FIG. 1) examines the physical hardware system and locates all devices connected to the system. If a hardware component is found but is not reflected in the set of customized object classes 500, the configuration manager 10 accesses the predefined device object classes 300 to find an object class representing the new hardware component and calls a so-called object definition method to define an object instance from the predefined class 300. The configuration manager then represents the object instance in the tailor-made Class 500 with all the corresponding attributes.

The system relies on the fact that class information for all possible hardware devices is present in the predefined database. Since there is no class hierarchy, the class information must be redefined each time a new device needs to be added to the predefined database.

European patent application 0 374 512 discloses a means for notifying client programs of a change in a monitored object-oriented database. The reference relates to a method for monitoring changes in the values of attributes of objects in an object database system. A client application program requests the system to monitor an attribute of an object. Only clients requesting monitoring of a specific attribute are informed of a change in the attribute. Furthermore, the reference does not disclose the use of hardware interface objects and the use of connector objects to represent physical connections.

The present invention is primarily concerned with user-oriented hardware configuration, but may also be applied to other types of hardware configuration, such as I/O hardware configuration. Conventional computer systems distribute hardware configuration tasks among different applications. For example, on the well-known Apple Macintosh computer, the Chooser application must be used to connect a Stylewriter printer to a modem port. To connect a modem to a modem port, a communications application (e.g., Macterminal) must be used. To set up an Apple SCSI drive, the "Apple HD SC Setup" application must be used. To set the double-click speed of the mouse, the Mouse Control Panel in the Control Panel folder must be used. As can be easily seen can be, it is difficult for users to always know where to find these configuration applications. Likewise, it is difficult for users to remember which configuration applications are needed to configure specific resources.

Users must inform the computer of the location of some devices (that is, they must tell the computer how and where the devices are connected to the computer). These devices are called manually connected devices or manually configured devices and require special attention to hardware configuration.

When a manually connected device is connected to the computer, the computer cannot detect its presence. As one aspect of hardware configuration, a device in the computer must be told (by the user) what type of device it is and where it is connected.

In the well-known Apple Macintosh System 7, the unit that must be informed depends on the type of device in question. For example, the Comm Toolbox is used for modems and the Chooser for printers. Furthermore, the Comm Toolbox is port-centric, not device-centric (that is, the information stored by a document is about a port, not a device). Now, if a user plugs his modem into a different port, any terminal documents using the modem will not perform the transmission correctly because they expect the modem to be connected to the original port.

Therefore, a system and method for hardware configuration without the problems discussed above are needed.

Summary of the invention

The present invention relates to an object-oriented hardware configuration system for enabling centralized user configuration of the hardware in a computer system. The hardware configuration system comprises a plurality of object-oriented hardware interface objects, each presenting a physical connector of a hardware device, and a plurality of object-oriented hardware module objects.

Each of the hardware module objects represents a hardware device that is user-configurable. Each of these hardware module objects includes one or more hardware interface objects that are connected to the hardware device to define the connectors of the hardware device.

An object-oriented hardware configuration object is created, the hardware configuration object comprising a plurality of hardware module objects representing hardware devices connected to a particular computer system. The hardware configuration object defines a hardware configuration of the particular computer system. A user can access the hardware configuration object to configure the hardware devices connected to the particular computer system.

The configuration system of the present invention supports centralized configuration of hardware by the user. Centralized hardware configuration relieves the user of the burden of having to remember all the different locations where hardware configuration tools may be located. For example, a computer viewer (discussed below) supported by the configuration system is used to connect manually configured devices to the system. It provides access to configuration assistance tools (e.g., tools for formatting disk drives, changing the bit depth of a monitor, etc.) for all local facilities. It can also be used to select or directly use local services (eg local printers and modems)

In the area of manually connected devices, the hardware configuration system offers particular advantages. First, the system is used whenever a new device is added. This gives the system the ability to automatically assign the device if desired. Second, the hardware configuration system enables the system to track a device even if it has been moved to a different port. The user does not have to update all documents that use the affected device. Finally, a parts bin is supported that collects all the corresponding "installed" hardware resources that the system can currently support. The parts bin allows a user to quickly find and connect a new device using a hardware configuration viewer (e.g., the computer viewer). The parts bin is used for all manually connected devices.

The hardware configuration system offers a number of innovative features.

For example, the hardware configuration system maintains a database of devices and their ports. The hardware configuration system records the existence, physical characteristics, and ports of devices associated with a real hardware system. It allows clients to change ports and characteristics of these devices. For example, a personal computer consists of a computer and its peripheral devices. The existence and physical characteristics of the computer and its peripheral devices are recorded by a hardware database, and users can change ports and add new devices or remove existing ones. The hardware configuration system supports complex hardware systems that include switch boxes, multifunction cards, multi-slot cards, connections to more than one network (e.g. multiple network cards), multislot-type computers and expansion buses.

The hardware configuration system supports refreshing configuration databases. A service is provided that allows clients to update the database manually.

The hardware configuration system allows for persistence for devices and their ports. When a device object is registered in the hardware configuration system, the device object and its port(s) can be saved. Upon reboot, all of these saved device objects are automatically "restored" by the hardware configuration system. The restored device objects behave the same as before the reboot.

The hardware configuration system helps THardware-InterfaceReferences support device mappings. Enough information is recorded to allow a THardwareInterfaceReference object to automatically create a service for any attached device (manually or automatically). The reference object remains valid even if the device's port has changed in the computer viewer.

The hardware configuration system offers notifications. Notifications are offered to any interested client when the state of a hardware database of interest changes (e.g. when a device is added or removed or the connection changes). Only one TInterest is offered and that is "something has changed". As a result, clients are only informed that a change has occurred, but they do not automatically receive additional information about the nature of the change.

The hardware configuration system supports a hardware configuration viewer framework. Clients can create their own hardware databases that can be created using the hardware configuration system of the present invention and presented by the hardware configuration viewer framework. For example, a Laserwriter NTX configuration viewer can be created that would allow a user to view the hardware configuration of a remote Laserwriter (including its hard drives, ports, etc.).

The hardware configuration system supports the creation of device configuration viewers. Device configuration viewers allow a user to configure the "real device." Device configuration viewers are created by presentation objects. An operating system unit can create a presentation object using the information it has received from a device object. For example, a disk drive configuration viewer is created to reformat, partition, test, set up, and remove disks for a drive.

Further features and advantages of the present invention, as well as the structure and operation of various embodiments of the present invention, are described in detail below with reference to the accompanying drawings.

Short description of the drawings

Figure 1 is a block diagram of a computer system in which the hardware configuration system operates according to a preferred embodiment;

Figure 2 is a class diagram of a hardware configuration framework according to a preferred embodiment;

Figure 3 is a diagram used to illustrate the operation of the THardwareConfiguration object according to a preferred embodiment;

Figure 4 is a diagram used to illustrate the operation of a THardwareModule object according to a preferred embodiment;

Figure 5 is a diagram used to illustrate the operation of a THardwareInterface object according to a preferred embodiment;

Figure 6 is a diagram used to illustrate the operation of a THardwareInterfaceIdentifier object according to a preferred embodiment; and

Figures 7A-7E are diagrams used to illustrate the manner in which a preferred embodiment operates during an example hardware configuration scenario.

Detailed discussion of the preferred embodiments

The present invention relates to an object-oriented system and a method for configuring the hardware of a computer system. Since the system is object-oriented, the present invention will be described below using object-oriented terms and concepts. Such object-oriented terms and concepts are well known and are discussed in many publicly available documents, such as Object-Oriented Design by Grady Booch (Benjamin Cummings 1991).

Figure 1 shows a high level block diagram of a computer system 102 in which the object-oriented configuration system operates according to a preferred embodiment. It should be noted that the present invention alternatively includes the configuration system in combination with the computer platform 102.

The computer system 102 includes hardware components 104, such as a random access memory (RAM) 108, and a central processing unit (CPU) 106. It should be noted that the CPU 106 may comprise a single processor or multiple processors operating in parallel.

The computer system 102 also includes peripheral devices connected to the hardware components 104. These peripheral devices include an input device or devices (such as a keyboard, mouse, highlighter, etc.) 110, a data storage device 112 (such as a hard disk or floppy disk), a display 114, a printer 116, and a network adapter 118. The computer system 102 could be connected to other peripheral devices.

The computer system 102 also includes an operating system 122, and it may include microinstruction code 120 (also referred to as firmware). The operating system 122 may include a substantially full-function operating system, such as the DOS floppy disk operating system and the UNIX operating system. The operating system 122 may alternatively represent other types of operating systems. Preferably, the operating system 122 represents a limited functionality operating system, such as the Mach microkernel developed by IBM, which is well known to those skilled in the art.

In a preferred embodiment of the present invention, the computer system 102 is an International Business Machines (IBM) computer or an IBM compatible computer. In an alternative embodiment of the present invention, the computer system 102 is an Apple computer.

One or more programs 124 operate in parallel in the computer system 102.

Preferably, the object-oriented configuration system according to a preferred embodiment is implemented as a collection of object-oriented objects executing in the computer system 102. These objects are represented by one or more of the programs 124 executing in the computer system 102.

Alternatively, the objects could be implemented as part of the operating system 122, where the operating system 122 is not procedural, but object-oriented. Other methods for representing the configuration system according to a preferred embodiment (as discussed herein) in the computer system 102 will be apparent to those of ordinary skill in the art.

The objects implementing the configuration system according to a preferred embodiment are instances of a plurality of object-oriented classes that are collected together to form an object-oriented configuration framework. This hardware configuration framework and the classes contained therein are discussed below.

Before discussing the present invention in detail, it is helpful to define some terms that are important for understanding according to a preferred embodiment.

The first is "auto-configuration." There are two types of auto-configuration. The first is auto-identifying rather than auto-configuring. Devices in this category can identify themselves to the system. The system then looks around and finds the necessary software, which in some cases must be manually "installed" by the user (see manual configuration below). The other type of auto-configuration is self-configuration. Devices in this category can not only identify themselves, but also provide their own configuration software and data. Auto-configuration is "bottom-up." The system configures itself and passes the information up to the user.

The second term is "manual configuration". Manual configuration requires the user to do something does something special (e.g. "installs" a service or tells the computer where a device is connected). There are three cases of manual configuration.

According to the first case, the device can be identified by the system, but the required device driver(s) cannot be found. The user must manually "install" the service(s). The device is "software compromised".

According to the second case, the required services are available, but the device cannot be recognized or identified by the system (i.e. its icon appears in the Parts Container, but the device itself does not appear in the Computer Viewer). In this case, the user must drag the device from the Parts Container to where the device is connected in the Computer Viewer.

In the third case, the required services are neither available nor the device can be found. This is a partial combination of the two cases above. First, the user must "install" the service(s). Then he can drag the device from the parts bin to where the device is connected in the computer viewer.

Manual configuration is done from the top down. The user provides the information through a user interface and that information trickles down to the I/O system.

The next term is "software-impaired hardware". A hardware resource is said to be software-impaired if the hardware resource is known to the system, but the system cannot use it because the required software cannot be found. A THardwareModule can represent compromised hardware. A THardwareModule cannot be partially compromised. At the time the THardwareModule of a card to be initialized is registered, all the software required to initialize the card must be available. Software-impaired Hardware is detected during refresh or at boot time.

The hardware configuration system according to a preferred embodiment supports a hardware configuration viewer, which is preferably implemented using object-oriented techniques (such as by creating instances of related classes that form a framework). The hardware configuration viewer is described below.

The Hardware Configuration Viewer is a tool that shows a user a graphical representation of the current hardware configuration of a computer. The Hardware Configuration Viewer does this using the Parts Bin (discussed below). There are many types of hardware configuration viewers.

For example, a computer viewer displays a graphical representation of the current configuration of an entire computer system.

A printer viewer shows a user the configuration of a printer. For example, the printer viewer shows the hard disk drive(s) and any optional features the printer may have, such as an automatic sheet feeder. The user could see what character sets the printer has (on the hard disk).

A Parts Bin Viewer presents the user with all "potentially" connectable "dumb" devices (like the Apple Chooser, except the Chooser also shows some of the currently connected devices). The Parts Bin Viewer display may also include a window with a tab for each device type. For example, there might be tabs for printers and modems. The user selects a particular tab to view all devices of a particular type. Thus, the Computer Viewer shows the user what is currently connected, while the Parts container shows the user what can be connected.

A device configuration viewer allows the user to configure a "real device" (that is, a physical device). Device configuration viewers are created by presentation objects. An entity of the operating system can create a presentation object using the information it has received from a device object. For example, a disk drive configuration viewer is created to reformat, partition, test, set up, and remove disks for a drive.

Architecture of the hardware configuration system

As discussed above, the object-oriented configuration system according to a preferred embodiment is implemented as a collection of object-oriented objects executing in the computer system 102. These objects are instances of a plurality of related object-oriented classes that are collected together to form an object-oriented configuration framework. Figure 2 is a class diagram of this hardware configuration framework according to a preferred embodiment. The classes that make up the hardware configuration frameworks are discussed in the following sections.

THardwareConfiguration

The main purpose of the THardwareConfiguration class 204 is to support centralized user configuration of hardware. It does this by providing a set of hardware-related database services. THardwareConfiguration 204 has a collection of THardwareModule objects. Clients can use existing Remove THardwareModule objects from or add them to an instance of THardwareConfiguration. Clients can load any THardwareModule object or specific types of THardwareModule objects (eg Type=Printer, Types=Scanner & Modem) directly from an instance of THardwareConfiguration.

Clients have access to a special THardwareConfiguration object known as ComputerHardwareConfiguration (also called Computer Hardware Database), which represents the local hardware configuration of a personal computer. It contains device drivers such as the computer's mouse, keyboard, and monitor. This database is the basis for the centralized user configuration of a personal computer. Figure 3 shows an example of ComputerHardwareConfiguration.

For THardwareConfiguration objects, a message is sent to interested clients when a change has been made to a hardware configuration (e.g., when a hardware module is added or removed, or a connection is changed). Clients are only informed that a change has occurred, but they receive no additional information about the nature of the change. Since changes to hardware configurations occur very rarely, this minimal message scheme is unlikely to cause any problems (e.g., significant increase in interprocessor communication (IPC) traffic).

THardwareModules

The purpose of a THardwareModule object 206 is to represent, at a very low level, a device that is presented by the hardware configuration viewer (or parts container) and configured or used by a user. THardwareModule objects 206 are used to represent computers, cards, and peripheral devices. For example, each of the The following devices are presented by their own THardwareModule object: Apple Macintosh IIci computer, Apple ADB keyboard, and Macintosh video card.

As a member of THardwareConfiguration, a THardwareModule object 206 represents a real-world device that a user can configure or use. As a member of a TPartLocator (i.e., parts container 220, described below), a THardwareModule object 206 represents a prototype for any number of real-world devices with identical characteristics (i.e., a part that can be added to the system).

A THardwareModule object 206 has a group of ordered THardwareInterface objects 212 (discussed below, THardwareInterface objects 212 are also referred to herein as connector objects or simply connectors). Each THardwareInterface object 212 corresponds to a real physical connector on a real device. For example, referring to Figure 4, the THardwareModule object 410 representing the multifunction card 402 has THardwareInterface objects 416, 414, and 412, respectively, which correspond to the following devices: an edge connector 404, a video connector 406, and a SCSI connector 408.

Since no subclasses need to be created from the THardwareModule, the creator of a THardwareModule object must ensure that the corresponding THardwareInterface objects are created and included in the THardwareModule object.

Each THardwareInterface object 206 corresponds to a THardwareInterfaceIdentifier object 224 (described below), and it additionally corresponds to a connector object in a presentation object presented by the computer under consideration.

One or more of the owned connectors is considered a standard connector (see Figure 4, where the edge hardware object 416 is the standard object) Standard connectors represent special connectors, that are selected as potential connection targets during drag and drop of devices onto connectors. This is a shortcut method for creating connectors. The alternative is to drop the icon into a hardware viewer and then manually connect it to the correct connector. Example of a shortcut method: A user drags the video SCSI card shown above from the parts bin onto an ISA slot connector in the computer viewer. The computer viewer selects the edge connector (instead of the SCSI or video connector) because the developer specified the edge connector as the default connector.

Sometimes more than one standard connector is required. For example, a printer might have both a serial and a parallel port. If the user were to drag that printer over the serial port, the computer viewer would check both standard connectors for compatibility. It would discover that the printer is compatible with the serial port. The user could further drag the printer over a parallel port. The computer viewer would discover that the printer is compatible with that as well.

Each THardwareModule object 206 has a personality-independent HardwareModulesignature object 210 (discussed below) that identifies the class of physical hardware to which the THardwareModule object belongs. For example, a THardwareModule object 206 representing an Apple Imagewriter II has an instance of HardwareModulesignature 210 whose value is equal to "AppleImagewriterII".

Each THardwareModule object 206 has one or more HardwareModuleCategory objects 208 (discussed below).

Each category object 208 represents a specific device type that the THardwareModule object 206 is able to represent. For example, a THardwareModule object 206, which represents a fax machine that can be used as a modem, scanner, printer and fax, one instance each of the following Hardware ModuleCategories 208: "Modem", "Scanner", "Printer" and "Fax".

Typically, each THardwareModule object 206 in a hardware database is "hooked" to at least one other THardwareModule object 206. However, this is not strictly necessary, as a device can become completely unhooked for a variety of reasons. Unhooked devices in a THardwareConfiguration are still owned by the THardwareConfiguration object and can be reached by direct iteration.

A THardwareModule object has a number of attributes, including "root", "internal" and "wants persistence". Root is a boolean value. If true, the THardwareModule object 206 is the central device of a THardwareConfiguration. Each THardwareConfiguration object 204 has a boot device. For a personal computer database, the THardwareModule object 206 is the boot device that represents the computer. Root defaults to FALSE. The boot device is a special device used by the Hardware Configuration Viewer. When the Abstract or Schema Viewer is displayed by the Hardware Configuration Viewer, the boot device is "exploded" into a special area.

"Internal" is also a Boolean value. If it is true, the real device is physically located inside the root device. For example, the internal hard disk drive of a Macintosh is located "inside" the computer. By default, the value is set to FALSE. This status is used only by the Computer Viewer's Schema Viewer. If a device is inside the computer, it will be displayed in a special area.

"Wants persistence" is a boolean value. A module that is not persistent will be implicitly removed from the configuration when the system is rebooted (its connections will also be implicitly removed). On the other hand, a persistent module will remain in the configuration even when rebooting until it is explicitly removed. Typically, all manually connected devices will want to be automatically restored by the hardware configuration framework, but SCSI drives will not. By default, the value is set to FALSE.

HardwareModuleCategory

The purpose of the HardwareModuleCategory 208 is to provide clients with the ability to group THardwareModule objects 206 by their type. An instance of the HardwareModuleCategory 208 can be owned by a THardwareModule object 206 or a TPartLocator object 218 (discussed below). When owned by a THardwareModule object 206, an instance of the HardwareModuleCategory 208 represents a device type that the module is capable of representing. Each THardwareModule object 206 has a HardwareModuleCategory object 208 for each device type that it can represent.

When owned by a TPartLocator object 218, an instance of the HardwareModuleCategory 208 represents the common set of all THardwareModule objects 206 owned by the TPartLocator object 218.

Supported device categories include: Monitor, printer, keyboard, pointing device (mouse or tablet), modem, card, disk drive, scanner, fax, etc.

HardwareModuleSignature

The purpose of HardwareModuleSignature 210 is to provide a mechanism that allows operating system personalities (e.g. OS/2) to create their own objects to represent THardwareModule objects 206. This is necessary because THardwareModule objects 206 do not know which operating system personalities are above them. An instance of HardwareModuleSignature 210 represents a personality-independent "key" to a unique personality-dependent entity. For example, a particular operating system could use this key to resurrect from a file a presentation object corresponding to the HardwareModule object 206. Or it could convert the signature to a presentation class name and then create a new presentation object corresponding to the THardwareModule object 206.

An instance of THardwareConfiguration 204 may contain many devices with equivalent HardwareModuleSignature objects 210. For example, a database could contain two COMB Apple drives. There will be equivalent instances of HardwareModuleSignature 210, one for each THardwareModule object 206. These are not the same devices. They are two different THardwareModule objects 206 representing two different real devices of the same type.

THardwareInterface

The purpose of THardwareInterface 212 is to represent, at a very low level, a real connector for a real device. It can represent a connector on the computer, a card or a peripheral device. For example, each of the following devices would be represented by its own THardwareInterface object 212 SCSI connector on a Macintosh IIfx, video connector on a Macintosh video card, or a serial connector on a StyleWriter. THardwareInterface objects 212 are owned by THardwareModule objects 206.

Each THardwareInterface object 212 has one or more HardwareInterfaceCategory objects 214 (described below). Each category object 214 represents a particular type of interface that the THardwareInterface object 212 is capable of representing. For example, a THardwareInterface object 212 representing a serial port will have one instance of each of the following HardwareInterfaceCategory objects 214: "serial".

Each instance of THardwareInterface 212 will have one THardwareConnection object 216 (discussed below) for each THardwareInterface object 212 to which it is connected. For example, as shown in Figure 5, a SCSI connector on the computer may be connected to a SCSI drive and a SCSI printer. The SCSI connector on the computer would have two THardwareConnection objects 216. The SCSI drive and the SCSI printer would each have one.

Each instance of THardwareInterface 212 has a THardwareInterfaceIdentifier object 224 (discussed above), which serves as a unique key into the database.

Some THardwareInterfaces 212 represent an actual "interface port" (e.g., the SCSI port on a computer or the video port on a video card). These THardwareInterfaces 212 can be used to start service stacks.

Clients can request THardwareInterface objects 212 to refresh themselves. To do this, a client (e.g., the computer viewer) creates a THardwareInterfacereference 222 with "MReconfigurableInterface" as the topmost interface. If "MReconfigurableInterface" is supported, a service is returned when the Hardware Reference Object 222 is enabled and the client can safely call Reconfigure() on it.

Allowing a THardwareModule object 206 to have more than one THardwareInterface object 212 has the side effect that a connection can indirectly "loop back" to a device. If a client were to attempt to span all of the connections of a device, it would need to be aware of possible loops.

A THardwareInterface object 212 has the following attributes:

Max connections:

This is a short integer. A THardwareInterface object 212 can support one or more connections.

This attribute specifies the maximum number of legal connections of a THardwareInterface object 212. By default, the value is set to 1.

Mode:

Possible values are In/Out/InOut This attribute specifies the transmission type. A THardwareInterface object 212 can be an input, an output, or both. By default, the value is set to InOut.

Reconfigurable:

This is a Boolean value. If it is true, the hardware can support a refresh (i.e. it can check to see if anything has changed) This does not mean that a service is available that actually performs the rescan. By default, the value is set to FALSE.

This attribute is used only as an optimization. Before a client tries to refresh a port, it can first check whether the hardware supports this and The same information can be obtained by enabling THardwareInterfaceReference 222 for the port. However, the vast majority of hardware does not support reconfiguration and using property lookups is slow.

Wants persistent connections:

This is a boolean value. The concept of duration is the same as that described in connection with THardwareModule 206. A connector can request that its connection(s) be persistent. A connection is persistent if one of the two connectors making the connection requests it. By default, the value is set to FALSE.

A connector that wants persistent connections implies that its device also wants persistent connections. If the two do not match, an exception is raised.

HardwareInterfaceCategory

The purpose of the HardwareInterfaceCategory 214 is to provide clients with the ability to group THardwareInterface objects 212 by their type. For example, a client may want to find and group all serial ports for a given hardware configuration. An instance of HardwareInterfaceCategory 214 represents an interface type that a connector is capable of representing. Each THardwareInterface object 212 has a HardwareInterfaceCategory object 214 for each interface type that it can represent. The interface categories include: Serial, Parallel, Video, MIDI, ADB, SCSI, and Slot.

THardwareConnection

The purpose of a THardwareConnection object 216 is to support different presentations for connections based on their status. An instance of THardwareConnection 216 represents a connection between two THardwareInterface objects 212.

A hardware connection object 216 has the following attributes:

Child (type):

A connection can be automatic or manual. An automatic connection is made by the system. A manual connection is made by the user. It is important to be able to distinguish between these two types of connections. A user should not modify automatic connections. Therefore, these connections are presented in a way that discourages users from changing them. By default, the value is set to Automatic.

Wants Persistence:

A Boolean value. A derived attribute that is true if either connector wants persistent connections.

A connection object 216 may be created if (1) the maximum number of connections is not exceeded on either of the two THardwareInterface objects 212; (2) the "stack" of services between the two THardwareInterface objects 212 is createable (or is created). This means that the corresponding services must be installed before a user is allowed to install a new device in his computer viewer; and (3) the modes of the two THardwareInterface objects 212 are valid (use the table below): Table 1

TPartLocator

The job of the TPartLocator 218 is to find all "installed" THardwareModule "prototypes" for a specific parts bin category. As a member of a TPartsBin object 220, an instance of TPartlocator 218 represents the set of devices to be displayed by a parts bin viewer for a particular tab. Each TPartLocator object 218 has a BinCategory. The BinCategory determines what types of devices the TPartLocator object 218 will find. For example, if the BinCategory = "Printers", the TPartlocator object 218 will find all printer prototypes that are "installed" in the system. When this bin category is used by the parts bin, it corresponds to a tab on the parts bin viewer. The Parts Bin Viewer has a TPartLocator for each tab it displays.

A TPartLocator object 218 refers to a group of Parts (i.e., THardwareModules 206). Each Part represents a device that the computer system can support. For example, a printer TPartLocator object has a prototype THardwareModule object for each type of printer found.

A TPartLocator object 218 has the following additional behaviors:

All THardwareModule objects 206 owned by an instance of TPartLocator 218 belong to the same HardwareModuleCategory 208.

All THardwareModule objects 206 owned by an instance of TPartLocator 218 have unique HardwareModuleSignature objects 210.

TPartsBin

The purpose of TPartsBin 220 is to organize the abundance of manually configurable devices into meaningful groups of related devices. For example, instead of presenting the user with a complete list of all devices his system can support, the Parts Bin 220 organizes this group of devices into multiple lists, with each list based on a device category. A TPartsBin object 220 has a group of bin TPartLocator objects 218. Each bin represents a subdivision and corresponds exactly to a tab on the Parts Bin Viewer. The Parts Bin Viewer displays the contents of the TPartLocator objects 218. As new "parts" are introduced into the system (i.e., installed), the corresponding TPartLocator objects 218 are updated. In addition, when new categories of "parts" are introduced, new TPartLocator objects 218 are created from the TPartsBin object 220 and new tabs are automatically displayed. User-tailorable locators are not excluded.

The Parts Bin presents the user with all "potentially" connectable "dumb" devices (like the Apple Chooser, except the Chooser also shows some of the currently connected devices). The display consists of a window with a tab for each device type. For example, there are tabs for printers and modems. The user selects a specific tab to view all devices of a specific type. The user can drag a device from the Parts Bin to the Computer Viewer to connect it.

The Parts Bin replaces that part of Appler Chooser or a similar unit where a user would select a printer and then click on the printer's port to connect it. It also replaces that part of MacTerminal or a similar application where the user would select the port to which the modem is connected.

Each file representing a prototype of a THardware Module 206 and expected to appear in the Parts Bin must have a PartsBin THardwareCategory property for each partition in which the icon is expected to appear.

A TPartsbin object 220 has the following additional behaviors:

The user can open any of the icons to set permanent default settings.

An icon can belong to more than one parts bin category and therefore appear in more than one subdivision of a parts bin.

THardwareInterfaceReference

The purpose of THardwareInterfaceReference 222 is to shield clients from the details of how to create a service for a local device. It encapsulates the details necessary to create the service (for example, which port the device is connected to). It uses this information together with other information to build the appropriate service stack. The interface returned as a result of stack creation is a strong interface to the desired device. This "best" interface is specified directly by the client.

An instance of an active THardwareInterfaceReference object represents access to a service offered by a real, local device.

THardwareInterfaceIdentifier

The purpose of THardwareInterfaceIdentifier 224 is to uniquely identify a real, physical hardware component. THardwareInterfaceIdentifier objects 224 are used by services and configuration access managers (CAMs) to obtain the physical information they need to actually drive the hardware (for example, a service may need the physical address of the chip, the IRQ, byte-level information, etc.). THardwareInterfaceIdentifier objects 224 are strong in nature, so the service knows exactly what information is available and how to obtain it.

As an example, the THardwareInterfaceIdentifier object shown in Figure 6 is for a serial THardwareInterface object owned by a computer THardwareModule object. The THardwareInterfaceIdentifier object could be used by a service to get the physical I/O address of the SCC chip it represents.

A configuration access manager (CAM) is an input/output system unit responsible for initializing system hardware resources. It has a subclass for each type of hardware resource. For auto-configuring devices, the subclasses are responsible for finding live devices and starting their associated CAMs. A CAM may or may not automatically create and initiate an access manager (AM) for a device. For example, a SCSI CAM may create and initiate an AM for a SCSI hard disk, but not for a SCSI printer. AMs for printers are really only needed when the printer is in use.

An access manager is an I/O service that can talk directly to a chip. The AM decides between several requests regarding access to the chip.

Operation according to a preferred embodiment

Now, operation according to a preferred embodiment will be described by discussing the manner in which the present invention operates in a typical hardware configuration scenario. Operation according to a preferred embodiment under different hardware configuration scenarios will be apparent to those skilled in the art based on the discussion contained herein.

This scenario refers to manually attaching a device. In this scenario, a user adds a new ISA serial card to his system and boots it successfully. During the boot process, the ISA probe does not find the card, so the card cannot be used. Furthermore, the card is not shown in the Computer Viewer. Its absence in the Computer Viewer is an indication to the user that the system does not see it. The user must now give his system information about this new hardware module. He does this by using the Computer Viewer as supported by the Hardware Configuration System, as shown in the following steps.

(1) First, the user opens the computer viewer and the parts bin. Figure 7A is a partial representation of the initial state of the computer hardware configuration and the parts bin. The computer hardware configuration shown has a computer module with an empty ISA slot. The parts bin contains the ISA card with which we want to update the system.

(2) The user drags the icon for the ISA card from the parts bin to any ISA slot icon on the computer (preferably the slot into which the card will actually be plugged). The default connector is obtained from the card's THardwareModule object (in this example, it is the edge connector). Type negotiation between the two icons ensures that the two can be connected. The default negotiation process respects the connection invariants specified here.

(3) Now this card is inserted into the slot. This is done as follows. First, the Computer Viewer (via a Command object) adds the card to the THardwareModule object in the Computer Hardware Configuration. This is shown in Figure 7B.

(4) Next, the connection must be made. This is shown in Figure 7C. There are two connector (i.e. THardwareInterface) objects: one from the computer viewer, which is selected by the user, and one from the card, which is selected by default. The command connects the two connectors together by creating a THardwareConnection. The last step is to call the Add method on the connection to complete the connection.

(5) The Computer Hardware Configuration now has a copy of the ISA card and is connected to the ISA slot. This is shown in Figure 7D.

(6) Any changes to the hardware configuration result in a notification event that is sent to all interested clients. For example, the ISA configuration database is interested in manually connected ISA cards and receives a notification. This is shown in Figure 7E. In many cases, the new ISA card can be used as soon as the ISA database knows about it. However, if the ISA card's configuration access manager (CAM) requires additional information (e.g., physical address, IRQ, and/or DMA information), the card may not yet be available. The user may need to provide additional information to the card's CAM in such a case. If this is the case, the ISA card's icon should indicate the status (via a software-impaired device icon or something similar). Furthermore, a user alert can be generated to alert the user to this problem.

Duration of action of handling

This section describes the properties of handles in their relationship to the master objects in a hardware configuration. The hardware configuration framework according to a preferred embodiment provides all clients with persistent handles for the following: THardware-Configuration 204, THardwareModule 206, THardwareInterface 212 and THardwareConnection 216.

Authentic and loose handling

Handles can be in one of two states: authentic or loose. An authentic handle is a handle that points to a master in the database. An authentic handle is obtained by adding a master to the database or by adding another authentic handle. A loose handle is a handle that no longer points to a master in the database. Loose handles can be copied, but clients may not use loose handles to actually read or write the master.

Handling transition

A handle transitions from the authentic to the loose state when one of the following events occurs. (1) Unbeknownst to a handle, the master is explicitly removed from the database by another handle. Or (2) the master is implicitly removed from the database as a result of a reboot (because the master was marked as non-sustainable). A handle transitions from the loose to the authentic state when a new master is added to the database that is "equivalent" to the (old) master pointed to by the handle when it was in the authentic state. Equivalence is defined below.

Handling -Equivalence

The single THardwareConfiguration master per hardware configuration is implicitly marked as persistent. THardwareConfiguration masters only go away when the database is destroyed. Handles pointing to destroyed databases are permanently loose. For the purposes of this section, two configuration masters are never considered "equivalent." A pair of THardwareModule masters is considered "equivalent" if (1) their values for the Type attribute (THardwareModuleSignature) are identical and (2) there is a one-to-one mapping between equivalent THardwareInterface objects of the two module masters.

A pair of THardwareInterface masters is considered "equivalent" if (1) they belong to the same THardwareModule Masters and (2) they have THardwareInterfaceIdentifiers that are considered "==". A pair of THardwareConnection masters is considered "equivalent" if their own endpoints are equivalent.

Simultaneity of handling

This section describes the concurrency behavior of handles provided by the hardware configuration framework according to a preferred embodiment. The hardware configuration framework provides all clients with handles for THardwareConfiguration, THardwareMod w ule, THardwareInterface, and THardwareConnection. A handle is multipath safe only if the following holds: A method operating on a master in a configuration database (as opposed to a reference-counted master) is atomic with respect to other operations on the same master. In implementation terms, this means that a handle has no internal monitor. A reference-counted master also has no internal monitor. But for a master in the configuration database, there is synchronization to ensure that only at most one operation is performed on the master at a time.

Class interfaces

For purposes of illustration, we now describe additional details (such as the duration of handles and the functionality of member functions) associated with selected classes of the hardware configuration framework (see Figure 2). Such additional details for classes not specifically discussed below will be apparent to those skilled in the art from the discussion contained herein.

THardwareConfiguration

A THardwareConfigurationHandle 204 can be saved to a file and restored at any time. The handle is valid until the Destroy method is called. The THardwareConfiguration class 204 includes the following functions.

THardwareConfigurationhandle()

Constructs a loose handle. Useful as a target for streaming and mapping.

THardwareConfigurationHandle(const TText& name)

Constructs a handle to a master THardwareConfiguration object, which is constructed using the persistent hardware configuration specified by the name argument. Many different THardwareConfigurations can exist simultaneously, and this name is used to uniquely distinguish them. The namespace is managed by appending the device name to the beginning of the name argument. If a persistent hardware configuration is not desired, inserting a blank name (i.e. "") creates a non-persistent hardware configuration counted by reference.

The persistent hardware configuration, specified by the Name argument, contains all THardwareModule and THardwareConnection objects that have requested a persistence period.

All handles designed for the THardwareConfigurationHandie named "Foo" refer to the single master in the persistent hardware configuration named "Foo".

THardwareConfigurationHandle (const THardware-Configuration Handle& copyFrom

Copies the handle, not the master. The new handle becomes a reference to the master pointed to by copyFrom.

THardwareConfigurationHandle& operator=(const THardware Configuration Handle& copyFrom)

Copies the handle, not the master.

THardwareConfiguration Handle()

Destroy the handle, not the master.

void Destroy()

This process destroys the persistent storage and all master objects in this hardware configuration. All handles to every single object in this hardware configuration will be loose, including this one.

void GetAllHardwareModules (TCollectiOn< THardwareModule-Handle> & result) const

This procedure copies all handles registered for this hardware configuration and adds them to the collection specified by the result argument. It does not flush the result first.

The copied handles reflect the state of the master THardwareConfiguration object at the time this method is called. The state of the master THardwareConfiguration object can change at any time and is not directly reflected in the result. Changes are reflected by the handles in the result. For example, any handle whose master has been removed from its THardwareConfiguration object becomes a loose handle. The only methods that may be applied to a handle in the loose state are assigning, copying, or streaming operators. A loose Handling becomes authentic when it is the target of assignment or flow, when the source is not loose.

void GetHardwareModules (TCollection< THardwareModuleHandle> & result, const HardwareModuleCategory& desiredKind) const

This method copies all handles of desiredkind declared for this hardware configuration and adds them to the collection specified by the result argument: caller handles the storage. It does not flush the result first.

The copied handles reflect the status of the master THardwareConfiguration object at the time this procedure is called.

void AddHardwareModule (THardwareModuleHandle& newHardware-Module)

This method adds the given newHardwareModule object to this hardware configuration. It does this by moving the master THardwareModule object, which is referenced by the newHardwareModule object and any THardwareInterfaceHandle object owned by newHardwareModule, into the hardware configuration. If the client has handles to any THardwareInterfaceHandle object owned by newHardwareModule, they are updated to reflect the move in the database.

void RemoveHardwareModule (const THardwareModuleHandle& hardware Module)

This procedure removes all THardwareConnection objects for each THardwareInterface object owned by the master referenced by hardwareModule. Next, the master is removed from the hardware configuration: the master is referenced by this handle. All other handles that reference the master are dropped.

TInterest* CreateAnyChangeInterest()

This method creates an interest in any change in the hardware configuration (which includes any change to any member of the hardware configuration); the client is responsible for storing the result. A notification is sent from this THardwareConfiguration object to all interested clients. Clients can call this method directly to create an interest, which is used to subscribe to notifications.

Tstream& operator»=(TStream& toWhere) const

Emit a persistent reference to the master hardware configuration that represents this handle.

Tstream& operator«= (TStream& fromWhere)

Streams a reference to a master hardware configuration.

THardwareModules

A THardwareModuleHandle can be saved to a file and restored at any time. The handle remains valid until the master is removed (via a RemoveHardwareModule method). The THardwareModule class 206 includes the following functions.

THardwareModuleHandle ()

Creates a reference-counted master that is not present in any hardware configuration.

THardwareModuleHhandle (const THardwareModuleHandle& copyFrom)

Copies the handle, not the master. The new handle becomes a reference to the master pointed to by copyfrom.

THardwareModuleHandle& operator= (const THardwareModule Handle& copyFrom)

Copies the handle, not the master. If the left hand side is the last reference to a master that is not in any hardware configuration, the master is destroyed. The left hand side then becomes a reference to the master referenced by copyFrom.

THardwareModulehandle ()

Destroys the handle. If this is the last reference to a master that is not in any hardware configuration, the master is destroyed.

void GetAllConnectors (TSequence&le;THardwareInterfaceHandle> & result) const

This method copies all handles of THardwareInterface objects owned by this THardwareModule and adds them to the collection specified by the Result argument: Caller handles the storage. It does not flush the Result first. The connectors are added to the result in the same order as they were returned to the module (i.e. the first connector added becomes the first connector returned by the TSequence iterator).

The copied handles reflect the status of the master THardwareModule object at the time this procedure is called. The status of the master THardwareModule object can change at any time and is not directly reflected by the result. Changes are reflected by the handles in the result.

This method can be called by clients at any time. Typically, the hardware viewer framework calls this method to map the connector objects in a hardware module to the connector icons to be displayed.

void GetDefaultConnectors (TSequence< THardwareInterface handle> & result) const

This method copies all handles of THardwareInterface objects owned by this THardwareModule and recorded as standard connectors and adds them to the collection specified by the Result Argument: caller does the storing. It does not flush the Result first. The connectors are added to the result in the same order as they were added to the module.

The copied handles reflect the state of the master THardwareModule object at the time this method is called. This method can be called by clients at any time.

void AddConnector (const THardwareInterfaceHandle& newConnector, Boolean isDefault = FALSE)

This method moves the master THardwareInterface object referenced by newconnector to the master THardwareModule. If the isdefault argument is true, newconnector is recorded as the default connector.

This method is typically called when a THardwareModule object is constructed from scratch.

void RemoveConnector (const THardwareInterfaceHandle& connector)

This procedure removes all connections associated with the given connector. Next, the master specified by the connector argument is removed from the hardware configuration: the master is reference counted by this handle. All other handles that point to the master are dropped.

void Getsignature (HardwareModuleSignature& signature) const

Copies a personality-neutral entity that represents the device type that this THardwareModule object represents into the signature argument. The personality-neutral entity can be used to create a personality-dependent object (e.g. a presentation object). This method can be called by clients at any time. Typically, the computer viewer calls this method when the presentation object for this HardwareModule is first constructed.

void SetSignature (const HardwarModuleSignature&)

Specifies the type that this THardwareModule object represents. This method is called when a THardwareModule object is manually constructed from scratch, and is very rarely called directly by clients.

void GetCategories (TCollection< HardwareModuleCategory> & result) const

This method copies all HardwareCategory objects owned by this THardwareModule and adds them to the collection specified by the Result argument: Caller handles the storage. It does not flush the result first.

The iterator reflects the status of the Master-THardware-Module object at the time this procedure is called. This procedure can be called by clients at any time.

void AddCategory (const HardwareModuleCategory& category)

Appends the category argument to the end of the list of categories for this hardware module. This method is called when a THardwareModule object is manually constructed from scratch, and it is very rarely called directly by clients.

void DeleteCategory (const HardwareModuleCategory& category)

Deletes the HardwareModuleCategory object specified by the category argument from the master THardwareModule.

Boolean IsRoot() const

Returns TRUE if the THardwaremodule object is the central device of its THardwareconfiguration. Each THardwareConfiguration object has a root device. For a personal computer, the root device is the THardwareModule object that represents the computer.

void SetRoot (Boolean)

Sets the "root" attribute to the value of the given argument. This method is called when a THardwareModule object is manually constructed from scratch, and it is very rarely called directly by clients.

Boolean IsInternal() const

Returns TRUE if this THardwareModule object is inside the root THardwareModule. This method is called by the configuration viewer to determine whether to draw the device inside or outside the root device. For example, the internal hard disk drive of a Macintosh is "inside" the computer.

void SetInternal(Boolean)

Sets the "internal" attribute to the value of the given argument. This method is called when a THardwareModule object is manually constructed from scratch, and it is very rarely called directly by clients.

Boolean WantsPersistence( ) const

Returns TRUE if this THardwareModule object requests the hardware configuration framework to automatically restore the device when the master THardwareConfiguration object is restored. This method is typically called by the hardware configuration framework (i.e., by objects of the hardware configuration framework)

void SetwantsPersistence (Boolean)

Sets the "Wantspersistence" attribute to the value of the given argument. This method is called when a THardwareModule object is manually constructed from scratch, and it is very rarely called directly by clients.

TStream& operator»=(TStream& toWhere) const

If a master THardwareModule object is in a hardware configuration, this method streams a persistent reference. Otherwise, this method streams a copy of the master, including its connectors, but not its connections.

TStream& operator« (TStream& fromWhere)

Streams in a THardwareModuleHandle. If the object in the fromWhere argument is in a hardware configuration, this method streams in a persistent reference. Otherwise, this method streams in a master including its connectors.

THardwareInterface

A THardwareInterfaceHandle can be saved to a file and restored at any time. This handle remains valid until the master is removed. The THardwareInterface class 212 includes the following functions.

THardwareInterfaceHandle()

Creates a reference-counted master that is not present in any hardware configuration.

THardwareIntwareInterfaceHandle (const THardwareInterfaceHandle& copyFrom)

Copies the handle, not the master. The new handle becomes a reference to the master pointed to by copyFrom.

THardwareInterfaceHandle& Operator (const THardwareInterfaceHandle& copyFrom)

Copies the handle, not the master. If the left hand side is the last reference to a master that is not in any hardware configuration, the master is destroyed. The left hand side then becomes a reference to the master referenced by copyFrom.

THardwareInterfaceHandle()

Destroys the handle. If this is the last reference to a master that is not in any hardware configuration, the master is destroyed.

THardwareModuleHandle GetOwner () const

Returns a handle to the THardwareModule object to which this THardwareInterface object belongs. This method is typically called by the Hardware Configuration Viewer.

void GetAllConnections (TCollection(THardwareConnection handle> & result) const

This method copies all THardwareConnection handle objects associated with this THardwareInterface and adds them to the collection specified by the Result argument: Caller handles the storage. It does not flush the result first.

The copied handles reflect the state of the master THardwareInterface object at the time this method is called. This method is typically called from the Hardware Configuration Viewer.

void Delete Connection (const THardwareInterfaceHandle& otherEnd

This method deletes the THardwareConnection object specified by this object and the otherEnd from this hardware configuration. All handles related to the master THardwareConnection object become loose.

void DeleteAllConnections()

This method deletes all THardwareConnections from this THardwareInterface object. All handles related to the deleted master THardwareConnection objects become loose. This method is typically called by the hardware configuration viewer framework.

THardwareInterfaceIdentifier* CopyHardwareInterface-Identifier() const

Returns a pointer to the object that identifies the real physical hardware component that this connector represents. The caller accepts the returned storage.

void SethardwareInterfaceIdentifier (const THardwareIntwareInterfaceIdentifier&)

Sets the "InterfaceIdentifier" attribute to the value of the given argument. This method is called when a THardwareModule object is manually constructed from scratch, and it is very rarely called directly by clients.

short GetMaxConnections( ) const

Returns the maximum number of connections allowed by this connector. If this value is greater than one, the connector represents a bus (e.g. SCSI, ADB). This method is typically called by the hardware configuration viewer during connection negotiations.

void SetMaxConnections (short)

Sets the "MaxConnections" attribute to the value of the given argument. This method is called when a THardwareModule object is manually constructed from scratch, and it is very rarely called directly by clients.

ETransmissionMode GetMode() const

Returns the transfer mode supported by this connector. This method is typically called by the hardware configuration viewer during connection negotiations.

void SetMode(ETransmission Mode)

Sets the "TransmissionMode" attribute to the value of the given argument. This method is called when a THardwareModule object is manually constructed from scratch, and it is very rarely called directly by clients.

Boolean WantsPersistentConnections() const

Returns TRUE if this THardwareInterface object requests the hardware configuration framework to automatically re-establish its connections when the master THardwareConfiguration object is restored. A connection is restored when either of the two connectors performing the connection requests it.

void SetWantsPersistentConnections (Boolean)

Sets the "WantsPersistentConnections" attribute to the value of the given argument. This method is called when a THardwareModule object is manually constructed from the beginning, and it is very rarely called directly by clients.

Boolean IsReconfigurable() const

Returns TRUE if the hardware represented by this THardwareInterface object can support reconfiguration. This does not mean that a service is currently available to actually perform the reconfiguration. This attribute is an optimization.

void SetWantsReconfiguration (Boolean)

Sets the "WantsReconfiguration" attribute to the value of the given argument. This method is called when a THardwareModule object is manually constructed from scratch, and is very rarely called directly by clients.

void GetCategories (TCollection(HardwareIntwareInterfaceCategory)& result) const

This method copies all HardwareCategory objects owned by this THardwareInterface and adds them to the collection specified by the Result argument: Caller handles the storage. It does not flush the result first.

The iterator reflects the state of the master THardwareInterface object at the time this method is called. This method can be called by clients at any time.

void AddCategory (const HardwareInterfaceCategory& category)

Appends the category argument to the end of the list of categories for this hardware interface. This procedure is called when a THardwareInterface object is manually constructed from scratch, and it is very rarely called directly by clients.

void DeleteCategory (const HardwareInterfaceCategory& category)

Deletes the HardwareInterfaceCategory object specified by the category argument from the master THardwareInterface.

stream& operator»=(TStreamg& toWhere) const

If a master THardwareInterface object is in a hardware configuration, this method streams a persistent reference. Otherwise, this method streams a copy of the master.

TStream & operator« = (TStream& from Where)

Streams in a THardwareInterfaceHandle. If the object in the fromWhere argument is in a hardware configuration, this method streams in a persistent reference. Otherwise, this method streams in a master.

THardwareConnectionHandle

A THardwareConnectionHandle can be saved to a file and restored at any time. This handle remains valid until the master is removed. The THardwareConnection class 216 includes the following functions.

THardwareConnectionHandle()

Creates a loose handle. Useful as a target for streaming and mapping.

THardwareConnectionHandle (const THardwareIntwareInterfaceHandle& toConnector, const THardwareInterfaceHandle& fromConnector)

Creates a reference-counted master that does not exist in a hardware configuration.

THardwareConnectionHandle (const THardwareConnectionHandle& copy From)

Copies the handle, not the master. The new handle becomes a reference to the master pointed to by copyFrom.

THardwareConnectionHandle& operator= (const THardwareConnection Handle& copyFrom)

Copies the handle, not the master. If the left hand side is the last reference to a master that is not in any hardware configuration, the master is destroyed. The left hand side then becomes a reference to the master referenced by copyFrom.

THardwareConnectionHandle ()

Destroys the handle. If this is the last reference to a master that is not in any hardware configuration, the master is destroyed.

voidAdd()

This procedure moves the master THardwareInterfaceconnection object into the hardware configuration. No connector will see this connection until Add is called.

void Remove()

This method reverses the effect of Add. The master THardwareConnection object is removed from the hardware configuration: the master is referenced by this handle. All OTHER handles that reference the master are dropped. This method is typically called from the hardware configuration viewer.

THardwareInterfaceHandle GetOtherEnd (const THardwareInterfaceHandle& thisEnd) const

Given the THardwareInterfaceHandle specified by this-End, this method returns the THardware-InterfaceHandle at the other end.

EConnectionKind GetKind() const

Returns the connection type that this THardwareConnection object represents. A connection can be automatic or manual. An automatic connection is established by the system. A manual connection is established by the user. It is important to be able to distinguish between these two types of connections. This method is typically called by the hardware configuration framework.

void SetKind (EConnectionKind)

Sets the "kind" attribute to the value of the given argument. This method is called when a THardwareModule object is manually constructed from scratch, and it is very rarely called directly by clients.

Boolean IsPersistent() const

Returns TRUE if either of the two connectors of this THardwareConnection object wants persistent connections. This method is typically called by the hardware configuration framework.

Tstream& Operator»=(TStream& toWhere) const

If it is in a hardware configuration, this method streams in a persistent reference. Otherwise, this method streams out a copy of the master.

TStream& operator«=(TStream& fromWhere)

Streams in a THardwareConnectionHandle. If the object in the fromwhere argument is in a hardware configuration, this method streams in a persistent reference. Otherwise, this method streams in a master.

TPartLocator

A TPartLocator object cannot be saved. The TPartLocator class 218 includes the following member functions.

TPartLocator (const HardwareModuleCategory& theCompartment)

Creates a parts finder capable of finding all hardware module prototypes (i.e. parts) specified by theCompartment. The only expected client of this constructor is TPartsBin. TPartsBin creates one of these finders for each compartment (i.e. slot, bin, tab, etc.) that the parts bin has.

Boolean FindAll (TCollection(THardwareModuleHandle)& theResult)

This method looks for all FSEntities that identify themselves as parts that want to be in this compartment. It raises all THardwareModulehandle objects from the files found and adds them to the given collection specified by theresult: caller takes over storage. It does not flush the result first. It returns TRUE if anything is found. The parts container calls this when it needs to render (or prepare to render) the contents of a particular compartment.

THardwareModuleHandle FindOne(const TText& theName)

This method returns the THardwareModuleHandle that was "installed" for this slot whose HardwareModuleSignature matches theName value.

TInterest* CreateAddedInterest ()

This method creates an interest for clients to use to subscribe to notifications about the addition of a part belonging to this bin: client takes over result storage. The only expected client of this method is TPartsBin. TPartsBin calls this method immediately before calling Findall so that it can ensure an up-to-date display of available parts.

TInterest* CreateremovedInterest ()

This method creates an interest for clients to use to register for notifications about the removal of any part belonging to this bin: client takes care of result storage. The only expected client of this method is TPartsBin. TPartsBin calls this method immediately before calling FindAll so that it can ensure an up-to-date display of available parts.

TPartsBin

A TPartsBin object cannot be saved. The TPartsbin class 220 includes the following member functions.

TPartsBin ()

Constructs an empty parts container.

TPartsBin (const TPartLocator& copyFrom)

Copies all TPartLocators owned by copy-From into this TPartsBin.

void GetAllPartLocators (TCollection< TPartLocator> & result) const

This method copies all TPartlocator objects owned by this parts container and adds them to the collection specified by the Result argument: Caller assumes the storage was set. It does not flush the result first.

The contents of the Parts Bin object can change at any time, but this is not directly reflected by the Iterator. This method can be called by clients at any time. The only expected client of this method is the Parts Bin Viewer. It displays an icon (and a name) for each Parts Bin it owns. Each Parts Bin represents a tab on the Parts Bin. Furthermore, the Parts Bin displays all parts in that bin when a tab is selected by the user.

TPartLocator GetPartLocator (const HardwareModuleCategory& desired Compartment) const

Returns the TPartLocator object for the desired compartment in this parts container. This method can be called by clients at any time.

void AddCompartmentFor (const HardwareModuleCategory& compartment)

This method creates a TPartLocator object for the type of compartment specified by the compartment argument for this parts container. This method can be called by clients at any time. The only expected client of this method is a parts container viewer. A parts container viewer can decide which categories it wants to display.

void RemoveCompartment (const HardwareModuleCategory& compartment)

This method removes the TPartLocator object for the type of compartment specified by the compartment argument for this parts container. The only expected client of this method is the parts container viewer.

TInterest* CreateAddedInterest ()

This method creates an interest for clients to use to subscribe to notifications about the addition of any new part locators. The only expected client of this method is a parts bin viewer. The parts bin viewer calls this method immediately before calling GetAllPartLocators so that it can ensure an up-to-date display of available bins.

TInterest* CreateRemovedInterest 0 This method creates an interest for clients to use to subscribe to notifications about the removal of an existing part locator. The only expected client of this method is a parts bin viewer. The parts bin viewer calls this method immediately before calling Getallpartlocators so that it can ensure an up-to-date display of available bins.

Claims (13)

1. An object-oriented hardware configuration system for enabling centralized user configuration (104, 110, 112, 116, 118) of hardware in a computer system (102), comprising a plurality of object-oriented hardware interface objects, each of which represents a physical connector (212, 412, 414, 416) of a hardware device, and a plurality of object-oriented hardware module objects, each of which represents a hardware device that is user-configurable and contains one or more hardware interface objects that are connected to the hardware device in such a way that the connectors of the hardware device are defined, marked by: a plurality of connector objects (216), each of which represents a physical connection (212, 412, 414, 416) between two of a plurality of hardware interface objects; an object-oriented hardware configuration object (204) containing a plurality of hardware module objects representing hardware devices associated with a particular computer system, such that the hardware module object defines a particular hardware configuration of the particular computer system; and means for notifying interested clients of changes to the particular computer system by sending a message to the interested clients of changes in the hardware configuration object (204-224), said configuration system includes means for allowing a user to access the hardware configuration object for configuring the hardware devices connected to the particular computer system and for establishing connections between hardware devices with the plurality of connector objects. 2. The hardware configuration system of claim 1, further comprising means for notifying interested clients of changes in the connections between hardware devices by sending a message to the interested clients about changes in the hardware configuration object. 3. The hardware configuration system of claim 1, wherein the hardware module objects belong to device classes and each of the plurality of hardware module objects includes an object-oriented hardware module signature object identifying the device class to which the hardware module object belongs. 4. The hardware configuration system of claim 1, wherein each of the plurality of hardware module objects includes an object-oriented hardware module category object for identifying device types that each of the hardware module objects can represent. 5. The hardware configuration system of claim 4, wherein the device types include: a monitor type, a printer type, a keyboard type, a pointer device type, a modem type, a card type, a disk drive type, a scanner type, and a fax device type. 6. The hardware configuration system of claim 1, wherein each of the plurality of hardware interface objects comprises an object-oriented hardware interface category object for identifying device connector types that each of the hardware interface objects can represent. 7. The hardware configuration system of claim 6, wherein the device connector types include a serial connector type, a parallel connector type, a video connector type, a MIDI connector type, an ADB connector type, a SCSI connector type, and a slot connector type. 8. The hardware configuration system of claim 6, wherein each of the plurality of hardware interface objects represents a computer system interface port. 9. A method for manually configuring a computer system having storage means and a plurality of hardware components, each of which has at least one physical connector and is integrated into a hardware hierarchy, the method is characterized by the steps: (a) Storage in the storage means of class information defining a plurality of machine classes and subclasses corresponding to one of a plurality of hardware components, the plurality of machine classes are arranged in an object-oriented hierarchy; (b) storing in the storage means class information defining a plurality of connector classes and subclasses, each of which defines a connector for connecting two hardware interface objects corresponding to the physical connectors on one or more of the plurality of hardware components; (c) identifying a first of the plurality of hardware components; (d) instantiating a first machine-specific object from the object-oriented hierarchy to represent the first hardware component; (e) instantiating, via the first machine-specific object, a hardware interface object for each physical connector on the first hardware component; (f) identifying a second of the plurality of hardware components; (g) instantiating a second machine-specific object from the object-oriented hierarchy to represent the second hardware component; (h) instantiating, via the second machine-specific object, a hardware interface object for each physical connector on the second hardware component; (i) configuring the first and second hardware devices via the first and second machine-specific objects; (g) instantiating a connector object for representing a physical connection between the first hardware component and the second hardware component in response to a signal from the hardware interface object in the first machine-specific object and a signal from the hardware interface object in the second machine-specific object; and (k) notifying interested clients of changes in the hardware configuration of the specific computer system by sending a notification to the interested clients of changes in the hardware configuration object. 10. The method of claim 9, further comprising the step of notifying interested clients of changes in the connections between hardware devices by sending a message to the interested clients about changes in the hardware configuration object. 11. The method of claim 10, wherein each of the Hardware Module objects belongs to device classes and the method further comprises the step of identifying the device class to which the Hardware Module object belongs by an object-oriented Hardware Module signature object. 12. The method of claim 11, wherein each of the plurality of hardware module objects includes an object-oriented hardware module category object, and the method further comprises the step of identifying device types that each of the plurality of hardware module objects can represent. 13. The method of claim 12, wherein each of the plurality of hardware interface objects includes an object-oriented hardware interface category object, and the method further comprises the step of identifying device connector types that each of the hardware interface objects can represent.