Patent Application
20050177776
This application makes reference to, incorporates the same herein, and claims all benefits accruing under 35 U.S.C. §119 from an application for APPARATUS AND METHOD FOR MONITORING SOFTWARE MODULE STATE IN SYSTEMS USING EMBEDDED MULTITASK OPERATING SYSTEM earlier filed in the Korean Intellectual Property Office on 27 Jan. 2004 and there duly assigned Serial No. 2004-5153.
1. Field of the Invention
The present invention relates to an embedded multitasking operating system, and more particularly, to an apparatus and method for efficiently monitoring panics in a kernel or the internal state of a software module of an embedded multitasking operating system in a system using the embedded multitasking operating system.
2. Description of the Related Art
In general, an operating system (hereinafter will be referred to as “OS”) used in an embedded system includes a kernel or a software module functioning as a core element of the OS. While the OS is a concept more comprehensive than the kernel, they will be used together in the same meaning.
Although different more or less according to adopted OS, the kernel performs following functions:
First, memory management (e.g., support an imaginary memory and protect a memory) in a system; second, interrupt and timer management; third, process/task scheduling; and fourth, bus or controller initialization and management.
The foregoing functions constitute core elements of an OS and manage resources within a system so that software modules operating based upon the OS can effectively provide services. Most of these resources need the support from hardware. Therefore, realizing the kernel is generally associated with hardware in execution.
Since those software modules for managing services provided by the embedded system are designed to operate in the OS containing such a kernel, the OS is required to constantly maintain a normal operation state regardless of the operation state of an upper service software (i.e., a software operating based upon the OS). The OS is also required to have an ability of rapidly providing management in the event of any abnormal problems.
However, this kernel directly manages a large number of hardware parts together with many and various software modules, and thus is constantly exposed to abnormal operations. In case of abnormal operation of a software module that is not sufficiently verified in stability, the kernel itself may show abnormal operation.
In order to prevent the foregoing problems, the kernel has a function capable of restricting resource access according to mode types, classified into supervisor and user modes. However, a software module such as a device driver which directly accesses hardware may positively directly influence the kernel since it generally operates in the supervisor mode.
Hereinafter an operation for monitoring the status of a kernel software in an OS of the earlier art will be described with reference to appended
As shown in
As shown in
Since the OS can directly use all resources of a system in the supervisor mode, all software modules do not operate in the supervisor mode, but some software modules requiring direct management of resources operate in this module. Herein the terminology “resources” mean hardware parts such as a memory.
Those software modules operating in the common user mode are restricted by the kernel so that they cannot directly connect to the resources such as hardware. Therefore, the software modules operating in the common user mode rarely give fatal influence to the system. However, since those software modules called device drivers directly control hardware while operating in the supervisor mode, they can cause severe abnormal status to the system.
As a consequence, most OS's may have a software module for monitoring such status. This software module is also under the control of the kernel since it operates in the kernel.
As shown in
The scheduler 30 distributes predetermined times to the respective software modules according to self-algorithm so that all the software modules in the OS 10 can operate normally.
The respective kernel software modules 20a to 20n are required to perform their functions within the times distributed by the scheduler 30. After termination of the execution times of the kernel software modules 20a to 20n which are currently operating, the scheduler 30 transfers the right of using the resources to next ones of the kernel software modules 20a to 20n so that the next kernel software modules 20a to 20n can operate.
This process is repeated so that all the software modules in the kernel can be operated normally, and will be continuously repeated as long as the system is operated normally.
There is a status monitoring software module 40 for periodically monitoring the status of the software modules in the kernel 10 and informing the software status to the outside. The software module 40 can be controlled by the scheduler 30 as other kernel software modules 20a to 20n. A user can confirm the kernel status from information displayed on the display 10 via the status monitoring software module 40.
Hereinafter a conventional method for monitoring software module state corresponding to the conventional operation of the OS for monitoring software module state will be described with reference to
As shown in
After termination of times distributed to the currently operating ones of the software modules 20a to 20n and 40, the scheduler 30 temporarily stops the currently operating ones of the software modules 20a to 20n and 40, and operates those ones of the software modules 20a to 20n and 40 to be operated next and allocates execution times to the next operating ones of the software modules 20a to 20n and 40 (S101).
The scheduler 30 judges whether a software module to be operated is the status monitoring software module 40 (S102). If the currently operated software module is the status monitoring software module 40, the scheduler 30 inspects the status of the respective kernel software modules 20a to 20n and 40, and outputs the status information of the inspected kernel software modules 20a to 20n via the external display 100 so that a user can confirm the current status of the kernel software modules 20a to 20n (S103).
However, if it is judged in S102 that the software module to be executed next is any of the kernel software modules 20a to 20n which execute common functions, the scheduler 30 allows corresponding one of the kernel software modules 20a to 20n to execute its own function (S105), and judges whether the corresponding module malfunctions while executing its own function (S106).
If any of the kernel software modules 20a to 20n malfunctions, a system panic occurs so that the system cannot be restored.
However, if the kernel software modules 20a to 20n normally function, the scheduler 30 judges whether all the execution times allocated to the software modules 20a to 20n and 40 are terminated (S104).
If all the allocated execution times are terminated, the scheduler determines some of the software modules to be executed next, and repeats the foregoing process.
Exceptional situations take place because the software modules 20a to 20c in the kernel manage different types of hardware. In this case, if all the resources are occupied by specific ones of the kernel software modules 20a to 20n, the scheduler 30 itself may not properly operate.
In this severe situation, the status monitoring software module 40 does not operate normally so that the user cannot confirm the internal state of the system. Then, since the internal state of the system is not correctly inspected, approaches for solving the problems become difficult.
The primary reason of such a severe problem comes from an erroneously composed software. However, the corresponding software may be additionally composed for services rather than for the kernel itself. Even in this case, it is required to inspect the OS state rapidly to find the problem.
All of the scheduler within the kernel, the kernel software creating the problem and the state-monitoring software module are software. Therefore, the foregoing severe situation can be rarely solved with software modules only, and thus needs the aid of a hardware logic. Since the hardware logic can operate independent from the software modules, the hardware logic can recognize the state of a software only if the hardware logic is properly interfaced with the software.
It is, therefore, an object of the present invention to provide an apparatus and method for monitoring the state of software modules in a system using an embedded multitasking Operating System (OS) in which a hardware logic is constituted independent from software modules to monitor the internal state (panic) of the software modules to output the internal state information of the monitored software modules so that a user can easily recognize the internal state information.
It is another object to provide an apparatus and method for monitoring the software module state of the embedded multitasking OS in a system using the OS records the state information of the software modules of the OS in the hardware logic, reads the recorded state information of the software modules via the hardware logic, and displays or presents the read state information.
It is yet another object to provide the state information of the software modules of the OS to be recorded sequentially in the state recording range of the hardware logic and then sequentially read via the hardware logic in response to a state information inspection request from a user so that state information of the software modules of the OS can be monitored and confirmed independent from the operation of the software modules of the OS.
It is still another object to provide an apparatus and method for monitoring the software module state of the embedded multitasking OS in a system using the embedded multitasking OS according to the invention to sequentially record the state information of the software modules in the state recording range of the hardware logic, sequentially read the state information of the software modules from the state recording range, and display the state information so that the user can easily recognize the same.
It is another object to provide the state information of the software modules to be monitored and inspected independent from the operation of the software modules of the OS, and thus the state of the software modules or the OS can be inspected in any exceptional software-associated situations.
It is yet another object to provide a method and apparatus that provides the software and hardware to not influence each other's operation in a system and thus increasing system stability by avoiding severely negative system conditions including hanging or system crashes.
It is another object of the present invention to provide an apparatus and method for monitoring the state of software modules in a system that is easy to implement, cost effective and efficient and yet increase system stability.
According to an aspect of the invention for realizing the above objects, there is provided an apparatus of the invention for monitoring software modules in a multitasking Operating System (OS) in a system using the multitasking OS, including a hardware logic interfaced with the OS, wherein the hardware logic executes the following steps of: (a) determining a record range for recording the state information of the software modules of the OS therein and the size of the record range, and sequentially recording the state information of an operating software module in a corresponding range; and (b) reading and outputting the recorded state information of the software module in response to a state information request event.
Preferably, the OS determines a recording range address, in which the state information of the respective software modules will be recorded at the initialization of the software modules, and the size of corresponding address, and includes a state information record setting module for recording the determined address and the size of the software state information to be recorded in a state information recording range of the hardware logic.
Preferably, the address size is determined according to the size of the state information of the respective software modules of the OS to be recorded in the hardware logic.
Preferably, the OS determines a software module to be operated next from the software modules, upon termination of time allocated to a currently operating software module, operates the determined software module, and allocates an operating time to the determined software module in order to control the schedule of the respective software modules so that an operating software module can record its state information in a software state information recording range of the hardware logic.
Preferably, the currently operating software module records its state information, which is operated last in an execution time allocated to the currently operating software module by the scheduling module, in a state information record range of the hardware logic allocated to the currently operating software module.
Preferably, the hardware logic includes: a state information recording part for recording the state information of a software module of the OS, which is operated based upon the software module state recording range address determined at the initialization of the respective software modules of the OS and the size information of the corresponding address, in a corresponding range; a state information requesting part for providing a key input signal for inspecting the state information of the software modules of the OS recorded in the state information recording part; a state information reading part for reading the state information of the respective software module recorded in the state information recording part and outputting the read state information of the software modules in the form of displayable data upon receiving a state information inspecting request signal from the state information requesting part; and a display for presenting the data corresponding to the output state information of the software modules from the state information reading part.
Preferably, the state information recording part includes: a first recording field for recording the address, in which the state information of the respective software modules of the OS are to be recorded, and the size information about the state information of the respective software modules corresponding to the address; and a second recording field for recording the state information of a corresponding software module according the size information about the state information of the respective software modules of the OS recorded in the first recording field.
Preferably, the first recording field has a range at least the same as the number of the software modules of the OS, the state information of the respective software modules of the OS recorded in the second recording field is recorded in the form of hexa codes.
Preferably, the state information reading part includes a format converting part for converting the state information of a software module read from the state information recording part in the format of displayable data that is easily conceivable by a user.
Preferably, the format converting part converts the state information of the respective software modules of the OS recorded in the state information recording part into at least one format selected from a group including a binary number, decimal number and text message, and presents the converted format via the display.
Preferably, state information reading part sequentially reads the state information of the respective software modules from the state information recording part in a round robin fashion to present the read state information via the display in response to the request signal from the state information requesting part, or the state information reading part sequentially reads the state information of the respective software modules recorded in the information recording part to present the state information of all of the software modules via the display in response to the request signal from the state information requesting part.
Preferably, the display includes at least one of a character LED (light emitting diode) and a character LCD (liquid crystal display).
Preferably, the hardware logic is realized in the form of a Field Programmable Gate Array (FPGA).
According to another aspect of the invention for realizing the above objects, there is provided an apparatus for monitoring software modules in a multitasking Operating System (OS) in a system using the multitasking OS, including: an OS having software modules executing different operations, the OS determining a recording range address for recording state information according to the software modules and the size of the state information recording range, and generating the size information of the determined address and the state information; and a hardware logic interfaced with the OS for (a) recording an address, in which state information according to software modules created from the OS is recorded, and size information for recording the state information in a first range, and sequentially recording the present state information of an operating software module of the OS in a second range corresponding to the address and the state information size information, (b) reading the recorded state information of the software modules, converting the state information into a displayable format, and presenting the converted state information of the software modules via a display in response to a state information request event.
Preferably, the OS includes: software modules for operating different operations; a scheduling module for allocating executing times to the software modules and controlling the execution of the software modules according to the allocated times; and a state information record setting part for determining a record range address, in which the state information according to the software modules is recorded, and the size of the corresponding address at the initialization of the software modules, interfacing the determined address, the size value about the software state information to be recorded and the present state information of the software modules to the hardware logic.
According to further another aspect of the invention for realizing the above objects, there is provided an apparatus for monitoring software modules in a multitasking Operating System (OS) in a system using the multitasking OS, including: a state information recording part for recording the state information of the software modules of the OS in a corresponding range according to a software recording range address determined at the initialization of the software modules of the OS and the size of a corresponding address; a state information requesting part for providing a key input signal for inspecting the state information of the software modules of the OS recorded in the state information recording part; a state information reading part for reading the state information of the respective software modules recorded in the state information recording part and outputting the read state information of the software modules in the form of displayable data upon receiving a state information inspecting request signal from the state information requesting part; and a display for presenting the data corresponding to the output state information of the software modules from the state information reading part.
According to other aspect of the invention for realizing the above objects, there is provided a method for monitoring software modules in a multitasking Operating System (OS) in a system using the multitasking OS, the method including the following steps of: (a) determining a record range for recording the state information of the software modules of the OS therein and the size of the record range, and sequentially recording the state information of an operating software module in a corresponding range; and (b) if a state information request event occurs, reading and outputting the recorded state information of the software module.
Preferably, the recording step includes: recording an address and the size information about the state information of the software modules of the OS in a first recording field, the state information of the software modules being recorded according to the address and the size information corresponding to the address; and recording the state information of a corresponding software module in a second recording field based upon the size information about the state information of the software modules recorded in the first recording field.
Preferably, the range of the first recording field is at least the same as the number of the software modules of the OS, and the state information of the software modules recorded in the second field is recorded in hexa codes.
Preferably, the step of outputting the displayable data includes converting the state information of the software modules read from the state information recording range into one selected from a group including a binary number, decimal number and text message that is easily conceivable by a user.
Preferably, the step of outputting the displayable data includes sequentially reading the state information of the software modules from the state information recording range in a round robin fashion in response to a state information request signal from a user.
According to yet another aspect of the invention for realizing the above objects, there is provided a method for monitoring software modules in a multitasking Operating System (OS) in a system using the multitasking OS, the method including the following steps of: recording the state information of the software modules of the OS in a corresponding range according to a software recording range address determined at the initialization of the software modules of the OS and the size of a corresponding address; upon receiving a key input signal for inspecting the state information of the software modules of the OS, reading the state information of the respective software modules recorded in the state information recording part and outputting the read state information of the software modules in the form of displayable data; and presenting the output data corresponding to the state information of the software modules.
A more complete appreciation of the invention, and many of the attendant advantages thereof, will be readily apparent as the same becomes better understood by reference to the following detailed description when considered in conjunction with the accompanying drawings in which like reference symbols indicate the same or similar components, wherein:
Hereinafter an apparatus and method for monitoring software module state of a system using an embedded multitasking OS according to the invention will be described in detail with reference to the accompanying drawings.
As shown in
The OS part 10 includes a scheduler 30, a number of kernel software modules 20a to 20n and a state record setting part 50, and the hardware logic 100 includes a state recording part 140, a state reading part 130, a state output part 120, a display part 110 and an inspection requesting part 150.
The OS part 10 and the hardware logic 100 exchanges information through the state record setting part 50 and the state recording part 140.
While being executed, the kernel software modules 20a to 20n of the OS 10 can record their own state information in mapping areas of the state recording part 140 set by the state record setting part 50. The state recording part 140 can be divided according to the kernel software modules 20a to 20n or according to a method determined in view of the OS 10.
The scheduler 30 and the kernel software modules 20a to 20n will not be described in detail since they are substantially the same components as those of the conventional system shown in
The state record setting part 50 in the OS 10 shown in
The state recording part 140 of the hardware logic 100 is a type of memory for recording the state information of the kernel software modules 20a to 20n of the OS 10 provided by the state record setting part 50 into the fields allocated by the state record setting part 50 of the OS 10. The information recorded in the state recording part 140 includes offset address, state information address in which the state information of the kernel software modules 20a to 20n are to be recorded, the size information of the state information address and the present state information of the kernel software modules 20a to 20n. The state recording part 140 will be described in detail later in the specification with reference to
The state inspection requesting part 150 serves to output state monitoring results of the kernel software modules 20a to 20n via the display 110 so that a key input signal for inspecting the present state of the software modules 20a to 20 is provided to the state reading part 130, and may be constituted of a key or keyset. That is, the state inspection requesting part 150 has a user input processing function for inspecting the state information of the kernel software modules 20a to 20n.
When a request signal for the state information inspection to the present kernel software modules 20a to 20c is received from the state inspection requesting part 150, the state reading part 130 interprets or reads the state information of the kernel software modules 20a to 20n of the OS 10 stored in the state recording part 140, and provides the state information to the state output part 120.
The state output part 120 converts the state information of the kernel software modules 20a to 20n from the state reading part 130 into a format, which is easily recognizable by users, and displays the converted state information format via the display 110. Herein the display 110 is a hardware part utilizing a display device such as a character LED (light emitting diode), etc., and may present data in the form of binary or decimal numbers so that a user can easily conceive the state of the kernel software modules 20a to 20n. The display 110 may also present data in the form of text messages by using a display device such as an LCD (liquid crystal display), etc.
As a result, the hardware logic 100 shown in
The state recording part 140 shown in
As shown in
An offset array of the state recording part 140 shown in
The first field 141 is a field to be recorded with record initialization setting addresses (0x0000 0000 ˜) according to the kernel software modules 20a to 20n, and the second field 142 is a field (0x0000 1000 ˜) to be recorded with present state values according to the kernel software modules 20a to 20n.
In order to outwardly inform the present state of the kernel software modules 20a to 20n in the OS 10, the hardware logic 100 is required to know where a kernel software records its present state information. Such information is to be informed to the hardware logic 100 by the kernel software modules, and the first field 141 is used to inform such information. Herein it is required to record address values and sizes in the first field. For example, in order to store two items in 32 bits, the first field may be divided into 16 bit nibble units (e.g., upper and lower nibbles).
Further, the fields may be allocated with different sizes since the kernel software modules 20a to 20n may have different information to be recorded. That is, the size of the first field depends on the number of the kernel software modules 20a to 20n.
For example, a shown in
In the meantime, the second field 142 of the state recording part 140 is a space where the kernel software modules 20a to 20n record the present state in designated offsets. The second field 142 is recorded with values suggesting the present state of the software modules 20a to 20n. These values are distinguished according to software modules since they may be different according to the kernel software modules 20a to 20n. That is, the present state values are to be set and recorded according to different code values since the kernel software modules 20a to 20n execute their own functions different from one another. For example, the software modules may be recorded according to hexa values different from one another in order to discriminate the state values different from one another.
The present state values of the kernel software modules 20a to 20n recorded in the second field 142 of the state recording part 140 may include for example address values of I/O ranges to be accessed, major resource type values to be accessed, machine state values of the software modules and so on.
As a result, because present states are different according to the kernel software modules 20a to 20n, it is necessary for the user to discriminate in person output values via the display 110. Accordingly, those values displayed via the display 110 may be presented in the form of binary or decimal numbers or text messages so that the user can easily recognize the state value of the software modules. Those values are format-converted in the state output part 120 as shown in
Further, all the state values of the kernel software modules 20a to 20n can be displayed simultaneously. Alternatively, the state values of the kernel software modules 20a to 20n may be displayed in a round robin fashion, that is, the state values may be read and displayed in their order whenever the user presses the state inspection requesting part 150 in the form of a key. Then, the ID (identification) information of a corresponding kernel software module and the present state value thereof are displayed so that the user can identify the corresponding software module and its present state value.
Hereinafter a stepwise description will be made about a method for monitoring the software module state of the OS according to the invention corresponding to the operation of the apparatus for monitoring the software module state of the OS in the system using the embedded multitasking OS according to the invention as described above.
As shown in
If the execution times allocated to the software modules 20a to 20c are terminated, the scheduler 30 stops the software modules 20a to 20c, executes those ones of the software modules determined to be operated next, and then allocates execution times to the operating ones of the kernel software modules 20a to 20n (S202).
The operated kernel software modules 20a to 20n record their present state information in corresponding ranges of the state recording part 140 (S203). In order to record the state information of the kernel software modules 20a to 20n in the corresponding ranges of the state recording part 140, it is necessary to determine ranges for recording the state information and range sizes as shown in
After the state information of the corresponding kernel software modules 20a to 20n are recorded, the scheduler 30 judges whether the execution times allocated to the currently operating kernel software modules 20a to 20n are terminated, and if the allocated times are terminated, determines which of the kernel software modules 20a to 20n shall be operated, and then repeats the foregoing process (S204).
A method executed by the state record setting part 50 shown in
A process for determining addresses and address sizes according to which the kernel software modules 20a to 20n record their state information in the state recording part 130 is necessarily performed in the initialization of the kernel software modules 20a to 20n, and the state information may not be precisely read or displayed in the hardware logic 100 without correct execution of this process.
First, at the initialization of the kernel software modules, the state record setting part 50 of the OS 10 determines addresses according to which the state information of the kernel software modules 20a to 20n are recorded (S301) and the sizes of ranges for recording to state information.
The state record setting part 50 calls a related function or a state record setting function in order to record the determined addresses and the size information of the state information recording ranges in the state recording part 140 (S302).
The state record setting function of the state record setting part 50 records the state information from the kernel software modules 20a to 20n in corresponding ranges of the second field 142 of the state recording part 140 as in
As the initialization of one corresponding kernel software module is initialized to complete the state information record initial setup to record the state information of a kernel software module as well as the state information recording, the scheduler 30 inspects whether the kernel software modules 20a to 20c include any software module to be initialized next, and if the kernel software modules 20a to 20c include a software module to be initialized, repeats a process of the same as above (S304).
After the state information of the kernel software modules 20a to 20n is recorded in the state recording part 140, the recorded state information of the kernel software modules 20a to 20n are read and presented via the display 110 in response to a request from a user, which will be explained stepwise with reference to
First, when the user judges that the present system has an abnormal state, he/she inputs a state inspection request signal via the state inspection requesting part 150. Then, the state reading part 130 generates an interrupt associated with the state inspection request (S401). Herein, the state inspection requesting part 150 means a hardware button (key).
In response to the input state inspection requesting signal from the state inspection request part 150, the state reading part 130 selects one or more from the kernel software modules 20a to 20n so that the state information of the selected software module(s) is presented via the external display 110. This process can determine the kernel software modules 20a to 20n for example in a round robin fashion.
If currently used ones of kernel software modules 20a to 20c are recorded according to the above process whenever state inspection requests are received, next ones of the kernel software modules 20a to 20c can be used when a next inspection request is received. That is, this technique sequentially reads the state information for the kernel software modules 20a to 20n recorded in the state recording part 140 whenever the user presses the state inspection request key. Alternatively, when the state inspection requesting part 150 inputs a request signal in response to key input, all the state information of the kernel software modules 20a to 20n recorded in the state recording part 140 may be sequentially read and outputted.
In this way, the state reading part 130 finds addresses corresponding to some of the kernel software modules 20a to 20n which are outputted at present, reads the state information of the software modules 20a to 20n stored in the corresponding addresses, and sends the found state information to the state output part 120 shown in
The state output part 120 converts the state information of the kernel software modules 20a to 20n read by the state reading part 130 into a specific format that is easily recognizable by the user (S403). In the format conversion, if the state information of the kernel software modules 20a to 20n is stored in the form of hexa codes in the state recording part 140, hexa code values may be converted into binary or decimal numbers or into a text message format corresponding to the state information.
Then, the format-converted kernel state information is presented via the display 110 shown in
Next, upon receiving a further state information output request via the state inspection requesting part 150 from the user, the state information of the kernel software modules 20a to 20n is read and presented via the display 110 through the foregoing process in a round robin fashion (S405).
Alternatively, it is also apparent to those skilled in the art from the disclosure above that the state information of all the kernel software modules 20a to 20n recorded in the state recording part 140 may be sequentially read and presented via the display 110 when the user inputs a state inspection request signal by using the state inspection request key.
The foregoing process associated with software (as in
Such tracking is enabled because the state recording part 140 shown in
In the event of such a serious situation, the state information presents the final situation of the specific one of the kernel software modules 20a to 20n via the external display 110, and thus it is easy to approach a solution.
As a result, the apparatus and method for monitoring the software module state of the embedded multitasking OS in a system using the OS records the state information of the software modules of the OS in the hardware logic, reads the recorded state information of the software modules via the hardware logic, and displays or presents the read state information.
That is, the state information of the software modules of the OS is recorded sequentially in the state recording range of the hardware logic and then sequentially read via the hardware logic in response to a state information inspection request from a user so that state information of the software modules of the OS can be monitored and confirmed independent from the operation of the software modules of the OS.
The apparatus and method for monitoring the software module state of the embedded multitasking OS in a system using the embedded multitasking OS according to the invention sequentially records the state information of the software modules in the state recording range of the hardware logic, sequentially reads the state information of the software modules from the state recording range, and displays the state information so that the user can easily recognize the same. As a result, the state information of the software modules can be monitored and inspected independent from the operation of the software modules of the OS, and thus the state of the software modules or the OS can be inspected in any exceptional software-associated situations.
In practice, many systems suffer from such exceptional situations and heavy efforts have been made to solve such problems. The present invention can overcome such problems by providing the software and hardware design by which software and hardware not influence each other's operation.
Furthermore, in the prior art, it is difficult to find problems when the OS is in the above severe situation or hang, and a large amount of time and man power is required to solve such problems. However, the present invention can be applied to initial system design to save such waste.
The present invention can be realized as computer-executable instructions in computer-readable media. The computer-readable media includes all possible kinds of media in which computer-readable data is stored or included or can include any type of data that can be read by a computer or a processing unit. The computer-readable media include for example and not limited to storing media, such as magnetic storing media (e.g., ROMs, floppy disks, hard disk, and the like), optical reading media (e.g., CD-ROMs (compact disc-read-only memory), DVDs (digital versatile discs), re-writable versions of the optical discs, and the like), hybrid magnetic optical disks, organic disks, system memory (read-only memory, random access memory), non-volatile memory such as flash memory or any other volatile or non-volatile memory, other semiconductor media, electronic media, electromagnetic media, infrared, and other communication media such as carrier waves (e.g., transmission via the Internet or another computer). Communication media generally embodies computer-readable instructions, data structures, program modules or other data in a modulated signal such as the carrier waves or other transportable mechanism including any information delivery media. Computer-readable media such as communication media may include wireless media such as radio frequency, infrared microwaves, and wired media such as a wired network. Also, the computer-readable media can store and execute computer-readable codes that are distributed in computers connected via a network. The computer readable medium also includes cooperating or interconnected computer readable media that are in the processing system or are distributed among multiple processing systems that may be local or remote to the processing system. The present invention can include the computer-readable medium having stored thereon a data structure including a plurality of fields containing data representing the techniques of the present invention.
An example of a computer, but not limited to this example of the computer, that can read computer readable media that includes computer-executable instructions of the present invention is shown in
While the invention has been particularly shown and described with reference to the preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and details may be made therein without departing from the spirit and scope of the invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2004-5153 | Jan 2004 | KR | national |
