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

stty term=ansi </dev/ser1

Device subsystem performance

The flow of events within the device subsystem is engineered to minimize overhead and maximize throughput when a device is in raw mode. To accomplish this, the following rules are used:

•Interrupt handlers place received data directly into a memory queue. Only when a read operation is pending, and that read operation can be satisfied, will the interrupt handler schedule the driver to run. In all other cases, the interrupt simply returns. Moreover, if io-char is already running, no scheduling takes place, since the availability of data will be noticed without further notification.

•When a read operation is satisfied, the driver replies to the application process directly from the raw input buffer into the application’s receive buffer. The net result is that the data is copied only once.

These rules — coupled with the extremely small interrupt and scheduling latencies inherent within the OS — result in a very lean input model that provides POSIX conformance together with extensions suitable to the realtime requirements of protocol implementations.

Console devices

System consoles (with VGA-compatible graphics chips in text mode) are managed by the devc-con or devc-con-hid driver. The video display card/screen and the system keyboard are collectively referred to as the physical console.

The devc-con permits multiple sessions to be run concurrently on a physical console by means of virtual consoles. The devc-con console driver process typically manages more than one set of I/O queues to io-char, which are made available to user processes as a set of character devices with names like /dev/con1, /dev/con2, etc. From the application’s point of view, there “really are” multiple consoles available to be used.

Of course, there’s only one physical console (screen and keyboard), so only one of these virtual consoles is actually displayed at any one time. The keyboard is “attached” to whichever virtual console is currently visible.

Terminal emulation

The console drivers emulate an ANSI terminal.

Serial devices

Serial communication channels are managed by the devc-ser* family of driver processes. These drivers can manage more than one physical channel and provide character devices with names such as /dev/ser1, /dev/ser2, etc.

When devc-ser* is started, command-line arguments can specify which — and how many — serial ports are installed. On a PC-compatible system, this will typically be the two standard serial ports often referred to as com1 and com2. The devc-ser* driver directly supports most nonintelligent multiport serial cards.

QNX Neutrino includes various serial drivers (e.g. devc-ser8250, devc-serppc800, etc.). For details, see the devc-ser* entries in Utilities Reference.

The devc-ser* drivers support hardware flow control (except under edited mode) provided that the hardware supports it. Loss of carrier on a modem can be programmed to deliver a SIGHUP signal to an application process (as defined by POSIX).

Parallel devices

Parallel printer ports are managed by the devc-par driver. When devc-par is started, command-line arguments can specify which parallel port is installed.

The devc-par driver is an output-only driver, so it has no raw input or canonical input queues. The size of the output buffer can be configured with a command-line argument. If configured to a large size, this creates the effect of a software print buffer.

Pseudo terminal devices (ptys)

Pseudo terminals are managed by the devc-pty driver. Command-line arguments to devc-pty specify the number of pseudo terminals to create.

A pseudo terminal (pty) is a pair of character devices: a master device and a slave device. The slave device provides an interface identical to that of a tty device as defined by POSIX. However, while other tty devices represent hardware devices, the slave device instead has another process manipulating it through the master half of the pseudo terminal. That is, anything written on the master device is given to the slave device as input; anything written on the slave device is presented as input to the master device. As a result, pseudo-ttys can be used to connect processes that would otherwise expect to be communicating with a character device.

Pseudo-ttys.

Ptys are routinely used to create pseudo-terminal interfaces for programs like pterm, a terminal emulator that runs under the Photon microGUI and telnet, which uses TCP/IP to provide a terminal session to a remote system.

Chapter 11

Networking Architecture

In this chapter. . .

Introduction 189

Network manager (io-pkt*) 189

Introduction

As with other service-providing processes in QNX Neutrino, the networking services execute outside the kernel. Developers are presented with a single unified interface, regardless of the configuration and number of networks involved.

This architecture allows:

•Network drivers to be started and stopped dynamically.

•Qnet and other protocols to run together in any combination.

Our native network subsystem consists of the network manager executable (io-pkt-v4, io-pkt-v4-hc, or io-pkt-v6-hc), plus one or more shared library modules. These modules can include protocols (e.g. lsm-qnet.so) and drivers (e.g. devnp-speedo.so).

Network manager (io-pkt*)

The io-pkt* component is the active executable within the network subsystem. Acting as a kind of packet redirector/multiplexer, io-pkt* is responsible for loading protocol and driver modules based on the configuration given to it on its command line (or via the mount command after it’s started).

Employing a zero-copy architecture, the io-pkt* executable efficiently loads multiple networking protocols or drivers (e.g. lsm-qnet.so) on the fly— these modules are shared objects that install into io-pkt*.

The io-pkt stack is very similar in architecture to other component subsystems inside of the Neutrino operating system. At the bottom layer, are drivers that provide the mechanism for passing data to and receiving data from the hardware. The drivers hook into a multi-threaded layer-2 component (that also provides fast forwarding and bridging capability) that ties them together and provides a unified interface for directing packets into the protocol-processing components of the stack. This includes, for example, handling individual IP and upper-layer protocols such as TCP and UDP.

