WO2009010982A2

WO2009010982A2 - Software for a real-time infrastructure

Info

Publication number: WO2009010982A2
Application number: PCT/IL2008/000996
Authority: WO
Inventors: Asaf Shelly
Original assignee: Feldman, Moshe
Priority date: 2007-07-18
Filing date: 2008-07-17
Publication date: 2009-01-22
Also published as: WO2009010982A3

Abstract

An operating system having a plurality of interconnected operating system cores each of said operating system cores taking place in a system and each said operating system cores being efficient to exchange data with other operating system cores and applications programs.

Description

SQFTWARE FOR A REAL-TIME INFRASTRUCTURE

Field of the Invention

The present invention relates generally to operating system software, and more particularly, the invention relates to software for managing a realtime infrastructure.

Background of the Invention

An Operating System (OS) is a software (also called, a program) providing a basic tasks performing on a computer. These tasks, mainly related to communication between the main system and peripheral devices, can be such as: inputs (a key pressed on a keyboard, moves of or clicks on a mouse, network signals, etc) and output (displaying a text on a screen, writing data on a hard disk, etc). The OS is responsible for sharing the resources of a computer, and managing and coordinating the activities performed on a computer.

The OSs can be globally classified in a few main families. A multi-user OS allows at least two users to run programs simultaneously. Some OSs can manage up to thousands of concurrent users. A multi-processing OS supports running a program on at least two Central Processing Units (CPUs). A multi-tasking OS allows at least two programs to run concurrently. A multi-threading OS allows different parts of a single program to run at the same time. A real-time OS is a multitasking OS intended for applications with fixed deadlines and based on real-time computing. Theoretically, an OS can be based on one or more of the abovementioned approaches.

An OS generally provides a software platform (called environment) for other programs (called applications or applications programs) running on a computer. Programs must be written to run on top of a particular OS in order to extend the OS's abilities to communicate with peripheral device and users.

The OS acts as a host for application programs running on a computer and offer services to application programs and users, for example, programs access these services through Application Programming Interfaces (APIs) or system calls.

Since the two last decades, the OSs tend to have Graphical User Interfaces (GUIs) employing pointing devices for input, such as a mouse or a stylus.

Executing a program involves the creation of a process by the OS's kernel. The kernel is the central component of the OS and is the real manager of the system's ressources. The kernel creates a process and allocates memory to it before loading the related program code from an external or another memory location into the specifically allocated memory, and starting the process running.

Operating system kernels store various information about running processes. As an example, this information might include: the unique process identifier (program or a part of it), references of the memory used or allowed to be used by said process, the location from which the program was loaded into the memory, the last values of all CPU registers, etc.

Interrupts are signal issued form hardware devices or software components indicating that changes occurred in the behaviour of the hardware. According to the interrupes, the OS is able to deal with these unexpected activities.

When an interrupt is received, the computer's hardware automatically suspends whatever program is currently running to check and to treat an interrupt.

An operating system kernel contains a program called scheduler. A scheduler determines how much time each program spends executing, and in which order the programs (the processes) are executed.

It is an object of the present invention to provide a system allowing to efficiently manage the system's resources. It is another object of the present invention to provide a system having a logical architecture and a physical architecture which allow to manage said system easily when located in few locations.

It is yet another object of the present invention to provide a system that exhibits different behaviors for different types of data used in a communication, which can be real-time streaming data, bulk files, interrupting events, etc.

It is still another object of the present invention to provide a system allowing any communication protocol to be supported, including those added in the future, in order to manage all peripheral device of a system.

Further purposes and advantages of this invention will appear as the description proceeds.

Summary of the Invention

