Patent Description:
At present there is a number of solutions describing interfaces buses.

Connection of remote components to a host processor by means of an interface bus having a limited number of address ports is known from patent <CIT> (TANDEM COMPUTERS.

INC, published on <NUM>. The patent describes a host adapter incorporating a standard bus repeater component and an environment monitoring component. The environment monitoring component has a standard bus interface and is selectably coupled to the standard interface bus, and hence to a host processor. The host interface transceiver is coupled by means of a standard bus to the host processor, and is also selectably coupled to a drive interface transceiver by means of the standard bus. The drive interface transceiver is coupled by the standard bus to one or more storage devices. The host adapter is selectably switchable between two modes in such way, that either the drive interface transceiver is coupled through the host interface transceiver to the host processor, or the environment monitoring component is coupled to the host processor.

A prior art solution (<CIT>), describing a method and apparatus for preventing potentially faulty commercial peripherals (COTS) or I/Os from disabling the bus to which they are connected is known. The apparatus has isolators coupled to the bus and the I/Os. A controller is coupled between the interfaces, a processor and memory, operating in such way, that an I/O cannot transfer data to the bus without permission from the bus. Isolation memory keeps I/O and bus messages separate. I/O messages are checked before being sent to the bus. This prevents a failed I/O or peripheral from disabling the bus. Another known prior art (<CIT><CIT>, later published on <CIT> as <CIT>) describing method and system providing possibility for the first process (client) to remotely instantiate "COM" components in another <NUM> custom process (context). The method uses impersonator component in target process and special Factory process-mediator, which instructs the impersonator component on behalf of the client, which COM component it should load from the operating system' System library. One of the important limitations of this method is its inapplicability for components assembled as static libraries. This method also is not disclosing the way of how insert this impersonator component into an arbitrary 3rd party application process (security conflicts). The method's other limitations are (a) support for "COM" specification only and (b) the necessity to run a separate process for <NUM> the Factory component and its Association table, such process will consume system resources and subject to faults. This method doesn't solve the problems of components and tasks registration and mutual interaction, including for situations, when various components, applications and operating system itself belong to the different OS Generations with different set of system interfaces (APIs).

A solution describing device interfacing in a multiprocessor computer system is also known. The solution is disclosed in patent <CIT>).

However, prior art solutions describing device interaction within operating system (OS) architecture by means of an interface bus, have a limited functionality, in particular, none of them provides for simultaneous operation of various generations of operating system components.

Wherein a generation is seen as an operating system version developed as part of OS enhancement to support hardware requirements and state of the art as of the date of OS version release.

This disclosure is aimed at removal of disadvantages of prior art solutions.

The technical problem the invention aims to solve is development of a new way of interaction among operating system components and tasks by means of an interface bus, which is described in the independent claims. Alternative embodiments of the present invention are described in the dependent claims.

The technical result is interface bus enhancement due to different generation OS' components concurrent operation.

It provides for interoperability of applications developed for various operating system generations and equipment, as well as interaction of system components of various generations without the need of rewriting them.

Particular and preferred aspects of the invention are set out in the accompanying independent claims.

The embodiment of the invention will be described hereinafter in accordance with the accompanying drawings, which are presented to illustrate the essence of the invention and in no way limit the scope of the invention. The following drawings are attached to the application:.

The following detailed description of the embodiment of the invention comprises multiple embodiment details providing for clear understanding of the present invention. Due to the fact that those skilled in computer system operation and design are familiar with common terms, components and procedures, such methods, names and components are not described in details not to obscure specific features of the present invention and its application options.

Besides, it is apparent from the given explanation that the invention extends beyond the described embodiment. Multiple potential modifications, changes, variations and replacements maintaining the essence and form of the present invention will be evident for domain experts.

The present invention is aimed at creation of a computer-implemented method of interaction among operating system' components and tasks by means of an interface bus.

In the claimed solution, OS architecture is based on an interface bus used for components data exchange.

Since the OS architecture utilizes entirely interface-based interaction, the bus data comprises only pointers to components' interfaces; the bus neither utilizes, nor supports any other data types, therefore, it is an interface bus.

Wherein, in accordance with the claimed solution, there is no need in data exchange buffer creation, it is enough to send a single pointer to an interface. An exception to the above is when components are located in different address spaces; in this case the marshalling mechanism - interface data transformation to a correct transmission format is used.

For efficient interaction, an interface bus acts as a dynamic registry for the search of components loaded to random access memory. For search and on-demand loading of other components, the interface bus uses auxiliary components, such as a file manager for file system components, or a network manager for loading components from remote resources.

In addition, an auxiliary Remote Procedure Call (RPC) component, if any, provides for registration of components located at remote computer devices in the bus registry using the resources of such devices.

