WO2001065365A1 - Appareil et procede permettant l'echange de dispositifs pendant que l'ordinateur est allume - Google Patents

Appareil et procede permettant l'echange de dispositifs pendant que l'ordinateur est allume Download PDF

Info

Publication number
WO2001065365A1
WO2001065365A1 PCT/US2000/005378 US0005378W WO0165365A1 WO 2001065365 A1 WO2001065365 A1 WO 2001065365A1 US 0005378 W US0005378 W US 0005378W WO 0165365 A1 WO0165365 A1 WO 0165365A1
Authority
WO
WIPO (PCT)
Prior art keywords
controller
computer system
node
driver
program product
Prior art date
Application number
PCT/US2000/005378
Other languages
English (en)
Inventor
Susumu Arai
Original Assignee
Phoenix Technologies Ltd.
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 Phoenix Technologies Ltd. filed Critical Phoenix Technologies Ltd.
Priority to PCT/US2000/005378 priority Critical patent/WO2001065365A1/fr
Priority to CN00819275.8A priority patent/CN1199102C/zh
Priority to JP2001563993A priority patent/JP2003525494A/ja
Publication of WO2001065365A1 publication Critical patent/WO2001065365A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
    • G06F9/4413—Plug-and-play [PnP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers

Definitions

  • the invention relates generally to the field of interconnecting devices with a computer, and more specifically, to swapping or changing the devices interconnected with a computer while the computer is in operation.
  • each operating system there are a series of drivers for discovering and initializing devices included in a computer so that they can properly communicate with all of the resources of the computer.
  • the drivers enumerate or recognize the devices connected to the computer when the driver is started during the installation or booting up of the operating system.
  • their associated device driver is not fully “plug and play” enabled. Examples of these drivers include the IDE driver for hard disk drives and the floppy driver for floppy drives. Because these drivers are not fully “plug and play” enabled, the drivers for these devices are unable to enumerate the devices during runtime.
  • the present invention comprises a method for enumerating a first device present in a computer system to make the first device recognizable to the computer system, the computer system having a memory and an operating system which uses a data structure stored in the memory for establishing a working configuration of the computer system, the data structure having one or more device nodes corresponding to devices present in the computer system, the method including the steps of providing an indication to the operating system that the first device has been inserted into the computer system while the computer system is in operation, enumerating a controller for controlling the first device in response to the indication, initializing a driver associated with the first device controller in response to the enumeration of the first device controller, locating, with the initialized driver, an enumerator associated with the first device controller, and enumerating the first device with the located enumerator, wherein the driver associated with the first device controller is only capable of locating the enumerator associated with the first device controller when initialized.
  • the method prior to the step of connecting the first device, further includes the steps of determining whether a second device in the computer system is currently being accessed, removing the device node corresponding to the second device and a device node corresponding to a controller for controlling the second device from the data structure, isolating any data signals which are transmitted between the second device and the second device controller from being transmitted from the second device controller to the second device, and powering off the second device.
  • the step of removing the device nodes corresponding to the second device and the second device controller includes the substep of unloading all drivers associated with the second device and the second device controller.
  • a computer program product comprises a computer usable medium having computer readable program code modules embodied therein for enumerating a first device present in a computer system to make the first device recognizable to the computer system, the computer system having a memory and an operating system which uses a data structure stored in the memory for establishing a working configuration of the computer system, the data structure having one or more device nodes corresponding to devices present in the computer system, the computer program product including a first enumeration module for enumerating a controller for controlling the first device after inserting the first device into the computer system while the computer system is in operation, an initialization module for initializing a driver associated with the first device controller in response to the enumeration of the first device controller, a locator module for identifying, with the initialized driver, an enumerator associated with the first device controller, and a second enumeration module for enumerating the first device with the located enumerator associated with the first device controller, where
  • Fig. 1 is a block diagram of a computer system consistent with the present invention.
  • FIGs. 2a and 2b are block diagram flowcharts of a swapping process consistent with the present invention.
  • Fig. 3 is a block diagram flowchart of an enumeration process consistent with the present invention.
  • Fig. 4 is a block diagram of a device exchange system consistent with the present invention.
  • Fig. 1 shows how the components of a computer system 10 consistent with the present invention fit together.
  • computer system 10 includes a configuration manager 20, a plurality of devices or resources 30, a registry 40, a devnode tree 50, and a device driver storage 60. See the definitions to follow for the foregoing elements
  • Computer system 10 is preferably implemented m a Plug and Play framework
  • computer system 10 includes other elements, such as a processor, a memory, a monitor, and an input device, like a keyboard or pointing device Additional elements may also be included m computer system 10 as is known in the art
  • Configuration manager 20 which can be implemented as a virtual device driver (VxD), is the central component of a plug and play framework VxD is a driver specifically formatted for Windows 95 and 98 Other drivers, including DLL and DOS TSR formats, are also possible Configuration manger 20 directs all configuration management m computer system 10 To direct the configuration management, it can use three data stores registry 40, devnode tree 50 and device driver storage 60, and can work with four software components enumerators, arbitrators, device loaders and device drivers "Enumerators” determine which hardware devices are currently installed m computer system 10 and what resources they require Accordingly, enumeration is the discovery or identification of a device Like configuration manager 20, enumerators can also be implemented as VxDs After identifying each device, an enumerator creates a "device node " A device node is a data structme containing basic information about an identified device The device node can contain fields indicating possible configurations, current configuration,
  • Registry 40 stores a hierarchical tree of entries, which include keys and values, for each device which has ever been installed in computer system 10
  • the key for each entry is an identification for a respective device
  • the values in each entry include information about the type of device and its desc ⁇ ption, which drivers should be loaded for a particular device when enumerated, d ⁇ ver revision number, manufacturer, and potential logical configurations of the device
  • the information for the values can come from a device information file supplied by the vendor with a device or from the device itself
  • “Device information files” contain information about known devices and their configurations
  • the enumerator can use the information corresponding to an entry for the device in registry 40.
  • Devnode tree 50 is a hierarchical tree of device nodes that describes all of the hardware present in computer system 10.
  • the hierarchy in devnode tree is structured such that device nodes are placed in the hierarchy under the device node for the device controlling these device nodes to thereby provide an indication of control.
  • the device nodes for devices controlled by a bus are placed under the device node for the bus.
  • Device nodes, like the device node for the bus are called parent nodes, whereas the device nodes controlled by a parent node, like the devices connected to the bus, are child nodes.
  • configuration manager 20 invokes a "device loader" associated with the device.
  • a device loader which can be implemented as a VxD, loads and manages device drivers and enumerators for a given device node.
  • Device loaders are typically used when devices are managed by various layers of device drivers. The device loader coordinates the work of the various layers and carries out general configuration tasks that apply to all device drivers.
  • a "device driver” controls and manages the device hardware.
  • Devices drivers are responsible for identifying the specific resource requirements of a given device and for setting the device to operate with the configuration assigned by configuration manager 20.
  • the device drivers for all devices 30 which have been installed in computer system 10 can be stored in device driver storage 60.
  • arbitrators which can also be implemented as VxDs, are used by configuration manager 20 to resolve resource conflicts between devices 30.
  • An arbitrator reviews a list of requirements for devices 30 installed in computer system 10 and finds the best allocation of resources to satisfy all of the devices. The arbitrators make conflict-free assignments for several resources in computer system 10, including input/output (I/O) addresses, memory addresses, interrupt requests (IRQs), and direct memory access (DMA) channels.
  • I/O input/output
  • IRQs interrupt requests
  • DMA direct memory access
  • arbitrators, enumerators, registries, devnode trees, configuration managers and device loaders are standard items of software provided by a variety of software vendors, including by Microsoft Corporation in Windows 95 and Windows 98.
  • a device node is the basic in-memory representation of a device 30 that is physically present on the system. It is a data structure which contains information relating to the device and its drivers.
  • the information stored in a device node includes the device identification (ID), its currently assigned configuration, possible logical configurations, status information, and a device driver entry point.
  • ID device identification
  • device nodes are created by enumerators. In response to the creation of a device node, configuration manager 20 causes the appropriate driver to be loaded.
  • a "device ID" used in the device node data structure is an ASCII string unique to each device 30 that may be included in computer system 10.
  • the string typically identifies the component that found the device, but because it is also serves as a key in registry 40, it must be unique within computer system 10 so that information about the device can be retrieved reliably.
  • This string can be used to cross-reference data about the device stored in registry 40.
  • PCMCIA ⁇ MEGAHERTZ-XJ124FM-936B As seen from these examples, the first part of the ID identifies the component that found the device. For example, ISAPNP would correspond to the ISA bus for Plug and Play devices. This naming scheme for device IDs is a bus-specific naming scheme.
  • each of the busses includes an enumerator invoked by configuration manager 20 for locating devices on its respective bus.
  • These busses include PCI, EISA, PCMCIA, SCSI, and others.
  • Devices on these busses are generally configured to fully support Plug and Play.
  • An ISA bus can also be configured to support Plug and Play, and is referred to as a ISAPNP bus.
  • Device nodes for the devices identified on the busses can have enumerators of their own to create child nodes on devnode tree 50. Any of these child device nodes can have an enumerator that creates on devnode tree 50 further children of that device node.
  • configuration manager 20 can use detection modules instead of enumerators. Detection modules can use methods to identify a Legacy device, such as examining hard-coded I/O locations for expected values to detect devices like a keyboard or interrupt controller.
  • Enumerators are responsible for creating device IDs for the devices they locate. As noted above, each identifier should be unique and be consistently the same on each system boot. The string should be constructed so that it can serve to identify a unique entry in registry 40. The string generally starts with the enumerator's name followed by a backslash. For example, the ISA Plug and Play enumerator can start all device identifiers with "ISAPNPV" Enumerators build devnode tree 50 and may participate in configuring the devices 30 on the bus associated with a respective enumerator. In most operating systems, an enumeration process takes place every time the computer starts.
  • devnode tree 50 includes information about available system resources, required device drivers, and other requirements for those resources.
  • Devnode tree 50 is a hierarchical tree of device nodes representing the structure of the hardware in computer system 10. Accordingly, a device node is either at the root of devnode tree 50 or is the child of a parent device node. A device node can have multiple child device nodes. The other children of a device node's parent are called siblings.
  • Devnode tree 50 is built each time the computer is started. Furthermore, it can be completely dynamic, changing even while the computer is running if a device 30 is removed or added to computer system 10.
  • Devnode tree 50 provides several functions for computer system 10. First, it describes all hardware that is present in computer system 10. In addition, devnode tree 50 provides a mechanism for enumerators to configure their children's hardware, allowing bus independent drivers. The drivers can be bus independent because the enumerators for each bus can identify and configure the devices controlled by the bus independently of the other busses. Normally, drivers do not know or care about their exact location within the tree. Drivers typically are only concerned with their own hardware device or device node, and are oblivious to the layers above or below them in the tree.
  • Devnode tree 50 contains configuration information for all devices 30 in computer system 10, and configuration manager 20 uses it to keep track of the resources associated with each device 30, such as interrupt requests (IRQs), input/output (I/O) ports and even non-sharable resources like SCSI identifiers.
  • Devnode tree 50 describes existing devices and resources, resource requirements, resource interdependencies, and current resource allocations.
  • Table I shows an example of a devnode tree illustrating device IDs of some typical devices and where in the hierarchy one might expect to find them. The actual contents of each device node other than the device ID are not shown.
  • Root node is a parent node to the Sound Blaster and
  • Plug and Play BIOS has a series of child nodes.
  • An enumerator for the Plug and Play BIOS would identify each of these devices and create a device node for each device, where each device node is a child to the Plug and Play BIOS device node. As discussed above, this hierarchical structure shows that each of these child nodes is controlled by the Plug and Play BIOS.
  • an enumerator for the PCMCIA controller would identify the network adapter, which is controlled by the PCMCIA controller, and create a device node for the network adapter as a child node to the PCMCIA controller.
  • Computer system 10 also uses and extends a registry 40 and various device information files (with the .INF filename extension).
  • Registry 40 stores information about all devices 30 ever installed on a particular machine, including devices that are not fully Plug and Play enabled, such as Legacy devices.
  • Registry 40 also stores information about Plug and Play devices which have been located by an enumerator, device-specific state information, bindings of devices to device drivers, and data about the last known configuration— which is used to accelerate the allocation of resources.
  • the device information files noted above contain information about known devices and their configurations.
  • Computer system 10 can provide some class- information files (for example, SCSI. INF and MODEM. INF); others are provided by the device manufacturer.
  • SCSI. INF and MODEM. INF are provided by the device manufacturer.
  • all known .INF files are searched for entries matching the device ID.
  • the appropriate files are copied and the required data is copied into a newly created registry entry in registry 40.
  • Registry 40 is a system-wide database, accessed in Windows 95, Windows 98 and Windows NT® through the Microsoft Win32® API set. Additionally, Windows 95 and Windows 98 provide real-mode access to registry 40 to allow its use during boot-up prior to the switch to protect mode. As noted previously registry 40 stores a hierarchical tree of "Keys" and "Values," similar to entries in Windows 3.1 - format .INI files (except that Windows 3.1 .INI files have a flat structure, as opposed to the tree structure of the registry.) The operating system uses registry 40 to store information about which drivers should be loaded when a particular device is enumerated, as well as such information as the driver revision number, manufacturer, and potential logical configurations of the device. Table II, below, shows an exemplary registry entry.
  • BootConfig (I/0 ports 20h, 21h, AOh, and Alh - binary resource data)
  • Driver System ⁇ 0000
  • HardwareID "*PNP0000”
  • Mfg "Microsoft”
  • NoSetupUI "l”
  • ENUM ⁇ BIOS ⁇ *PNP0000 ⁇ 0000 ⁇ LogConfig 0 (Binary resource data, in this case as BootConfig above)
  • the registry entry in Table II shows an example of information that may be included in registry 40 for a particular device.
  • the device is a programmable interrupt controller.
  • the information for this device includes a possible boot configuration, a device driver associated with the device, a unique ID, the name of the device's information file, and a device loader for loading the device driver of the device.
  • a device installer creates new entries m registry 40 when an enumerator or detection module detects a device for which there is no registry entry in registry 40 Most of the information is provided either by the INF file provided with the device or directly by the device's setup module Registry 40 also stores configuration-specific information, which is information relevant to whether a capable portable computer is docked or undocked, as well as user-specific information
  • devnode tree 50 is an accurate hierarchical representation of the currently installed devices
  • registry 40 contains information for all devices ever installed (even if they are not currently present)
  • the location of a device m registry 40 does not fully reflect the hierarchical structure desc ⁇ bed in devnode tree 50
  • devices are located beneath their enumerator, but all enumerators are kept m a flat list, meaning that enumerators are not kept in a hierarchical structure according to the enumerator that identified their associated device
  • Devnode tree 50 exists in memory only, whereas registry 40 is saved on disk
  • a device driver controls and manages the device hardware
  • Device drivers are responsible for identifying the specific resource requirements of a given device 30 and for setting that device to operate with the configuration assigned by the configuration manager 20
  • Configuration manager 20 provides services and messages that a device driver can use to carry out its tasks.
  • a device driver examines the portion of the device node in devnode tree 50 representing the assigned configuration of its device to determine which resources have been allocated for the device. For Plug and Play cards, the assigned resources for a given device may change from one boot to the next, or even while computer system 10 is running (dynamically). Logical configurations describe the various configurations that are valid for a given piece of hardware. Information about the state of a device, such as whether it is disabled or configured, is maintained by configuration manager 20 in each device node in devnode tree 50. Drivers can query this information by querying configuration manager 20 for the infomiation. When a driver is loaded for a specific device node, it registers with configuration manager 20, passing an entry point for the device that will be called to assign or change hardware configurations.
  • a device driver or other component cannot access devnode tree 50 or the device nodes directly, it can retrieve information about the identity of a device node and carry out tasks that retrieve and set information in the device node.
  • Configuration manager 20 provides these services to carry out tasks on a device node.
  • device drivers and other components can store information about a given device node in registry 40 as well as retrieve information about a device node stored in registry 40 by configuration manager 20.
  • a device loader loads and manages device drivers and enumerators for a given device node. Device loaders are typically used when devices are managed by various layers of device drivers. The device loader coordinates the work of the various layers and carries out general configuration tasks that apply to all device drivers.
  • a device loader can be associated by configuration manager 20 with a given device node.
  • the device loader can also load an enumerator and device driver for the given device node or any child device nodes.
  • Other services include retrieving and assigning private values to device nodes and retrieving the device descriptor block for any dynamically loaded virtual device associated with a device node.
  • Arbitrators are the components that assign ownership of various resources, such as IRQs and I/O ports. Resource arbitrators resolve resource conflicts between devices. An arbitrator reviews a list of requirements for devices and finds the best allocation of resources to satisfy all devices Configuration manager 20 also provides services and messages to support the operation of resource arbitrators
  • the list of requirements identifies the type resources a device 30 needs to successfully operate and any constraints associated with those resources IRQs, I/O ports, DMA channels and memoiy ranges aie examples of types of resources Constraints are often resource mteidependencies, such as a device 30 requiring that it must see IRQ3 and I/O port 02F8 m combination in order to operate successfully
  • a logical configuration is a description of the resources required by a device 30 to operate successfully Any given device 30 can have several possible logical configurations
  • Configuration manager 20 uses the logical configurations of a device 30 to determine how to allocate resources among competing devices
  • Configuration manager 20 provides services that device drivers, enumerators, and other components can use to examine and create logical configurations
  • a resource descriptor describes the resources m a logical configuration There are resource descriptors for memory, I/O ports, DMA channels, and IRQs Other resource descriptors can be created as needed to identify other types of resources available to devices
  • the memory resource descriptor identifies memory address ranges This descriptor contains a MEM_DES structure that describes a memory resource and an array of MEM_RANGE structures that identify the possible memory configurations for each device
  • the I/O port resource descriptor identifies I/O port address ranges It contains an IO_DES structuie that describes the I/O port resource and an array of IO_RANGE structures that identify the possible port configurations
  • the DMA channel resource descriptor identifies a set of DMA channel alternatives This desc ⁇ ptor is a DMA_DES structure that identifies the DMA channels that the device can use Finally, the IRQ resource desc ⁇ ptor identifies a set of
  • IRQ alternatives It ts a IRQ_DES structure that identifies the IRQs the device can use and whether the IRQ can be shared
  • the IOR_Ahas and IOR_Decode values specify the port aliases to which a device responds
  • a port alias is an address that a device 30 responds to as if it were the actual address of an I/O port
  • some cards will actually use additional ports for different purposes, but use a decoding scheme that makes it seem as though they were using aliases; for example, an ISA card may decode 10 bits and require 03C0h. This card would need to specify an IOR_Alias offset of 04h and a IOR_Decode of 3 (no aliases are used as actual ports).
  • the alias field can be set to zero to indicate that no aliases are required; in this case, the decode field is ignored.
  • the IOR_Alias value would be the same and the IOR_Decode value would be OFh, indicating that bits 11 and 12 of the port address were significant.
  • the allocation is for all of the ports (PORT[i] + (n*alias*256)) & (decode*256
  • a range list is a sorted list of I/O port or memory address ranges (in DWORD form) in which no two ranges overlap.
  • Range list services that manage I/O and memory resources use the range list services to discover whether a given I/O or memory range conflicts with any other range. These services detect attempts to create range lists containing overlaps and either fail or create merged ranges where there would have been overlaps. Each range must specify a contiguous range of addresses, but the range lists itself can contain multiple ranges, none of which necessarily need to be contiguous with any other range in the list.
  • configuration manager 20 finds workable configurations for all devices 30 of computer system 10 so that each device 30 can use its assigned IRQ number, I/O port addresses, and other resources without conflict with other devices. Configuration manager 20 also helps monitor computer system 10 for changes in the number and type of devices 30 present and manages the reconfiguration of devices 30 as needed when changes take place. To create and maintain the configuration, configuration manager 20 works in conjunction with enumerators, resource arbitrators, device loaders, and device drivers. It provides services and messages that these components use to cany out their configuration tasks. Table III, below, shows a list of some of the services provided by configuration manager 20 and a description of each of these services.
  • CONFIGMG_Create_DevNode Adds a device node to the hardware tree.
  • CONFIGMG_Disable_DevNode Disables a device node in the hardware tree.
  • CONFIGMG_Enable_DevNode Enables a device node in the hardware tree.
  • CONFIGMG_Query_Remove_SubTree Checks whether a device node and its progeny can be removed.
  • Figs. 2a and 2b are flow diagrams of a process consistent with the present invention for removing and inserting devices in computer system 10 while in operation for devices having not fully "plug and play" enabled drivers.
  • This process can be implemented as a software program, a hardware device wired to perform the process, such as a programmable memory, firmware or processor, or some combination thereof.
  • configuration manager 20 when computer system 10 is booted up, configuration manager 20 generates devnode tree 50 using the enumerators, device nodes, device drivers and registry 40 (step 110).
  • a user of computer system 10 can request that a device currently present in computer system 10 be exchanged or swapped for a different device (step 112).
  • a user can query computer system 10 through a windows- type interface or any other type of interface consistent with the operating system being utilized by computer system 10.
  • the user can specify the device to be removed and the new device to be inserted. Alternatively, if no device is being removed, then the user can merely specify the device being inserted.
  • configuration manager 20 makes a call to a driver for the controller of the device the user has requested to remove (step 114).
  • the device controller can be, for example, an IDE controller if the device to be removed is a hard drive, or a floppy controller if the device to be removed is a floppy driver. Other controllers are also possible, depending upon the type of device being removed.
  • the driver for the device controller determines if the device to be removed is currently in use (step 116). For example, if the device is a disk drive, the driver would determine if a file on the drive is currently open. To make the determination, a CONFIGMG_Query_Remove_SubTree call or query can be made. In the example of a disk drive, the disk drive can be accessed through several layers of drivers, such as a file system driver, a disk drive driver and a disk controller driver. Although the disk controller driver may be unaware of a file open on the disk drive, it can forward the query regarding the status to other driver layers which can make the determination. If the device is currently in use, the user is notified through the interface that the device cannot be removed (step 118).
  • the device is determined to be cu ⁇ ently in use if in response to the query, a CR_REMOVE- VETOED indication is returned.
  • a message may be provided to the user to close the file and retry the exchange after the file is closed.
  • the user is notified via the interface that the exchange can go forward (step 120).
  • the device is not in use if the indication returned is CR_SUCCESS.
  • configuration manager 20 removes all the device nodes from devnode tree 50 associated with the device controller to be removed and all the devices controlled by the device controller, including the device to be removed (step 122). This can be done using the CONFIGMG_Remove_SubTree service. As a result of this operation, all the drivers and drive letters related to the removed device nodes are unloaded from computer system 10. For example, the removal of the device nodes for a floppy disk drive and its controller would remove their associated drivers and drive letter, such as the "a" drive.
  • the devices being exchanged are controlled by the same controller, such as a CD-ROM and a hard drive which are both controlled by an IDE controller, then only the device node for that controller is removed. However, if the devices being exchanged are controlled by different controllers, then it is necessary to remove the device node for both controllers. If a new device is being inserted without removing another device, it is only necessary to remove the device node for the controller that controls the new device.
  • the signals transmitted between the device to be removed and its controller are isolated (step 124).
  • a circuit may be integrated into the controller or may be added to computer system 10 between the controller and the device to be removed.
  • This signal isolation circuit can be, for example, a switching device, which blocks the transmission of signals between the controller and the associated device to be removed when switched off.
  • the switch control for the signal isolation circuit would be responsive to an indication that the device could be exchanged.
  • the signal isolation is not required, it is preferably included to avoid possible damage to the controller and the device to be removed. In the event that the devices being exchanged are controlled by different controllers, it would also be necessary to isolate the signals for the controller of the device to be inserted. The isolation of the signals for the controller of the device to be inserted is also necessary if the device to be inserted is not being exchanged for another device.
  • the device being removed is powered off (step 126). Once the signals have been isolated and the device has been powered off, the user can remove the device from computer system 10 (step 128).
  • the user can insert the new device (step 130).
  • an indication may be provided to the user through the interface that computer system
  • the user Before powering on the new device and reconnecting the isolated signals, the user can provide an indication via the interface that the new device has been inserted.
  • a sensor circuit may be included in computer system 10 to sense or determine that the new device has been inserted, and provide the indication that the new device has been inserted.
  • the new device is powered on (step 132) and the isolated signals from the aforementioned controller are reconnected to the new device (step 134).
  • configuration manager 20 then instructs an enumerator to enumerate or identify the controller for the newly added device (step 136). This enumerator would correspond to the bus to which the controller for the new device is connected. The enumeration can be done using the
  • CONFIGMG_Reenumerate_DevNode system call By re-enumerating the controller, the controller for the new device is located and its device node is added to devnode tree 50 (step 138). If the devices being exchanged are controlled by different controllers, then the controller for the removed device is also re-enumerated.
  • the driver corresponding to the controller is also initialized (step 140).
  • the devnode for the controller can include information regarding the location of the driver for the controller.
  • the driver for the controller locates the enumerator associated with the controller, which enumerates the new device as being connected to that controller (step 142)
  • the device node corresponding to the new device is also added to devnode tree 50 (step 144)
  • computer system 10 is able to recognize and use the new device as if the new device had been installed at bootup
  • Enumerators can be associated with a particular device node, such as device nodes for busses or device controllers
  • at least one enumerator is associated with the root node of devnode tree 50
  • Configuration manager 20 uses this enumerator associated with the root node of devnode tree 50 to begin the enumeration process at start-up
  • the enumeration process progresses m the same manner regardless of whether the enumerator is associated with the root node, a parent node or a child node
  • Fig 3 shows a flow diagram of an enumeration process consistent with the present invention
  • configuration manager 20 or a device driver associated with a device node determines whether a device node includes an associated enumerator (step 210) If not, then that device node cannot have any child nodes and associated devices to enumerate and invoke drivers therefor On the other hand, if configuration manager 20 or the device driver determines that the device node includes an enumerator, the enumerator is invoked (step 212) The invoked enumerator then searches for any devices that are associated with or controlled by the device of the corresponding device node (step 214) If such a device is located, the enumerator searches registry 40 for an entry corresponding to the located device (step 216) If no entry corresponding to the located device is found in registry 40, a module called a device installer creates a new entry in registry 40 for the located device (step 218).
  • the enumerator adds the device node of that entry to devnode tree 50 (step 220).
  • the device node for the located device added to devnode tree 50 is included as a child node to the device node having the enumerator which found the located device. For example, if the enumerator for the device node of an IDE controller locates a hard drive, the device node for the hard drive would be added as a child node to the device node for the IDE controller in devnode tree 50.
  • the enumerator also identifies the device driver for the located device based on information in the device node (step 222) and uses this information to invoke the device driver (step 224). The process then repeats itself.
  • Fig. 4 shows a block diagram of a device exchanger 70 consistent with the present invention.
  • Device exchanger 70 may be implemented as a software program, a hardware device, such as a programmable memory, firmware or processor, or some combination thereof.
  • Device exchanger 70 can be included as part of a computer system, such as computer system 10 shown in Fig. 1. For example, if implemented as a software program, device exchanger can be loaded into a memory of computer system 10 when activated.
  • device exchanger 70 includes a query module 72, a remove module 74, an isolation and power module 76 and an enumerate module 78. These modules can be loaded into a memory of computer system 10 while computer system 10 is in operation.
  • a user of computer system 10 in Fig. 4 can make a request using an input device to exchange a device 30 installed in computer system 10 for another device.
  • This request is received by query module 72 of device exchanger 70, which determines whether the device to be removed is currently being accessed (step 116 of Fig. 2a). If so, query module 72 informs the user through an interface, such as a monitor in computer system 10, that the device is currently being used and cannot be removed at that time (step 118 of Fig. 2a).
  • query module 72 informs the user that the exchange is acceptable (step 120 of Fig. 2a).
  • remove module 74 removes the device node for the device and its associated controller from devnode tree 50 (step 122 of Fig 2a) This removal also unloads all the drivers related to the device and the controller and the drive letters for the drive
  • isolation and power module 76 signals the isolation circuit, not shown, to isolate the signals which are transmuted between the device being removed and the controller (step 124 of Fig 2a) Isolation and power module 76 also powers off the device being removed (step 126 of
  • isolation and power module 76 receives an indication that the newly added device has been inserted, powers on the newly added device and signals the isolation circuit to reconnect the signals transmitted between the controller and the added device (steps 132 and 134 of Fig 2b)
  • Enumerate module 78 which also receives the indication that the newly added device has been inserted, then locates the controller for the newly added device and adds the device node for the controller into devnode tree 50 (steps 136 and 138 of Fig 2b) This controller may be the same controller or a different controller than the controller for the removed device
  • the device d ⁇ ver associated with the device node for the controller is initialized and invokes the enumerator associated with the controller, which locates the newly added device and adds its device node to devnode tree 50 (steps 140, 142 and 144 of Fig 2b) At this point, the newly added device is fully accessible to the rest of computer system 10

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne un système destiné à l'échange de dispositifs installés dans un système informatique permettant aux utilisateurs d'échanger des dispositifs pendant que le système informatique est allumé ou qu'il est en état de veille. Ce système est capable de reconnaître, d'accéder au dispositif nouvellement ajouté et de l'utiliser sans qu'il soit nécessaire de redémarrer ou de réinitialiser le système informatique.
PCT/US2000/005378 2000-03-02 2000-03-02 Appareil et procede permettant l'echange de dispositifs pendant que l'ordinateur est allume WO2001065365A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/US2000/005378 WO2001065365A1 (fr) 2000-03-02 2000-03-02 Appareil et procede permettant l'echange de dispositifs pendant que l'ordinateur est allume
CN00819275.8A CN1199102C (zh) 2000-03-02 2000-03-02 在计算机运行中交换设备的装置与方法
JP2001563993A JP2003525494A (ja) 2000-03-02 2000-03-02 コンピュータの動作中に装置をスワップするための装置および方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2000/005378 WO2001065365A1 (fr) 2000-03-02 2000-03-02 Appareil et procede permettant l'echange de dispositifs pendant que l'ordinateur est allume

Publications (1)

Publication Number Publication Date
WO2001065365A1 true WO2001065365A1 (fr) 2001-09-07

Family

ID=21741107

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/005378 WO2001065365A1 (fr) 2000-03-02 2000-03-02 Appareil et procede permettant l'echange de dispositifs pendant que l'ordinateur est allume

Country Status (3)

Country Link
JP (1) JP2003525494A (fr)
CN (1) CN1199102C (fr)
WO (1) WO2001065365A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008007316A2 (fr) * 2006-07-10 2008-01-17 Koninklijke Philips Electronics N.V. Procédé d'installation de logiciel destiné à permettre une connexion d'un téléphone à un réseau interconnecté
CN101931576A (zh) * 2010-07-21 2010-12-29 中兴通讯股份有限公司 一种无线接入设备及方法
EP2390786A1 (fr) * 2009-01-26 2011-11-30 Fujitsu Limited Processeur d'informations doté d'une fonction de changement de configuration, procédé de changement de configuration de système et programme de changement de configuration de système
US8595405B2 (en) 2008-02-18 2013-11-26 Hewlett-Packard Development Company, L.P. Systems and methods of communicatively coupling a host computing device and a peripheral device

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7574534B2 (en) * 2006-05-23 2009-08-11 International Business Machines Corporation Method for using device enumeration information to identify an operating system running on a computer system
CN106844260A (zh) * 2016-12-16 2017-06-13 广州致远电子股份有限公司 一种基于树形拓扑结构的设备管理方法
CN106844261A (zh) * 2016-12-19 2017-06-13 杰发科技（合肥）有限公司 在恢复模式下实现热插拔的方法及设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5781798A (en) * 1993-12-30 1998-07-14 International Business Machines Corporation Method and apparatus for providing hot swapping capability in a computer system with static peripheral driver software
US5794032A (en) * 1996-04-15 1998-08-11 Micron Electronics, Inc. System for the identification and configuration of computer hardware peripherals
US5793979A (en) * 1994-05-27 1998-08-11 Microsoft Corporation System for allocating the resources of a computer system

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6012103A (en) * 1997-07-02 2000-01-04 Cypress Semiconductor Corp. Bus interface system and method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5781798A (en) * 1993-12-30 1998-07-14 International Business Machines Corporation Method and apparatus for providing hot swapping capability in a computer system with static peripheral driver software
US5793979A (en) * 1994-05-27 1998-08-11 Microsoft Corporation System for allocating the resources of a computer system
US5794032A (en) * 1996-04-15 1998-08-11 Micron Electronics, Inc. System for the identification and configuration of computer hardware peripherals

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Method to Dynamically Bind Device Drivers", IBM TECHNICAL DISCLOSURE BULLETIN., vol. 28, no. 2, July 1985 (1985-07-01), IBM CORP. NEW YORK., US, pages 617, XP002153353, ISSN: 0018-8689 *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008007316A2 (fr) * 2006-07-10 2008-01-17 Koninklijke Philips Electronics N.V. Procédé d'installation de logiciel destiné à permettre une connexion d'un téléphone à un réseau interconnecté
WO2008007316A3 (fr) * 2006-07-10 2008-06-19 Koninkl Philips Electronics Nv Procédé d'installation de logiciel destiné à permettre une connexion d'un téléphone à un réseau interconnecté
US7958207B2 (en) 2006-07-10 2011-06-07 Koninklijke Philips Electronics N.V. Method of installing software for enabling a connection of a phone to an interconnected network
US8595405B2 (en) 2008-02-18 2013-11-26 Hewlett-Packard Development Company, L.P. Systems and methods of communicatively coupling a host computing device and a peripheral device
EP2390786A1 (fr) * 2009-01-26 2011-11-30 Fujitsu Limited Processeur d'informations doté d'une fonction de changement de configuration, procédé de changement de configuration de système et programme de changement de configuration de système
EP2390786A4 (fr) * 2009-01-26 2012-08-08 Fujitsu Ltd Processeur d'informations doté d'une fonction de changement de configuration, procédé de changement de configuration de système et programme de changement de configuration de système
CN101931576A (zh) * 2010-07-21 2010-12-29 中兴通讯股份有限公司 一种无线接入设备及方法
US8689291B2 (en) 2010-07-21 2014-04-01 Zte Corporation Wireless access device and method
CN101931576B (zh) * 2010-07-21 2015-04-01 中兴通讯股份有限公司 一种无线接入设备及方法

Also Published As

Publication number Publication date
JP2003525494A (ja) 2003-08-26
CN1199102C (zh) 2005-04-27
CN1437726A (zh) 2003-08-20

Similar Documents

Publication Publication Date Title
US6496893B1 (en) Apparatus and method for swapping devices while a computer is running
US5748980A (en) System for configuring a computer system
US5768542A (en) Method and apparatus for automatically configuring circuit cards in a computer system
US7308511B2 (en) System for allocating resources in a computer system
US6003097A (en) System for automatically configuring a network adapter without manual intervention by using a registry data structure maintained within a computer system memory
US5761448A (en) Physical-to-logical bus mapping scheme for computer systems having multiple PCI bus configuration
US10445258B1 (en) Method for creation of device drivers and device objects for peripheral devices
US5819107A (en) Method for managing the assignment of device drivers in a computer system
US7363480B1 (en) Method, system, and computer-readable medium for updating the firmware of a computing device via a communications network
US6961791B2 (en) Method for expansion and integration of option ROM support utilities for run-time/boot-time usage
US5920709A (en) Bus interface for IDE device
US5854905A (en) Extensible bios for boot support of devices on multiple hierarchical buses
US5768568A (en) System and method for initializing an information processing system
US6185677B1 (en) Automatic generation of ACPI source language for peripheral resource configuration
US6487608B2 (en) Method for automatically configuring network interface card and capable of randomizing a media access controller address of the network interface card
US5797031A (en) Method and apparatus for peripheral device control by clients in plural memory addressing modes
US6934956B1 (en) Method and apparatus for installing an operating system
EP1774435B1 (fr) Procede et appareil pour la detection de materiel dans un systeme de traitement de donnees
JPH04263349A (ja) コンピュータにｂｉｏｓをロードする装置及び方法
JP2003519837A (ja) 最小限の変更で、既存の回路およびドライバを使用してホット・スワップ機能を提供するシステムおよび方法
WO1996021899A1 (fr) Compatibilite amont pour les systemes prets a l'emploi
US20040267708A1 (en) Device information collection and error detection in a pre-boot environment of a computer system
JPH10222453A (ja) コンピュータ・システム内でバス・アドレスを動的に変換する方法及びシステム
Shanley Plug and play system architecture
WO2001065365A1 (fr) Appareil et procede permettant l'echange de dispositifs pendant que l'ordinateur est allume

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CN JP SG

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
ENP Entry into the national phase

Ref country code: JP

Ref document number: 2001 563993

Kind code of ref document: A

Format of ref document f/p: F

WWE Wipo information: entry into national phase

Ref document number: 008192758

Country of ref document: CN

122 Ep: pct application non-entry in european phase