An operating system having a plurality of interconnected operating system cores each of said operating system cores taking place in a system and each said operating system cores being efficient to exchange data with other operating system cores and applications programs. Said operating system is configured to manage securely communication and data flows between all the components of a system. Furthermore, the present invention includes a plurality of operating system cores which are grouped in subsets of operating system cores and linked to one another. Each operating system core is able to communicate, with other operating system cores and applications programs, using all available communication protocols and all new communication protocols are implementable. Moreover each task submitted to the system can be optionally replicated in at least two operating system cores. This replication of tasks in at least two operating system cores allows system crash tolerance and each task is submitted to a particular operating system core according to its systems capabilities. Replication between operating system cores is a transparent process for the End-user. A system core CPU manages a plurality of operating system cores.

All the above and other characteristics and advantages of the invention will be further understood through the following illustrative and non-limitative description of preferred embodiments thereof, with reference to the appended drawings; wherein similar components are designated by the same reference numerals.

Brief Description of the Drawings

In order to better understand the invention and to see how it may be carried out in practice, a preferred embodiment will now be described, by way of a non-limiting example only, with reference to the accompanying drawings, in which:

- Fig. 1 is a schematic representation of the logical model of the OS Core model of communication with applications;

- Fig. 2a is another schematic representation of the OS Core model of communication with applications;

- Fig. 2b is an example of the schematic representation of the OS Core model of communication with applications;

- Fig. 3 is a schematic representation of the hierarchic relationships between applications managed by the OS Core based on filter patterns;

- Fig. 4 is a schematic representation of the data flow into the OS Core;

- Fig. 5 is a schematic representation of the internal layout of an application;

- Fig. 6 is a schematic representation of the task dispatch function of an application into the OS Core.

Description of Preferred Embodiments

The applications, that is to say software, in the present invention system possess defined software interfaces with the external world, that is to say any element (e.g., OS Core, other applications, user, etc..) which is not embedded into the application. According to some embodiments of the present invention, these interfaces are implemented as following:

- Input terminal and queue, for input data;

- Output terminal and queue, for output data;

- Design Interface, in order to define application layout and interfaces;

- Control Interface, allowing defining operation and functional controls;

- Configuration Persistence, allowing saving state and reloading state of the system at a previous date;

- Traffic Control, which records all the application events;

- Debug Interface, allowing to test said application; and

- Watchdog, checking in real-time if the application is still alive.

According to some embodiments of the present invention, applications in the present invention system may implement the following functionalities:

- Input Queue, allowing stacking data incoming in an application;

- Output Queue, allowing stacking data outcoming in an application;

- Buffer Veto and Buffer Vote, respectively allowing, blocking or voting regarding the right of an application to run;

- Buffer Modify, can modify the buffers;

- Design Description, allowing to describe the internal application design including: Controls, Interfaces, States, Operations, etc;

- Save Configuration, allowing saving the configuration of an application; - Load Configuration: reload a saved configuration with the Save Configuration function;

- Filtered Log: send logs (saved events of the application) that match a rule set, in order to extract particular events of the system;

- Full Log: send a full log of all traffic, controls, and operations;

- Filtered Prohe: send runtime information that match a rule set;

- Full Probe: send all runtime information available;

- Record: send all information that affects operations;

- Snapshot: pause, take a snapshot of all information and configuration, and resume;

- Enumeration: list all connected applications, objects and system resources;

- Interrupt: raise event in the case of predefine an exceptional event takes place;

- Data Frame Group: A list of incoming Data Frames to produce a single output Data Frame appropriate for the next application;

- Data Mask: match a Mask on the input Data Frame to determine the applications that should receive the output Data Frame;

- Watchdog Keep Alive: notify the system that the application is still functional;

- Error Report; notify the system about an error or bug and the consequences, such as restart required, errors on last data frames, low resources, etc, of said application; - Live Update: pause, Save Configuration and Queue, Detach from upper application with suspend notification, and notify new version that it can load, restore and resume.

According to an embodiment of the present invention, a set of functionalities are implemented in order to allow tests related to the application running.

- Simulation Playback: use recorded information to reproduce recorded behavior;

- Simulation Inject: generate traffic internally that simulates extreme conditions for the receiving end;

