Electrical computers and digital processing systems: memory – Storage accessing and control – Specific memory composition
Reexamination Certificate
2000-02-22
2004-05-11
Peikari, B. James (Department: 2186)
Electrical computers and digital processing systems: memory
Storage accessing and control
Specific memory composition
C711S103000, C711S152000, C707S793000, C707S793000, C709S241000, C713S002000
Reexamination Certificate
active
06735666
ABSTRACT:
BACKGROUND INFORMATION
Traditional multitasking operating systems (e.g., UNIX, Windows) have been implemented in computing environments to provide a way to allocate the resources of the computing environment (e.g., CPU, memory, Input/Output (I/O) devices) among various user programs that may be running simultaneously in the computing environment. The operating system itself comprises a number of functions (executable code) and data structures that may be used to implement the resource allocation services of the operating system.
Operating systems have also been implemented in a so-called “object oriented” manner. That is, when a particular function and/or data structure (defined by a “class” definition) is requested, the operating system creates (“instantiates”) an “object” that uses executable code and/or data structure definitions specified in the class definition. Such objects thus may contain executable code, data structures, or both. Objects that perform actions are typically referred to as “tasks” (also known as “threads”), and a collection of tasks may be referred to as a “process. ” Upon loading and execution of the operating system into the computing environment, system tasks and data structures will be created in order to support the resource allocation needs of the system. User applications likewise upon execution may cause the creation of tasks (“user tasks”), processes (“user processes”), and other objects in order to perform the actions desired from the application.
In order to protect the operating system and each task running in the computing environment from interference from other tasks also running in the computing environment, typical operating systems apportion the computing environment's execution “space” (e.g., its memory) into a “system” space and a “user” space. The system space generally contains the operating system tasks and data structures, while the user space contains the code and data structures for user tasks. Typically, operating systems are designed so that user tasks cannot directly access the memory apportioned to system tasks. The operating system itself, however, can typically access all portions of memory.
Conceptually, this “protection model” is illustrated by FIG.
1
. In a computer system
1
controlled by an operating system
2
, there may be any number of user processes
3
and system tasks
5
executing at one time. User processes
3
each include a number of user tasks
6
. Because each user process
3
is only allocated a portion of the system memory, the operating system
2
may restrict access by any user task
6
affiliated with a particular user process
3
to the memory allocated to another user process or the operating system. Typically, however, system tasks
5
have unrestricted access to memory allocated to the operating system
2
and each user process
3
(indicated by direct connections
7
).
There may be instances, however, when a user task desires access to resources controlled by the operating system. For example, a user task may want access to a network I/O connection, the control of which is delegated to a system task. Alternatively, a user task often may want to read information from a data structure maintained and used by the operating system (e.g., an error status report, or the time remaining until some preplanned system event occurs). Using known operating systems, in order to make such access, the user task is required to request execution of the system functions that perform the desired actions or control access to the desired data structures via a “system call”. A system call is typically implemented via a special instruction used to cause the processor executing the code to “trap” to a trap routine (implemented in the system software) that makes a function call to the desired facilities of the operating system. Thus, the user task executing the system call cannot directly access the instructions and data structures in the system space it wishes to access, but rather must employ a special access procedure (represented in
FIG. 1
as connections
4
). Furthermore, since the user task is not permitted access to system resources or data structures, another task must be created by the operating system in the system space in order to perform the requested action. While this procedure protects the operating system from potential interference caused by user tasks, it increases system-processing overhead and thus increases execution time.
Certain operating systems, called “real-time operating systems,” have been developed to provide a more controlled environment for the execution of application programs. Real-time operating systems are designed to be “deterministic” in their behavior, i.e., responses to an event can be expected to occur within a known time of the occurrence of the event. Determinism is particularly necessary in “mission-critical” applications, although it is generally desirable for all operating systems, as it increases the reliability of the system. Real-time operating systems are therefore implemented to execute as efficiently as possible with a minimum of overhead.
Particularly in real-time systems, it is common and desirable for user tasks to obtain information about the overall state of the operating system, or information about particular aspects of the operating systems operations. This information allows tasks to operate more efficiently and reliably. For example, in a real time application, where a user task must return an answer by a deadline, a user process may choose a different method of computing a result depending on how much CPU time the user process expects to receive. A faster less, accurate method of computing might be used when the system is busy and less computation time is available, while a more accurate, but resource-intensive method might be used when more system resources are available. Similarly, a user process might decide to operate in a “safe” mode when errors have occurred. Thus, it would be beneficial to implement a system and method whereby user tasks are able to access operating system information without incurring operation overhead (such as created using the system trap) or compromising system security.
SUMMARY OF THE INVENTION
According to the present invention, an exemplary computer system is described, comprising a memory space having a number of memory locations, an operating system, a software module located, a plurality of operating system data structures, a system page including a subset of the plurality of operating system data structures, and a function located within the software module.
A first method is also described as part of the exemplary embodiment according the present invention. The method includes the steps of creating a task assigned to execute at least one function, assigning a memory access map to the task, including in the memory access map indications of read-only access to memory locations of a system page including operating system data structures, and allowing a read memory access by the task to the system page.
A second method is also described as part of the exemplary embodiment according to the present invention. The second method includes the steps of retrieving a software module having a symbol reference used by an instruction, resolving the symbol reference to obtain a symbol value for the symbol, and inserting a symbol value in the into the instruction.
REFERENCES:
patent: 5032981 (1991-07-01), Bril et al.
patent: 5381549 (1995-01-01), Tamura
patent: 5557771 (1996-09-01), Kawaguchi et al.
patent: 5745418 (1998-04-01), Ma et al.
patent: 5893166 (1999-04-01), Frank et al.
patent: 0327707 (1989-08-01), None
patent: 0415515 (1991-03-01), None
patent: 2740235 (1997-04-01), None
patent: 09016499 (1997-01-01), None
patent: 10232786 (1998-01-01), None
patent: WO 97/36236 (1997-10-01), None
patent: WO 01/22209 (2001-03-01), None
Hennessy, et al. Computer Organization and Design. p. 597. Morgan Kaufmann Publishers, Inc., 1997.*
White, Ron. How Computers Work. ZD Press, 1997. pp. 10-13 and 84-85.*
“Use of Process-Scoped Address T
Kenyon & Kenyon
Peikari B. James
Wind River Systems, Inc.
LandOfFree
Method of providing direct user task access to operating... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method of providing direct user task access to operating..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method of providing direct user task access to operating... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3222950