Abstract:
An electronic system comprises a memory, a parser, and a device driver. A plurality of applications and a document are stored in a user space of the memory, the document storing configuration parameters. The parser module parses the document to retrieve the parameters in response to invocation from at least one application. The device driver creates data structure for the parameters in the kernel space of the memory, thus to facilitate a plurality of programs to execute different functions of the system by commonly utilizing the parameters through the device driver.

Description:
BACKGROUND 
       [0001]    1. Technical Field 
         [0002]    The disclosure relates to electronic devices, and more particularly to an electronic device system capable of sharing configuration parameters among processes. 
         [0003]    2. Description of Related Art 
         [0004]    The extensible markup language (XML) is commonly utilized to organize various software parameters as a document. An application may invoke functions or relative libraries to analyze XML documents to retrieve parameters. Since the parameters may be proprietary to an application, sharing of the parameters with other applications or with an operating system kernel is difficult. 
         [0005]    With reference to  FIG. 1 , a main memory  100  comprises a user space and a kernel space. Applications  10   a - 10   b  and a document  12  of configuration parameters are located in the user space while an operating system kernel is located in the kernel space. When an application accesses the configuration parameters, the application parses the document  12  to rearrange the configuration parameters in a tree structure, referred to as a configuration tree, such as trees  11   a - 11   c  in  FIG. 1 , according to an interior structure of the document. Each node of the configuration tree records a parameter value. The application allocates the configuration tree in a private area of the application which is unknown and inaccessible by other programs. This underlies the difficulty of parameters synchronization or sharing among processes. 
         [0006]    Sharing of configuration parameters among applications, however, is necessary in some circumstances. In an example of an asymmetric digital subscriber line (ADSL) modem, after a program utilizes point-to point protocol (PPP) or dynamic host configuration protocol (DHCP) to acquire an internet protocol (IP) address, other programs in the modem, such as a network address translation (NAT) program and/or a firewall program may require retrieval of the IP address. Configuration trees in  FIG. 1  hinder configuration parameter sharing or synchronization among programs. Additionally, an operating system kernel  13  in  FIG. 1  may face similar difficulty in accessing configuration trees or configuration parameter documents. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]      FIG. 1  is a schematic diagram of a commonly used configuration tree in a main memory; 
           [0008]      FIG. 2  is a block diagram of one embodiment of an electronic device system of the disclosure; 
           [0009]      FIG. 3  is a schematic diagram showing one embodiment of a configuration of the disclosure of a configuration tree in a main memory; 
           [0010]      FIG. 4  is a schematic diagram of one embodiment of software functional blocks of an electronic device system of the disclosure; 
           [0011]      FIG. 5  is a schematic diagram of one embodiment of a configuration parameters document of the disclosure; 
           [0012]      FIG. 6  is a schematic diagram of one embodiment of a portion of a configuration tree converted from a block B 1  in the configuration parameters document of  FIG. 5 ; 
           [0013]      FIG. 7  is a flowchart of one embodiment of a configuration tree construction in the electronic device system; 
           [0014]      FIG. 8  is a flowchart of one embodiment of a configuration tree modification in the electronic device system; and 
           [0015]      FIG. 9  is a flowchart of one embodiment of a node retrieval from a configuration tree in the electronic device system. 
       
    
    
     DETAILED DESCRIPTION 
       [0016]    The disclosure may be implemented in various device or systems, such as routers, ADSL devices, cable modems, or set-top boxes (STBs). 
         [0017]    With reference to  FIG. 2 , an electronic device system  200  comprises a nonvolatile memory  210 , a processor  220 , a main memory  230 , and a communication unit  240 . The communication unit  240  may comprise communication ports and various components, such as antennas and controllers thereof, a digital signal processor (DSP), an analog-to-digital converter, a tuner in a cable modem, an Ethernet controller, a universal serial bus (USB) controller, and/or a peripheral component interconnect (PCI) controller. The processor  220  may be made up of integrated circuits (IC) implementing processes and/or executing programs. The processor  220  may be packaged as one IC chip or multiple interconnected IC chips. For example, the processor  220  may be a central processing unit (CPU) or a combination of a CPU and a communication controller. The communication controller controls communication between components of the electronic device system  200  and/or communication between the electronic device system  200  and an external device. Note that the communication components may be integrated into the communication unit  240  or the processor  220 . 
         [0018]    The main memory  230  may comprise one or more types of random access memory (RAM), Examples of the nonvolatile memory  210  may comprise electrically erasable programmable read-only memory (EEPROM) or flash memory. The nonvolatile memory  210  stores an operating system (OS) and applications of the electronic device system  200 . Programs and data may be stored in the nonvolatile memory  210  in compressed formats, for decompression and loading to main memory  230  before execution or retrieval of the programs and data. 
         [0019]    With reference to  FIG. 3 , the electronic device system  200  may comprise a main memory  100 A. The main memory  100 A may be a virtual memory mapped to an area on the main memory  230  or the nonvolatile memory  210 . The main memory  100 A comprises a user space and a kernel space. A document  12  comprises configuration parameters privileged to an application  10   c,  which is to be shared by other applications. 
         [0020]    One application (such as the application  10   c  in  FIG. 3 ) in the electronic device system  200  activates parsing of the document  12 . A kernel  13  builds a configuration tree (such as a tree  11   d ) corresponding to the document  12  in the user space of the main memory  100 A according to relationships of configuration parameters in the document  12 . Each application which is to read or modify parameters in the tree  11   d  is required to utilize the kernel  13  to read or modify. Data structure of configuration parameters is organized as trees in the disclosed embodiments but is not limited thereto, and may alternatively be organized as arrays or linked lists. Each of applications  10   a - 10   c  may read or modify parameters in the tree  11   d  through the kernel  13 . An exemplary embodiment of electronic device system is detailed with reference to  FIG. 4 . 
         [0021]    In  FIG. 4 , the electronic device system  200  comprises a group  10  of applications A 1 -An, where n is a positive integer greater than one. Examples of the applications A 1 -An may comprise the applications  10   a - 10   c  in  FIG. 3 . The electronic device system  200 . The electronic device system  200  further comprises an application programming interface (API)  30 , system calls  32  provided by the kernel  13 , a device driver  34 , and a device file (or device special file)  36 . 
         [0022]    The API  30  comprises function library including functions for analyzing configuration parameter documents (such as document  12 ), functions for building configuration trees based on the analysis, and functions for reading and modifying parameter values in the configuration tree. Since configuration trees are located in the kernel space, functions in the API  30  may utilize system calls (such as “ioctl” in the Linux operating system) provided by the kernel  13  to trigger the kernel  13 , whereby the kernel  13  further triggers the device  34  to establish, read, or modify configuration trees in a group  38  thereof. The group  38  comprises configuration trees T 1 -Tm, wherein m is a positive integer greater than one. For example, configuration trees in the group  38  can comprise the configuration tree  11   d  in  FIG. 3 . 
         [0023]    In Unix, Linux, or Unix-similar OSs, a device file represents a device and a device driver thereof, and is stored in a directory “/dev”, thus to enable interaction with the device driver by an application through standardized input/output system calls. Here, the device file is named “xmlconf” and represents the group  38  and configuration trees therein. In  FIG. 4 , a major number N 1  in the device file  36  is a number representing the device driver  34 , and a minor number set N 2  comprises multiple minor numbers each representing one of configuration trees T 1 -Tm. Each application in group  10 , functions in the API  30 , and the device driver  34  can utilize the device file  36  to specify, and read or write one configuration tree. 
         [0024]    An application may open the device file /dev/xmlconf to retrieve the major number N 1  and subsequently request the kernel  13  to locate and utilize the device driver  34  based on the major number N 1 . The device driver  34  may locate a specific configuration tree based on a minor number in the device file /dev/xmlconf and modify or read parameter values in the specific configuration tree in response to requests from the application. 
         [0025]    Device files may comprise, for example, character special file (corresponding to a character device) and block special file (corresponding to a block device). The character special file specifies a character device and that the data exchanged between the character device and an OS is in character units. The block special file specifies a block device and that the data exchanged between the block device and an OS is in block units. A block unit is greater than a character unit. Examples of the character devices may comprise modems and telephony devices. Examples of the block devices may comprise hard disk drives and optical disc drives. The device driver  34  retrieves and returns parameter values in a node of a configuration tree for each read request, and thus the device file  36  is preferably a character device. An example of parsing a configuration document to generate a corresponding configuration tree of the document is given in the following: 
       EXAMPLE 1 
       [0026]      FIG. 5  shows an example of the configuration document  12  corresponding to a portion of a configuration tree shown in  FIG. 6 . Configuration parameters recorded in a configuration document  12  are between &lt;ConfigTree&gt; and &lt;/ConfigTree&gt;. Configuration parameters related to asynchronous transfer mode (ATM) communication are between &lt;AtmCfg&gt; and &lt;/AtmCfg&gt;. Between &lt;AtmCfgTd&gt; and &lt;/AtmCfgTd&gt; are configuration parameters related to link types of ATM communication. For example, “CBR” specifies “constant bit rate”. Between &lt;AtmCfgVcc&gt; and &lt;/AtmCfgVcc&gt; are configuration parameters related to permanent virtual circuit (PVC). Between &lt;SecCfg&gt; and &lt;/SecCfg&gt; are configuration parameters related to network security. Between &lt;WirelessCfg&gt; and &lt;/WirelessCfg&gt; are configuration parameters related to wireless local area network (wireless LAN, IEEE 802.11). Between &lt;RouteCfg&gt; and &lt;/RouteCfg&gt; are static routing tables of the electronic device system  200 . Between &lt;PMapCfg&gt; and &lt;/PMapCfg&gt; are configuration parameters related to port mapping. &lt;SNTPCfg&gt; and &lt;/SNTPCfg&gt; are configuration parameters related to network time service, that is for configuring a simple network time protocol (SNTP) server. Between &lt;Voice&gt; and &lt;NVoice&gt; are configuration parameters related to voice over Internet protocol (VoIP). Between &lt;pppsrv — 8 — 35&gt; and &lt;/pppsrv — 8 — 35&gt; are configuration parameters related to point-to-point protocol (PPP). Between &lt;wan — 8 — 35&gt; and &lt;/wan — 8 — 35&gt; are parameters for configuring wide area network (WAN) ports, which is closely related to the ATM PVC configuration. 
         [0027]    The kernel  13  or each application in the electronic device system  200  may initiate the conversion from the document  12   a  to a configuration tree. For example, the kernel may initiate the conversion upon bootstrap of the electronic device system  200 . Alternatively, an application Ai (wherein i is an positive integer, and 1≦i≦n) may initiate the conversion up initialization of the application Ai. The kernel  13  or each of the applications A 1 -An may utilize the API  30  to convert the document  12   a  to representative data thereof in a specific intermediate format, and the device driver further establishes a configuration tree corresponding to the document  12   a  from the representative data. 
         [0028]    A process is a program in execution by the processor  10  and may comprise an executed application, or kernel. With reference to  FIG. 7 , when a first process in the electronic device system  200  is to establish a configuration tree, the process invokes a tree-establishing function in the API  30  (step  700 ). The invocation comprises a filename of the device file  36  corresponding to the device driver  34 . The tree-establishing function acts as a parser module to parse the document  12   a  and generate representative data comprising parameter values and parameter relationships recorded in the document  12   a  in response to the invocation from the process (step  702 ). The attribute “autoScan” and the value thereof in the tag &lt;protocol&gt; may be, for example, represented by “protocol.autoScan=enable” in the representative data in step  702 . The tree-establishing function further transfers the filename of the device file  36 , the representative data, and other required data to the kernel  13  through a system call  32  provided by the OS of the electronic device system  200  (step  704 ). The kernel  13  retrieves the device file  36  based on the filename, subsequently retrieves the device driver  34  based on the major number N 1  in the device file  36 , and transfers the representative data to the device driver  34 , thus to trigger configuration tree establishment by the device driver  34  (step  706 ). The device driver  34  creates a minor number in the minor number set N 2  to correspond to the to-be-established configuration tree (step  708 ). The device driver  34  accordingly utilizes the representative data to establish a configuration tree Tj representative of the representative data and the document  12   a  (step  710 ). The variable j is a positive integer, and 1≦j≦m. 
         [0029]      FIG. 6  shows a portion of the configuration tree generated from a block B 1  in the document  12   a . Tags &lt;SystemInfo&gt; and &lt;/SystemInfo&gt; has tag name “SystemInfo” and encloses tags respectively with tag names “protocol”, “sysLog”, and “sysUserName”. Accordingly, the device driver  34  creates nodes respectively corresponding to parameters and tags associated with “SystemInfo”, “protocol”, “sysLog”, and “sysUserName” in the corresponding configuration tree of the document  12   a  in response to the invocation in step  700 , wherein the node of “SystemInfo” is a parent node of the nodes of “protocol”, “sysLog”, and “sysUserName”. Since the tag of “protocol” comprises attributes of “autoScan”, “upnp”, “igmpSnp”, “igmpMode”, macFilterPolicy”, “encodePassword” and “enetwan”, the device driver  34  accordingly creates nodes corresponding to “autoScan”, “upnp”, “igmpSnp”, “igmpMode”, macFilterPolicy”, “encodepassword” and “enetwan” to be children nodes of the node of “protocol”. Each node corresponding to an attribute comprises the value of the attribute. The device driver  34  may similarly create children nodes of the nodes of “sysLog” and “sysUserName” and other nodes in the configuration tree. 
         [0030]    After the configuration tree Tj has been established, parameter values in nodes of the configuration tree Tj may be read or modified by other processes. With reference to  FIG. 8 , when a second process in the electronic device system  200  is to modify a specific node in the configuration tree Tj (referred to as a target node hereafter), the second process invokes a function in the API  30  for modifying the configuration tree (step  800 ). The second process may be a process of any of the application A 1 -An or the kernel  13 . The invocation in step  800  comprises a filename of the device file  36  corresponding to the device driver  34 , new configuration parameter values, and other data as required. For example, a PPP or DHCP process receives a new IP address of the electronic device system  200  as a new configuration parameter value from a WAN and accordingly utilizes the new IP address to update an original IP address of the electronic device system  200  recorded in a target node in the configuration tree Tj. The invocation in step  800  may comprise the name of the target node and the path from the root of the configuration tree Tj to the target node. The path may comprise names of ancestor nodes of the target node. 
         [0031]    The modifying function invoked in step  800  transfers the filename, the name of the target node, and new configuration parameter values to the kernel  13  through a system call provided by the OS of the electronic device system  200  (step  802 ). The kernel  13  retrieves the device file  36  based on the filename, subsequently retrieves the device driver  34  based on the major number N 1  in the device file  36 , and transfer the new configuration parameter values to the device driver  34 , thus to trigger the device driver  34  to update parameter values in the target node (step  804 ). The device driver  34  locates the target node in the configuration tree Tj (step  806 ) and utilizes the new configuration parameter values to update parameters values recorded in a target node (step  808 ). In step  808 , the device driver  34  may retrieve the target node based on the path directing thereto or by searching the entire configuration tree Tj. 
         [0032]    In  FIG. 6 , the IP address of electronic device system  200  in the configuration tree Tj is generated from an attribute ‘address=“192.168.1.1”’ in “entry 1 ” tags in block B 2 . After the IP address update, a firewall program in the electronic device system  200  may read the new IP address of the electronic device system  200  from the configuration tree Tj and utilize the new IP address to perform firewall functions. Similarly, a network address translation (NAT) program in the electronic device system  200  may read the new IP address of the electronic device system  200  from the configuration tree Tj and utilize the new IP address to perform NAT functions. 
         [0033]    With reference to  FIG. 9 , when a third process in the electronic device system  200  is to read a specific node in the configuration tree Tj (referred to as a target node hereafter), the third process invokes a function in the API  30  for reading the configuration tree (step  900 ). The third process may be a process of the applications A 1 -An or the kernel  13 . The invocation in step  800  comprises a filename of the device file  36  corresponding to the device driver  34  and the name of the target node. The invocation in step  900  may comprise the path from the root of the configuration tree Tj to the target node. The path may comprise names of ancestor nodes of the target node. 
         [0034]    The reading function invoked in step  900  transfers the filename and the name of the target node to the kernel  13  through a system call provided by the OS of the electronic device system  200  (step  902 ). The kernel  13  retrieves the device file  36  based on the filename, subsequently retrieves the device driver  34  based on the major number N 1  in the device file  36 , and transfers the name of the target node to the device driver  34 , thus triggering the device driver  34  to locate the target node and retrieve parameter values in the target node based on the node name (step  904 ). The device driver  34  locates the target node in the configuration tree Tj based on the node name of the target node (step  906 ) and returns parameter values therein to the kernel  13  (step  908 ). The kernel  13  further returns the parameter values retrieved from the target node to the third process (step  910 ). In step  906 , the device driver  34  may retrieve the target node based on the path directing thereto or by searching the entire configuration tree Tj. 
         [0035]    Utilizing the disclosed method, the application A 1 -An and the kernel  13  may share and synchronize configuration parameters. The method may be implemented in alternative embodiments. For example, the electronic device system  200  can comprise a system configuration process. The system configuration process allows a username, currently “admin” as shown in  FIG. 6 , to be recorded in the child node “value” of the node “sysUserName”. The system configuration process provides a user interface to receive setting of the configuration parameters, such as “logLevel”, in the configuration tree in  FIG. 6  from a user. Here, each program in the electronic device system  200  records relative events of the program during execution thereof in a log file. The electronic device system  200  may transmit the log file to an external server for further analysis. Each program in the electronic device system  200  determines the complexity of event recording related to the program based on a parameter value in the node “logLevel”. For example, each program in the electronic device system  200  may determine event types based on a parameter value in the node “logLevel” and records no event except events of the determined types. Values recorded in node “sysUserName” and “logLevel” can be set, read, or modified according to the method as described. 
         [0036]    The electronic device system  200  further comprises a user authentication process. The system configuration process provides a user interface to receive setting of an IP address of a remote device capable of remotely accessing the electronic device system  200 , and stores the IP address of the remote device between &lt;TelnetAcl&gt; and &lt;/TelnetAcl&gt; in block B 3  of the document  12   a . After configuration parameters in the block B 3  has been converted to one node in the configuration tree Tj, the system configuration process may add, delete, or modify the IP address in the node. The user authentication process may access and utilize the IP address of the remote device to accordingly provide access control of the electronic device system  200  to any user from any remote device. 
         [0037]    The disclosed method can assist the current system design. The application A 1 -An and the kernel  13  may share and synchronize configuration parameters utilizing the disclosed method. The disclosed method is preferably implemented in Linux/Unix-similar OS environments. 
         [0038]    It is to be understood, however, that even though numerous characteristics and advantages of the disclosure have been set forth in the foregoing description, together with details of the structure and function of the invention, the disclosure is illustrative only, and changes may be made in detail, especially in matters of shape, size, and arrangement of parts within the principles of the invention to the full extent indicated by the broad general meaning of the terms in which the appended claims are expressed.