Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-04-04
2001-04-03
Banankhah, Majid A. (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06212574
ABSTRACT:
BACKGROUND OF THE INVENTION
1. The Field of the Invention
The present invention relates to the interaction between software components in the user mode of a computer operating system and software components in the kernel mode of a computer operating system. More specifically, the present invention relates to the proxy of software components in the kernel mode of a computer operating system by software components in the user mode of a computer operating system.
2. The Prior State of the Art
Although computers were once a rather obscure oddity used primarily by scientists, today computers have become an integral part of mainstream society. Almost daily, computers are changing the way that many people live, work, and play. The widespread proliferation of computers has opened up vast new uses and applications that were unheard of only a few short years before. Today, computers are not only a powerful tool used by many businesses, but also a source of recreation and enjoyment for millions.
As computers have evolved and have been applied to an ever increasing array of uses, they have also become more powerful, and sophisticated. Computers today have complex operating systems that provide a robust environment for various application programs and intuitive user interfaces. Such operating systems normally have different operational levels or “modes,” depending on the level of sophistication of the operating system and the security features that are implemented by the operating system. For example, normal application programs typically run at the lowest priority and have a full complement of security devices in place to prohibit interference with other applications, or with other layers of the operating system. Hardware and other services provided by the operating system are only accessed through controlled interfaces or mechanisms which limit the ability of a single user application to “crash” the system. This lowest priority mode is generally referred to as “user” mode and is the mode that most computer users are familiar with.
In operating systems that provide more than one layer or mode, applications are typically not permitted to directly access computer hardware. The operating system, rather, provides interfaces through which an application program in user mode may access hardware or other services provided by the operating system. Thus, a layer of software typically exists on top of computer hardware in the system. This layer of software is typically referred to as a driver or filter.
Software drivers are normally built to control hardware and provide an interface that can be used to control or access the hardware. Drivers are typically very closely linked to the hardware components they control. For this reason, it is generally desirable to allow drivers to run in a mode with very little overhead. When drivers interface with hardware, they also typically perform many time critical functions. For example, when a driver writes data onto a mass storage device, the driver must ensure that the mass storage device always has sufficient data available to permit the data to be written to the mass storage device without large delays.
Because of the close integration of drivers with their associated hardware and because of the time critical nature of the tasks that many drivers perform, drivers typically run in an operating system mode that has a much higher priority and much lower security protection. This mode is generally referred to as “kernel” mode. Because of the few security protections available in kernel mode, software components running in kernel mode are typically restricted to the most trusted software components. Such software components typically must be thoroughly tested and behave in ways that are absolutely predictable.
Because the general concept of a software driver contemplates controlling specific hardware or providing specific services to user mode applications, drivers are normally developed in isolation from one another and provided by a hardware manufacturer or an operating system provider. For example, software drivers providing a particular type of I/O service associated with an add-in hardware card through a device interface need not communicate with, nor know the existence of, any other driver.
As previously discussed, today, computers are not only a powerful tool used by many businesses, but also a source of recreation and enjoyment for millions. One application area that has been opened up by newer, more powerful personal computers, has been the area of multimedia. Multimedia typically requires processing a stream of data using a sequence of processing functions. The data typically consists of digital samples representing sound or video, and the processing blocks or “filters” may include decompression processing for compressed data, special effects processing, transforms, scaling, rendering processing to convert digital data into analog signals, etc. Processing architectures which connect a series of different filters, each performing a particular function on a given item of data before passing the item of data onto another filter, are typically referred to as streaming architectures. The connected sequence of filters is sometimes referred to as a filter graph.
Referring now to
FIG. 1
, an example system is presented for rendering a stream of sound data from a disk drive so that it may be heard through the speaker according to a prior art model. An amount of data is stored on disk
20
, representing sound in the form of digitized samples. Alternatively, the source of the sound data stream may be digitized information coming from a phone line, digitized information from a network, or other communication packets or sources known in the art.
A kernel mode disk driver
22
, retrieves data from disk
20
under the control of a user mode reader process
24
. Reader process
24
will interact with disk driver
22
using a standard I/O control interface of the operating system and will cause the compressed sound data to be read from disk
20
. As data is retrieved from disk
20
, it is typically placed in buffers allocated in user mode as part of the user mode address space.
When data is retrieved from disk
20
as described above, reader
24
passes the data to decompressor
28
, which will decompress the data and prepare the data for further processing. In the example illustrated in
FIG. 1
, this step is performed entirely in user mode. This subjects the decompression step to the lower priority processing of user mode and also provides the safety mechanisms attendant with user mode execution.
After decompressor
28
has decompressed the data, the data is passed to effects component
30
will operate on the data to provide some special effect. In the example illustrated in
FIG. 1
, effects component
30
has an accompanying effects filter
32
operating in kernel mode. Furthermore, effects filter
32
may utilize effects processor
34
or may perform the desired processing entirely in software. In order to access effects filter
32
, effects component
30
will use the system I/O control mechanism to transfer data and control to effects filter
32
. This results in a kernel mode/user mode boundary transition in order to utilize effects filter
32
. Effects filter
32
will utilize effects processor
34
as appropriate for the function and data presented.
After control and data is transferred from effects filter
32
back to effects component
30
, the data is transferred to sound rendering block
36
. Sound rendering block
36
will transfer control and data to sound rendering driver
38
. This causes another mode transition as the kernel mode/user mode boundary is crossed. Sound rendering driver
38
in turn controls sound card
40
in order to render the data, as processed and filtered, as sound through speaker
42
.
Operation of the filter graph including reader
24
, decompressor
28
, effects component
30
, and sound rendering block
36
may be under the control or direction of a client or controlling process. In
FIG. 1
, such a controlling process is il
O'Rourke Thomas J.
Shaw George H. J.
Woodruff Bryan A.
Banankhah Majid A.
Bullock, Jr. Lewis A.
Microsoft Corporation
Workman & Nydegger & Seeley
LandOfFree
User mode proxy of kernel mode operations in a computer... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with User mode proxy of kernel mode operations in a computer..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and User mode proxy of kernel mode operations in a computer... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2545331