Winux Micro-Kernel Requirements

---

1. Job Control
2. Kernel System Manager

1. Userland API
2. Kernel API

The Winux Kernel is a hybrid kernel. To the running programs and most developers it seems like the monolithic kernels that dominate the operating system world. However, when one dives deeper into the design, the Winux Kernel is a wonderfully designed micro-kernel system that presents itself to the world of users and applications as a monolithic kernel.

The Winux Kernel achieves its monolithic kernel looks by presenting itself to the world through only one of its subsystems (Winux Userland/Actual OS). This system handles alls the requests from userland and divides them up to where they are to go in kernel land. Additionally, it provides a system, the API Controller system (a.k.a API Converter System) that allows multiple system to run natively on a Winux-based computer by loading the appropriate API module. Finally, this system provides one more essential feature, in that it runs a second scheduler that is subserviant to the Winux Micro-Kernel's scheduler.

The Winux Kernel also has specific subsystems that handle Device Drivers/modules, networking, registry for storing settings, memory, and other systems that are normally part of the whole kernel. Thus, the Winux Micro-Kernel is responsible for only a small set of responsibilities, which are as followes:

• Primary Process/Job Scheduling
• CPU management
• Primary System Management
• Resource Management
• Process creation
• System Initialization

1. Job Control

   Jobs scheduling is broken into two parts: the primary and the secondary scheduler. The primary schedule, which is part of the Winux Micro-Kernel, is the master scheduler, and allocates time between the Winux Kernel tasks (all the sub-systems) and the secondary scheduler, located within the Actual OS sub-system.

   The secondary scheduler is responsible for allocating time between all userland tasks, but any task may be preemted by a task from the primary scheduler. Likewise, the primary scheduler will also operate in a pre-emptive multitasking mode.

   Requirements Home Table of Contents
2. Kernel System Manager

   As with any kernel, computer resources must be managed. This can be as simple as letting software manage the resources like Unix does, or as complex as doing deadlock detection like Microsoft Windows. The Winux Kernel seeks to take a median between the two. By acting like Unix, speed and performance are greatly enhanced, but by providing mechanisms, ala the SITS Shell, to do the more complex, performance eating tasks we also gain the stability for applications given by doing things like deadlock detection. Thereby, the Winux Micro-Kernel must provide the ability to manage the entire system while handing out certain parts, such as device driver management, to the necessary sub-systems, in this case the HAL.

   Requirements Home Table of Contents

The Winux system is to provide a rather complex API system that will be broken into two groups: (1) Userland API's and (2) the Internal Kernel API.

1. Userland API

   The Userland API will be handled by the Winux Userland subsystem (a.k.a. Actual OS). This part of the API will provide API plugins (converters) that will translate between foreign API's and our native API. To applications it will speak whatever API is available in the API converter modules that are installed and loaded. To the kernel it will speak the native API.

   There will be two kinds of API modules. First there will be the native API module that provides the native interface for applications that desire to be native applications to the system. All others API modules will have an external interface that complies with the API it is converting from, and when communicating with API system it will be making any and all calls needed, whether to the native API module (for simplicity) or internal API system, in order to provide the same function as that which was called. Each application will receive its own instance of the foreign APIs so as to make it easier for the system to provide conversion between structures and objects.

   Requirements Home Table of Contents
2. Kernel API

   The Kernelland API will provide all the functions of a normal API in a secure manner. The Microsoft Win32 API is an insecure API because of who it speaks with itself and applications, for instance void pointers. The Kernelland API will do all it can to keep from making the same mistakes and pass known structures whenever possible. The Kernel API (a.k.a. KPI) will be designed to provide for all the functions needed betweent he Kernel subsystems. Additionally, it will need to be statically linked to the Winux Micro-Kernel, HAL, and Memory Management systems, though it may be dynamically linked to all the other sub-systems.

   Requirements Home Table of Contents