Литература_1 / sys_arch

•fstat(fd,..), which fills in the stat structure as it does for a shared memory object, except that the size field doesn’t hold the size of the typed memory object.

•close(fd) closes the file descriptor.

•dup() and dup2() duplicate the file handle.

•posix_mem_offset() behaves as documented in the POSIX specification.

Practical examples

Allocating contiguous memory from system RAM

int fd = posix_typed_mem_open( "/memory/ram/sysram", O_RDWR, POSIX_TYPED_MEM_ALLOCATE_CONTIG);

unsigned vaddr = mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);

Defining packet memory and allocating from it

Assume you have special memory (say fast SRAM) that you want to use for packet memory. This SRAM isn’t put in the global system RAM pool. Instead, in startup, we use as_add() (see the Customizing Image Startup Programs chapter of Building Embedded Systems) to add an asinfo entry for the packet memory:

as_add(phys_addr, phys_addr + size - 1, AS_ATTR_NONE, "packet_memory", mem_id);

where phys_addr is the physical address of the SRAM, size is the SRAM size, and mem_id is the ID of the parent (typically memory, which is returned by as_default()).

This code creates an asinfo entry for packet_memory, which you can then use as POSIX typed memory. The following code allows different applications to allocate pages from packet_memory:

int fd = posix_typed_mem_open( "packet_memory", O_RDWR, POSIX_TYPED_MEM_ALLOCATE);

unsigned vaddr = mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

Alternatively, you may want to use the packet memory as direct shared, physical buffers. In this case, applications would use it as follows:

int fd = posix_typed_mem_open( "packet_memory", O_RDWR, POSIX_TYPED_MEM_ALLOCATABLE);

unsigned vaddr = mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, offset);

Defining a DMA-safe region

On some hardware, due to limitations of the chipset or memory controller, it may not be possible to perform DMA to arbitrary addresses in the system. In some cases, the chipset has only the ability to DMA to a subset of all physical RAM. This has

traditionally been difficult to solve without statically reserving some portion of RAM of driver DMA buffers (which is potentially wasteful). Typed memory provides a clean abstraction to solve this issue. Here’s an example:

In startup, use as_add_containing() (see the Customizing Image Startup Programs chapter of Building Embedded Systems) to define an asinfo entry for DMA-safe memory. Make this entry be a child of ram:

as_add_containing( dma_addr, dma_addr + size - 1, AS_ATTR_RAM, "dma", "ram");

where dma_addr is the start of the DMA-safe RAM, and size is the size of the DMA-safe region.

This code creates an asinfo entry for dma, which is a child of ram. Drivers can then use it to allocate DMA-safe buffers:

int fd = posix_typed_mem_open( "ram/dma", O_RDWR, POSIX_TYPED_MEM_ALLOCATE_CONTIG);

unsigned vaddr = mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

Pipes and FIFOs

To use pipes or FIFOs in QNX Neutrino, the pipe resource manager (pipe) must be running.

Pipes

A pipe is an unnamed file that serves as an I/O channel between two or more cooperating processes—one process writes into the pipe, the other reads from the pipe. The pipe manager takes care of buffering the data. The buffer size is defined as PIPE_BUF in the <limits.h> file. A pipe is removed once both of its ends have closed. The function pathconf() returns the value of the limit.

Pipes are normally used when two processes want to run in parallel, with data moving from one process to the other in a single direction. (If bidirectional communication is required, messages should be used instead.)

A typical application for a pipe is connecting the output of one program to the input of another program. This connection is often made by the shell. For example:

ls | more

directs the standard output from the ls utility through a pipe to the standard input of the more utility.

FIFOs

FIFOs are essentially the same as pipes, except that FIFOs are named permanent files that are stored in filesystem directories.

Chapter 4

The Instrumented Microkernel

In this chapter. . .

Introduction

An instrumented version of the QNX Neutrino microkernel (procnto-instr) is equipped with a sophisticated tracing and profiling mechanism that lets you monitor your system’s execution in real time. The procnto-instr module works on both single-CPU and SMP systems.

