WO2008054133A1

WO2008054133A1 - Terminal having mutual api calling function in platform library, and dsl module generation method and api calling method using the same

Info

Publication number: WO2008054133A1
Application number: PCT/KR2007/005423
Authority: WO
Inventors: Jung Yun Won; Jong Bae Kim; Hoo Jong Kim
Original assignee: Sk Telecom Co., Ltd.
Priority date: 2006-10-31
Filing date: 2007-10-31
Publication date: 2008-05-08
Also published as: KR20080038969A; KR101182534B1

Abstract

The present invention relates to a terminal having a mutual API calling function in a platform library, and a DSL module generation method and a mutual API calling method using the terminal. The terminal includes a first storage medium for separating platform functions according to function, configuring the separated platforms as DSL modules, and including stub blocks in the DSL modules. A second storage medium loads and stores execution data together with the DSL modules when a stored platform is loaded, and calls an API by performing linking to a location corresponding to an API when the API is called. When a DSL module calls another API, a main control unit searches a stub block of a currently loaded DSL module for an address value of the API, performs linking to a location corresponding to the API address value, and performs calling processing.

Description

TERMINAL HAVING MUTUAL API CALLING FUNCTION IN PLATFORM LIBRARY, AND DSL MODULE GENERATION METHOD AND API CALLING METHOD USING THE SAME

Technical Field

[1] The present invention relates, in general, to a terminal having a mutual Application

Program Interface (API) calling function in a platform library, and a Dynamic System Library (DSL) module generation method and a mutual API calling method using the terminal, and, more particularly, to a terminal having a mutual API calling function in a platform library, which separates all of the platforms of the terminal according to function, configures the separated platforms as modules in the form of DSL, and promptly calls mutual APIs between the configured DSL modules through stub blocks provided in the DSL modules, and to a DSL module generation method and a mutual API calling method using the terminal. Background Art

[2] Generally, a communication function, which allows a traveling person to exchange various types of data, such as characters, numbers, and images, with the other party using his or her mobile terminal enabling wireless transmission or reception, in a wireless manner through a base station system, is called wireless data communication. Such wireless data communication is a mobile communication system for bidi- rectionally exchanging or searching data in travel through various types of terminals, for example, a cellular phone, a portable computer, a fax machine, and a credit card checker.

[3] However, in the terminal of the mobile communication system, a region for a manufacturing company (Original Equipment Manufacturer: OEM) that produces the terminal is included in an operating system for managing internal memory, and a region for Wireless Internet Platform for Interoperability (WIPI), managed by a network operator that operates the communication network of such s terminal, is also included.

[4] Further, when the conventional terminal uses an application to execute a set application program, the application program uses the Application Program Interface (API) of an OEM platform or a WIPI platform. Such an API is an interface allowing an application program to use the function of other programs, such as a computer OS, or a Database Management System (DBMS), and is also called an application programming interface. Typically, the application program interface is abbreviated to "API". In practice, the term "API" means a set of functions for defining the functions of an OS or the like and methods for utilizing the functions. Application programs may use various functions provided in the OS or the like using the API. Further, Read-Only Memory (ROM) of the terminal for storing the above-described platform information is typically implemented using NAND flash memory.

[5] The above-described terminal using the NAND flash memory is described below with reference to FIG. 1. A terminal 74 includes Read-Only Memory (ROM) 71, Random- Access Memory (RAM) 72, and a control unit 73. The ROM 71 is nonvolatile memory divided into a Read-Only (RO) region, a Read- Write (RW) region, and a Zero-Initialized (ZI) region, and is configured such that an API link table 70, in which the API address values of statically linked libraries are stored in the RO region in a recording sequence, and a phone Basic Input/Output System (BIOS) or application programs for platform operation are stored in the RW region in an embedded form. The RAM 72 is volatile memory for storing internally processed temporary data in a heap region while loading the API link table 70, loaded from the ROM 71, into an RO region, loading execution data for the phone BIOS and the application programs into an RW region, and loading information about the sizes of global variables, which are not initialized, into a ZI region. The control unit 73 performs control such that the phone BIOS or application program set by a user is loaded into the RW region of the RAM 72, and such that APIs desired to be executed are searched for in the API link table 70, located in the RO region, in the sequence of storage, and are called, and thus the function of a platform, for example, the function of an OEM platform or a WIPI platform, is executed through the APIs.

