As for T-Kernel, its source code is scheduled to be made public worldwide as open source in December 2003. After the source code has been made open, based on Project Leader Sakamura's concept of "100 year software," the functions of T-Kernel will come to be fixed as a specification.
In the T-Engine Forum, we have carried out a final study and adjustments of the specification aimed at this opening up of the kernel. The T-Kernel source code during this work was released on a limited basis to forum members, and evaluations and verifications have been carried out.
The study was not just the T-Kernel functions and specifications, but rather it was also carried out in regard to the readability of the source code. However, under Project Leader Sakamura's thinking that even if we make the source public, it's meaningless if it is difficult to read, the source code and the comments were adjusted. In regard to the comments, on the premise that T-Kernel will be used internationally, they have all been entered in fine detail in English.
Where T-Kernel differs with lots of other open source programs is the fact that the source code has been made into and is managed as single source. The distribution of a changed T-Kernel is basically not permitted, and the T-Kernel source code always consists of one.
This is something that is necessary in order to realize the "platform for middleware distribution" that T-Engine, which includes T-Kernel, has as its goal, and, for middleware to be distributed, it is important that the OS that serves as its base be "one." In other words, T-Kernel is not just a simple operating system, it is something that is the fruit of a "standardization" project. As for T-Kernel code, we can think of that itself as part of a specification for strong standardization.
Previously, "weak standardization" was carried out with ITRON. This was something that was useful to embedded devices where the hardware wasn't made along common lines, but it led to the birth of many µITRON-specification OSs that differed slightly in terms of their functions. As a result, there occurred a state in which software that ran on top of a certain µITRON-specification OS didn't run on top of another µITRON-specification OS. This formed a great obstacle in accumulating µITRON middleware. At present, when the amount of middleware and application software resources that run on top of a kernel is being raised as one the important items in its evaluation, this is a very great problem.
In the T-Engine project, we have aimed principally at the distribution of middleware from the outset, and we have attempted standardization from a hardware level called the T-Engine board. As for programs written in accordance with T-Engine operation methods, as long as they do not depend on a unique hardware function, the goal is to run them just through recompiling even though the CPU, for example, is different. For this purpose also, there is a need to make the T-Kernel source code single source and fix its functions.
In other words, various variations of the T-Kernel appearing in the world is not permitted.
In regard to the single sourcing of T-Kernel source code, because several misunderstandings have also come into being, I would like to lay down for the future some explanations.
First, as for the biggest of the misunderstandings, there is the one that states that "T-Kernel doesn't allow for changes." This, of course, is an error, as changing and using the T-Kernel source code is not a problem. When using T-Kernel in a product, and also when using T-Kernel in experiments and test manufacturing, no one cares whether you freely modify the source code.
What is prohibited is a party redistributing a changed T-Kernel. This, as already mentioned, is for the purpose of preventing various variations of the T-Kernel coming into existence and thus hindering the distribution of middleware.
Actually, with embedded device products, there are not a few cases in which the functions and limitations of hardware greatly differ with the T-Engine standard hardware environment. In these types of cases, the optimization (changing) of T-Kernel is necessary, and there is no problem in embedding a changed T-Kernel in products and distributing it.
As for the next misunderstanding, there is the one that goes "because T-Kernel cannot be changed, it cannot be ported to a new CPU." I will give an explanation in detail in the following section concerning this, but with T-Kernel source code, we have clearly divided the basic parts as an OS in which there are portions that are dependent on hardware and those that are not, and thus making the source code single source and fixing the specification applies only to the portions that are not hardware dependent.
It is possible for T-Kernel to be compatible with various types of hardware without changing the source code of its basic parts. At the present stage, T-Kernel is running on CPUs with different architectures, such as ARM, SH, and MIPS, but the basic source code is all the same (in Table 1, I show a list of T-Engines that are compatible at the time T-Kernel will be made open in December).
|
|
|
| Standard T-Engine/SH7727 | µT-Engine/M32104 |
| Standard T-Engine/SH7751R | µT-Engine/VR4131 |
| Standard T-Engine/VR5500 | |
| Standard T-Engine/ARM920-MX1 | |
| Standard T-Engine/ARM720-S1C | |
As I would also like you to understand from what I have mentioned up to here, the making of T-Kernel into open source is something that is different from the famous GNU license (GPL). For this, I believe, the point that T-Engine project has kept in mind a different world from personal computers called embedded devices is of great significance. As you know, with GPL, when you use GPL software in a portion of your software, it is necessary in accordance with the GPL to make public all the source code of that software, and when this is the software of home appliances, cell-phones, control devices, and the like, making public that source leads to many difficult cases for a maker. With T-Kernel, there is absolutely no necessity to make public that source code, even though you have used T-Kernel in a product. On the other hand, in order to guarantee the distribution of middleware, the making public and distribution of changed T-Kernels is limited.
As for real-time OSs, in terms of their properties, to a greater or lesser extent, there exist parts that depend on the CPU or other hardware functions. For example, interrupt and exception processing, the processing of registers at the time of task switching, the measuring of system time, and so forth correspond to this. Moreover, for the hardware-dependent processing of these things, there are also cases when writing with just C language is difficult or impossible, and thus writing in assembly language becomes necessary.
Almost all of the T-Kernel source code is written ANSI-based standard C language, and we have done the utmost to make the hardware-dependent parts few in number, but, nevertheless, in regard to the hardware-dependent parts, we have made them compatible in the following manner.
At the time the hardware power supply is turned on, startup processing and the basic handling of interrupts and exceptions are carried out not by T-Kernel, but by a program called T-Monitor. T-Monitor, figuratively speaking, is the BIOS of T-Engine, and it provides hardware-dependent, low-level functions and hardware level debugging functions.
T-Monitor is a program that is completely dependent on hardware, and thus there is a need to prepare it for each hardware platform. However, because individual T-Monitors are implemented as standard equipment on T-Engine boards there is no need to separately prepare a T-Monitor. In a case where you are porting T-Kernel to original hardware, there will be a need to create a T-Monitor; the basic functions of T-Monitor can be easily created if one refers to the T-Kernel implementation specification.
In T-Engine processing, hardware-dependent parts are called "system dependent parts." Parts outside of system dependent parts, in other words, parts that are not dependent on hardware are called kernel basic parts.
Kernel basic parts and system dependent parts are clearly separated inside the directory configuration of the source code. What I show in Fig. 1 is an outline of the directory configuration of T-Kernel; in this, the hardware-dependent source code is stored in the directory named "sysdepend." The cpu directory and the device directory have been placed under the sysdepend directory, and source code dependent on the CPU has been placed in the former, and source code dependent on hardware other than the CPU has been placed in the latter. The separation of the two is in order to make porting easier when creating new hardware using a CPU that T-Kernel has already been made compatible with.
 |