- Simulation Trace: generate internal behavior and traffic as specified by a manually engineered source;

- Simulation Stress: simulate the internal behavior that corresponds to internal overload such as high latency, bit-errors, random drop, etc. This is according to the functional behavior and common stress conditions for a given application;

Fig. 1 is a schematic representation of an embodiment of the present invention, in which the engine is indicated by numeral 100.

Data output from the engine is raw data. The first application receives the raw data and then prepares the data for the next application below it. The data sent (as input) to an application is a "Data Frame". Tlie Data Frame for the first application is the raw data. The standard architecture of a data frame is structured in four blocks (also called buffers). Since the order of blocks is defined by system design, as an example, the first one is the identification of the source (as input) of the data frame; the second block is the identification of the destination of the output; the third bloc relates to data; the fourth is a control sequence. According to one embodiment of the present invention a block can be empty.

According to an embodiment of the present invention, an application can send a Data Frame to any permitted application. This is a Command or a Function Invocation. The application does that by specifying the destination application. An application can also use "Next In Line" as the destination which will send to all applications that appear after this application in the block diagram of Fig. 1. The application can also specify "Caller" as the destination which will send the Data Frame to whomever sent the original Data Frame to it.

According to the architecture of the data frame, the applications recognize any protocol. The Design Interface allows defining adequate rules in order to define the inputs and the outputs of an application. More generally the architecture of this type of data flow allows supporting any network protocol, including those that may be added in the future. Each application is responsible for preparing the Data Frame for the subsequent applications, and subsequent application is responsible for specifying the patterns of Data Frames that it can receive and handle in order to extract relevant data in the Data Frame.

According to an embodiment of the present invention, the application replies with a modified frame, in order to be in accordance with network filtering model and not when working with e.g. a word processor, and a decision into the control sequence, that can be: Allow, Block, Voting, with/without data modification. Data modification may require re-voting by other applications as the data flows back.

According to an embodiment of the present invention, an HTLM file can be checked as follow. The OS Core receives a Data Frame from another application and the OS Core emits a Data Frame 105 to the application TCP/IP 103 which formats it to be able to make use of it and to send the new Data Frame 109 to the HTTP application 113. The HTTP application 103 formats it to be able to make use of it and to send the new Data Frame 117 to the MIME application 119. The MIME application 119 generates a decision and modifies if necessary the data frame 115 and send it back to HTTP application 113. The HTTP application 113 generates a decision and modifies if necessary the data frame 111 according to the previous decision 115 and send it back to TCP/IP application 103. The end-decision 107 is sent back to the OS Core 101. According to another embodiment of the present invention, Fig. 2a is view of the OS Core model 200 of communication with the applications by the intermediate of the Access Control Layer 228.

According to yet another embodiment of the present invention, the Access Control Layer 228 is responsible for all access permissions and security filtering. According to this, the Firewall 208 starts working when the system is initialized; the Firewall 208 sends a set of patterns or rules to the Access Control Layer 228 and can then stop working because Access Control Layer 228 can do the work. It is possible for the Firewall 208 to send a rule to the Access Control Layer 228 that will wake up the Firewall 208 for given events (using the Interrupt interface of the Firewall 208 application). The system supports applications that can do the filtering themselves, so it is still possible for the Firewall 208 to do the filtering for all network traffic by loading a rule to the Access Control Layer 228, so that any data related to the network goes to the Firewall 208 as a filter.

The OS Core 202 can receive Data Frames and send raw data to the same or to other applications. As an example, the OS Core 202 sends to a Firewall 208 a data frame 206 and receives it back (see line 204), modified or not. The OS Core 202 send to instant messenger software 214 a data frame 210 and receives a Data Frame 212 as a result. The OS Core 202 sends to a word processing software 220 a data frame 218 and will receive back data frame 216 as a result. The OS Core 202 sends to Internet browser software 226 a data frame 222 and will receive back a data frame 224 as a result. According to the last descriptions, this model is OS Core centered.