[6] Meanwhile, the loading operation of the conventional terminal using NAND flash memory is described. First, when a system is turned on, the control unit 73 of the terminal 74 performs boot. When a terminal user executes his or her desired application program, for example, a game program provided in the WIPI region, or an application program having a calculator function provided in another OEM region, using a keypad 75, the control unit 73 loads all libraries related to that application into the RAM 72 from the ROM 71.

[7] That is, when boot is performed or a program is executed, the control unit 73 of the terminal 74 loads libraries related to the boot or the program into the RAM 72. For example, the API link table 70, located in the RO region of the ROM 71, is loaded into the RO region of the RAM 72, and OS and application programs, located in the RW region of the ROM 71, are stored in the form of images, and are copied to the RW region of the RAM 72 at the same time that boot is performed or the program is executed, so that a RAM disk is created. Thereafter, the OS and the application program, for example, an OEM application or a WIPI application, is executed on the RAM disk. [8] Further, information present in the ZI region of the ROM 71, for example, size information, is also loaded into the ZI region of the RAM 72, together with the information present in the RW region.

[9] In this case, when the control unit 73 of the terminal 74 calls APIs required to execute the loaded program, the control unit 73 searches the previously loaded API link table 70, located in the RO region of the RAM 72, for APIs desired to be executed in the sequence of storage, acquires the address values of corresponding APIs, calls the APIS, and then executes the function of a platform, for example, an OEM platform or a WIPI platform, through the called APIs.

[10] However, the above-described conventional equipment, using NAND flash memory, employs a method of sequentially storing the address values of APIs of a WIPI platform or an OEM platform in the API link table 70. Therefore, when the addresses of specific APIs are intended to be subsequently added or deleted to or from the API link table 70, the sequence of the addresses may be confused. Therefore, even if attempts are made to call the specific APIs, the APIs are not called, so that the function of the terminal is stopped, and thus the operational stability of the terminal is greatly deteriorated. When it is desired to change API addresses, newly created without regard to the sequence of API addresses, the entire content of the API link table 70, located in the RO region of the ROM 71, must be changed, and thus costs incurred by the change of the API link table 70 are greatly increased. Disclosure of Invention

Technical Solution

[11] Accordingly, the present invention has been made keeping in mind the above problems occurring in the prior art, and an object of the present invention is to provide a terminal having a mutual API calling function in a platform library, and a mutual API calling method using the terminal, in which the address values of an API is obtained through stub blocks regardless of the recording sequence of APIs at the time of calling a desired API, and immediate linking to the location, corresponding to the obtained API address, is performed, thus stably calling the API without causing calling errors.

[12] Another object of the present invention is to provide a terminal having a mutual API calling function in a platform library and a mutual API calling method using the terminal, in which whether an API to be actually executed is present can be determined through the stub blocks of respective DSL modules, the address value of the API can be promptly obtained, and prompt linking to the location corresponding to the actual address of the API can be performed.

Advantageous Effects

[13] As described above, the present invention is advantageous in that, since it can generate a connection link between required DSL modules using stub blocks capable of calling mutual APIs provided in respective DSL modules, the address value of a desired API is obtained through the stub blocks, regardless of the recording sequence of newly added APIs, when the desired API is called, and performs immediate linking to the location corresponding to the API address, so that the API can be stably called without causing calling errors, thus maximizing the calling characteristics of APIs.

[14] Further, the present invention is advantageous in that it determines whether an API to be actually executed is present in the stub blocks of respective DSL modules, promptly obtains the address value of the API, and performs prompt linking to the location corresponding to the actual API address, thus greatly improving the dynamic linking characteristics of the platform. Brief Description of the Drawings

[15] The above and other objects, features and other advantages of the present invention will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings, in which:

[16] FIG. 1 is a diagram showing conventional terminal having a static linking function;

[17] FIG. 2 is a diagram showing a terminal having a mutual API calling function in a platform library according to the present invention;

[18] FIG. 3 is a diagram showing the structure of a DSL module generated according to the present invention;

[19] FIG. 4 is a flowchart showing a method of generating a DSL module according to the present invention;

