Getting System Information

You can select a topic from this diagram:

This chapter shows you how to work with the System Information perspective.

• Introduction
• What the System Information perspective reveals
• Logging system information
• Controlling your system information session
• Examining your target system's attributes
• Watching your processes
• Examining your target system's memory
• Inspecting virtual address space
• Tracking heap usage
• Examining process signals
• Getting channel information
• Tracking file descriptors
• Tracking resource usage
• Tracking the use of adaptive partitioning
• Associated views

Introduction

The IDE provides a rich environment not only for developing and maintaining your software, but also for examining the details of your running target systems.

Within the IDE, you'll find several views whose goal is to provide answers to such questions as:

• Are my processes running?
• What state are they in?
• What resources are being used, and by which processes?
• Which processes/threads are communicating with which other processes/threads?

Such questions play an important role in your overall system design. The answers to these questions often lie beyond examining a single process or thread, as well as beyond the scope of a single tool, which is why a structured suite of integrated tools can prove so valuable.

The tools discussed in this chapter are designed to be mixed and matched with the rest of the IDE's development components to help you gain insight into your system and thereby develop better products.

What the System Information perspective reveals

The System Information perspective provides a complete and detailed report on your system's resource allocation and use, along with key metrics such as CPU usage, program layout, the interaction of different programs, and more:

The perspective's metrics may prove useful throughout your development cycle, from writing and debugging your code through your quality-control strategy.

Key terms

Before we describe how to work with the System Information perspective, let's first briefly discuss the terms used in the perspective itself. The main items are:

thread

The minimum "unit of execution" that can be scheduled to run.

process

A "container" for threads, defining the virtual address space within which threads execute. A process always contains at least one thread. Each process has its own set of virtual addresses, typically ranging from 0 to 4GB.

Threads within a process share the same virtual memory space, but have their own stack. This common address space lets threads within the process easily access shared code and data, and lets you optimize or group common functionality, while still providing process-level protection from the rest of the system.

scheduling priority

Neutrino uses priorities to establish the order in which threads get to execute when multiple threads are competing for CPU time.

Each thread can have a scheduling priority ranging from 1 to 255 (the highest priority), independent of the scheduling policy. The special idle thread (in the process manager) has priority 0 and is always ready to run. A thread inherits the priority of its parent thread by default.

You can set a thread's priority using the pthread_setschedparam() function.

scheduling policy

When two or more threads share the same priority (i.e. the threads are directly competing with each other for the CPU), the OS relies on the threads' scheduling policy to determine which thread should run next. Three policies are available:

• round-robin
• FIFO
• sporadic

You can set a thread's scheduling policy using the pthread_setschedparam() function or you can start a process with a specific priority and policy by using the on -p command (see the Utilities Reference for details).

state

Only one thread can actually run at any one time. If a thread isn't in this RUNNING state, it must either be READY or BLOCKED (or in one of the many "blocked" variants).

message passing

The most fundamental form of communication in Neutrino. The OS relays messages from thread to thread via a send-receive-reply protocol. For example, if a thread calls MsgSend(), but the server hasn't yet received the message, the thread would be SEND-blocked; a thread waiting for an answer is REPLY-blocked, and so on.

channel

Message passing is directed towards channels and connections, rather than targeted directly from thread to thread. A thread that wishes to receive messages first creates a channel; another thread that wishes to send a message to that thread must first make a connection by "attaching" to that channel.

signal

Asynchronous event notifications that can be sent to your process. Signals may include:

• simple alarms based on a previously set timer
• a notification of unauthorized access of memory or hardware
• a request for termination
• user-definable alerts

The OS supports the standard POSIX signals (as in UNIX) as well as the POSIX realtime signals. The POSIX signals interface specifies how signals target a particular process, not a specific thread. To ensure that signals go to a thread that can handle specific signals, many applications mask most signals from all but one thread.

You can specify the action associated with a signal by using the sigaction() function, and block signals by using sigprocmask(). You can send signals by using the raise() function, or send them manually using the Target Navigator view (see "Sending a signal" below).

---

For more information on all these terms and concepts, see the QNX Neutrino Microkernel chapter in the System Architecture guide.

---

Logging system information

You can gather system information from a Neutrino target and log it to a file, and then view it later in the IDE. Here's how:

1. Right-click your target in the Target Navigator, and then choose Log With...-->Log from the menu.
2. Select System Information Logging Configuration, and then select the New launch configuration icon () to create a Log configuration.
3. In the Main tab of the log configuration, select the location where you'd like to store the log file.
4. Select the mode to use:
   • Snapshot mode collects all the requested data, and then stops.
   • Continuous mode collects the data, and then continues to collect any changes to the data for the requested period of time at an interval provided (the default is 1 second).
5. Select the Neutrino target and optionally the processes you wish to collect data for.
6. If you wish, switch to the Logging Options tab and select the level of information you require:

   

7. Select Log.

Here are a few things to consider when setting up your log configuration:

• Some types of data require other data. For example, if you want to collect any of the process-level data, you must select Processes in the list of system-level data, as shown in the example of the Logging Options tab above. Similarly, if you want to collect thread-level data, you must select Threads in the list of process-level data.
• If you select specific processes for logging, the IDE doesn't log process data for any new processes (e.g. process IDs show as -1). If you wish to log all processes, including those created during the logging operation, don't select any processes in the process-selection area on the Main tab of the log configuration.

Viewing captured system information

Once the logging process has begun, you'll see a progress monitor for it in the Progress view and the lower right progress area of the main IDE window. You can cancel the logging at any time through the Progress view.

When the logging operation finishes, the IDE presents the captured data as a target in the System Information History View. This view behaves the same way as the Target Navigator view; selecting the target or one or more processes causes the System Information views to display the corresponding data from the log.

To view the data captured over a period of time in continuous mode, drag the time index slider at the bottom of the System Information History view to the point in time where you'd like to view the data; the views update to display the data at that point in time.

To view a log file from a previous logging session, select the Search log files button () in the toolbar area of the System Information History View. This presents you with a dialog showing a list of the log files the IDE has found:

In this dialog, you can set search paths for the IDE to use to find log files that you can load into the System Information perspective. By default any log configurations that you've used to gather information are displayed, along with any log files that were created using it. To load a log file, select it in the tree, and then select Open Log; when the loading is complete, the data from the log file appears as a target in the System Information History view.

Associated views

You use the views in the System Information perspective for these main tasks:

They're described in the pages that follow.