TEKlib is an open-source library project under the terms of the free MIT software license. By picking from its facilities, it can serve as a
- embedded operating system
- virtual OS target for applications and libraries that would have to be ported to many individual hosts
- component architecture and hosting environment that allows plug-ins and their hosts to be written in a platform-independent way
TEKlib is designed to be largely agnostic as to whether it runs in a shared or seperate address spaces. Its freestanding nature, small footprint and absence of global data recommend it as a layer for portability and code reuse in a wide range of environments; it can be used in userspace applications, kernel modules, plug-ins, in device drivers and on raw hardware.
TEKlib is grouped into small compartments in a common namespace. These modules are built on a component architecture, on top of which all of TEKlib's own and third-party functionality is implemented. Regardless whether they are dynamically loaded or linked into a monolithic application, their usage remains consistent. Also, modules provide the interface for device drivers and are an architectural means for object orientation.
Portability and plug-in scenario
|In this scenario, a regular application uses TEKlib as a cross-platform plug-in mechanism. From the programmer's point of view, TEKlib provides the component interface, on top of which modules can be written for the application at hand.|
|Moreover, TEKlib offers mechanisms for the creation of low-level services, such as hardware abstraction layers, device drivers and file systems. This allows applications and compontents to be ported to embedded hardware directly.|
|Protocols and protocol stacks can be implemented as modules on top of TEKlib's module and component interface — the resulting architecture would then be called a Middleware.|
- Recursive memory management: Allocators can be stacked on top of each other and carry attributes for automatic cleanup and thread-safety; special allocators can implement tighter packing, custom allocation strategies, leak tracking, or operate in user-supplied memory
- TEKlib threads (tasks) are 'heavy-weight', or process-like. They are equipped with means for local storage, individual file descriptors, a reserved set of signals and endpoints for communication. User signals can be synchronized on individually, in sets or by using messages and I/O packets
- TEKlib provides strict asynchronoucy and atomicity throughout its API; the core as a whole never blocks due to latency inflicted by I/O, and it never imposes polling as an inevitable mechanism
- The module interface is inherently thread-safe and provides a referencing scheme for any number of tasks requesting a component, library or device driver at the same time
- Recursive mutexes and an extension thereof, atoms, allow for lookup by name, locking attempts and shared resource arbitration
- An asynchronous device driver interface can be utilized by applications for overlapping I/O; using this interface, TEKlib also implements a portable timer device
- File systems are an extension to device drivers. TEKlib provides a file system namespace for any number of mountpoints (devices) and logical roots (assigns). Handlers are modules implementing roots in the file system; they can be mounted explicitely or initialize themselves on demand. In hosted scenarios, the file system is initially populated with a default handler to occupy the root node, thus abstracting from a host's native file system.
- Inbuilt data structures such as doubly-linked lists, arrays of key/value pairs, nodes with userdata and destructor, hashes and callback hooks
- TEKlib comes with its own, entirely self-contained makefile generator.
See also: Development