Every system configuration script that creates a system on which software can
run, should add an os_awareness object to the software slot of each
top-level object.
For further details on how to configure the OSA framework see section
2.8.
This is done by running the new-os-awareness command and naming the new object
by appending .software to the system top object name.
This is how it’s done in the standard configuration files (usually called
something-system.include).
simics> new-os-awareness name = $system.software
Created OS awareness framework 'test_board.software'
If a target script starts a specific kernel version, it is convenient to make it include pre-defined parameters for the tracker. For example, if we have linux-3.1.4.simics, we could also provide a linux-3.1.4.params file with parameters matching the target OS. This makes it possible to run the system without having to configure the tracker each time. However, not everyone may have access to a specific tracker module, so care needs to be taken in order to add support to the target script so it works even without a tracker. Below is an example of how a target script can be written so that the system can be brought up even if the user does not have access to the tracker. The tracker itself, will not work if the parameters are not supported.
if not defined tracker_params = {$tracker_params = "linux-3.1.4.params"}
$sw = $system.software
# First check if any parameters should be loaded at all.
if $tracker_params != "" {
if $sw.supports-parameters $tracker_params {
$sw.load-parameters file = $tracker_params
} else {
echo ("No tracker module found that supports parameters file: "
+ $tracker_params)
}
}
The software object handles user interaction by providing a number of commands,
see section 2.3 for further details.
The object will contain interfaces for scripting against node trees.
The software object will also contain a sub-object named tracker which will be
added once a tracker has been configured.
Configuration of the tracker can be done in two ways.
The first way is by loading parameters with the load-parameters command, which
will add a tracker composition object matching the tracker specified in the
parameters file loaded, if a matching tracker module exists.
The second way is by inserting a tracker composition object of a specific kind
with the insert-tracker command.
This way has to be used if no parameters exist.
The tracker composition object can then provide ways to detect parameters for
the target software.
See section 2.7 for more information about parameters.
Most tracker composition objects will contain two objects, one named
tracker_obj which takes care of tracking the currently running software.
The other object will be the mapper object which takes care of mapping the
information given by the tracker into a node tree (see section 2.2)
which can be used when scripting or debugging.
One tracker could potentially have several different mappers to represent the
tracker’s information in different node trees.