Data processing: structural design – modeling – simulation – and em – Emulation – Of instruction
Reexamination Certificate
1998-11-02
2002-07-16
Teska, Kevin J. (Department: 2123)
Data processing: structural design, modeling, simulation, and em
Emulation
Of instruction
C703S023000
Reexamination Certificate
active
06421635
ABSTRACT:
TECHNICAL FIELD OF THE INVENTION
This application relates in general to computer systems utilizing an emulator, and in specific to mechanism for handling signals during the emulation of system calls.
BACKGROUND OF THE INVENTION
Software applications utilize the functionality provided by the underlying operating system during execution time. As shown in
FIG. 2
, the functionality, such as manipulating files, shared memory, and semaphores, is usually provided in libraries
22
along with an application program interface (API)
21
. The operating system
24
implements most of this functionality internally by means of a set of system calls
25
. The interface between the libraries and the system calls in the operating system is provided by an application binary interface (ABI)
23
. Thus, a software application
11
will make system calls
25
to the operating system
24
, via the API interface
21
with the libraries
22
and the ABI interface
23
with the operating system.
Most software applications are developed to operate on one particular type of platform, and thus will not directly run on a different type of platform. A variety of mechanisms have been developed to allow software applications to run on different platforms. One particular mechanism is an emulator which emulates the software application on a different platform from that which it was developed to run. For example,
FIG. 1
depicts software application ‘A’
11
which was developed to run on platform ‘
1
’
12
. Application ‘A’
11
cannot run on a different type of platform, platform ‘
2
’
13
, unless emulator
14
emulates the code of software application
11
for use on platform ‘
2
’
13
. Emulators are also used in testing and prototyping software applications.
Emulators
14
are typically software mechanisms which are resident in the second platforms, i.e. platform ‘
2
’
13
. The emulator exactly reproduces the operating environment expected by the software application. The emulator does this by emulating both the instruction set architecture (ISA) of the platform, which refers to the machine instructions in the software, and the environment, which refers to the system calls, signals, etc. used by the software. Part of the environment emulation involves emulating the signals and the system calls provided by the operating system which ordinarily would be directly visible to the software application.
A problem occurs during the emulation of the system calls, particularly with signals which occur during the emulation. Signals are mechanisms provided by the operating system to notify processes or software applications about events that have occurred. Signals are usually classified into synchronous or asynchronous. Synchronous signals are caused by the execution of the software application, and thus, are delivered immediately, at well defined points in the emulated application program code. Asynchronous signals are caused externally and are not delivered at any precise location, i.e., the delivery location is indeterminate. Thus, asynchronous signals need not necessarily be delivered immediately after they occur. Moreover, an emulator may need to delay delivery of asynchronous signals because the emulated application may not be in a state consistent with the arrival of the signal when the signal arrives. Consequently, asynchronous signals are deferred until the emulated application
11
is in a proper state to receive such a signal.
A system call is a mechanism that transfers control from the software application to a specified functionality of the operating system of the platform. The emulator can emulate most system calls made by the emulated software application by mapping them onto the system calls provided by the operating system of the second platform, i.e. platform ‘
2
’
13
. A system call may be interrupted by an asynchronous signal.
A problem would occur if a signal were deferred during the emulation of a system call. The signal would not be delivered until the emulation of the system call was completed, which is when the emulated application is in a proper state to receive such a signal. In order to emulate the system call, the emulator makes a corresponding system call to the native operating system. The native system call will block whenever the corresponding system call would have blocked on the legacy system. If the emulated application is relying on the fact that a blocked system call will be interrupted by a signal, the application will not function correctly under the emulator, since the deferred signal would no longer be able to interrupt the system call, and the system call will block forever.
FIG. 3
depicts an example of the problem occurring during the emulation of system calls. Software application
11
makes a system call, read( )
31
, with the assumption that a signal, SIG_X
32
, will interrupt the system call and thereby cause control to return to the application. As shown in
FIG. 3
, the signal SIG_X
32
occurs after emulation
33
of the read( )
31
has commenced and before the system call has been mapped
34
to an equivalent system call in the second platform, platform ‘
2
’
13
. After mapping, control is transferred
36
to the kernel of the operating system
24
. If the emulator defers SIG_X for later delivery
35
instead of immediate delivery, then the read( ) system call will block or hang indefinitely because it is waiting for SIG_X to interrupt it, which can no longer interrupt it because it has already been deferred. Thus, the operating system is waiting for the signal
37
before returning to the emulator
38
, and completing the system call
39
. Note that emulator
14
performs additional steps during emulation of the system call which are depicted by . . . characters in FIG.
3
. These steps will vary, depending upon the specific system call being emulated, and thus are not shown here.
Therefore, there is a need in the art for a mechanism which will deliver any asynchronous signals that either arrive or are pending during the emulation of system calls.
REFERENCES:
patent: 4974159 (1990-11-01), Hargrove et al.
patent: 5481684 (1996-01-01), Richter et al.
patent: 5481693 (1996-01-01), Blomgren et al.
patent: 5625788 (1997-04-01), Boggs et al.
patent: 5664098 (1997-09-01), Bianchi et al.
patent: 5721876 (1998-02-01), Yu et al.
patent: 5764962 (1998-06-01), Buzbee
patent: 5781750 (1998-07-01), Blomgren et al.
patent: 5784638 (1998-07-01), Goetz et al.
patent: 5909567 (1999-06-01), Novak et al.
patent: 5958054 (1999-09-01), O'Connor et al.
patent: 5964890 (1999-10-01), Inui et al.
Auder et al.; Implementing fault injection and tolerance mechanisms in multiprocessor systems; IEEE Int. Symp. Defect and Fault Tolerance in VLSI Systems; pp. 310-317, 1996.
Brauch Rupert
Chandramohan Bharath
Dunn David A.
Teska Kevin J.
Thomson William
LandOfFree
Method and apparatus for handling asynchronous signals while... 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 and apparatus for handling asynchronous signals while..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for handling asynchronous signals while... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2877276