KR20050105481A - Rtfs controls queue of requests from os - Google Patents

Abstract

Real-time software and a non-time OS co- exist in a system, wherein the real-time software controls the requests from the non-real-time OS for access of a shared resource. The requests are put into a queue and the real-time software determines when which pending request gets executed.

Description

RTFS controls queue of requests from OS

The present invention is directed to providing real-time (RT) data processing capabilities to a non-RT operating system (OS). The present invention particularly relates to, but is not necessarily limited to, combining a non-RT OS and an RT file system (RTFS).

For example, for RT recording on a hard-disk drive (HDD), RT access to the disk is required. HDDs are shared among multiple processes. If requests for access are guaranteed to be granted under RT conditions, careful scheduling is required. Host OS (HOS), such as Linux, provides access to disks based on "best-effort", which is not sufficient for RT requirements. Non-RT OSs typically have a scheduler optimized for high average performance under the condition that each process obtains a fair portion of bandwidth for the disk. On the other hand, the RTFS software used to provide RT storage space, for example for storing video streams, is an RT scheduler for re-ordering disk requests to ensure that all video streams are stored and retrieved under RT conditions. It includes. In particular, the present invention seeks to solve the problem of achieving RT operation with a non-RT OS.

U. S. Patent No. 6,466, 962 discloses a system and method for supporting RT computing in a general purpose OS by means of co-resident operating systems. RT systems technology is allowed to coexist with commercial, general-purpose (non-RT) operating systems to support applications such as desktop multimedia conferencing. The central processor and other system resources are divided into two virtual machines. The first machine runs a largely unmodified general-purpose operating system and the second machine runs an RT kernel. Access to physical hardware is multiplexed by virtual machines. The multiplexer is pre-scheduled to multiplex at exact periodic intervals between machines, or the multiplexer is operated under the control of an interrupt in response to a request from the RT OS to ensure that the RT kernel has accessed the hardware.

1 is a block diagram of a system of the present invention.

2 includes tables of requests at various stages of operation of the system of the present invention.

The present invention proposes a more advantageous alternative to known devices for merging non-RT OS with RT data processing. To this end, the present invention provides an RT software stack that cooperates with a non-RT OS by intercepting non-RT OS requests and controlling the non-RT OS requests according to RT rules. More specifically, the present invention relates to a method of implementing RT software that coexists with a non-RT OS to share one or more resources between the RT software and the non-RT OS. The method includes enabling RT software to examine a queue of one or more pending requests from a non-RT OS for access of a resource; And allowing the RT software to determine when the pending request will be executed.

In the present invention, RT software is allowed to throttle traffic in non-RT OS in accordance with RT rules. Requests from non-RT OS are not executed immediately as in the normal case. RT software controls the points at which non-RT OS requests are executed.

To illustrate, the term "hook" in this article refers to a communication channel between RT software and a non-RT OS.

An embodiment of RT software that coexists with a non-RT OS in accordance with the present invention is that the RT software runs on a non-RT OS. In another embodiment, the RT software runs outside of the non-RT OS. In case RT software is running on a non-RT OS, the OS needs to have some limited kind of real time processing guarantees if the data handling controlled by the hook will be guaranteed in real time. If not, the RT-software may not have the opportunity to issue a command for the hook. Therefore, it is desirable to run RT software on a high-priority thread. Only the CPU processing of the OS needs to have this provision. The hook mechanism affects this to create real-time guarantees for other processes, such as, for example, access to the HDD or other resources. The required real-time preparation can be quite coarse, since the hook controls coarse-grained processing.

Desirably, the hook can be enabled and disabled at run time. When disabled, non-RT OS behaves like no hook. This allows booting in the usual way. The hook recognizes requests from RT software and allows them to pass immediately. This allows the RT software to use the relevant device driver (s) of the non-RT OS and ensure that RT requests are executed without delay. The hook intercepts all requests from the non-RT-OS and queues them. This ensures that non-RT requests do not interfere with RT requests from RT software. The hook also provides information to the RT software about non-RT requests in the queue. This allows the RT software to determine the execution of certain non-RT requests in a manner that prevents certain non-RT requests from interfering with the RT traffic. For example, RT software determines the sequence in which non-RT requests are executed to optimize resource usage.

The hook is preferably enabled to disable itself under certain conditions. For example, the hook disables itself when the RT software stops checking the queue of pending non-RT requests. This allows the system to restore from the state where the RT software stopped working.

These features provide the following benefits to the system of the present invention. RT software may use device drivers of a non-RT OS. Non-RT OSs can boot as usual. Access to the hardware through the drivers is under full RT control. The RT software may be independent of the non-RT OS, for example the RT software runs outside or on top of the non-RT OS. As a result, a portable RT software stack can be developed.