[20] FIG. 5 is a diagram showing a stub source according to the present invention;

[21] FIG. 6 is a flowchart showing a mutual API calling method according to the present invention; and

[22] FIG. 7 is a diagram showing an API calling method according to an embodiment of the present invention. Best Mode for Carrying Out the Invention

[23] In accordance with an aspect of the present invention to accomplish the above objects, there is provided a terminal having a mutual Application Program Interface (API) calling function in a platform library, comprising a first storage medium, which is non- volatile memory for separating platform functions, located in a Read-Only (RO) region, according to function, configuring the separated platforms as Dynamic System Library (DSL) modules, and including stub blocks, required to call APIs using function symbols, in the configured DSL modules; a second storage medium, which is volatile memory for loading and storing execution data together with the DSL modules when a platform stored in the first storage medium is loaded, and for calling an API by performing linking to a location corresponding to an API found in stub blocks of the DSL modules when the API is called using a function symbol required for program execution; and a main control unit for performing control such that, when a DSL module, loaded into and executed in the second storage medium, calls another API, a stub block of a currently loaded DSL module is searched for an address value of the API using a required function symbol, linking to a location corresponding to the API address value in the DSL module is performed, and calling processing is performed.

[24] In accordance with another aspect of the present invention to accomplish the above object, there is provided a method of generating a Dynamic System Library (DSL) module, comprising a module configuration process of separating all platform functions of a terminal according to function, and configuring the platform functions as DSL modules; a function list extraction process of, after the module configuration process, extracting a list of Export functions to be provided by a given DSL module from a DSL header, given as a factor; a stub source generation process of, after the function list extraction process, generating a stub source to allow other DSL modules of a platform to use function symbols (function names) contained in the extracted Export function list; an ELF file generation process of, after the stub source generation process, generating an Executable and Linking Format (ELF) file using a difference between two object files for the platform; and a DSL file generation process of, after the ELF file generation process, generating a file in a DSL file format using information about the generated stub source and the generated ELF file, and storing the DSL file in Read-Only Memory (ROM).

[25] In accordance with a further aspect of the present invention to accomplish the above objects, there is provided a mutual Application Program Interface (API) calling method, comprising a DSL loading step of loading a stub block of a DSL module from a first storage medium (ROM) into a second storage medium (RAM), together with execution data required for current execution, when a specific function is set in a terminal; a function symbol-based search step of, after the DSL loading step, searching a stub block of a currently executed DSL module for an address value of an API corresponding to a function symbol using the function symbol so as to execute a loaded DSL module; a linking step of, after the function symbol-based search step, performing linking to a location corresponding to the found actual API address value using the found actual API address value, and calling the actual API to be currently executed, thus executing content of the DSL module; a function symbol-based re-search step of, after the linking step, searching the stub block of the current DSL module for an address value of an API corresponding to a function symbol using the function symbol for subsequent execution when the current DSL module calls an API of another DSL module; and an API re-calling execution step of, after the function symbol-based re- search step, performing linking to a location corresponding to the actual API address value, found between the DSL modules, using the actual API address value, and calling the actual API to be currently executed, thus executing content of the DSL module.

Mode for the Invention

[26] Hereinafter, embodiments of the present invention will be described in detail with reference to the attached drawings.

[27] As shown in FIG. 2, a terminal 1 of the present invention includes a first storage medium 4, a second storage medium 5, and a main control unit 6.

[28] The first storage medium 4, which is non- volatile memory (Read-Only Memory:

ROM) (hereinafter referred to as 'ROM'), separates all of the platform functions of the terminal 1, located in a Read-Only (RO) region in the memory area divided into the RO region, a Read- Write (RW) region, and a Zero-Initialized (ZI) region, according to function. For example, the first storage medium 4 separates the platform functions into platform functions for a Database Management System (DBMS), a media system, a file system, and a network system. Further, the first storage medium 4 configures the separated platform functions as DSL modules 2A to 2N, includes respective stub blocks 3, required to call APIs using function names (function symbols), in the configured DSL modules 2A to 2N, and stores a phone Basic Input/Output System (BIOS) or application programs, required for platform operation, in the RW region.

