Kernel and Tasks

Like every other operating system, NeuroKernel has a kernel that oversees task creation and termination, resource allocation and security. NeuroKernel is not a conventional operation system that sits on top of a physical hardware. It is a higher level operating system that utilizes web technologies to the user's advantage. Each task is given a task context which contains a task container that runs the user application. The system interfaces of task container can be accessed by the developer using ISystem interface.

Figure 1: Default display manager of NeuroKernel /OS showing the login options

Task processor is responsible with task execution and termination. It decides the eligibility of a remote application for execution. It also handles plugin applications. Task processor can create a tunnel to a bridged task so that it can be plugged into another application. When a plugin is force killed by the task processor, its parent application will also be tagged as suspicious. If more plugins that are requested from the same application gets force killed, the parent application will also be terminated if a certain threshold is reached.

When the system first boots up, a kernel context (Kernel Task Container) is initialized in the web browser then it executes the Kernel task which loads the modules to manage the entire runtime. Kernel task can not be force killed and will live during the entire operating system session.

A User task is a task executed from a collection of system registered applications. User tasks enjoy the privileges given by the kernel when compared to limitations put on remote tasks. A remote application can be registered by the administrator which can also run as a user task and uses the same privileges as the server local applications. It is important to check the privacy and security features of such remote application before registering with the system.

Remote tasks can live anywhere in a remote HTTP server or Cloud file system. Any network node accessible via browser is supported. These applications will have restrictions while accessing system resources. If not flagged as trusted during runtime their access protocol will also be checked constantly. If any anomaly is present in the protocol, it will be force killed immediately by the kernel. Remote applications cannot extend system protocol, and cannot access default file system available via kernel. Peer tasks are the tasks run via the BitTorrent network. NeuroKernel utilizes WebTorrent for its peer-to-peer operations. These P2P applications are also considered as remote applications by the system.

Bridged tasks may be run from a command shell typically from your favourite terminal software or VT terminal application that comes with NeuroKernel. A display must be set for bridged applications to find your browser display. It is automatically set when VT terminal launched from NeuroKernel. An environment variable called NDISPLAY is required. This can be manually set on an external terminal application by setting this environment variable or passing it to the bridged application from the command line. A NeuroKernel application called bexecd must be run to communicate with external terminal. This application will display the NDISPLAY value that needs to be used. Bridged Task technology is a very powerful feature of NeuroKernel and is not limited to shell based applications.

NeuroKernel application can run in workers if desired. It can be registered as such, or a system argument is passed to the application to let the task processor know about the intension. All task types can be run in workers.

Port Authority handles opening and closing ports between tasks. Unregistered remote applications can only listen to named pipes. Only trusted remote applications can craete and listen to any port. Port authority automatically closes open ports when an application terminates.

Shared data is available to all trusted applications. It is important not to use easy to guess shared data entries for important data if remote applications are utilized. Shared data entries can be created as read only which can not be overwritten by other tasks.

Window manager is responsible with creating, destroying and managing windows. It also manages NeuroKernel's powerful plugin system. When a task is created it is automatically assigned a task context which also includes a top level window. Top level window of an application will not be rendered if getMainFrame method of NApplication class is called. Applications must extend NApplication class. Window manager is a sub module of kernel task and is not a separate task.

When an application execution request reaches Kernel, the task processor module asks window manager to allocate a application main window. This top level window is the root to all other windows, dialogs or tool windows created by the application. Windows and controls are created in a tree hierarchy where the top level main window is the root of all. Destroying the main window means exiting the application entirely. User interface of an application will be rendered only if the toplevel window is made visible or painted.

Plugin window is basically a top level window for the plugin application and a normal internal window for the parent application. Window system manages plugin applications seamlessly for the best end user experience. If plugin is an applet view which runs a miniature NeuroKernel system inside with a desktop manager as the plugin application, the menus will not break out of the plugin window. It is possible to position a parent window menu by communicating its exact position with the plugin applet. Applet views can be used for sensitive data access that requires an isolated protocol environment such as financial institutions.

It is possible to write a custom system manager by extending NSystemManager class. It must be registered in place of dspmgr application in the registry. The guide to writing a system manager can be found in Writing System Manager if needed. System manager is also used for remote login. This means that when someone wants to remote login to your server from a work station, your login screen served by your custom system manager will be executed and displayed to the user.

NeuroKernel also offers an interface to input and output to a terminal. A terminal application is available with the default package which is used for terminal IO. The terminal access request is made with getTerminal method which returns an ITerminal interface object, and ITerminalListener is used to manage the input and output operations. Application must be executed from the terminal command line in order to have terminal IO functionality. ITerminal interface object is also passed to the listener methods for more convenient way of interaction.