Abstract:
A method and system for communicating between operating systems using an interface that provides an abstraction layer of one of the operating systems. At least one channel is created that allows messages and data packets to be transferred between the operating systems without converting the data into an operating system&#39;s format before sending the data to another operating system. The interface provides commands for each of the operating systems to use to communicate with each other and provides the flexibility to create platform specific extensions to the provided commands. The interface also allows a first operating system to demand load devices on a second operating system by extending demand load functionality of the second operating system to the first operating system. A second channel is created that is used to only send data and data related control messages on the channel, eliminating the need to distinguish between general control messages and data specific control message.

Description:
TECHNICAL FIELD 
     This invention relates generally to communication and data transfer between operating systems and, more particularly, relates to a system and method for transferring data between operating systems involving an abstraction layer. 
     BACKGROUND OF THE INVENTION 
     Continued advances in computer technology have lead to not only increased performance, but also increased performance expectations by the users of such computer equipment. These increased user expectations extend not only to processing capability, but also to all aspects and peripheral equipment associated with a home or business computing environment. The industry has responded with increased speed for CD ROM drives, communication modems, faster video and audio cards, and even faster processors. However, these advances in performance also increased the computational tasks the computer&#39;s operating system is required to perform to allow users to take the full advantage of these performance enhancements. 
     For example, in areas such as multimedia and audio compression, a technique known as streaming was developed for transferring data so that it can be processed as a steady and continuous stream. Streaming technologies are becoming increasingly important with the growth of the Internet because most users do not have fast enough access to download large multimedia files quickly. With streaming, the data can start to be displayed before the entire file has been transmitted. For streaming to work, the data must be processed as a steady stream and converted to audio or video. If the data isn&#39;t processed quickly enough, however, the presentation of the data will not be smooth. The processing of this data requires a large number of computations that can load down the computer&#39;s operating system, consume a significant amount of the computer&#39;s resources, and incur additional latency. These effects degrade performance. 
     In response, the industry developed operating systems designed specifically to perform these types of computational heavy tasks in order to free up the computer&#39;s resources and reduce latency. The digital signal processor (DSP) is the most prevalent type of processor designed to perform these tasks. It is recognized that DSPs can be used in areas such as video cards, audio cards, telecommunication devices, automotive applications, industrial applications, and any other application where an electronic controller is used. Many of these DSPs are installed as add-ons to a computer. As new advancements and improvements are made, these DSPs are readily changed to handle the computations necessary to support the advancements and improvements. However, it was soon realized that DSPs introduced a new problem in that DSPs have to communicate with the computer&#39;s operating system efficiently to move the data from the computer&#39;s operating system down to the DSP to allow the DSP to perform the computations and then send it back to the computer operating system or on to another device. 
     One prior solution that overcomes the communication problem is where each DSP developed its own interface to the computer&#39;s operating system that is specific to the DSP&#39;s particular operating system. However, while this particular interface is acceptable for that particular DSP, such an interface generally cannot be used with any other DSP as the interface is specific to features of that particular DSP. This required that multiple interfaces be developed, one for each type of DSP. 
     Another solution to the communication problem is the computer operating system providing a fixed driver for the DSP to communicate with the computer operating system. Since the fixed driver may not address all of the functions available through the DSP, this results in limiting the functionality of the DSP to the particular functions provided by the driver. This does not allow users to take advantage of the full capabilities of the DSP. Furthermore, as new features are added to the DSP, the fixed driver cannot support them and new drivers must be created. 
     There therefore exists a need in the art for a system and method that allows different types of operating systems to communicate with each other that can be generalized for all types of operating systems without limiting the capability of either operating system. 
     SUMMARY OF THE INVENTION 
     In view of the above described problems existing in the art, the present invention provides an interface of a computer operating system to enable other operating systems to communicate with the host computer operating system. This interface provides an abstraction layer of a first operating system for DSPs and other operating systems to communicate with the first operating system. Each operating system does not need to know every command of the other operating system. The interface provides basic communication commands for operating systems to use and provides the flexibility to add operating system specific parameters to the basic communication commands to allow additional functionality. In one embodiment, one of the operating systems abstracts the other operating system as a bus transport. 
     The interface enables control channels and data channels to be created to allow data to be passed between the operating systems without having to convert the data into another format. The control channel is used for exchanging control related messages and the data channel is used for transferring data and messages between the operating systems. The interface allows dynamic loading and unloading of tasks on the DSP to enable new tasks to be distributed and used on the DSP. 
     Additional features and advantages of the invention will be made apparent from the following detailed description of illustrative embodiments that proceeds with reference to the accompanying figures. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     While the appended claims set forth the features of the present invention with particularity, the invention, together with its objects and advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings of which: 
     FIG. 1 is a block diagram generally illustrating an exemplary computer system on which the present invention resides; 
     FIG. 2 is a block diagram illustrating data flow between operating systems using the interface of the invention; 
     FIG. 3 is a block diagram illustrating an embodiment of an operating system employing the interface to transfer data between a user mode source and a task on another operating system using an interface; 
     FIG. 4 is a block diagram illustrating data flow between a source residing in user mode on a first operating system, through kernel mode on a first operating system, and to a task residing on a second operating system; 
     FIG. 5 is a block diagram illustrating a portion of a registry entry in an operating system. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Turning to the drawings, wherein like reference numerals refer to like elements, the invention is illustrated as being implemented in a suitable computing environment. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a personal computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. 
     With reference to FIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a conventional personal computer  20 , including a processing unit  21 , a system memory  22 , and a system bus  23  that couples various system components including the system memory to the processing unit  21 . The system bus  23  may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read only memory (ROM)  24  and random access memory (RAM)  25 . A basic input/output system (BIOS)  26 , containing the basic routines that help to transfer information between elements within the personal computer  20 , such as during start-up, is stored in ROM  24 . The personal computer  20  further includes a hard disk drive  27  for reading from and writing to a hard disk, not shown, a magnetic disk drive  28  for reading from or writing to a removable magnetic disk  29 , and an optical disk drive  30  for reading from or writing to a removable optical disk  31  such as a CD ROM or other optical media. 
     The hard disk drive  27 , magnetic disk drive  28 , and optical disk drive  30  are connected to the system bus  23  by a hard disk drive interface  32 , a magnetic disk drive interface  33 , and an optical disk drive interface  34 , respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the personal computer  20 . Although the exemplary environment described herein employs a hard disk, a removable magnetic disk  29 , and a removable optical disk  31 , it will be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories, read only memories, and the like may also be used in the exemplary operating environment. 
     A number of program modules may be stored on the hard disk, magnetic disk  29 , optical disk  31 , ROM  24  or RAM  25 , including an operating system  35 , one or more applications programs  36 , other program modules  37 , and program data  38 . A user may enter commands and information into the personal computer  20  through input devices such as a keyboard  40  and a pointing device  42 . Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit  21  through a serial port interface  46  that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or a universal serial bus (USB). A monitor  47  or other type of display device is also connected to the system bus  23  via an interface, such as a video adapter  48 . In addition to the monitor, personal computers typically include other peripheral output devices, not shown, such as speakers and printers. 
     The personal computer  20  may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer  49 . The remote computer  49  may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the personal computer  20 , although only a memory storage device  50  has been illustrated in FIG.  1 . The logical connections depicted in FIG. 1 include a local area network (LAN)  51  and a wide area network (WAN)  52 . Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet. 
     When used in a LAN networking environment, the personal computer  20  is connected to the local network  51  through a network interface or adapter  53 . When used in a WAN networking environment, the person computer  20  typically includes a modem  54  or other means for establishing communications over the WAN  52 . The modem  54 , which may be internal or external, is connected to the system bus  23  via the serial port interface  46 . In a networked environment, program modules depicted relative to the personal computer  20 , or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used. 
     In the description that follows, the invention will be described with reference to acts and symbolic representations of operations that are performed by one or more computer, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processing unit of the computer of electrical signals representing data in a structured form. This manipulation transforms the data or maintains it at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the computer in a manner well understood by those skilled in the art. The data structures where data is maintained are physical locations of the memory that have particular properties defined by the format of the data. However, while the invention is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that various of the acts and operation described hereinafter may also be implemented in hardware. 
     In accordance with the invention, FIG. 2 shows a representative block diagram of data flow from a source  100  to an endpoint  102  in a first operating system  104 . Between the source  100  and the endpoint  102 , the data is transformed in some manner by operational blocks which are commonly known as filters. The data stream is moved from the source  100  to filter  106 . The filter  106  performs some operation on the data and passes the data to filter  108 . Filter  108  processes the data and the data is moved to the endpoint  102 . In some circumstances, the operating system  104  may pass the data to a filter  110  residing on another operating system  112  through an interface  114  of the invention in order to reduce the overhead on operating system  104  or to have the second operating system perform some function that the second operating system is designed to do efficiently. The operating systems  104  and  112  may be any operating system, including home and business computer operating systems and operating systems contained in peripheral equipment including modems, printers, and audio and video cards. One such operating system wherein the invention can be used is the Windows operating system as provided by Microsoft Corporation. 
     Turning now to FIG. 3, the invention will be described in context to the Windows operating system. The Windows operating system  118  has a kernel mode  122  and a user mode  120 . The kernel mode  122  allows access to all memory and all CPU instructions can be issued. The user mode  120  allows limited access to memory and a limited set of interfaces to CPU instructions. Filters reside in user mode  120  and in kernel mode  122 . Data from an application or an external source or hardware is sent to filters for processing and then sent back to its source or on to hardware or another application or external operating system. FIG. 3 shows a representative example of data flow in the Windows operating system  118 . Filter  124  residing in user mode  120  receives the data, transforms it in some manner and the data is sent to filter  126  for further transformation. Filter  126  transforms the data in some manner and the data is then sent to filter  130  for further transformation. The data could also be sent to filter  128  residing in kernel mode  122  for transformation prior to being sent to filter  130 . Filter  130  does further transformation on the data and the data is sent to filter  134  for further transformation prior to being sent to hardware device  136 . Data may be sent to filter  138  residing on an external operating system  140  for further transformation prior to being sent to filter  134 . It should be noted that the data from an application or an external source or hardware can be sent directly to a filter or hardware device residing in kernel mode. The data can also be sent directly to the external filter  138  from the Windows operating system  118  and then back to a filter or a hardware device or an application or an external source. 
     One form of external operating system  140  that is widely used is Digital Signal Processing (DSP) operating systems. DSPs have been designed specifically to perform computationally heavy tasks, and are typically placed on cards or devices that are installed in computer systems running a host operating system such as Windows. For example, a video card or a sound card employing a DSP and installed in a computer generally has a real-time operating system on the card. It is recognized that DSPs can be used in areas such as video cards, audio cards, telecommunication devices, automotive applications, industrial applications, and any other application where an electronic controller is used. From hereon, the external operating system shall be called a DSP OS. 
     When a computational heavy task is required, the Windows operating system can send the data to the DSP OS to perform the data transformation. 
     Turning now to FIG. 4, the interface of the invention will be described in the context of the Windows operating system and a DSP OS. For the following description, exemplary commands of one embodiment shall be put in parentheses. See appendix  1  for the specific details of the exemplary command. Appendix  1  provides a listing of commands for one specific implementation of the invention. It should be noted that the command is not limited to the specific implementation of this embodiment and the invention is not limited to the commands of appendix  1  or to the Windows operating system or to a DSP OS. 
     When a DSP is first sensed by the Windows operating system  152 , a platform driver  154  is loaded. These platform drivers are provided by the DSP OEM or independent software vendors. The platform driver  154  controls hardware and manages data transfers and messages down to the DSP OS  150 . The platform driver  154  registers with the Windows operating system  152  and, as illustrated in FIG. 5, the Windows operating system  152  creates a tree  156  having identifiers  158  in a registry. These identifiers  158  include a device identification  160  and an interface identification  162  that identifies the tasks the DSP can perform. The registry also includes the pin identifications and pin types of the DSP filters. A portion of this information is obtained from platform driver  154  and the Windows operating system  152  generates the rest of the information as known by those skilled in the art. For example, in one embodiment, pin  0  of the DSP filter has pin ID  0  and may be an input pin of the MP3 type and pin  1  may have pin ID  1  and be an output pin that is 16 bit, 44 kHz stereo. In other embodiments, the DSP filter&#39;s pins may have different pin types. The Windows operating system  152  uses this information to load the appropriate platform driver  154  when an application or external source requests that a task be performed that the DSP has the capability to do. 
     In an alternate embodiment, the DSP OS  150  can also be installed as a bus on the Windows operating system  152  (KsCreateBusEnumObject). This provides the DSP OS  150  the capability to dynamically load other tasks it may require when performing the DSP task  164 . This dynamic loading is known as demand loading. To provide the DSP OS  150  with demand load capability, the platform driver  154  requests the Windows operating system  152  to extend the capability to the platform driver  154  when the platform driver  154  is loaded (KsCreateBusEnumObject). Once this capability is provided, the Windows operating system  152  provides the necessary support to the platform driver  154  to dynamically load other devices the DSP OS  150  requests when the DSP OS  150  is performing the DSP task  164 . 
     When a data source  166  requests the Windows operating system  152  to perform some DSP task  164  that resides on the DSP OS  150 , the Windows operating system  152  loads a driver  168  that corresponds to the interface identification  162  (FIG.  5 ). The driver  168  serves as an interface between drivers residing on the user mode  120  and the Windows operating system  152 . A user mode driver  170  is also loaded by the Windows operating system  152  to provide an interface between the data source  166  and the driver  168 . The driver  168  loads an interface  172  that provides an interface between the Windows operating system and the DSP operating system. The user mode driver  170  and the driver  168  can be provided by independent software vendors and operating system OEMs. 
     Once the interface  172  is loaded, the driver  168  commands the interface  172  to create a control channel  180  (CreateDSPControlChannel). The control channel  180  is used to communicate with the DSP task  164  to perform general transactions. The interface  172  sends a load task message (KSDSP_MSG_LOAD_TASK) to the platform driver  154  to load the control channel  180 . The platform driver  154  provides a task context object which identifies the DSP task  164  and which is opaque to all layers except the platform driver. The task context object has an associated control channel  180 . The interface  172  then queries the platform driver  154  for the control channel identifiers and receives them (GetControlChannel). The control channel identifiers are opaque to other drivers and objects of the Windows operating system. 
     The Windows operating system  152  by default provides standard services to perform a number of routine operations on filter pins, filters, and filter topology properties on behalf on the driver  168 . This default handling of the standard services can be extended to the interface  172  by a dynamically loaded module that is called when the DSP task  164  is instantiated or when a DSP filter&#39;s pin is instantiated (GetAutomationTable). The extension of the standard services can result in a more streamlined interface  172  because it does not need to emulate the standard services. The standard services are then combined with the operations not handled by the standard services. Operations not handled by the Windows operating system  152  are sent to the driver  168 . Driver  168  then sends a message to the interface  172  which in turn sends a message to the platform driver  154  via property (KSDSP_MSG_PROPERTY), method (KSDSP_MSG_METHOD), and event (KSDSP_MSG_EVENT) messages to perform these operations. 
     Once the DSP task  164  is loaded and a control channel  180  is created, the driver  168  issues a translation command to convert any Windows operating system&#39;s identifications, such as the device identification  160  (FIG. 5) and interface identification  162  (FIG.  5 ), that are larger than a pre-selected size into identifiers of the pre-selected size (SetGuidTranslationTable). In one embodiment, the pre-selected size is preferably 32 bits in length. This reduces the size of control messages containing identifiers which reduces the memory footprint associated with the control message, resulting in less overhead in sending messages and data between the operating systems. 
     Communication between the Windows operating system  152  and the DSP task  164  are sent by preparing a message (PrepareChannelMessage, PrepareMessage) and sending the message (SendMessage). To prepare a message, a control message is sent to the DSP task  164  to notify it that a message is being sent. This message may include a pointer to an I/O request packet, a message identifier, a pointer to an allocated message frame or a pointer to receive the resultant message frame and the length of the message that will be sent. Other message specific parameters such as the identification of the target channel may also be sent in this message and whether the message is for general control or for a specific task. Alternatively, this message can allocate an I/O request packet or a message frame (AllocateMessageFrame) or both an I/O request packet and a message frame. The platform driver  154  receives this message and translates the message, if necessary, into the format required by the DSP task  164 . 
     Providing the capability to identify whether the message is a general control message or a task specific message allows the DSP OS  150  to distinguish between message types. This provides the DSP OS  150  with the flexibility to be able to receive and send general control messages differently than for pin specific and data transfer control messages. For example, a general control message may have different parameters associated with it than data transfer control messages. Having the capability to send a general control message without any parameters specifically needed only to support data transfer control messages or to send a data transfer control message without any parameters specifically needed only for a general control message can result in more efficient communication between the DSP OS  150  and the Windows operating system  152 . 
     After the operating systems have been notified that a message is being sent, the message is sent (SendMessage) to the DSP task  164 . It should be noted that the notification and sending may be combined into a single step. This message may include indications that the driver  168  is waiting for the DSP task to perform an operation and the I/O request packet associated with the message, and other optional parameters that an operating system may require. This distinguishes from fixed drivers by allowing operating systems to put platform specific parameters in messages. The driver  168  retrieves results of messages sent by sending a message that requests the results. The message includes an identifier that identifies the message frame sent to the DSP task  164  (GetMessageResult). 
     Data is sent to the DSP task  164  on a separate data channel  182 . Control messages may also be sent on a data channel  182 . In one embodiment, only data related control messages such as start, run, and stop messages are sent on the data channel  182 . This eliminates the operating systems from having to distinguish between general control messages and data related control messages. When a DSP filter&#39;s pin is instantiated, the driver sends a message to create a data channel and provides the pin identification and type of pin being created (OpenDataChannel). The message also provides a pointer to receive the identifier for the data channel being created. The platform driver  154  then commands the DSP task  156  to open a data channel  182  (KSDSP_MSG_OPEN_DATA_CHANNEL) and receives from the DSP task  164  an identifier that identifies the resultant data channel. 
     To transfer data streams between a source and the DSP task  164 , direct memory access transactions are used. However, it should be noted that other methods of transferring data streams can be used as known by those skilled in the art. From hereon, the term DMA shall indicate the method of transferring data. The driver  168  sends a message to inform the DSP task  164  to prepare for a DMA transaction (MapDataTransfer). The message may include a pointer to an I/O request packet, an indication of whether to perform a Read DMA transaction (KSDSP_MSG_READ_STREAM) or a Write DMA transaction (KSDSP_MSG_WRITE_STREAM), a pointer to an allocated message frame or a pointer to receive the resultant message frame, a pointer to a buffer for the DMA transfer and the size of the buffer used for the DMA transfer. Other message specific parameters such as the identification of the target channel may also be sent in this message. Alternatively, this message can allocate an I/O request packet or a message frame (AllocateMessageFrame) or both an I/O request packet and message frame. The platform driver  154  receives this message and translates the message, if necessary, into the format required by the DSP task  164 . Preferably, the platform driver  154  prepares the buffer for the transfer. The platform driver  154  then sends the appropriate message to the DSP task  164  to put the DSP task  164  in a run mode for the DSP task  164  to perform the DMA transfer (KSDSP_MSG_SET_CHANNEL_STATE). 
     The DSP task  164  performs the operation that it was requested to do by the driver  168 . The DSP task  164  then notifies the platform driver  154  that the operation is complete and the platform driver sends a message using the methods above to inform the driver  168  that the operation is complete. The data is then transferred back via a DMA transaction as described above. However, if there is another task on the DSP  150  that will receive the output from the DSP task  164 , the driver  168  commands the platform driver to send the output of the DSP task  164  to the input pin of the other task on the DSP  150  (SetTargetChannel). This command message includes an identifier for the output pin of the DSP task  164  and the target channel that is to receive the data from the DSP task  164 . The platform driver  154  then sends a command to the DSP operating system  150  to transfer the data to the other task (KSDSP_MSG_SET_TARGET_CHANNEL). Once the DMA transfer is complete, the driver  168  can send a command to the platform driver to release, or unmap, the buffers used in the DMA transfer (UnmapDataTransfer). 
     The driver  168  then sends a command to close the data channel if no further data is to be processed by the DSP task  164  (CloseDataChannel). The platform driver  154  then issues a command to close the data channel to the DSP task  164  (KSDSP_MSG_CLOSE_DATA_CHANNEL). Once all DSP operations have been completed for a particular task, the connection to the DSP task  164  is closed. The platform driver commands the DSP to free the task (KSDSP_MSG_FREE_TASK). 
     All of the references cited herein, including appendices, patents, patent applications, and publications, are hereby incorporated in their entireties by reference. 
     In view of the many possible embodiments to which the principles of this invention may be applied, it should be recognized that the embodiment described herein with respect to the drawing figures is meant to be illustrative only and should not be taken as limiting the scope of invention. For example, those of skill in the art will recognize that the elements of the illustrated embodiment shown in software may be implemented in hardware and vice versa or that the illustrated embodiment can be modified in arrangement and detail without departing from the spirit of the invention. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.