Another important task solved by the claimed interface bus is different generations' components communication. Using Adapted Component Object Model (similar to COM by Microsoft) technology of component reusability, a second-generation interface bus for <NUM>-bit processor architecture comprises a first-generation interface bus for <NUM>-bit processor architecture. Since an external component controls the internal component' interfaces, the marshalling mechanism is required for correct and transparent operation.

<FIG> shows a computer-implemented method (<NUM>) of interaction between operating system components and tasks by means of an interface bus, implemented using a computer device. Such components may include a memory manager, a device manager, a file manager, etc..

At step (<NUM>) components are loaded to memory and automatically registered in an interface bus. Wherein, at step (<NUM>) a component record and the information on which generation it is related to is stored in the dynamic registry of the interface bus in the form of UGUID (Unlimited Globally Unique Identifier) and a pointer to component factory of the component itself.

The UGUID identifier consists of three parts:.

Since the standard provides for <NUM>-bit unique identifier length, the upper part is cut off for the unlimited, for example, <NUM>-bit unique identifier format.

The second example for a <NUM>-bit unlimited unique identifier format: two <NUM>-bit identifiers are generated as per the standard, RFC <NUM> and integrated in a <NUM>-bit identifier.

The third example shows the difference between the UUID = {96EBAA04-7B4E-4BDE-914D-8C3C57F48F2F } generated as per the standard, RFC <NUM>, applied in the COM technology by Microsoft:.

Then at step (<NUM>) an instance for a system interface corresponding to the component generation is created for interface bus and its registered components access, the system interface pointer' address being sent to the loaded component (<NUM>).

At step (<NUM>) the component and the task interact on the basis of the system interface' pointer. At step (<NUM>) the respective component is disabled in accordance with the loaded task.

The marshalling mechanism is applied for the purpose of interaction between components with different address-mapping and tasks located in different address spaces (at stage <NUM>).

Below is the example of a marshaling mechanism application case:.

<FIG> shows an interface bus reflecting interaction among components and tasks. The interface bus is a link between the components and the tasks.

The interface bus registry contains information only on the components located in the memory. The component registry has a limited capacity. To extend the interface bus registry capacity, a memory manager is loaded by a loader and registered in the interface bus registry. File system components are loaded by a file manager. If the file system components are used, the loader has to load the file manager to the system memory and register it in the interface bus register.

Two operations are performed when a component is loaded to the memory and registered in the interface bus:.

Thus, the loaded component can request other components interfaces.

When a task (specific application) is loaded to memory, a new system interface instance shown in <FIG> is created (captured) in the interface bus. In accordance with the algorithm for interface bus and registered components access shown in <FIG>, the system interface pointer' address is sent to the task. The operations of component registration/deregistration and creation (capture)/ release of system interface instances should be atomic, which is conditioned by interface bus specifications. A system interface can be conventionally called an interface bus connection point.

System interface instances for components and tasks are stored in the object pool of interface bus (shown in <FIG>) without processor time being spent on object (interface) creation and destroying, except the case when both there is no free objects in the pool and pool extension is allowed by configuration. In such case the newly created instances are stored in the extended parts of the pool.

It should be emphasized that the interface bus does not have its own task (process) for instance creation (capture)/release. All these operations are performed at the account of own processor time of the scheduled tasks themselves.

<FIG> and <FIG> show interprocess communication options. The sequence diagrams show the process of instance creation and release.

The algorithm of getting a system interface' pointer is shown in <FIG>.

To create a new task, a system interface' pointer is required; to get it, an initiating task requests a system interface' pointer from an interface bus. Having received a free instance, the initiating task increases object's reference count. When branching to a new task, the new task, in its turn, also increases object's reference count. After the new task is successfully created, the initiating task, depending on the required solution, can decrease new task system interface instance reference count.

If the initiating tasks is completed earlier than the created task, it has to decrease task' system interface instance reference count before it is completed.

Thus, the entire interaction between components and tasks is limited by a transfer of a single system interface pointer, through which components or tasks can get access to requested interfaces.

It should be noted that a component or a task has its own pointer to a system interface instance. Then, depending on the type and requirements of the problems to be solved, when the mentioned approach of interprocess communication subtype is not enough, a developer is not limited in interprocess communication methods, i.e. components for operation of sockets, channels (see example in <FIG>), signals, synchronization mechanisms, etc. can be registered in an interface bus.

By requesting through a single system interface pointer, a developer can choose any interprocess communication mechanism implemented in components. This differs to a great extent from the QNX OS approach, where interprocess communication is arranged via messages (byte packets) at the microkernel level, so, to transfer an object, it has to be serialized first, and then it is necessary to deserialize the data. In the claimed solution, the component approach is arranged as a construction kit, requiring an intermedium, represented by an interface bus having a modular structure with the option of expansion at the account of other OS components, including, but not limited to a Memory Manager, a File Manager or a Network Manager for remote components
access.