In Neutrino, a resource manager forms a layer on top of the stack. The resource manager acts as the message-passing intermediary between the stack and user applications. It provides a standardized type of interface involving open(), read(), write(), and ioctl() that uses a message stream to communicate with networking applications. Networking applications written by the user link with the socket library. The socket library converts the message-passing interface exposed by the stack into a standard BSD-style socket layer API, which is the standard for most networking code today.

io-pkt

Net application Stack utilities

A detailed view of the io-pkt architecture.

At the driver layer, there are interfaces for Ethernet traffic (used by all Ethernet drivers), and an interface into the stack for 802.11 management frames from wireless drivers. The hc variants of the stack also include a separate hardware crypto API that allows the stack to use a crypto offload engine when it’s encrypting or decrypting data for secure links. You can load drivers (built as DLLs for dynamic linking and prefixed with devnp- for new-style drivers, and devn- for legacy drivers) into the stack using the -d option to io-pkt.

APIs providing connection into the data flow at either the Ethernet or IP layer allow protocols to coexist within the stack process. Protocols (such as Qnet) are also built as DLLs. A protocol links directly into either the IP or Ethernet layer and runs within the stack context. They’re prefixed with lsm (loadable shared module) and you load them into the stack using the -p option. The tcpip protocol (-ptcpip) is a special option that the stack recognizes, but doesn’t link a protocol module for (since the IP stack is already built in). You still use the -ptcpip option to pass additional parameters to the stack that apply to the IP protocol layer (e.g. -ptcpip prefix=/alt to get the IP stack to register /alt/dev/socket as the name of its resource manager).

A protocol requiring interaction from an application sitting outside of the stack process may include its own resource manager infrastructure (this is what Qnet does) to allow communication and configuration to occur.

In addition to drivers and protocols, the stack also includes hooks for packet filtering. The main interfaces supported for filtering are:

Berkeley Packet Filter (BPF) interface

A socket-level interface that lets you read and write, but not modify or block, packets, and that you access by using a socket interface at the application layer (see http://en.wikipedia.org/wiki/Berkeley_Packet_Filter). This is the interface of choice for basic, raw packet interception and transmission and gives applications outside of the stack process domain access to raw data streams.

Packet Filter (PF) interface

A read/write/modify/block interface that gives complete control over which packets are received by or transmitted from the upper layers and is more closely related to the io-net filter API.

For more information, see the Packet Filtering and Firewalling chapter of the Neutrino Core Networking User’s Guide.

Threading model

The default mode of operation is for io-pkt to create one thread per CPU. The io-pkt stack is fully multi-threaded at layer 2. However, only one thread may acquire the “stack context” for upper-layer packet processing. If multiple interrupt sources require servicing at the same time, these may be serviced by multiple threads. Only one thread will be servicing a particular interrupt source at any point in time. Typically an interrupt on a network device indicates that there are packets to be received. The same thread that handles the receive processing may later transmit the received packets out another interface. Examples of this are layer-2 bridging and the “ipflow” fastforwarding of IP packets.

The stack uses a thread pool to service events that are generated from other parts of the system. These events may be:

•time outs

•ISR events

•other things generated by the stack or protocol modules

You can use a command-line option to the driver to control the priority at which the thread is run to receive packets. Client connection requests are handled in a floating priority mode (i.e. the thread priority matches that of the client application thread accessing the stack resource manager).

Once a thread receives an event, it examines the event type to see if it’s a hardware event, stack event, or “other” event:

•If the event is a hardware event, the hardware is serviced and, for a receive packet, the thread determines whether bridging or fast-forwarding is required. If so, the thread performs the appropriate lookup to determine which interface the packet should be queued for, and then takes care of transmitting it, after which it goes back to check and see if the hardware needs to be serviced again.

•If the packet is meant for the local stack, the thread queues the packet on the stack queue. The thread then goes back and continues checking and servicing hardware events until there are no more events.

•Once a thread has completed servicing the hardware, it checks to see if there’s currently a stack thread running to service stack events that may have been generated as a result of its actions. If there’s no stack thread running, the thread becomes the stack thread and loops, processing stack events until there are none remaining. It then returns to the “wait for event” state in the thread pool.

This capability of having a thread change directly from being a hardware-servicing thread to being the stack thread eliminates context switching and greatly improves the receive performance for locally terminated IP flows.

Protocol module

The networking protocol module is responsible for implementing the details of a particular protocol (e.g. Qnet). Each protocol component is packaged as a shared object (e.g. lsm-qnet.so). One or more protocol components may run concurrently.

For example, the following line from a buildfile shows io-pkt-v4 loading the Qnet protocol via its -p protocol command-line option:

io-pkt-v4 -dne2000 -pqnet

The io-pkt* managers include the TCP/IP stack.

Qnet is the QNX Neutrino native networking protocol. Its main purpose is to extend the OS’s powerful message-passing IPC transparently over a network of microkernels.

Qnet also provides Quality of Service policies to help ensure reliable network transactions.

For more information on the Qnet and TCP/IP protocols, see the following chapters in this book:

•Native Networking (Qnet)

•TCP/IP Networking