[29] The second storage medium 5, which is volatile memory (Random- Access Memory:

RAM) (hereinafter referred to as 'RAM'), is configured such that, when the platform stored in the first storage medium 4 is loaded, the second storage medium 5 loads and stores execution data of the phone BIOS or application programs, together with the DSL modules 2A to 2N, and such that, when an API is called through a function name (function symbol) required to execute a program, the second storage medium 5 calls the API by performing linking to the location of the API found in the stub blocks 3 of the DSL modules 2A to 2N. The second storage medium 5 stores temporary data processed in the terminal, and is divided into an RO region, an RW region, a ZI region, and a Heap region.

[30] The main control unit 6 performs control such that the DSL modules 2A to 2N of the

ROM 4 and a phone BIOS or an application program, set by the user, are loaded into the corresponding region of the RAM 5, and such that, when an API, required for the execution of a program, is called using a function name (function symbol), the address value of the API is searched for in the stub blocks 3 of the DSL modules 2A to 2N, linking to the location of the API corresponding to the address value is performed, and the API is called and processed. The main control unit 6 controls the overall function of the terminal 1.

[31] In this case, the first storage medium 5, which is non-volatile memory (ROM), may be implemented using NAND flash memory.

[32] Further, the terminal 1 can be a Personal Digital Assistant (PDA), a notebook computer, a Personal Computer (PC), or a mobile phone, each provided with a Radio Frequency (RF) module.

[33] Further, the stub blocks 3 are located in the DSL modules 2A to 2N located in the

RO region of the ROM 4, and are configured to individually store actual address values of APIs, searched for by the functions configured as modules when the DSL modules 2A to 2N are executed, and to store a procedure for searching for the actual API address values.

[34] As shown in FIG. 3, each of the DSL modules 2A to 2N is implemented using a structure including a DSL header, an RO section, an Import section, an RW section, and a Relocation Info section.

[35] The Import section is configured to include fields for import library info, a symbol finder, a Global Offset Table (GOT), a Procedure Linkage Table (PLT), a stub block (Import library) 3, etc.

[36] Meanwhile, the terminal 1 further includes an RF module unit 8 for processing a radio call signal (including a multimedia signal) including video and audio signals that are transmitted or received through the terminal 1 via a mobile communication network system 7 in response to a transmission control signal from the main control unit 6, a display 9 for externally displaying various types of data processed by the terminal 1 in response to a display function control signal from the main control unit 6, a codec unit 11 for converting an analog audio signal, input through a microphone 10, into a digital signal, or converting a digital audio signal into an analog signal and outputting the converted signal in response to a call connection control signal from the main control unit 6, and a key panel unit 12 connected to one end of the main control unit 6 and configured to input a function setting signal, input by the user, to the main control unit 6.

[37] A control method applied to the above-described terminal is described below.

[38] As shown in FIG. 4, a DSL module generation method according to the present invention proceeds from an initialization step to a module configuration process Sl, in which all of the platform functions of the terminal are separated according to function, and the separated platform functions are configured as DSL modules.

[39] Further, after the module configuration process Sl, the method proceeds to a function list extraction process S2, in which a list of Export functions to be provided by a given DSL module is extracted from a DSL header, given as a factor.

[40] After the function list extraction process S2, the method proceeds to a stub source generation process S3, in which a stub source is generated to allow other DSL modules of the platform to use the function symbols (function names) contained in the extracted Export function list.

[41] Moreover, after the stub source generation process S3, the method proceeds to an

ELF file generation process S4, in which an executable and linking format (ELF) file is generated using the difference between two object files for the platform.

[42] In this case, the ELF file generation process S4 includes a detailed ELF file execution step of linking two object files to each other using scatter loading scripts having a difference of 0x20 therebetween, thus generating two ELF files. Further, the ELF file generation process S4 further includes a binding information generation step of comparing the two ELF files with each other and generating binding information related to a dissimilar portion.

[43] The ELF file generation process S4 further includes an address table recording step of finding a symbol address using the name of the Export function extracted from the ELF file having a starting address of 0x0, generating a function address table using the address, and recording the function address table as an Export function address table having a DSL file format.

[44] The ELF file generation process S4 further includes a function name recording step of configuring each function name in the ELF file as a single character string, and recording configured character strings in the form of an Export function name table having a DSL file format.

