Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/54—Interprogram communication
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/54—Interprogram communication
  • G06F9/546—Message passing systems or structures, e.g. queues

Definitions

• This invention relates to communication between software applications and the handling of input/output (I/O) devices for avionics equipment.
• IMA Integrated Modular Avionics
• the IMA approach also brings new problems and issues. Chief among these is the problem of avoiding unwanted dependencies between applications. It is necessary to be able to show, with a very high level of assurance, that a problem or failure in one application cannot have an adverse impact on any other application. Without a high level of assurance the aircraft certification authorities (e.g. the FAA) will be unwilling to certify the installation of such systems on an aircraft. Therefore, it is required for IMA-based applications to be strongly partitioned both spatially and temporally.
• the IMA environment needs to ensure strong partitioning among the integrated applications both spatially and temporally.
• the address space of each application must be protected against unauthorized access by other applications.
• an application should not be allowed to over-run its allocated quota of CPU time usage and delay the progress of other integrated applications.
• the erroneous behavior of an application can be the result of a software fault or a failure in a hardware device used exclusively by that application.
• the fault can be generic, accidental or intentional in nature; it can be permanent, transient or intermittent in duration. It is useful to implement application-specific semantic checks, which verify the validity of the communicated data to detect errors due semantic-related generic faults in the application software.
• the system is not liable to Byzantine faults, i.e. all faults manifest themselves into errors, which are detected in the same way by all the other healthy modules. Additionally, faults usually occur one at a time with no simultaneity.
• the present invention discloses novel techniques for inter-application communication and handling of I/O devices that facilitate integration of applications in an IMA system. These techniques enable the integration of multiple applications while maintaining strong spatial partitioning between application modules. Integration of application modules is simplified by abstracting the desired interactions among the applications as device access transactions. Such abstraction facilitates the integration of previously developed application in the IMA environment. The approach requires less support from the operating system than other approaches and minimizes the dependency of the integrated environment on details of the applications. Thus, this invention focuses on ensuring spatial partitioning while enabling communication and device sharing, among the integrated applications.
• the present invention comprises methods and apparatus for inter- application communication and handling of I/O devices that facilitate integration of applications in an IMA system which comply with the ARINC specification 653.
• the present invention enables the integration of multiple applications while maintaining strong spatial and temporal partitioning between applications.
• the present invention simplifies integration of these application modules by abstracting interactions among the applications as device access transactions using an inter-partition messaging service which can be abstracted to the application tasks within a partitioned application as a device driver.
• FIG 1 is a diagram depicting the two layer operating environment that may be employed by our invention.
• Figure 2 depicts the client-server inter-partition message passing protocol in accordance with our invention.
• Figure 3 depicts the registry table of Inter Partition Communication (IPC) channels.
• IPC Inter Partition Communication
• FIG. 4 illustrates the access to the IPC queue developed in accordance with the present invention.
• Figure 5 illustrates the circular queue developed in accordance with the present invention.
• Figure 6 is a table of commands for a send algorithm of the present invention developed in accordance with the present invention.
• Figure 7 is a table of commands for a receive algorithm developed in accordance with the present invention.
• FIG 8 illustrates the broadcasting stream buffer at the present invention developed in accordance with the present invention.
• Figure 9 depicts the handling of output devices developed in accordance with the present invention.
• Figure 1 shows an architecture for integrating real-time safety-critical avionics applications, as described in Aboutabl-Younis application Serial No. 648,985, filed August 20, 2000, and which may be used in our present invention.
• the architecture, depicted in Figure 1 is fundamentally a two-layer operating environment that is able to comply with the ARINC specification 653 and the Minimum Operational Performance Standards for Avionics Computer Resource.
• the present invention goes further by enabling the integration of legacy software modules together with their choice of real-time operating system, all executing on a shared CPU.
• the discussion of our approach for inter-application communication refers to this architecture, the techniques are also applicable to other IMA systems.
• the bottom layer of the architecture termed the System Executive (SE) 10, provides each application module 13 with a virtual machine, i.e. a protected partition, inside which the application can execute. In this way, the application is isolated from other applications in the space domain.
• SE System Executive
• hardware means such as a memory management unit (not shown) which is available with most modem processors to enforce spatial partitioning.
• Time-domain isolation is accomplished by sharing CPU board 19 and other resources among applications based on a pre-computed static timetable.
• the system 10 executive maintains a real-time clock 11 to strictly implement the timetable in which each application is assigned well-defined time slices.
• the SE 10 handles context switching, and initializes / monitors / terminates application partition 13.
• Each CPU 19 also includes a device driver 12 which communicates with external devices, such as a keyboard or computer located on an airplane 17 and a bus driver 21 which provides communication with the interconnection data bus 18.
• each application 13 is accompanied by its own Application Executive (AE) 15 as well as an Interface Library (IL) 16 to the System Executive (SE) 10.
• the AE 15 handles intra- application communication and synchronization.
• the AE 1 also manages the dynamic memory requirements of the application within the boundaries of the application's own memory partition.
• the AE 15 may also implement its own strategy for scheduling the application's tasks. All of the Application Executive's (AE) 15 functions related to inter-application and inter-processor communications are handed through the Interface Library 16 to the SE 10.
• the System Executive 10 needs to provide services to the application executives 15 that enable them to handle privileged operations. These services include exception handling, interrupt enabling and disabling and access to processor internal state, e.g., during thread context switching.
• the Interface Library (IL) 16 encapsulates these services.
• the IL acts as a gateway between the Application Executive 15 and the computer's hardware services.
• the main design goal for the two-layer architecture is to keep the SE 10 simple and independent of the number and type of integrated applications. Simplicity of the SE 10 design facilitates the certification. Being independent of the integrated applications 13 makes the SE 10 insensitive to changes to the applications and thus limits re-certification efforts to application changes or upgrades.
• the inter-application communication paradigm is one major aspect that determines the degree of coupling between the SE 10 and the individual application partitions. Therefore, the mechanism for inter-application communication should avoid coupling the SE 10 with the application to the greatest extent possible.
• the following description discusses our approach for inter-application communication that maintains strong partitioning between integrated applications, allows communications and does not involve the SE. Throughout this discussion, the terms partition and application are used interchangeably.
• application 13 is split between application partitions PI and P2, which communicate to share data and services, as seen in Fig. 2. If a partition PI needs data from another partition P2, PI either sends an explicit request to P2 to obtain the data or expects P2 to continuously make the data accessible to PL Sharing services often requires exchange of request and response messages between the requester (client) and the service provider (server).
• client-server request- response
• client-server IPC client-server IPC
• Implementation of status messages is simplified by posting the messages and making them readable to designated partitions. The following explains how client-server and status messages among partition are supported.
• Copying messages from the sender 22 to the receiver partition 25 requires that a comprehensive message handler be included in the SE.
• the handler physically copies the message to the destination queue after validating the authenticity of such communication.
• Involving the system executive in handling of inter-application messages increases the coupling between the applications and the SE and thus complicates the integration.
• a message-handling library, supported by the SE significantly contributes to the complexity of the SE design - particularly when dealing with context switching among partitions, interrupts and potential exceptions triggered during message handling.
• an allocation involves the use of a circular queue 40 in the sender partition 22 for outgoing messages as shown in Figure. 4.
• the circular queue will be mapped, by the SE 10 using a channel registry table 30, to the address space of an authorized receiver partition 25 for read-only access.
• the sender partition 22 is the only one that has write access to the circular queue 40.
• the sender partition maintains a read pointer 50 and a write pointer 51 for the circular queue 40.
• the write pointer 51 will be used to insert new messages.
• the read pointer 50 is used to detect overflow conditions, as will be explained later.
• the receiver partition 25 will maintain its own read pointer 52 for the queue and will make it readable to the sender partition.
• the receiver will use its sender read pointer 50 to access messages from the circular queue 24.
• the sender partition 22 detects an overflow during message insertion, it removes those messages if any, which the receiver has already consumed.
• the sender identifies the consumed messages by comparing the value of its version of the read pointer 50 with the value of receiver's read pointer 52. If the sender still experiences an overflow after updating its read pointer 50, an error should be declared and an application-specific action has to be taken.
• the read receiver pointer 52 of the receiver partition 25 can also be used for acknowledgment, if needed.
• the sender partition 22 can check the value of the read pointer of the receiver read pointer 52 to ensure that a message (client's request, for example) is being received by the server, receiver partition 25.
• the new inter-partition message service can be abstracted to the application tasks within a partition as a device driver. This abstraction is consistent with - l i ⁇
• ARINC 653 the specifications of the ARINC 653 standard, which describes communication primitives between the partitions as a whole. Routing the inter-partition messages to component tasks is not handled by this standard.
• Using the device driver abstraction facilitates the integration of legacy federated applications since they already have a means to communicate over external devices. Since message queue is SE 10 specific, it does not have to change when integrating a new application. In addition, only the device driver for the communication channel used by a federated application needs to be replaced for the integration.
• the sender partition 22 needs to register the queue address 27 with the SE 10.
• the receiver partition has to register the location of its receiver read pointer 52 for that queue. The registration can be performed either during system initialization or at link time. In both cases, the SE 10 will maintain a list of the addresses of all IPC-related data structures. Registering the addresses during system's initialization requires invocation of SE's 10 library routines in order to access the SE's 10 address space. After the registration both the sender partitions 22 and receiver partitions 25 should query the list for the addresses of the receiver read pointer and queue respectively.
• a sender partition PI which sends messages to a receiver partition P2, needs to statically define a queue in its own address space to host these messages.
• the sender partition PI is required to register that queue partition that is to make an Interpartition Communication (IPC) service 28 within the SE 10 aware of the queue address and of the receiver partition P2 authorized to receive messages from this queue.
• IPC Interpartition Communication
• the SE 10 maintains the IPC channel registry table 30 for all open IPC channel 31.
• the registry table is maintained by the system executive 10 and is accessible for read-only by the partitions.
• a pre-defined circular message queue 40 structure (IPC_queue) has to be used in order to unify the handling of the IPC queues.
• the IPC_queue type requires unique pre-partition queue names to be defined at compile time in order to prevent any erroneous change that might cause inconsistency with the SE's IPC channel registry table 30. As shown in Figure 4, the queue is accessible using two separate read and write pointers, i.e., the receiver read pointer 52 and the sender write pointer 51.
• the sender read pointer 50 is used and modified by the receiver partition to retrieve the next message.
• the sender write pointer is solely used by the sender partition to insert messages.
• the write operation is completely local to the sender partition 22.
• the sender 22 needs to remove consumed messages so that their entry can be reused.
• the sender partition 22 maintains its own sender read pointer 50 to prevent overwriting an unread message.
• the sender partition 22 updates its own sender read pointer 50 to the value maintained by the receiver 25 when the sender detects a queue overflow. If the overflow condition persists even after using the value of the receiver's read pointer 52, the sender declares an error (receive partition not consuming data).
• the receiver's read pointer 52 will be advanced at the last stage of the read operation in order to protect the message from being accidentally overwritten.
• the address of the receiver's read pointer 52 is included in the channel registry table 30 (the "Msg Ack" field) and could be referenced by the sender when synchronizing, the values of the two read pointers.
• the send and receive algorithms are illustrated in figure 5, 6 and 7.
• a dual-state status field is attached to each message indicating whether the message entry is used (valid) or not (empty). If the next entry to be read from the queue contains an empty message, the reader partition concludes that there is no message in the queue. The message status will be made valid only after if it is completely inserted in the queue.
• a stream buffer of messages could be created by the sender partition in its own memory space and made readable to multiple recipients, as depicted in Fig. 8.
• the sender will be the only partition that has write permission to the stream buffer 80.
• the system executive will ensure chat this stream buffer can be written only by the sender and maps the stream buffer 80 to the memory space of one or several recipients as a read-only area.
• the stream buffer 80 is circular with one write pointer 51 maintained by the sender and a receiver read pointer 52 for each recipient.
• Each receiver partition 25 is responsible for maintaining its own read pointer. As depicted in Figure 8, multiple receivers 25 might read from different locations within the circular stream buffer. Since there is only one stream buffer to be used by the sender and all recipients, tight control is needed to correctly handle concurrent read and write requests. Effectively, the sender partition 22 and receiver partition 25 must exclusively lock the message location in the stream buffer before writing or reading a message in order to ensure consistency if the partition is preempted. Locking will not only result in a considerable slowdown of the operation but also might introduce blocking conditions to the sender and recipient partitions. Alternatively, in accordance with another aspect of our invention we use a more liberal form of concurrency for the control commands, as listed in Appendix B.
• the stream buffer "IPC_stream" has four attributes:
• the identifier is the current value of a per-stream message sequence counter.
• the sender partition 22 first invalidates the current message, then updates the message body with the proper check sum, sets the message identifier to the current message sequence counter, sets the valid flag and finally increments the message sequence counter. Recipients first make sure that the current message is valid. Next they retrieve the message body and inspect the check sum code. If the recipient is pre-empted while retrieving a message and the sender inserts a new message in the same location with a new check sum then the recipient will detect that the 'CRC" does not match the message body it just retrieved and may re-read the message.
• the message sequence counter keeps track of the message writing order. Since the stream has multiple readers and a single writer, there might be wide variations in speed and frequency between the writer and one or several of the readers. Thus, the writer might overwrite a message pointed at by a reader. If the reader retrieves two messages after it resumes execution, the reader will end up with out-of-sequence messages since the first message is the most recently inserted one and the second is the oldest message in the stream. By identifying the message order by use of the message sequence counter, the reader partition can detect such an occurrence and can take an appropriate action.
• the stream buffer 80 needs to be statically created in the sender's address space.
• the sender partition should register the stream buffer 80 with the SE 10 so that the SE 10 includes the address of the stream into the memory map of authorized receiving partitions, with read-only access permission.
• the SE 10 records the address in a registry table (not shown)("IPC_stream_registry_table") similar to the "IPC_channel_registry_table" 30 (see Figure 3) to allow resolution of the stream buffer addresses.
• -PC_channel_registry_table 30 can also be used to register -PC stream buffers, it is better to use a separate table to boost the IPC performance.
• the stream registry table (not shown) is maintained by the SE and is made accessible for read-only access to applications. After registration, the receiver partition should query the table for the addresses of the stream data structures. The registration can be performed either during system initialization time, link time or load time. Registering the addresses during system's initialization requires invocation of SE's library routines in order to access the SE's address space. A detailed description of the data types and library routines are set forth in Appendix B.
• a second approach in accordance with another aspect of our invention, is to maintain a health status history for every partition by the system executive 10.
• the system executive 10 saves the health status of partitions in a shared memory area readable to all partitions writeable solely by the system executive 10.
• the receiver partition 25 In order for a receiver partition 25 to detect the failure of the sender partition 22, the receiver partition 25 needs to check the status of the sender partition 22 prior to each IPC activity.
• the failure history of a partition can be captured by two integer values.
• the first value indicates the number of repetitions of failure of the sending partition; the second reflects the current status of the partition.
• Each receiver partition 25 needs to maintain its own copy of a value for the number of times the sender partition 22 has failed. This private value is compared with the value maintained by the system executive (SE) 10 for this particular sender. If the two values match, the sender would be healthy. If the system executive (SE) 10 presents a larger repetition value, the receiver partition 25 would conclude that a failure has occurred in the sender is able to trigger a recovery procedure. Recovery actions include application specific procedures, updating, its own value of the sender's failure repetition to the value presented by the system executive and resetting the read pointer.
• the second value reflects the status of the partition (ready, being terminated or being initialized). In this way receiver can know the sender is healthy before resuming (or continuing) IPC activities with that sender.
• I/O input and output
• operating systems abstract an I/O device by a software driver, which manages the device hardware while performing input or output operations.
• the device driver provides a high-level interface for application tasks that need access to the device. Since I/O devices can be shareable, they can be an indirect means for fault propagation among partitions in our environment. For example, a partition that erroneously keeps on resetting an input device might hinder the device's availability to other healthy partitions and thus disrupt their operation.
• the EVIA two-layer architecture of Figure 1 raises multiple issues on how the application will get access to the device.
• I/O devices can be classified into two types; polling-based and interrupt-driven devices.
• polling-based 170 the device is accessible upon demand and does not notify the application of data availability.
• Interrupt-driven devices generate an interrupt when the device has completed a previously started operation. The generated interrupt can be handled either by the CPU or by a dedicated device controller. Both types of devices can be either memory-mapped or IO-mapped.
• memory-mapped I/O regular memory-read and write instructions are used to access the device. Special I/O Instructions are used for IO-mapped device access. In our environment of the present invention, we assume that the CPU will not receive any interrupts from I/O devices.
• the I/O device should be either polled or supported by a device controller, which is included in the device-specific hardware to handshake with the device and buffer the data.
• a device controller which is included in the device-specific hardware to handshake with the device and buffer the data.
• frequent interrupts generated by I/O devices to the CPU reduce the system predictability and greatly complicate system validation and certification.
• the use of a device controller or I/O co-processor is very common on modem computer architectures to off-load the CPU and boost the performance.
• the CPU either supports memory-mapped I/O or provides mechanism to enable partition-level access protection for IO-mapped devices. In all cases, access to /O devices should not require the use of privileged instructions. In recent years, support of memory-mapped I/O devices has become almost standard on microprocessors. For example, the Motorola® PowerPC processor supports memory-mapped devices only. Using the memory management unit, access to a memory-mapped device can be controlled by restricting the address space of a partition. A partition can access the device using regular memory access instructions if the device address is in its address space.
• the Intel Pentium processor supports both memory-mapped and I/O-mapped devices. However, the I/O instructions of the Pentium processor are privileged. Thus, only memory-mapped devices are allowed if the Pentium processor is used in our environment.
• Device handling in our approach can be performed within either the SE 10 or the AE 15. Handling I/O devices within the SE 10 will require the implementation of synchronization mechanisms to maintain correct order of operations among the applications and thus complicate the design of the SE 10. Maintaining the simplicity of the SE 10 is a design goal in order to facilitate the SE 10 certification. In addition, including device handlers in the SE 10 makes the SE 10 sensitive to device changes. Such dependency might mandate the re-certification of the SE 10 every time a new device is added or removed. On the other hand, Application Executives (AEs) cannot handle shared I/O devices without coordination among themselves.
• AEs Application Executives
• the AE 15 handles I/O devices that are exclusively used by that application (partition).
• AE 15 synchronization primitives can be used to manage access to a device made by tasks within the partition.
• the SE 10 will ensure that every device in the system is mapped to one and only one partition.
• a device daemon 94 (handler) will be created in a dedicated partition.
• the device daemon 94 then "serves" access requests to that device driver 93 made by the other application partitions (PI, P2).
• the shared device manager partition P3 still has exclusive access to the device.
• IPC primitives Application partitions that need read or write access to a shared device communicate with the device daemon via IPC primitives.
• Devices that allow read/write (e.g. backplane bus), random read (e.g. a disk) or write- only (e.g. actuator) types of access require the use of client-server IPC protocol for communication among the device daemon 94 and application partitions (PI, P2).
• the device daemon 94 serializes requests from different partitions to maintain predictable and synchronized device access patterns.
• IPC streams can be used by the device daemon 94 to make the input data available to other partitions.
• the partition P3 that manages the shared device 93 can perform only device handling or can host an application in addition to processing device access requests.
• a partition P3, which controls a device manages access to the device among its own internal tasks and can still serve access request from other partitions.
• the dedicated device partition typically contains only the device daemon in order to ensure responsiveness.
• Managing a shared device 93 by a partition P3 that hosts other application tasks involves some risk since it introduces dependencies between partitions that require device access and the application partition that hosts the daemon for that device. If a failure of an application task causes the whole partition to crash, the shared device 93 no longer becomes accessible to the other partitions (PI, P2). Since this configuration may threaten the system partitioning, it should not be used unless losing access to the device will not cause other partitions to fail.
• IPC primitives simplifies the integration of applications through routing messages among applications transparently, whether they are allocated to the same, processor or to different processors.
• the developer consistently refers to applications using IPC channels.
• An IPC channel as discussed, can abstract communication with a device or with another application partition.
• our approach facilitates the integration of legacy applications designed originally for a federated system since they generally will not require excessive adaptation to use the IPC communications model.
• FIG. 9 An example of the approach of the present invention for device handling is shown in Figure 9.
• Two partitions PI and P2 are integrated in the system.
• the first partition (PI) needs frequent access to output devices Dl 90 and D3 93 and occasional access to the output device D2 92.
• Partition P2 needs heavy access to devices D2 92 and D3 93.
• a dedicated partition P3 is included to manage the shared device D3 93 and to serve requests made by PI and P2.
• Partition P3 has an exclusive access to D3 and includes the device daemon 94 task and the device driver 93 for D3.
• the device driver abstracts the device hardware and can be part of the daemon or as a separate library. Typically, the driver is supplied by the device manufacture.
• the daemon task receives incoming access requests from other partitions by reading from dedicated request queues (IPC_queue) allocated in a readable shared memory area.
• Partitions PI and P2 use the IPC client-server message passing protocol described earlier to communicate with the shared device partition P3.
• Partition PI has an exclusive access to Dl, which is not shared with other partitions. Since D2 is shared between PI and P2, a device daemon is needed. A dedicated partition could have been included to manage D2. Alternatively, D2 was allocated to P2 since PI 's access to D2 is significantly less frequent than is P2's. Access requests to D2 from PI and from tasks within P2 have to be queued for service by the D2 device daemon. As shown in Figure 9, tasks, P2-A, P2-B, within the partition P2 use a separate queue Q2 to send requests to the device D2 daemon and another queue Ql is assigned for requests from partition PI. The use of two separate queues decreases the dependencies between partitions PI and P2.
• Device handling in accordance with our invention enables great flexibility in scheduling access requests to the shared device by decreasing the coupling between scheduling of application tasks and shared devices and thus simplifying schedulability analysis.
• having the device daemon allocated to a dedicated partition ensures fault containment among the partitions, protects the application partitions from errors in the device driver and facilitates debugging. Again through this approach the SE will have very little to do with I O handling and will maintain its intended simplicity.
• the system integrator needs to schedule the daemon partition as an integral part of the application partitions and to consider it in the scheduiability analysis to ensure timeliness under worst-case scenarios.
• Increased device access requests might mandate invoking the daemon partition for that device at a high frequency to ensure timely access. While the use of a dedicated partition for the device daemon can increase message traffic among partitions, it simplifies the scheduling of the shared device and ensures global consistency of the device status. For example If the daemon partition is preempted during an access to the device.
• IPC nessage buffer [num_msgs]
• IPC_channel_registry_tabIe can be built before linking with the SE executive or during an application initialization phase. If the channel registry table is built during initialization, the SE should export two library routines running in a privileged execution mode. Applications would use these two routines to insert a registry entry for the IPC queue and the address of the receiver read pointer. Building the registry table before linking would not require these registration procedures. Since the registry table would be made readable to applications, the rest of the IPC library would not require privileged execution mode.
• the IPC library routines are outlined next. Generally, the routines impose extensive validation of parameters to ensure the detection of erroneous parameter values that might cause a violation of the strong partitioning
• IPC queue* queue IPC queue* queue, int num_messages, int message size, partitioned senderJOD, PartitonJD authorized_receiver
• the partition is required to register that queue using IPC device register library routine.
• the registration makes the IPC service within the SE aware of the address of the queue inside the sender's address space and of the partitions authorized to receive messages from this queue. This routine runs in supervisor mode and performs the following:
• the SE check for available space -in "IPC_channel_registry_table" and registers the queue by inserting an entry in the registry table for that queue.
• Partition_ID senderJQD int* rcvRd
• the receiver partition Once the receiver partition creates and initializes its own index of next-to-read message for the IPC in the sender partition, the receiver is required to register the address of this index using IPC_device_ack_register library routine.
• the sender partition later will query the "JPC_channel_registry table" to get the address of the receiver's read index and use it for message acknowledgment and reclamation of the space occupied by consumed messages.
• This routine runs in supervisor mode and performs the following:
• the receiver partition uses this routine to get the address of the message queue that the sender designated.
• This routine runs in user mode and performs the following:
• the sender partition uses this routine to get the address of the receiver's read index.
• This routine runs in user mode and performs the following:
• IPC_device_write IPC_queue* queue, char* message
• the sender partition needs to invoke the library function "IPC_device_write" to put a new message in a specific queue.
• the queue is a circular data structure, therefore the write index wt will be reset to 0 after reaching, the end of the queue.
• an empty message slot shall always be kept as a separator between the most recently inserted message and the next one to be read by the receiver. This is a safety guard in circular queues to prevent a fast reader from reading old messages. The empty message will stop such fast reader.
• the abstraction of the sending operation is a write to an IPC device corresponding to the message queue. This routine runs in user mode and performs the following actions:
• the receiving partition needs to invoke the library function "IPC_device_read" to get a message from the sender queue.
• the abstraction of the receiving operation from is a read from an IPC device corresponding to the sender queue.
• This routine only retrieves the next valid message and advances the receiver's read index.
• This routine runs in user mode in the receiver partition's address space during its time slice and performs the following actions:
• typedef struct char message [msg_size] boolean status /* initially VALID */ unsigned long msgJD /* initially 0 */ int CRC ;
• typedef struct const char stream_name[ 10] int write-index; /* initially 0 */ unsigned long msg_seq_counter ; ⁇ initially 0 */ Status_message streamjvlsg [num_msgs]
• IPC streams are to be allocated by the application statically at compile time.
• the "IPC_stream_registry_table" can be built before linking with the SE executive or during an application initialization phase. If the stream registry table is built during initialization, the SE should export a library routine running in a privileged execution mode. Applications would use that routine to insert a registry entry for the IPC stream. Building the registry table before linking would riot require such registration procedure. Since the registry table would be made readable to applications, the rest of the IPC library would not require privileged execution mode.
• the IPC library routines are outlined next. Generally, the routines impose extensive validation of parameters to ensure the detection of erroneous parameter values chat might cause a violation of the strong partitioning.
• IPC_stream register IPC stream* stream, int num_messages. int message_size, Partition _ID senderJD, Partiton_ID authorized_receivers[ ]
• the partition is required to register that stream using IPC_stream_register library routine.
• the registration makes the IPC service within the SE aware of the address of the stream and the partitions authorized to retrieve messages from this scream.
• This routine runs in supervisor mode and performs the following actions:
• the SE registers the stream by inserting an entry for that stream in the "lPC_stream_regisitry_table". In addition on, the SE maps the stream for read-only access to the address space of the authorized receivers.
• Partition-ID sender-ID In order to retrieve data messages from the stream buffer the receiver partition needs to find out, using this routine, the address of the stream buffer in the address space of the sender partition This routine runs in user mode and performs the following:
• the sender partition needs to invoke the library function "IPC_stream_write” to write a message to a stream.
• This routine is to be executed in the user mode using the application executive stack.
• the stream is circular, thus the write pointer will be reset co the location of the first message after reaching the end of the stream.
• the abstraction of the sending operation is a write to an IPC stream corresponding to the stream.
• the "IPC_stream_write” routine performs the following actions:
• the receiving partition needs to invoke the SE library function "IPC_device_read” to get a message from the stream.
• Each receiver keeps its own read-index, which identifies the next message to read from the stream. Different receivers may be reading from different locations in the stream.
• This routine is to be executed in the user mode using the application executive stack.
• the abstraction of the receiving operation is a read from an IPC stream corresponding to the sender stream.
• the "IPC_stream_read” routine performs the following actions:
• the receiver might have been preempted before completely reading the message and the sender overwrote it. Thus a retrial is performed. If the retrial still experiences wrong CRC, it indicates that the error is due to a failure in the sender partition in the hardware. However if the retrial indicates the stream is empty, the routine concludes that the sender has been preempted before completely overwriting the message and the location referred to by the read index contains no ready data.

Priority Applications (5)

Applications Claiming Priority (4)

Publications (2)

Family

ID=26898202

Family Applications (1)

Country Status (8)

Cited By (7)

Families Citing this family (71)

Citations (8)

Family Cites Families (3)

• 2001
  • 2001-03-29 US US09/821,601 patent/US20020144010A1/en not_active Abandoned
  • 2001-05-09 AU AU2001274823A patent/AU2001274823A1/en not_active Abandoned
  • 2001-05-09 JP JP2001583324A patent/JP2004514959A/ja not_active Withdrawn
  • 2001-05-09 CA CA002408525A patent/CA2408525A1/en not_active Abandoned
  • 2001-05-09 IL IL15272301A patent/IL152723A0/xx unknown
  • 2001-05-09 KR KR1020027015061A patent/KR20030015238A/ko not_active Application Discontinuation
  • 2001-05-09 EP EP01941471A patent/EP1454235A2/en not_active Withdrawn
  • 2001-05-09 WO PCT/US2001/014895 patent/WO2001086442A2/en active Application Filing

Patent Citations (8)

Non-Patent Citations (11)

Also Published As

Similar Documents

Legal Events