μT-Kernel 2.0 has been designed by paying attention to the the compatibility with T-Kernel 2.0. Namely, porting between μT-Kernel 2.0 and T-Kernel 2.0 ought to be simple. If only common features are used, a simple re-compilation will do. Even if changes are necessary, the amount of change is small. That is the design goal. So μT-Kernel 2.0 specification is equipped with API designed to fulfill the needs of many systems, including functions that are not always needed in some systems. Although some of these functions are not needed for some target systems or purposes, the approach of defining subsets for such systems has the disadvantage of hampering portability of device drivers, middleware and other software. So μT-Kernel 2.0 standard does not define any subsetting options, and all implementations of μT-Kernel 2.0 specification OS shall offer all the functions in principle.

For features that have strong dependency on hardware such as MMU and FPU, and features that have potential implications for run-time efficiency such as hooks for debug support, the specification allows subsetting as exceptional case. To accommodate the subsetting in this manner, and the desire to keep the distribution and portability of middleware and application high, such software needs to obtain information about the implementation details of μT-Kernel 2.0. μT-Kernel 2.0 has introduced a mechanism, "service profile", to let each implementation of μT-Kernel 2.0 describe implementation details clearly. All μT-Kernel 2.0 implementations shall provide a service profile and provide information on the functions that were omitted to create a subset.

As in T-Kernel 2.0, however, the simple dummy implementation can be applied to those functions that are not required in the target systems.

A "Simple dummy 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 to provide an environment on which a middleware developed for a large system can run without modification. For example, a system that does not use an MMU (Memory Management Unit) may implement the μT-Kernel/SM LockSpace() as follows:

#define LockSpace(addr, len)    ( E_OK )