Sunteți pe pagina 1din 5

QNX ::::

As a microkernel-based OS, QNX is based on the idea of running most of the OS in the
form of a number of small tasks, known as servers. This differs from the more traditional
monolithic kernel, in which the operating system is a single very large program
composed of a huge number of "parts" with special abilities. In the case of QNX, the use
of a microkernel allows users (developers) to turn off any functionality they do not
require without having to change the OS itself; instead, those servers are simply not run.

The system is quite small, with earlier versions fitting on a single floppy disk.[1]

QNX Neutrino (2001) has been ported to a number of platforms and now runs on
practically any modern CPU that is used in the embedded market. This includes the
PowerPC, x86 family, MIPS, SH-4 and the closely related family of ARM, StrongARM
and XScale CPUs.

As of September 12, 2007, QNX offers a license for non-commercial users.

*he QNX kernel contains only CPU scheduling, interprocess communication, interrupt
redirection and timers. Everything else runs as a user process, including a special process
known as proc which performs process creation, and memory management by operating
in conjunction with the microkernel. This is made possible by two key mechanisms -
subroutine-call type interprocess communication, and a boot loader which can load an
image containing not only the kernel but any desired collection of user programs and
shared libraries. There are no device drivers in the kernel. The network stack is based on
NetBSD code.[5] There are three variety of drivers supported: native, legacy io-net and
drivers ported from NetBSD

*VxWORKS
VxWorks started as an improvement on a primitive ROM chip with a 4K kernel sold by
Ready Systems, now a Mentor Graphics product.[2][3] It contained VRTX, which lacked
everything from a file system to a development environment. Wind River created an
accessory called VxWorks that turned the VRTX kernel into an OS and a development
environment. Fiddler and Wilner had negotiated an agreement to sell VRTX with
VxWorks. In 1987, anticipating that Ready Systems was going to cancel its reseller
contract, Wind River developed its own kernel and a smaller, faster, lighter OS – written
by an intern.

VxWorks is a popular real-time multi-tasking operating system for embedded


microprocessor systems, designed by Wind River Systems of Alameda, CA. Like Unix
and Linux, VxWorks is generally compliant with the IEEE's POSIX (Portable Operating
System Interface) standard, version 1003.1b. The current release of VxWorks is version
5.4. VxWorks projects are usually developed in the Tornado 2 Integrated Development
Environment (IDE) which provides for specifying a configuration (e.g., the libraries with
which a project is linked), project builds, and code testing. Code is written is written
C/C++ with segments, usually short, in the target processor's assembly language.
VxWorks runs on many target processors including, but not limited to the following
processors: Motorola PowerPC, 68K and CPU32 cores; MIPS; ARM; Intel X86 (386 and
up) and i960. SPARC/SPARCLite.

1. Introduction to VxWorks Programming

Some of the rudiments of VxWorks programming are presented here. These do not
appear in the same order presented in Ref 1, which should be read by any serious
VxWorks programmer. Rather they reenforce some of the material that can be found
there, but appear in a top-down order, with basic concepts described first, followed by
details.

1.1 Tasks
In VxWorks, the unit of execution is the task, corresponding to a Unix/Linux process.
Tasks may be spawned (i.e., created), deleted, resumed, suspended, and preempted (i.e.,
interrupted) by other tasks, or may be delayed by the task itself. A task has its own set of
context registers including stack. The term thread, while not unknown in VxWorks
jargon, does not exist in a formal sense as in other operating systems. A thread, when the
term is used, may be thought of as a sub-sequence of connected program steps inside a
task, such as the steps the VxWorks kernel performs in spawning a task, or the sequence
of instructions in an else-clause following an if-statement. Tasks can communicate with
each other in a manner similar to Interprocess Communications in Unix and Linux.

Tasks are in one of four states, diagrammed in Figure 1-1, adapted from Ref. 1.

Figure 1-1 Task State Diagram

A newly spawned task enters the state diagram through the suspended state.

Tasks may be scheduled for execution by assigning them priorities, ranging from 0
(higest priority) to 255. Once started, that is, having entered the ready state in Figure 1, a
task may execute to completion, or it may be assigned a fixed time slice in round-robin
scheduling. A task blocks (enters the pended state) while another task takes control. A
task may be prempted because it has consumed its time slice, or because another task
with higher priority exists. Task priorities may be changed during execution. A task may
avoid being preempted by locking the scheduler while it has control. (This does not
prevent interrupts from occurring.)

A task may also enter the delayed state, for example while waiting a fixed time between
reading samples within a task before processing them as a group, during which time
another task may take control. The delay is controlled by an external timer which runs
independently of processing (combined with a tick counter maintained by the kernel) that
awakens the delayed task and avoids having the task tie up resources with an index
counter which would prevent another task from executing.

The suspended state is used to halt a task for debugging without loss of its context
registers.

Several system tasks exist concurrently with user defined tasks. These are the root task,
named tUsrRoot; the logging task tLogTask; exception task tExcTask; and the network
task tNetTask.

Intertask communication (corresponding to Unix/Linux Interprocess Communication)


can occur through semaphores that provide interlocking and synchronization of tasks, and
messaging that allow tasks to communicate events or data with each other. Although
semaphores and messaging are implemented with different kernel mechanisms, it is
customary to treat them together.

Semphores can be categorized as ordinary binary semaphores and a special class of


binary semaphores called mutual exclusion semaphores. Binary semaphores are used for
task synchronization. As implemented in VxWorks, a binary semaphore has two values:
full and empty. When full, it is available for a task. When empty, it is unavailable. A
pending task proceeds by taking an available semaphore, which makes the semaphore
empty or unavailable.. When the semaphore is no longer needed (because the task is
about to return to the pending state), it gives the semaphore which makes it full or
available for another task. A mutual exclusion semaphore (also called a mutex) allow
one task to have exclusive use of a resource while it is needed.

The difference between an ordinary binary semaphore and a mutex semaphore is in the
way the semaphore is initialized. For an ordinary binary semaphore, a task attempting to
synchronize to an external event creates an empty semaphore. When it reaches the point
to be synchronized, it attempts to take a semaphore. If unavailable, it waits at this point.
A second task which controls the synchronization event gives the semaphore when it is
no longer needed. The first task receives notification that the semaphore is available and
proceeds. For a mutex semaphore, a task wishing to block other tasks from a resouce
first creates a full semaphore, and then takes the semaphore, making it unavailable to
other tasks. When it is no longer needed, it the task gives the semaphore, making the
resource available. A mutual exclusion semaphore must have matching "takes" and
"gives".
Kernel (computing)
From Wikipedia, the free encyclopedia

(Redirected from Kernel (software engineering))


Jump to:navigation, search

A kernel connects the application software to the hardware of a computer.

In computing, the kernel is the central component of most computer operating systems; it
is a bridge between applications and the actual data processing done at the hardware
level. The kernel's responsibilities include managing the system's resources (the
communication between hardware and software components).[1] Usually as a basic
component of an operating system, a kernel can provide the lowest-level abstraction layer
for the resources (especially processors and I/O devices) that application software must
control to perform its function. It typically makes these facilities available to application
processes through inter-process communication mechanisms and system calls.

Operating system tasks are done differently by different kernels, depending on their
design and implementation. While monolithic kernels will try to achieve these goals by
executing all the operating system code in the same address space to increase the
performance of the system, microkernels run most of the operating system services in
user space as servers, aiming to improve maintainability and modularity of the operating
system.[2] A range of possibilities exists between these two extremes.

S-ar putea să vă placă și