[45] Meanwhile, after the ELF file generation step S4, the method proceeds to a DSL file generation process S5, in which a file is generated in a DSL file format using the generated stub source and the ELF file information.

[46] In other words, the platform of the terminal 1 according to the present invention is separated into DSL modules, which are individual functional modules, on the basis of a base layer. Further, the list of Export functions to be provided by a given DSL module is extracted from the header, given as a factor. The stub source is generated to allow other DSL modules to use the function symbols (function names) contained in the extracted Export function list.

[47] In this case, the stub source is generated in the format of FIG. 5 using an Application

Reference Model (ARM) assembler.

[48] Further, the two object files of the platform are linked to each other using scatter loading scripts having a difference of 0x20 therebetween, and thus two ELF files are generated. The reason for this is to generate dynamic binding information, as in the case of a Wireless Internet Platform for Interoperability (WIPI) binary format. Further, during this process, two ELF files are compared to each other, so that binding information about a dissimilar portion is also generated. Further, a symbol address is found using the name of an Export function extracted from an ELF file having a starting address of 0x0, and the function address table is generated using the symbol address and is recorded as the Export function address table having a DSL file format. Furthermore, each function name in the ELF file is configured as a single character string, and is recorded in the Export function name table having a DSL file format.

[49] Meanwhile, a file is generated in a DSL file format using the information generated through the above process, for example, stub source information and ELF file information, and is then stored in the ROM 4.

[50] In this case, the DSL file format is implemented using a structure including a DSL header, an Export function address table, an Export function name table, an RO Section, an Import library table, and an RW section.

[51] Meanwhile, as shown in FIG. 6, the API calling method performed between DSL modules according to the present invention proceeds from an initialization step S 11 to a function setting determination step S 12, in which, whether a specific function, for example, an application program, has been currently set in the terminal is determined. If it is determined at the function setting determination step S 12 that the specific function, for example, the application program, has not been set in the terminal, the method terminates the current step and proceeds to a standby state.

[52] However, if it is determined at the function setting determination step S 12 that the specific function, for example, the application program, has been set in the terminal, the method proceeds to a DSL loading step S 13, in which a DSL module provided with a stub block is loaded from the ROM into the RAM, together with execution data of the phone BIOS or an application program required for current execution.

[53] Further, after the DSL loading step S 13, the method proceeds to a function symbol- based search step S 14, in which the address value of an API corresponding to a function symbol is searched for in the stub block of the currently executed DSL module using the function symbol so as to execute the loaded DSL module.

[54] Further, after the function symbol-based search step S 14, the method proceeds to a linking step S 15, in which linking to the location corresponding to the found actual API address value of the function is performed using the found actual API address value of the function, and then an actual API to be currently executed is called to execute the content of the DSL module.

[55] Further, after the linking step S 15, the method proceeds to another DSL API calling determination step S 16, in which whether the current DSL module is calling the API of another DSL module is determined. In this case, if it is determined at another DSL API calling determination step S 16 that the current DSL module is not calling the API of another DSL module, the method terminates the current step and proceeds to a standby state. However, if it is determined at another DSL API calling determination step S 16 that the current DSL module is calling the API of another DSL module, the method proceeds to a function symbol-based re-search step S 17, in which the address value of the API of a function symbol is searched for in the stub block of the current DSL module using the function symbol to perform subsequent execution.

[56] Further, after the function symbol-based re-search step S 17, the method proceeds to an API re-calling execution step S 18, in which linking to the location corresponding to the actual API address value of the function, found between the DSL modules, is performed using the actual API address value, and the actual API to be currently executed is called to execute the content of the DSL module.

[57] In this case, each of the function symbol-based search step and the function symbol- based re-search step further includes a detailed function search step of searching the stub block of the Import section of the DSL module 2A, the execution of which has been currently completed, for an API to be executed at the subsequent step using a function symbol (function name), when there is a need to search for an API to be executed at the subsequent step. Each of the function symbol-based search step and the function symbol-based re-search step further includes a GOT recording step of recording a found address value in the Global Offset Table (GOT) of the Import section of the currently executed DSL module when an API desired to be searched in the stub block is present in the DSL module.