<FIG> shows the algorithm of system interface transfer to a task and component using the pool object shown in <FIG>.

This algorithm is improved in terms of execution time, since it does not spend any processor time on memory allocation and deallocation for system interface instances (objects). It is also based on the components' property of own lifetime management by using references' counter.

Reference count for a system interface is all that is needed for retaining an instance in memory. A task and a component do not release a system interface' pointer until complete working with it. Basing on this property, references' count, the algorithm shown in <FIG>, consists of the following steps:.

The sequence diagram example in <FIG> shows access to a shared resource provided by "Component A".

Task <NUM> and Task <NUM> request via the interface bus the IFoo interface of "Component A" providing access to the shared resource. The interface bus, in its turn, refers to the component registry in order to find the requested component. After the search is completed, the interface bus via "Component A" factory interface creates IFoo interface data object instance for the task. Having received pointers to "Component A" IFoo interface via the interface bus, Task <NUM> and Task <NUM> interact directly with "Component A" providing the shared resource.

In the event that the tasks are in different address spaces, the marshalling mechanism is applied.

Synchronization of access to the shared resource is performed by "Component A" itself. Thus, Task <NUM> and Task <NUM> can easily perform reading and writing operations without resorting to additional synchronization mechanisms.

The sequence diagram example in <FIG> shows data exchange via a named pipe provided by "Component A".

Task <NUM> and Task <NUM> request INamedPipe interface of "Component A" via an interface bus. The process of getting interface via the interface bus is the same as that for the example in <FIG>.

Via the obtained INamedPipe interface, the tasks open the Foo named pipe (interprocess communication method), whereat the pointer to the IPipe interface used for data exchange between the tasks is returned. Upon completion, the tasks are disconnected from the named pipe, and it is deleted, when none of the tasks uses it.

These examples show various interprocess communication methods for data exchange, which can be implemented as components, and an interface bus is also a kind of interprocess communication subtype providing component interfaces to tasks.

For communication between various component generations, the IEcoSystem* (* - generation number) interface is used by an interface bus.

For each microkernel generation, a system interface has its own unique identifier (UGUID), i.e. a particular system interface is or will be determined for each microkernel generation, depending on the technical capacity, for example, IEcoSystem <NUM> (<NUM>-st generation), IEcoSystem2 (<NUM>-nd generation), IEcoSystem3 (<NUM>-rd generation), etc., each having its own UGUID. Thus, when a task or a component requests a system interface for the generation of the kernel, the solution was developed for, via an interface bus of the previous or earlier generation, the interface bus via Querylnterface determines the requested system interface generation on the basis of UGUID.

Depending on the technical capacity (computer architecture) and interface bus implementation, i.e. the application of reusability, aggregation or containment mechanisms, the interface bus conveys a request to the interface bus of the previous generation, which, in its turn, determines, if the requested system interface corresponds to the generation of the microkernel the request was readdressed to. If successful, the respective system interface returns to the requested component or task. In other words, in accordance with the claimed solution, a new generation interface bus contains or aggregates an earlier generation interface bus. Then the task or component interacts with the microkernel of its generation.

Claim 1:
A computer-implemented method for interaction among components and tasks of an operating system, OS, via an interface bus, comprising:
a) loading (<NUM>) components into a memory and registering said components with the interface bus, wherein, for each component, said registration comprises:
- storing (<NUM>) a component record comprising information about a generation of the component in the form of an Unlimited Globally Unique Identifier, UGUID, comprising a preamble determining the space allocated to a data length value, a data length value and data in the form of unique identifier generated in accordance with standard RFC4122, and a pointer to a component factory of the component in the interface bus;
- creating (<NUM>) a system interface instance of the interface bus having a generation corresponding to the generation of the respective component, wherein a generation corresponds to a microkernel generation, and sending (<NUM>) an address of the system interface instance to the respective loaded component as its dedicated interface for querying respective interfaces of the interface bus and other registered components;
b) providing (<NUM>) client-server interaction between a client component or a task and another component using the address of the respective system interface instance, wherein the client-server interaction comprises the client component or the task querying the interface of the interface bus, querying, upon receiving the queried interface of the interface bus, the interface of said another component from interface bus, and receiving a pointer to the interface of said another component from the interface bus, wherein the interface bus first calls the factory class of said another component to create an instance of the component, before returning a pointer to interface of the newly created instance of the component to the client component or task;
c) deregistering (<NUM>) a registered component or task in the interface bus via a task by deleting the instance of system interface and record for the registered component or task; and
d) applying marshalling (<NUM>) for interaction between components and tasks located in different address spaces.