Fig. 2b is an example of an embodiment of the schematic representation of the OS Core model of communication with applications.

Mouse Device 230 is clicked. This signal 232 is sent to the Access Control Layer 228 which checks the rights of said Mouse device 230 to access other system components before forwarding the signal 234 to OS Core 202. The Hardware I/O Manager 260 receives a Data Frame 264 coming from the OS Core 202 by way of the Access Control Layer 228, and sends a 'click event¹ Data Frame (by way of Access Control Layer 228 and OS Core 202 using respectively signals 266 and 268) to the Mouse Driver 270 (by way of Access Control Layer 228 and OS Core 202 using respectively, signals 272 and 274). The Mouse Driver 270 sends to the OS Core 202 a 'button click event' using signals 276 (for step Mouse Driver 270 - Access Control Layer 228) and 278 (for step Access Control Layer 228 - OS Core 202). The OS Core 202 sends the 'button click event' Data Frame 240 (for step OS Core 202 - Access Control Layer 228) 242 (for step Access Control Layer 228 - Word Processor 220) to the Word Processor 220. The Word Processor 220 sends a 'file save' Data Frame 246 (for step Word Processor 220 - Access Control Layer 228) and 248 (for step Access Control Layer 228 - OS Core 202) to the File System 250, using signals 252 and 254. The File System 250 sends a sequence of 'disk I/O write¹ Data Frames to the Hardware I/O Manager 260 (using successively, signals 256, 258, 280, and 282). The Hardware I/O Manager 260 sends the sequence of 'disk I/O write' to the Physical Disk Device 288 (using successively signals 284, 286, 290, and 292). The Physical Disk Device 288 sends 'result' Data Frames (using signals 294 and 296 respectively for steps Physical Disk Device 288 - Access Control Layer 228 and Access Control Layer 228 - OS Core 202) to the Hardware I/O Manager 260 (not shown). The Hardware I/O Manager 260 sends 'result' Data Frames to the File System 250 (not shown). The File System 250 sends a 'result' Data Frames to the Word Processor application 220 (not shown). If the Word Processor application 220 tries to send a Data Frame to the Hardware I/O Manager 260 this Data Frame is stopped by the Access Control Layer 228, because the Word Processor application 220 does not have permission to access the hardware. A 'file save' Data Frame sent to the Mouse Driver 270 will be stopped by the Access Control Layer 228 because it does not match the pattern that the Mouse Driver 270 specified as valid input Data Frames. A 'result' Data Frame can be sent by the Access Control Layer 228 when a Data Frame is blocked. Whether the Access Control Layer 228 sends this result depends on the pattern specified by the receiver, so for example, it is possible for a network driver to ignore notifications about dropped packets.

According to another embodiment of the present invention, Hardware I/O Manager 260 can be an internal part of OS Core 202. Fig. 3 is schematic representations of an embodiment of the hierarchical relationships between applications, according to one embodiment of the present invention. As said previously, each application has an input and an output; for example IP 301 is the input for UDP 303 and TCP 305. TCP 305 is an input for FTP 307, SMTP 309, or HTTP 311. Each application can load other applications as service providers, or attach to other applications as data providers; for example MIME 313 loads an anti-virus program 315 or an anti-spyware program 317 as a service provider; HTTP 311 is attached to its data provider TCP 305. A data provider application has a list of masks; each mask has an equivalent operation such as Drop, Forward to appropriate subsequent application, push to end of queue, etc; application masks are preset by the application that requests data sink or by the Administrator or by any other element in the system that is allowed to do so, by the way of the Design Interface. Application masks are patterns sent to the ACL. If the OS Core manages the queues for a given application, then the OS Core will manage queue operations and it is possible for the ACL to notify the OS Core of a pattern match that triggers a queue manipulation.