[58] In other words, when the user sets the execution of, for example, an application program provided in the terminal 1, the terminal 1 of the present invention loads DSL modules 2A to 2N, provided with stub blocks 3, from the ROM 4 into the RAM 5, together with execution data of application programs required for current execution.

[59] That is, when the program is set in this way, the main control unit 6 of the terminal 1 loads platform functions, configured as modules and located in the RO region of the ROM 4, that is, the DSL modules 2A to 2N, into the RO region of the RAM 5, and also loads a phone BIOS, located in the RW region of the ROM 4 and required for platform operation, or both the phone BIOS and the application program, into the RW region of the RAM 5.

[60] Further, when the DSL modules are loaded and executed as described above, the main control unit 6 of the terminal 1 executes the functions of a DSL module 2A located in the RO region of the RAM 5 so as to call a currently executed API, and thereafter searches the stub block 3 of the Import section of the DSL module 2A, the execution of which has been currently completed, for an API to be executed at the subsequent step, using a function symbol (function name) when there is a need to search for the API to be executed at the subsequent step.

[61] In this case, when an API is searched for in the stub block 3, for example, when an

API desired to be found is present in a DSL module 2B, as shown in FIG. 7, the main control unit 6 records the address value of the found API in the GOT of the Import section of the DSL module 2A. Further, the main control unit 6 performs linking to the location corresponding to the found API address in the DSL module 2B, calls the corresponding API, and executes the content of the DSL module.

[62] Similarly, when there is a need to search for an API during the operation of the DSL module 2B, for example, when it is assumed that an API desired to be found for subsequent execution is present in a DSL module 2C, the main control unit 6 searches the stub block 3 of the DSL module 2B for the address value of the API, records the found API address value in the GOT of the import section of the DSL module 2B, performs linking to the location corresponding to the found address, in the DSL module 2C, calls the corresponding API, and thus executes the content of the DSL module.

[63] Therefore, when the method of the present invention is used, each of the DSL modules 2A to 2N calls the API of another module 2A to 2N while executing pi atforms, thus smoothly executing the API function between the DSL modules.

[64] In this case, when the application program of the terminal 1 is executed in this way, the main control unit 6 transmits an audio signal to a speaker(not shown) through the codec unit 11 while displaying the executed content on the display 9. In this case, when an external radio call is received through the RF module unit 8, the main control unit 6 of the terminal 1 provides notification of the external radio call through the display 9 or the speaker. Further, when the user of the terminal 1 desires to answer the call, the main control unit 6 transmits a response call to the other party's terminal 13 through the mobile communication network system 7, thus enabling typical communication to be performed. Industrial Applicability

[65] As described above, the present invention is advantageous in that, since it can generate a connection link between required DSL modules using stub blocks capable of calling mutual APIs provided in respective DSL modules, the address value of a desired API is obtained through the stub blocks, regardless of the recording sequence of newly added APIs, when the desired API is called, and performs immediate linking to the location corresponding to the API address, so that the API can be stably called without causing calling errors, thus maximizing the calling characteristics of APIs.

[66] Further, the present invention is advantageous in that it determines whether an API to be actually executed is present in the stub blocks of respective DSL modules, promptly obtains the address value of the API, and performs prompt linking to the location corresponding to the actual API address, thus greatly improving the dynamic linking characteristics of the platform. [67] Although the preferred embodiments of the present invention have been disclosed for illustrative purposes, those skilled in the art will appreciate that various modifications, additions and substitutions are possible, without departing from the scope and spirit of the invention as disclosed in the accompanying claims.

Claims

[1] A terminal having a mutual Application Program Interface (API) calling function in a platform library, comprising: a first storage medium, which is non-volatile memory for separating platform functions, located in a Read-Only (RO) region, according to function, configuring the separated platforms as Dynamic System Library (DSL) modules, and including stub blocks, required to call APIs using function symbols, in the configured DSL modules; a second storage medium, which is volatile memory for loading and storing execution data together with the DSL modules when a platform stored in the first storage medium is loaded, and for calling an API by performing linking to a location corresponding to an API found in stub blocks of the DSL modules when the API is called using a function symbol required for program execution; and a main control unit for performing control such that, when a DSL module, loaded into and executed in the second storage medium, calls another API, a stub block of a currently loaded DSL module is searched for an address value of the API using a required function symbol, linking to a location corresponding to the API address value in the DSL module is performed, and calling processing is performed.