|
In the system dependent parts of T-Kernel, outside of parts that are dependent on hardware, there are also parts that are dependent on OS extensions. Extensions run on top of T-Kernel, and they are system programs that realize higher level OS functions. Also, by switching extension parts, it becomes possible to realize the functions of a different OS on top of T-Kernel.
When we switch extensions, changes also occur in the T-Kernel source code. These are mainly processes concerning with the initialization of the extension and the management of memory, and these extension dependent parts also are made into system dependent parts that are collected together and stored in the extension directory.
The separation of the kernel basic parts and the system dependent parts has the following meanings.
First, the raising of portability can be mentioned. When porting T-Kernel to different hardware, compatibility becomes possible just by modifying the source code under the "sysdepend" directory. Also, in a case where that hardware is using a CPU that T-Kernel has already been made compatible with, what we modify is only the "sysdepend/device" directory.
Second is the problem of the changing of T-Kernel. In a case where T-Kernel has been changed, one cannot redistribute that changed T-Kernel. However, there is a problem in regarding as changed something in which along with no changes made to the functions of T-Kernel there was just porting to a new CPU. Therefore, we make only the kernel basic parts the subject by which we regard the source code as being changed, and we make the system dependent parts things that we exclude--and, by means of this, porting to a new CPU or hardware becomes possible without changing T-Kernel.
The above article on T-Engine appeared on pages 28-29 in Vol. 84 of TRONWARE . It was translated and loaded onto this Web page with the permission of Personal Media Corporation.
Copyright © 2003 Personal Media Corporation
Copyright © 2003 Sakamura Laboratory, University Museum, University of Tokyo