Fig. 4 is a schematic representation of the data flows 400 and 420 into the OS Core, according to an embodiment of the present invention.

In data flow 400, an application 406 has an input queue 404 so that the OS Core can push data 402 into its queue. The application 406 has an output queue 410, so that it can buffer outgoing data frames and the OS Core can pull asynchronously (412). Application 406 has an internal clock 408 for processing data.

In data flow 420, application 416 does not have an input or an output queue and behaves as a slave for input data 414, and as a slave for output data 418. The OS Core sends a single data frame at a time and waits for the processing to complete before it can send another data frame. The OS Core also must to receive the outgoing data frame as soon as it is ready, because the application 416 cannot buffer it. It is possible for an application to have any combination of either input queue or input slave, and either output queue or output slave. A possible configuration is to have a sequence of connected applications, all having an output queue and an input slave, all synchronized with the same base clock. Such an example can be used for video streaming.

Fig. 5 is a schematic representation of the internal layout of an application managed by the OS Core, according an embodiment of the present invention. The internal features of application 500 are:

- an Input Interface 501 and Output Interface 523;

- the application can implement an input queue 503 for buffering incoming data frames and can implement an output queue 521 for buffering outgoing data frames.

- a Save State Interface 507 allows to save the state of said application 500 to an external storage; - a Control Interface 519 used by the infrastructure of the present invention to define controls such as Stop, Start, Pause, Reset, Self Test, etc;

- a User Interface 509 that is used for user's display and presets; the User Interface 509 allows remotes of the application's information, status and controls to another machine or another system by describing the user interface and naming an interactive operations with an Operation id' that will be sent as part of the 'command' data frame with its parameters;

- Operational Units 511, 513, and 515 computing the data inputted; and

- The Dispatcher 505 deciding which of the Operational Units handles a given task according to a set of rules. The dispatcher may use services provided by the OS Core or have a part of it integrated in the OS Core.

According to an embodiment of the present invention, Fig. 6 is a schematic representation of the task dispatch function 600 of an application. The task dispatch function features of an application are a set of Operational Units.

Any number of Operational Units such as 511, 513, and 515 can be managed by a single Core Unit 602. As an example, a task 606, 608, or 610 in Task Queue 604 can be queued by a single application or by several applications on the same system. A task can be the need to scan for viruses, the need to match Masks or any other application calculation and operation. When a task is queued in the Task Queue 604, Core Unit 602 defines which Operational Units 511, 513, or 515 should attend to it, according to the units load, proximity or any other consideration such as network bandwidth costs.

In order to allow reliability and redundancy, the system should include at least two operational units. Both units receive the same tasks so that if one fails the other completes the job for it. The first to complete the task causes the same task on other work units to cancel. This also increases performance for high priority operations because the task is handled by the first work unit that is ready to take the job work.

In order to allow both reliability and increased performance of the system, when said system has more than two operational units, the units share tasks so that a given task is distributed to at least two units but not all the operational units. According to this embodiment, any given operational unit that fails during an operation will not degrade system's performance and reliability, because all of its tasks are backed by parallel operational unit.

As an example, the task distribution in Fig-6 is made on three operational units 511, 513, and 515. Operational Unit 511 received Tasks 606 and 608; Operational Unit 513 received Tasks 606 and 610; and Operational unit 511 received Tasks 608 and 610.

According to an embodiment of the present invention, an operational unit with a strong CPU receives more Mask Matching tasks than others and an operational unit with large amount of memory will receive more virus and spam scanning tasks. This is optional and is subject to system design.

The operating system's elements OS Core and ACL are responsible for the interaction and communication between applications and tasks in way that the OS Core identifies the communicating elements and the ACL identifies the interaction between the elements. The system knows many resources such as Tasks, Applications, Files, CPU Cores, Machines, Network Sockets, etc. Every such resource may be accessed under restrictions. The following two models are utilized by the systems: Clearance Rings and Interest Frames.

