T-Engine Forum Middleware Distribution
Working Group Activities

An Approach to the Distribution of Middleware

Koichi Sato

YRP Ubiquitous Networking Laboratory

One of the greatest objectives of the T-Engine project is realizing the distribution of middleware. Toward that end, for strong standardization, the project prescribes a hardware specification, and for T-Kernel, which is a real-time kernel, we have established a stricter specification than with ITRON up to now. Also, we have made it possible for T-Kernel to dynamically load and execute programs by equipping it with functions for MMUs and the automatic creation of object IDs, and thus the system embedding of obtained middleware has become easy.

In the T-Engine Forum, we are carrying out various initiatives for the purpose of realizing not just the standardization of hardware and a real-time kernel made in this manner, but also middleware distribution. For example, we have drawn up such things as T-Format, which determines the format for describing programs and their binary formats, and standard device driver API specifications. In this article, I would like to introduce these initiatives.

T-Format

T-Format is rules for making it possible to construct a system by combining together middleware that multiple vendors provide. In concrete terms, it fixes such things as program formats and global variable name rules. I think we could say that these are the minimum provisions for middleware distribution. Furthermore, what we are making the object of middleware here are applications that run on top of the T-Engine/T-Kernel environment and other software that provide some type of service to middleware, which is middleware is in the "broad sense" of the meaning, including also such things as device drivers and libraries that we will distribute (in contrast to this, we call software modules realized using T-Kernel-specification subsystems middleware in the "narrow sense"). Below, I shall introduce the items that have already been prescribed at present.

Vendor Code

It has come about that vendors who provide middleware products on T-Engine shall obtain a vendor code. A vendor code is a code that is formed from three or more but within eight alphanumeric characters, and thus is something that uniquely distinguishes each vendor. For example, the YRP Ubiquitous Networking Laboratory has obtained the code 'unl'. To obtain a code, each vendor makes a request for the desired code to the T-Engine Forum's secretariat, and acknowledgement and registration of it are carried out on the secretariat side.

Program Binary Format

We have made satisfying the Executable and Linking Format specification a necessary requirement. However, concerning parts that cannot be prescribed in the ELF specification as they are parts that depend on such things as the CPU and the compiler, it has been decided to follow implementations based on a GNU base reference development environment that the T-Engine Forum will determine separately.

C Language Global Symbol Name

This mainly has as its goal preventing disorders when linking programs that different vendors provide. In particular, this prescribes identification of global symbol space that library format middleware provides. I show below examples of prescribed items.

Middleware file name

We express this with "vendor name + function name (+ detailed function name)."

Ex.: unl_mpeg2_basic.h

The basic header file of an MPEG2 processing program that the vendor possessing the vendor code unl created

Function name to be exported

We express this with "vendor name + function name (+ detailed function name) + function identifier."

Ex.: unl_mpeg2_decode( . . . );

Global variable name to be exported

We express this with "vendor name + function name (+ detailed function name) + variable identifier."

Ex.: char *unl_mpeg2_bufptr;

Beside these, it prescribes the naming methods of such things as data type names and constant macros that are used with global variables.

Standard Device Driver Specifications

In T-Engine, we have prescribed a device driver incorporation method through the Device Management Function specification of T-Kernel System Manager (T-Kernel/SM). In other words, in Fig. 1, a specification has been decided for an application interface for an application to call up a device driver function, plus a device driver interface to be prepared on the device driver side.

Figure 1. Device Management Function

When implementing a device driver, the Device Driver Interface specification must be followed. In concrete terms, the implementation of such things as an open/close function, a read/write processing function, a wait completion function, an event processing function, and a suspend processing function have been prescribed. By means of these, it becomes possible to realize through the same mechanism processing and abort processing at the time of event creation that is related to the entire system, and thus it is possible to lighten the burden at the time of system construction.

On the other hand, application interfaces are prescribed as system calls, and it is possible to utilize device driver functions from applications and higher level middleware with the same procedures, such as a non-synchronous wait completion method.

And then, not only did we draw up provisions for the kernel specification made in this manner, but in order to promote the distribution of middleware, we have also drawn up standard device driver specifications centering on devices that we normally support on T-Engine. By means of these, higher level middleware can be utilized as is even on different systems. For example, even on a system where the CPU is different, it becomes possible to utilize higher level middleware if we recompile it.

In concrete terms, we have drawn up standard device driver specifications for the following devices.

Serial communications device
LAN network interface device
System disk (PC card type, USB storage, RAM/ROM disk)
eTRON chip SIM interface device
Clock device
Keyboard/pointing device
Screen (display) device
Audio/voice device
MIDI device

Besides these, we have drawn up device manager specifications for USB and PCMCIA. These device managers control the USB Host Controller and the PCMCIA Controller, and they are things that provide services to device drivers that deal with each USB device and each PCMCIA device located at a higher level (higher level device drivers). As an example, I show the USB Manager positioning in Fig. 2. When an external device is newly connected to the USB interface, the USB Manager sends an attach event to the USB device driver that has been registered beforehand, and it also provides a data send/receive function between the match-up and the end point.

Figure 2. The positioning of the USB
Manager

Through the drawing up of device manager specifications, the drawing up of those higher level device driver specifications and their implementation becomes possible, and it also comes about that the higher level device drivers can be utilized on any system with basically the same program code.

Furthermore, that these standard device driver specifications are also made up into things that have taken into consideration real-time performance in embedded systems is a big merit of T-Engine.

Moreover, in the T-Engine Forum, in order to support device driver development, we are also carrying out activities such as creating and releasing programs that serve as a reference, and drawing up implementation guidelines.

The above article on T-Engine appeared on pages 30-31 in Vol. 84 of TRONWARE . It was translated and loaded onto this Web page with the permission of Personal Media Corporation.