SYSTEM AND METHOD OF DYNAMICALLY LOADING AND EXECUTING MODULE DEVICES USING INTER-CORE-COMMUNICATION CHANNEL IN MULTICORE SYSTEM ENVIRONMENT

• US 20090158297A1
• Filed: 06/19/2008
• Published: 06/18/2009
• Est. Priority Date: 12/12/2007
• Status: Active Grant

• Current Assignee: Electronics and Telecommunications Research Institute
• Original Assignee: Electronics and Telecommunications Research Institute
• Inventors: Kang, Dong Wook, Kim, Jae Myoung, LEE, Kwang Yong, Kim, Dong Hwan
• Granted Patent: US 8,321,876 B2
• Time in Patent Office: Days
• US Class Current: 719/313
• CPC Class Codes: G06F 9/5044 considering hardware capabilities
• CPC Class Codes: G06F 9/505 considering the load
• CPC Class Codes: G06F 9/546 Message passing systems or structures, e.g. queues

Abstract

Provided are a system and method for allocating a specific job or application to a specific slave core by using an inter-core-communication (ICC) channel and executing the job or application in a multicore system environment including the master core and a plurality of slave cores. The method of a master core, includes: initializing message transmission times; generating an event for processing a instruction received from an application program and generating a channel event message from the event; checking a process for transmitting the generated channel event message, and if a channel event message queue corresponding to an event transmitting request is not “FULL” of a previously-stored channel event message, transmitting the channel event message to a specific slave core to request for storing the channel event message; and returning a response of processing status to the request for storing the channel event message to the application program.

Claims

1. A method of dynamically loading and executing a module device of a master core using an ICC (inter-core communication) channel in a multicore system environment including the master core and a plurality of slave cores, comprising:

initializing message transmission times;

generating an event for processing a instruction received from an application program and generating a channel event message from the event;

checking a process for transmitting the generated channel event message, and if a channel event message queue corresponding to an event transmitting request is not “

FULL”

of a previously-stored channel event message, transmitting the channel event message to a specific slave core to request for storing the channel event message; and

returning a response of processing status to the request for storing the channel event message to the application program.

2. The method of claim 1, further comprising, if the channel event message queue corresponding to the event transmitting request is “

FULL”

of the previously-stored channel event message, executing another process.

3. The method of claim 1, wherein the returning of the response of processing status to the request for storing the channel event message to the application program comprises:

if the processing status to the request for storing the channel event message is normal, returning a response representing that the message transmission status is normal, and if the processing status is abnormal, re-transmitting the channel event message to the specific slave core; and

checking the re-transmission times and, if the re-transmission times of the message is larger than or equal to a threshold value, returning a response representing that the message transmission status is abnormal.

4. The method of claim 1, wherein the event is one of a module device loading event for registering the module device in the specific slave core, a module device executing event for executing functions of the module device loaded on the specific slave core, and a module device deleting event for deleting the module device if the module device is not needed for the specific slave core.

5. A method of dynamically loading and executing a module device of a specific slave core using an ICC channel in a multicore system environment including a master core and a plurality of slave cores, comprising:

receiving a channel event message generated by the master core through the ICC channel in order to process a instruction received from an application program;

storing the channel event message in a channel event message queue thereof; and

an event handler of the specific slave core interpreting the stored channel event message and executing one of a module device loading process, a module device executing process, and a module device deleting process.

6. The method of claim 5, wherein the storing of the channel event message in the channel event message queue comprises:

initializing a system environment of a communication driver between multicore internal processes provided to the ICC channel; and

checking whether or not a message queueing event exist in the communication driver between the multicore internal processes, storing the channel event message in the channel event message queue if the message queueing event exist, and executing another process if the message queueing event does not exist.

7. The method of claim 6, wherein the storing of the channel event message in the channel event message queue further comprises checking the message queueing status in the communication driver between the multicore internal processes, if the message queueing status is normal, transmitting a normal response message to the master core, and if the message queueing status is abnormal, transmitting an abnormal response message to the master core.

8. The method of claim 5, wherein the module device loading process comprises:

the event handler fetching an object code from an OS kernel of the specific slave core and loading the object code on a memory;

linking a code of the module device loaded on the memory and a kernel code with reference to a kernel symbol table; and

invoking a predefined initialization function of the linked module device and storing the initialization function in a device driver list of the kernel.

9. The method of claim 8, wherein the module device executing process comprises:

the event handler interpreting the channel event message;

if the interpreted type of the message is a periodic message, a periodic event handler being invoked by an interrupt of a timer, and the periodic event handler fetching a channel event message from a periodic event message queue and interpreting the channel event message;

opening a module device requested by the application program according to a result of the interpretation to obtain a file descriptor, invoking a function of the module device by using the file descriptor, and executing the function;

if the execution of the function of the module device is completed, closing the module device to complete the module device execution; and

if the module device execution is completed, registering the channel event message in the periodic event message queue in the order of periods.

10. The method of claim 9, wherein, if the interpreted type of the message is a non-periodic message, the module device executing process comprises:

interpreting the channel event message;

opening the module device requested by the application program according to a result of the interpretation to obtained a file descriptor;

invoking a function of the module device by using the file descriptor, and executing the function; and

if the execution of the function of the module device is completed, closing the module device to complete the module device execution.

11. The method of claim 9, wherein in the invoking of the function of the module device, if a type of the interpreted channel event message is a module device opening event, an open function is invoked, if the type is a module device closing event, a close function is invoked, if the type is a module device reading event, a read function is invoked, if the type is a module device writing event, a write function is invoked, and if the type is a module device control event, an ioctl function is invoked.

12. The method of claim 8, wherein the module device deleting process comprises:

searching the module device in the device driver list of the kernel;

invoking a module device release function from the kernel; and

deleting the module device searched from the device driver list by using the module device release function.

13. A system for dynamically loading and executing a module device using an ICC channel in a multicore system environment, comprising:

a master core generating an event for requesting for a module device loading process, a module device deleting process, or a module device executing process requested by an application program, generating channel event message from the event, and transmitting the channel event message through the ICC channel; and

a plurality of slave cores performing the module device loading process, the module device deleting process, or the module device executing process according to the received channel event message.

14. The system of claim 13, wherein the event is one of a module device loading event for registering the module device in a specific slave core among the a plurality of slave cores, a module device executing event for executing functions of the module device loaded on the specific slave core, and a module device deleting event for deleting the module device if the module device is not needed for the specific slave core.

15. The system of claim 13, wherein each of the master core and the slave cores has the ICC channel including an ICC middleware and an MC IPC (multicore inter process communication) driver to communicate with each other.

16. The system of claim 13, wherein each of the slave cores comprises:

an MC IPC driver storing the received channel event message in a channel event message queue; and

an ICC middleware,

wherein the ICC middleware comprises;

an event handler interpreting the channel event message stored in the channel event message queue, executing one of the module device loading process, the module device deleting process, and the module device executing process if the channel event message is a non-periodic channel event message, and storing the channel event message in a periodic event message queue if the channel event message is a periodic channel event message; and

a periodic event handler interpreting the periodic channel event message stored in the periodic event message queue and performing one of the module device loading process, the module device deleting process, and the module device executing process according to an predetermined interrupt of a timer.