[2] The terminal according to claim 1, wherein the first storage medium is NAND flash memory.

[3] The terminal according to claim 1, wherein the terminal is one of a Personal

Digital Assistant (PDA), a notebook computer, a Personal Computer (PC), and a mobile phone, each provided with a Radio Frequency (RF) module.

[4] The terminal according to claim 1, wherein each of the stub blocks is provided in each of the DSL modules located in the RO region of the first storage medium, and is configured to store actual address values of APIs searched for by the functions configured as modules when the DSL module is executed, and to store a procedure for searching for the address values.

[5] The terminal according to claim 1, wherein each of the DSL modules comprises a DSL header, an RO section, an Import section, an Read- Write (RW) Section, and a Relocation Info section.

[6] The terminal according to claim 5, wherein the Import section includes fields for import library info, a symbol finder, a Global Offset Table (GOT), a Procedure Linkage Table (PLT), and a stub block (import library).

[7] A method of generating a Dynamic System Library (DSL) module, comprising: a module configuration process of separating all platform functions of a terminal according to function, and configuring the platform functions as DSL modules; a function list extraction process of, after the module configuration process, extracting a list of Export functions to be provided by a given DSL module from a DSL header, given as a factor; a stub source generation process of, after the function list extraction process, generating a stub source to allow other DSL modules of a platform to use function symbols (function names) contained in the extracted Export function list; an ELF file generation process of, after the stub source generation process, generating an Executable and Linking Format (ELF) file using a difference between two object files for the platform; and a DSL file generation process of, after the ELF file generation process, generating a file in a DSL file format using information about the generated stub source and the generated ELF file, and storing the DSL file in Read-Only

Memory (ROM).

[8] The method according to claim 7, wherein the ELF file generation process comprises a detailed ELF execution step of linking the two object files to each other using scatter loading scripts having a difference of 0x20 therebetween, thus generating two ELF files.

[9] The method according to claim 7, wherein the ELF file generation process comprises a binding information generation step of comparing the two ELF files and generating binding information about a dissimilar portion.

[10] The method according to claim 7, wherein the ELF file generation process comprises an address table recording step of finding a symbol address using a name of an Export function extracted from an ELF file having a starting address of 0x0, generating a function address table using the address, and recording the function address table as an Export function address table having a DSL file format.

[11] The method according to claim 7, wherein the ELF file generation process comprises a function name recording step of configuring each function name in the ELF file as a single character string, and recording configured character strings in a form of an Export function name table having a DSL file format.

[12] A mutual Application Program Interface (API) calling method, comprising: a DSL loading step of loading a stub block of a DSL module from a first storage medium (ROM) into a second storage medium (RAM), together with execution data required for current execution, when a specific function is set in a terminal; a function symbol-based search step of, after the DSL loading step, searching a stub block of a currently executed DSL module for an address value of an API corresponding to a function symbol using the function symbol so as to execute a loaded DSL module; a linking step of, after the function symbol-based search step, performing linking to a location corresponding to the found actual API address value using the found actual API address value, and calling the actual API to be currently executed, thus executing content of the DSL module; a function symbol-based re-search step of, after the linking step, searching the stub block of the current DSL module for an address value of an API corresponding to a function symbol using the function symbol for subsequent execution when the current DSL module calls an API of another DSL module; and an API re-calling execution step of, after the function symbol-based re-search step, performing linking to a location corresponding to the actual API address value, found between the DSL modules, using the actual API address value, and calling the actual API to be currently executed, thus executing content of the DSL module.

[13] The method according to claim 12, wherein each of the function symbol-based search step and the function symbol-based re-search step comprises a detailed function search step of searching a stub block of an Import section of a DSL module, execution of which has been completed, for an API to be executed at a subsequent step when there is a need to search for the API to be executed at the subsequent step.

[14] The method according to claim 12, wherein each of the function symbol-based search step and the function symbol-based research step comprises a GOT recording step of recording a found address value in a Global Offset Table (GOT) of an Import section of the currently executed DSL module when an API desired to be searched for in the stub block is present in the DSL module.