According to yet another embodiment of the present invention, the Clearance Rings model is a model that defines privilege levels and restrictions in a concentric layout. An example is the access to a database in the network can be described using a Clearance Rings model in such a way that a guest user is in the innermost ring and cannot access the database, next outer ring is the untrusted user who's requests to the database are scanned before they are forwarded to the database, next outer ring is the trusted user who can access the information stored in the database with no restriction and the outermost layer is the database administrator who can define user restrictions and can shut down the database. Multiple Clearance Rings models are used to describe resources, machines, users, and any other system managed element and groups of elements. The collection of Clearance Rings models help determine the system's behavior for a new request.

According to still another embodiment of the present invention, the Interest Frames model is an access control and restrictions model that defines groups of elements with hierarchies. An example is a organization layout that has a Chief Executive Officer (CEO) managing a Chief Financial Officer (CFO) and a Chief Technical Officer (CTO) managing two employees. The first Interest Frame has the CEO as the frame leader with CFO and CTO in this frame. The second frame has the CTO as frame leader with the two employees as frame members. According to Interest Frames model the CFO does not directly access the employee because the employee is not a part of a mutual frame. Overlapping frames are possible so that a project may define a temporary frame lead by the CFO with CTO and an employee as members. Each Interest Frame defines the restrictions of anyone that is not member of the frame and permissions of members of the frame.

According to a further embodiment of the present invention, the Access Control Layer utilizes the Clearance Rings model and Interest Frames model as access control models. Every system resource including applications, tasks, files, network sockets, etc. is mapped in these models. As an example a device driver is mapped in a hardware access Clearance Ring as allowed to communicate with a device whereas a word processor application is in a more restricted ring that does not allow access to hardware resources. Another example is a USB disk drive where the USB driver can suspend the device or allow device removal while the File System driver can only work with files on the device. An example for use of an Interest Frame is an application that can have all related processes, threads and tasks as part of the same Interest Frame so that they can communicate with each other. Such a frame would allow interprocess communication only between members of the same frame. Another example is a word processor that has all text document files in its interest frame thus restricting access from other applications, so for example an image editor cannot even see document files on the hard drive unless it is added as a frame member, or an instant messenger can only read text documents but not edit them. It is also possible to use an Interest Frame in a Clearance Ring which will cover all the elements in that Interest Frame.

Although embodiments of the invention have been described by way of illustration, it will be understood that the invention may be carried out with many variations, modifications, and adaptations, without exceeding the scope of the claims.

Claims

1. An operating system having a plurality of interconnected operating system cores each of said operating system cores taking place in a system and each said operating system cores being efficient to exchange data with other operating system cores and applications programs.

2. An operating system, according to claim 1, configured to manage securely communication and data flows between all the components of a system.

3. An operating system according to claim 1, including a plurality of operating system cores which are grouped in subsets of operating system cores and linked to one another.

4. An operating system according to claim 1, wherein each operating system core is able to communicate, with other operating system cores and applications programs, using all available communication protocols.

5. An operating system according to claim 4, wherein all new communication protocols are implementable.

6. An operating system according to claim 1, wherein each task submitted to the system is replicated in at least two operating system cores.

7. An operating system according to claim 6, wherein replication of tasks in at least two operating system cores allows system crash tolerance.

8. An operating system according to claim 6, wherein each task is submitted to a particular operating system core according to its systems capabilities.

9. An operating system according to claim 6, wherein replication between operating system cores is a transparent process for the End-user.

10.An operating system according to claim 1, wherein a system core CPU manages a plurality of operating system cores.

11.An operating system according to claim 1, wherein a Data Frame uses

'source' block, 'destination' block, 'data' block and 'control' block.

12.An operating system according to claim 11, wherein any block of a Data

Frame can be empty.

13.An operating system according to claim 11, allowing multiple blocks of the same type in a single Data Frame.

