1.2 Scalability
T-Kernel is a real-time kernel for embedded system use, applicable to a wide range of systems large and small. It is aimed at enhancing portability of software such as device drivers and middleware.
The T-Kernel speci.cation is designed to be applicable even to large-scale systems. The approach of de.ning subsets to this end, with functions specified in some subsets but not mandatory in others for small-scale systems, has the disadvantage of hampering portability of device drivers, middleware and other software. Functional requirements also vary widely from one target system to another, making it di.cult to settle on workable subset specifications.
The T-Kernel speci.cation does not adopt a level division or other subset approach. In principle, all operating systems compliant with the T-Kernel speci.cation must implement the speci.cation in it entirety. A target system, however, that does not need all the OS functions is free to implement a scaled-down version of the OS. It is also acceptable to o.er T-Kernel users the option of leaving out functions not used in a target system. The important point here is that it is the user, not the OS provider, who decides which functions to omit.
- The entire speci.cation must be implemented. Scaled-down implementations for specific target systems are allowed.
- Providing users with the means for removing or skipping unnecessary functions is also allowed.
- Middleware must be designed to meet all the T-Kernel requirements. It cannot be limited to specific target systems but must be applicable to a variety of systems and scales.
- Providing users with the means for removing or skipping unnecessary functions is allowed.
A “scaled-down implementation” means one that does not provide the entire range of specified functions but does not behave abnormally (return error, etc.) if a non-implemented function is called. It is important, in other words, that middleware developed for large-scale systems provide an environment enabling it to run without problem on other systems. For example, a system that does not use an MMU can implement the T-Kernel/SM LockSpace() as follows.
#define LockSpace(addr, len) (E_OK)
The absence of an MMU does not, however, make it allowable not to implement LockSpace() or to return the error code E NOSPT.
At the same time, when middleware is created, leaving out LockSpace() from an implementation because the target system does not use an MMU would prevent the middleware from supporting a system that does use an MMU.
Comments