Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1999-09-24
2003-07-15
Coulter, Kenneth R. (Department: 2142)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C370S235000, C709S220000, C709S238000, C709S246000, C710S048000, C710S052000, C712S225000
Reexamination Certificate
active
06594709
ABSTRACT:
BACKGROUND OF THE INVENTION
A typical device driver is a computer program that enables computer hardware or a computer application to use or communicate with a particular device (e.g., a printer or monitor). Some specialized computer systems use device drivers to perform specialized operations. For example, in a network, a data communications device may use communications port device drivers to receive and send data (e.g., packets, cells, etc.) using input and output ports.
In general, a traditional device driver is monolithic in structure. That is, the device driver typically comprises a single series of instructions which the processor executes as a single process in order to communicate with a particular device. As the processor executes through this series of instructions, the processor serially performs a mixture of primary operations and administrative operations. For example, in a data communications device, a primary operation for a communications port device driver may be to receive data from an input port and/or to send data on an output port. Some administrative operations of the communications port device driver may be to check for requests, and to respond to such requests by (i) setting up or destroying connections, (ii) gathering statistical information, (iii) changing the manner in which resources are allocated for data transfer, and/or (iv) configuring the device port (an input or output port). Generally, the code for such administrative operations is interleaved with code for the primary operations.
In one arrangement, the processor continuously cycles through the series of instructions by jumping back (or looping back) to the beginning of the series once the end of the series is reached in order to re-perform the primary and administrative operations on a continuous basis. In another arrangement, the device driver executes through the series of instructions a fixed number of times (e.g., once) in response to a triggering event such as a wakeup notification or an interrupt from the operating system, and then suspends execution until awaken by another event.
It is common for device driver developers to further develop and improve their device drivers over time. Subsequent device driver versions typically include bug fixes (i.e., solutions to device driver defects), optimizations, and/or new features. For example, when a new version of a device is introduced to the market, the new version typically includes a new device driver designed and developed to take advantage of any new improvements or enhancements in the new version of the device.
SUMMARY OF THE INVENTION
Prior to releasing a device driver for normal use, device driver developers typically test their device drivers to identify and correct any defects (or bugs). A newly discovered defect may not have existed in earlier versions of the device driver, or may have existed but not posed a problem in the earlier versions.
The inventors of the present invention have observed that, in certain device drivers (e.g., communication port device drivers for data communications devices), bugs rarely occur in the portions of the device driver that direct the processor to perform the device driver's primary operations (e.g., receiving data from an input port or sending data to an output port). Rather, the inventors have observed that, in these particular device drivers, bugs are more likely to occur in the portions related to administrative operations (e.g., setting up or tearing-down connections, gathering statistics, and changing resource allocation parameters).
One explanation for this tendency may be that the portions of these device drivers that perform the rudimentary or primary operations are generally not susceptible to new defects. This may be because the code for the primary operations is typically mature (e.g., well developed), fairly simple, and/or short. As such, any bugs that may have existed in the past probably have long been fixed. Furthermore, it may be unlikely that future modifications are needed for these portions of code since these portions are often heavily scrutinized and tested early on in the life cycle of the device driver. Accordingly, if problems are to arise, it is likely that such problems will exist in the portions of code dealing with the administrative operations of the device drivers.
Unfortunately, when a device driver is monolithically structured as a single series of instructions for performing both primary and administrative operations (as is generally the case in a conventional device driver), and when the device driver operates as a single process, bugs in portions of code that deal with administrative operations may affect the portions of code that handle the primary operations. In particular, improper processing of a code portion for an administrative operation may lead to improper processing of a code portion for a primary operation. For example, in a conventional device driver for a data communications device, conventional driver code for a statistics gathering operation (i.e., an administrative operation of the port driver) may include a defective branch operation and interfere with conventional driver code for accessing buffered data received on an input port or destined for an output port (i.e., a primary operation). Although the conventional driver code for accessing the buffered data may have been flawless, the accessing operation can fail due to improper operations of the conventional statistics gathering driver code.
Similarly, an improper memory access by the conventional statistics gathering driver code may lead to improper operation of the conventional driver code for accessing the buffered data. For example, the conventional statistics gathering code may inadvertently overwrite a critical memory location (e.g., a particular control register) used by the conventional accessing code (i.e., the primary operation driver code for accessing the buffered data) rather than read from that location. Such an improper memory access by the conventional statistics gathering code (code for an administrative operation) may cause improper operation of the conventional accessing code (code for the primary operation).
In contrast to conventional device drivers that have code for primary and administrative operations integrated into a monolithic structure that operates as a single serial process, the invention is directed to techniques for sending and receiving data using a device driver that is arranged to prevent improper operation of a non-primary routine (e.g., an administrative operation) from causing improper operation of a primary routine (e.g., a data transfer operation). Such an arrangement enables the primary routine to continue to operate properly after a failure or improper operation of the non-primary routine.
One embodiment of the invention is directed to a data communications device for transferring data. The data communications device includes a port that couples to a network, and a processor coupled to the port. The data communications device further includes memory, coupled to the processor, that stores a device driver. The device driver has a first set of instructions that directs the processor to perform a data transfer routine that moves data between the port and the memory, and a second set of instructions that directs the processor to perform an administrative routine. The first and second sets of instructions are arranged to prevent improper operation of the administrative routine from causing improper operation of the data transfer routine.
Preferably, the administrative routine of the device driver includes at least one of the following routines: a state change routine to cause a state change in the device driver when the device driver operates in the data communications device, a control routine to cause a control change in the device driver when the device driver operates in the data communications device (e.g., storing a hardware address to perform MAC address filtering), a resource management routine to manage a device driver resource, a statistic
Agasaveeran Saravanan
Agrawal Rajesh
Balestriere James
Berl Steven
Cox Gordon
Chapin & Huang , L.L.C.
Cisco Technology Inc.
Coulter Kenneth R.
Huang, Esq. David E.
Nguyen Hai V.
LandOfFree
Methods and apparatus for transferring data using a device... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Methods and apparatus for transferring data using a device..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Methods and apparatus for transferring data using a device... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3008711