The procnto-instr module uses very little overhead and gives exceptionally good performance — it’s typically about 98% as fast as the noninstrumented kernel (when it isn’t logging). The additional amount of code (about 30 KB on an x86 system) in the instrumented kernel is a relatively small price to pay for the added power and flexibility of this useful tool. Depending on the footprint requirements of your final system, you may choose to use this special kernel as a development/prototyping tool or as the actual kernel in your final product.

The instrumented module is nonintrusive — you don’t have to modify a program’s source code in order to monitor how that program interacts with the kernel. You can trace as many or as few interactions (e.g. kernel calls, state changes, and other system activities) as you want between the kernel and any running thread or process in your system. You can even monitor interrupts. In this context, all such activities are known as events.

For more details, see the System Analysis Toolkit User’s Guide.

Instrumentation at a glance

Here are the essential tasks involved in kernel instrumentation:

1The instrumented microkernel (procnto-instr) emits trace events as a result of various system activities. These events are automatically copied to a set of buffers grouped into a circular linked list.

2As soon as the number of events inside a buffer reaches the high-water mark, the kernel notifies a data-capture utility.

3The data-capture utility then writes the trace events from the buffer to an output device (e.g. a serial port, an event file, etc.).

4A data-interpretation facility then interprets the events and presents this data to the user.

Process and thread activity

Instrumented

microkernel

Event buffers

Data-capture

utility

Data filter/ interpretation

Instrumentation at a glance.

Event control

Given the large number of activities occurring in a live system, the number of events that the kernel emits can be overwhelming (in terms of the amount of data, the processing requirements, and the resources needed to store it). But you can easily control the amount of data emitted. Specifically, you can:

•control the initial conditions that trigger event emissions

•apply predefined kernel filters to dynamically control emissions

•implement your own event handlers for even more filtering.

Once the data has been collected by the data-capture utility (tracelogger), it can then be analyzed. You can analyze the data in real time or offline after the relevant events have been gathered. The System Analysis tool within the IDE presents this data graphically so you can “see” what’s going on in your system.

Modes of emission

Apart from applying the various filters to control the event stream, you can also specify one of two modes the kernel can use to emit events:

The trade-off here is one of speed vs knowledge: fast mode delivers less data, while wide mode packs much more information for each event. Either way, you can easily tune your system, because these modes work on a per-event basis.

As an example of the difference between the fast and wide emission modes, let’s look at the kinds of information we might see for a MsgSendv() call entry:

Ring buffer

Rather than always emit events to an external device, the kernel can keep all of the trace events in an internal circular buffer.

This buffer can be programmatically dumped to an external device on demand when a certain triggering condition is met, making this a very powerful tool for identifying elusive bugs that crop up under certain runtime conditions.

Data interpretation

The data of an event includes a high-precision timestamp as well as the ID number of the CPU on which the event was generated. This information helps you easily diagnose difficult timing problems, which are more likely to occur on multiprocessor systems.

The event format also includes the CPU platform (e.g. x86, PowerPC, etc.) and endian type, which facilitates remote analysis (whether in real time or offline). Using a data interpreter, you can view the data output in various ways, such as:

•a timestamp-based linear presentation of the entire system

•a “running” view of only the active threads/processes

•a state-based view of events per process/thread.

The linear output from the data interpreter might look something like this:

TRACEPRINTER version 0.94

-- HEADER FILE INFORMATION --

-- KERNEL EVENTS --

To help you fine-tune your interpretation of the event data stream, we provide a library (traceparser) so you can write your own custom event interpreters.

System analysis with the IDE

The IDE module of the System Analysis Toolkit (SAT) can serve as a comprehensive instrumentation control and post-processing visualization tool.

From within the IDE, developers can configure all trace events and modes, and then transfer log files automatically to a remote system for analysis. As a visualization tool, the IDE provides a rich set of event and process filters designed to help developers quickly prune down massive event sets in order to see only those events of interest.