OpenRG platforn of Jungo

/* OpenRG Version 4.7 */

OpenRG平台的程序结构
( refer to 《Programmer's Guide v4.7》)

Based on various configuration options, the OpenRG system is comprised of several components of the following types:
• Linux kernel or VxWorks
• Kernel modules
• OpenRG user-mode main program
• Additional user-mode programs

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

16.8.2. Understanding Asynchronous Programming and Main Task Architecture

OpenRG management code logic is handled by Main Task and named "openrg". Main Task is a framework for running entities that provide services, and for controlling network devices. It is responsible for system initialization, reconfiguration, and communication of the reconfiguration events to the various entities, which in turn correspond with the functional tasks. Main Task is also responsible for coordinating dependencies between entities and network devices. For example, it coordinates between a DSL PPP link and a dependent underlying ATM device.

Each Main Task feature consist of two components: an entity and a task. The entity is a basic unit of operation within the Main Task which manages a specific function. Each entity manages a task that carries out its functionality. A task performs a certain function according to the configuration defined by the entity. The Main Task is the coordination logic under which all the entities run.

16.8.2.1. The Asynchronous Nature of Main Task

Since OpenRG management is being handled in a single process which runs all the time, operations should never perform blocking actions. Blocking actions are handled by an event dispatch loop. Main Task provides a callback mechanism to enable actions to be performed while other actions wait for a result. Main Task's general behavior is as follows:

1. Main Task runs a task for the first time by calling the task's open() function.
2. During the task's life cycle, it may need to wait for an external event to occur. This delay may be the result of the task waiting for a timeout or a packet.
3. The task will register a request for the desired event in Main Task's event dispatch loop, specifying a callback function, and return to its caller - usually Main Task.
4. When the registered event occurs, the dispatch loop invokes the callback function to handle the event.
   

16.8.2.2. The Task

A task is a set of functions that implement a certain protocol or service, for example PPP, DNS or HTTP. A task can be characterized as being self-contained and system independent. It does not rely on other tasks, configuration files or any other kind of outside help.

The OpenRG library, libOpenRG, provides the task with rudimentary services such as an event dispatch loop, memory allocation and logging functions. The entire configuration that a task may require is imparted as parameters to its open() function. The task's genuine work is actually performed by the callback function, a pointer which is also given as a parameter to the open() function. It follows that tasks are inherently portable and reusable. To illustrate, the Ping task can be employed in two different ways:

• The DHCP server may use the Ping task to test whether an IP address it is about to lease is already taken by pinging the address in question. The task parameters in this case will be a ping packet, a brief time-out reply and callback functions. All of these are implemented in the DHCP code.
  

• The Web-based management may use the Ping task to implement a 'Connectivity Diagnostics Test' interface screen. The task parameters will be the number of ping attempts, a ten second time-out and callback functions. Again, these parameters are implemented in the Web-based management code.
  

16.8.3. The Entity

An entity serves as a unified API between the task and core logic of the Main Task and the Configuration Database. An entity supports the following operations:

• open - The entity registers itself, so that it will be called on relevant events.
• changed - When rg_conf is modified, the entity must find out if there is an impact on its managed tasks.
• reconf - The entity should reconfigure its tasks based on the old and new values of rg_conf .
• close - The entity should shut down its tasks.

For example, the DNS entity handles the DNS task according to OpenRG's rg_conf configuration database. It initiates the DNS task, and equips it with callback functions that enable it to search for locally configured host names. These names are entered either manually by the user using the Web-based management, or by the DHCP server, which dynamically allocates IP addresses to computers on the network. The architectural advantage of this design is that the task is unaware of the configuration database format, nor of the methods of polling the DHCP server for a host name -- all of these responsibilities are left to the entity.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

25.2.1 Coordination Logic

OpenRG is a multi-threaded multi-process product.
There are many kernel threads which handle the Firewall, Bridge, Route and others;
as well as user mode proccesses which handle the File Server (Sabma), the IPSec (FreeSwan) and others.

• Synchronization issues between processes/threads are avoided. Tasks cannot be interrupted while processing -- only when waiting for a callback.
  

• Context switches are minimized.

• Inter Process Communication (IPC) is simplified -- functional tasks communicate with the Main Task using a simple function call. Conversely, ordinary multi-process design involves information packaging, IPC tunneling and parsing by the receiving side.
  

• Memory footprint is reduced by linking all of the modules together, eliminating code needed for IPC, configuration and synchronization.

At the heart of the system lays the event loop. Main Task is designed as an event-driven application. Events are expired timers, network events (ready for read or write on a file descriptor) or an exception. Each component registers its own handlers for various events; this is usually done upon startup. Since events are used throughout the system, it does not appear explicitly in the following figures. The Coordination Logic is devided into 2 parts:

• Generic which always exists. The major generic part is the Entities mechanism, which serves as a uniform API between tasks and the core logic of the Main Task. Each registered entity is notified on configuration changes, and may affect other entities. Additional information can be found later in this chapter, in Section 25.2.1.1.
  

• Component Specific which belongs to specific components. For example, the TOD client entity, which is a part of the TOD client component, notifies the DHCP Server when a new time was received, so that it can update its lease status. Most components register themself as an entity, thereby are notified on configuration changes. Additional information can be found later in this chapter, in Section 25.2.1.2.

25.2.4 System Services

Inter Process Communication (IPC) is used for communication between the OpenRG process and other processes. For example, L2TP daemon uses IPC to check password for a specific user. IPC is implemeted by listening on a predefined TCP port on lo interface; interested processes need to use either ipc or mgt_client libraries to send commands to the main process and receive the results.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
当前code中的entity信息在“pkg/main/entity.h, entity.c"中定义，主要的entity包括：
dhcp, dns, ddns, igd, snmp, ipsec, h323, rip, ppp, wbm, http, firewall, syslog, igmp, telnet, bridge, route,wpa, tftp, ftp, vpn, voip, cwmp, qos, upnp等。

当前系统中的进程：
openrg, l2tpd, init, keventd, ksoftirqd_cpu0, kswapd, bdflush, kupdated, mtdblockd, ixp425_eth等
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


Boot Sequence

The OpenRG boot sequence proceeds as follows:
1. The boot loader is copied from Flash to RAM if necessary.
2. The boot loader begins executing.
3. The kernel image is decompressed and copied from Flash to RAM.
4. The RAM disk is decompressed and copied from Flash to RAM.
5. The boot loader concludes by starting the kernel.
6. The kernel initializes devices, peripherals and the main kernel thread (PID 1).
7. The kernel executes /bin/init and becomes the init (user mode) process.
8. The init process adds several modules to the kernel using insmod.
9. The init process executes /bin/openrg to start OpenRG.


//