14. An operating system according to claim 1, wherein system calls are made using a Data Frame that has 'destination' block, 'data' block and 'control' block.

15.An operating system according to claim 11, wherein said system returns values from system calls using a Data Frame that has 'destination' block,

'data' block and 'control' block.

16.An operating system according to claim 11, wherein any function call is made by using a Data Frame that has made using 'destination' block,

'data' block and 'control' block.

17.An operating system according to claim 11, wherein said operating system returns values from function calls made using a Data Frame that has 'destination' block, 'data' block and 'control' block.

18.An operating system according to claim 1, wherein the internal design defines tasks and task relations and not objects and object relations.

19.An operating system according to claim 18, wherein function calls are made by using a destination that is defined by a combination of 'task identifier' and 'function identifier' or 'task identifier' and 'feature identifier'

20.An operating system according to claim 18, wherein function calls are made by using a destination that is defined by a combination of 'resource identifier ' and 'function identifier ' or 'resource identifier ' and 'feature identifier '

21.An operating system according to claim 1, using a programming language that has special tags in code defining which parameters are passed as 'data' blocks and which are passed as 'control' blocks.

22.An operating system according to claim 1, using a programming language that has integral support for a data type 'pattern¹.

23. An operating system according to claim 22, where 'pattern' data type is a native type of the language.

24.An operating system according to claim 1, based on Operating System

Core Access Control Layer.

25.An operating system according to claim 24, Access Control Layer is hardware accelerated.

26.An operating system according to claim 24, Access Control Layer provides pattern matching services to other system elements and applications.

27.An operating system according to claim 1, wherein all Input/Output operations are performed by a single component or task in the system and applications and drivers do not directly access hardware.

28.An operating system according to claim 1, wherein any executable component is an application that has an input interface and an output interface.

29.An operating system of which any executable component is an application that has a control interface.

30. An operating system according to claim 1, wherein save state interface is integrally supported.

31.An operating system according to claim 1, wherein Configuration

Persistence functionality is integrally supported.

32. An operating system according to claim 1, Traffic Control functionality is integrally supported.

33.An operating system according to claim 1, Debug Interface functionality is integrally supported.

34.An operating system according to claim 1, Watchdog functionality is integrally supported.

35.An operating system according to claim 1, remote User Interface functionality for applications is integrally supported.

36.An operating system according to claim 1, wherein the Access Control

Layer is used order to define different privilege levels for applications instead of Central Processing Unit privilege level management or protection management.

37.An operating system according to claim 1, wherein any executable element and any task is a system resource.

38.An operating system according to claim 37, wherein function calls are made by using a destination that is defined by one or a collection of

'resource identifier' elements.

39.An operating system according to claim 37, wherein multiple Clearance

Rings that combine to evaluate the privilege levels and access rights for a resource, are defined.

40.An operating system according to claim 39, in which Access Control

Layer manages Clearance Rings and Clearance Rings related operations, or provides services required for management of Clearance Rings and for

Clearance Rings related operations.

41.An operating system according to claim 37, wherein multiple Interest

Frames, that combine to evaluate the privilege levels and access rights for a resource, are defined.

42.An operating system according to claim 41, wherein Access Control

Layer manages Interest Frames and Interest Frames related operations, or provides services required for management of Interest Frames and for

Interest Frames related operations.

43.An operating system according to claim 1, allowing a Security application deploying rules to operating system's Access Control Layer.

44.An operating system according to claim 1, having logical separation between Work Units, Memory, and Input/Output even if some are on the same physical devices, and exposes a pool of cores, a pool of memory, and a pool of hardware Input/Output.

45. An operating system according to claim 44, where the pool of cores are a virtual multi-core CPU.

46.An operating system according to claim 44, allowing the pool of memory to be exposed in a linear address space, or multiple linear address spaces by use of virtual memory mapping.

47.An operating system according to claim 44, wherein the pool of

Hardware Input/Output is virtually mapped into logical Hardware

Input/Output groups.