Electrical computers and digital data processing systems: input/ – Access arbitrating
Reexamination Certificate
1999-05-14
2001-04-10
Ray, Gopal C. (Department: 2181)
Electrical computers and digital data processing systems: input/
Access arbitrating
C709S241000
Reexamination Certificate
active
06216196
ABSTRACT:
FIELD OF THE INVENTION
The present invention is directed to a system and method to arbitrate control commands issued by multiple device drivers to a single multifunction device, thereby preventing conflicting control commands from degrading the performance of the multifunction device.
BACKGROUND INFORMATION
Device drivers are commonly used in computer systems as the lowest level software component to communicate with hardware devices. Typically, these device drivers are associated with the devices they control in a one-to-one relationship. For example, a serial port driver is associated with the data/fax modem of the computer, an Integrated Switched Digital Network (ISDN) driver is associated with the ISDN interface device, and yet another driver provides the interface to a Wide Area Network (WAN) data interface device. In such an arrangement, each dedicated driver performs the start-up, shutdown, maintenance, and functional operations for the hardware device.
Due to advances in technology, it has become possible to integrate several hardware devices into a single multifunction device. For example, a single hardware device may be capable of performing one or all of the functions of a data/fax modem, ISDN, and WAN interface. Such multifunction devices have several advantages over multiple single function devices, including reduced cost, smaller size, reduced load on the host system and easier installation. However, to remain compatible with legacy applications these multifunction devices still require dedicated drivers for each function, e.g., serial port, ISDN, WAN, etc. It is preferable to keep each device driver functioning independently which results in multiple device drivers sending commands to the single hardware device. Thus, there exists the possibility that the commands sent by one driver may conflict with the commands sent by another driver, resulting in a system malfunction. For example, one driver may send a command to shutdown the hardware device while other independent drivers are using the device. Another example is where one driver attempts to run a diagnostic test that requires exclusive access to the multifunction device to ensure valid results, and another driver attempts to access the multifunction device during this diagnostic test. There are numerous conflicts that can occur with multiple device drivers accessing a single multifunction hardware device.
FIG. 1
illustrates an exemplary prior art computer system
100
having a plurality of device drivers, i.e., device driver A
110
, device driver B
120
, and device driver C
130
being connected to a multifunction device
140
. In operation, computer system
100
may request a first function to be carried out by multifunction device
140
. When a function is requested, computer system
100
directs the driver corresponding to the requested function to send commands to multifunction device
140
in order for it to perform the requested function. For example, if function A is requested, computer system
100
directs device driver A
110
to send commands to multifunction device is
140
to perform function A. However, as described above, some device drivers may issue conflicting commands to the multifunction device. Conflicting commands being sent from different drivers may result from numerous scenarios in a system with a multifunction device. For example, while multifunction device
140
is being directed to perform function A by device driver A
110
, computer system
100
may direct device driver B
120
to issue commands to multifunction device
140
to perform function B. Part of the commands issued by device driver B
120
may be device initialization commands which conflict with the commands being issued by device driver A
110
. In such cases, the multifunction device may not perform some or all of the requested functions because of the conflict.
One possible solution to this problem is to combine the device drivers into a single multifunction driver, and thereby prevent conflicting commands using programmatic methods. However, this approach may require that a large portion or all of the software code of the existing drivers be rewritten to be able to work as a single driver. This solution also reduces the modularity of the software. A single combined driver is larger and more complex, and therefore is more difficult to create, test, maintain, and upgrade. Combining multiple drivers into a single multifunction driver can increase the total number of drivers required, when all the different permutations and combinations of drivers and multifunction devices are considered. Thus, it is highly desirable to keep the drivers separate. In some systems, such as Microsoft NT™, it may not even possible to combine drivers together due to restrictions imposed by the NT™ operating system environment.
When a multifunction device is implemented into the host system's bus architecture, for example, the Peripheral Component Interconnect (PCI) architecture, in addition to the device drivers, an interface for the bus architecture may be required. Normally, when multiple devices are combined on a single hardware card, a separate interface is required for each device on the card. However, in some multifunction devices a single processor is used to perform the protocol processing for all devices, for example, a modem, PSTN, and WAN. This approach is advantageous because it reduces hardware costs and improves the efficiency of inter-device communications by passing information between the devices on the same board, instead of passing it through the host system. The conventional solution for such a multifunction device is to create a new interface for all the functions on the device.
FIG. 2
illustrates an exemplary prior art multifunction device
180
having an interface
170
connected to the host system bus architecture
160
. Additionally, an associated device driver
190
to drive the multifunction device is also created. As described above, the problem with this arrangement is that it does not keep each device driver separate. Such device drivers are difficult to create and support, host systems may not recognize these types of device drivers and the host system may not be capable of loading these device drivers because of conflicts they have with the way individual drivers are used in the host environment.
SUMMARY OF THE INVENTION
The present invention discloses an arbitration mechanism that arbitrates the control commands issued by multiple device drivers to a single multifunction device. The arbitration mechanism prevents the multifunction device from receiving conflicting commands by allowing an individual device driver to request exclusive access to the multifunction device. When a device driver requests exclusive access, the other device drivers finish any critical operations they have remaining with the multifunction device and discontinue accessing the multifunction device so that the requesting device driver may have a period of exclusivity with the multifunction device. When the period of exclusivity is over, each of the multiple device drivers may equally access the multifunction device, until another device driver requests exclusive access.
The arbitration mechanism of the present invention allows the device drivers for the multifunction device to be developed separately and only requires minimal changes to implement the mechanism into existing drivers. Thus, device driver software may maintain its modularity. The arbitration mechanism of the present invention is also extrinsic, meaning that it's implementation is independent of the function of the device drivers or devices. The arbitration mechanism of the present invention may be implemented either in hardware or software.
Additionally, the present invention provides a separate interface corresponding to each device driver type that the multifunction device can support. In this manner, the multifunction device appears to the host system as an individual device for each function that the multifunction device is capable of performing.
REFER
Elwell Don
Sienicki James
Zimmermann Christopher
Ariel Corporation
Kenyon & Kenyon
Ray Gopal C.
LandOfFree
System and method for multiple device drivers to arbitrate... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for multiple device drivers to arbitrate..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for multiple device drivers to arbitrate... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2554972