For disk access, the time multiplexing used in the known systems described above is undesirable due to the relatively poor granularity of disk requests. Thus, we propose an arbitration scheme based on all available requests. This leads to an important difference between the known system and the present invention. In the present invention, the RT disk scheduler determines the order of request execution for both real time requests and non-RT requests. In known systems, this adjustment is performed only on the processor, ie externally both the RT kernel and the general purpose kernel. Multiplexing is entirely time-based with some specific measures taken to resolve conflicts between shared resources. Otherwise, conflicts can cause the general purpose process to interfere with the real time process. The present invention avoids all of these conflicts, as the disk scheduler is sure that the request from the general purpose OS is executed only at a time that does not interfere with the requests for live streaming.

The invention is explained in more detail by way of example with reference to the accompanying drawings.

Throughout the drawings, the same reference numerals indicate the same or corresponding properties.

The invention is described below by way of example in the context of writing streaming video to and feeding streaming video from memory. The memory includes, for example, an HDD, an optical disk drive, or a solid state memory. In the example below, it is assumed that the memory includes an HDD.

1 is a block diagram of a system 100 of the present invention. System 100 includes a host OS (HOS) 102 that is general-purpose, ie non-RT. System 100 also includes RT software 104, such as software with RTFS, for enabling video streaming applications. System 100 further includes hardware resource 106, which is an HDD here.

HOS 102 includes HOS file system 108, HOS cache 110, and HOS device driver 112 to operate resources 106. In order to coexist RT software 104 with HOS 102, HOS 102 is provided with a software hook 114 that enables communication between HOS 102 and RT software 104. Both HOS 102 and RT software 104 have processes that request access to HDD 106. The hook 114 intercepts all requests from the processes of the HOS 102 for access to the HDD 106 and puts the requests in the queue 116. This ensures that non-RT requests do not interfere with RT requests 118 from RT software 104. The hook 114 also provides the RT software 104 with information about non-RT requests in the queue 116. For example, the information includes the size of the request and the disk location. This allows the RT software 104 to determine the correct time for execution of pending non-RT requests to prevent pending non-RT requests from interfering with the RT traffic. Requests in queue 116 are executed only after explicit order 122 from RT software 104. In addition, for example, to optimize resource usage within system 100, RT software 104 may determine the sequence in which non-RT requests are executed. The hook 114 recognizes the requests 118 from the RT software 104 for access of the resource 106 and causes the requests 118 to pass immediately so that the requests 118 can be executed without delay. do. In this manner, the RT software 104 can use the device driver 112 of the HOS 102. Non-RT OSs typically use request queues for device drivers. Using this queue mechanism of the hook 114 simplifies the implementation of the hook 114.

2 includes tables 202, 204, 206, and 208 illustrating the operation of the system 100. HOS 102 issues multiple normal requests. The hook 114 puts these requests on the queue 116. Table 202 provides an example of requests queued to queue 116. Hook 114 provides a list of requests to RT software 104. The list is formatted such that only the required information is passed to the RT software 104. Table 204 is an example of a list based on the requests of table 202. RT software 104 first issues some RT requests 118 executed without delay by driver 112. Table 206 is an example of RT requests 118. The RT software 104 then finds that it is time to execute one or more pending HOS requests and instructs the hook 114 over the channel 122 to execute these requests. For example, the hook 114 is instructed to execute the requests # 1 and # 2 of the table 202. The hook 114 passes these requests to the driver 112 where the requests are executed. The remaining request # 3 of the table 202 is held pending in the queue 116, as shown in the table 208, with new requests issued by the HOS 102.

Claims (12)

12. A method for enabling RT software to coexist with a non-RT OS to share resources between the RT software and the non-RT OS. Enabling the RT software to examine a request from the non-RT OS for access to the resource; And Enabling the RT software to determine when the request is to be executed. The method of claim 1, Enabling the RT software to queue the request. The method of claim 1, The RT software includes RTFS. The method of claim 1, And allowing the RT software to access the resource through a device driver of the non-RT OS. The method of claim 1, And the resource comprises a memory. The method of claim 5, And the memory comprises an HDD. In a data processing system, RT software; Non-RT OS; And A resource shared between the RT software and the non-RT OS, The RT software is enabled to examine a request from the non-RT OS for access to the resource; The RT software is enabled to determine when the request is to be executed. The method of claim 7, wherein The RT software is enabled to queue the request. The method of claim 7, wherein The RT software includes an RTFS. The method of claim 7, wherein And said RT software is able to access said resource through a device driver of said non-RT OS. The method of claim 7, wherein And the resource comprises a memory. The method of claim 11, And the memory comprises an HDD.