Introduction Embedded system development has become one of the hottest fields in the computer industry, with applications penetrating into numerous areas such as home appliances, industrial control, communication and electronic equipment, and artificial intelligence devices. The introduction of embedded operating systems has greatly improved the functionality of embedded systems and facilitated the design of embedded application software, but it has also consumed valuable embedded system resources. Furthermore, because embedded application systems vary significantly in configuration and I/O operations are not standardized, the driver software is often provided by the application program. This necessitates the ability to tailor and extend the user-selected real-time operating system within the development environment and bind it to the application program to generate an application system that can run in the target environment. Therefore, tailoring unnecessary operating system modules to meet different application requirements and configuring a specific embedded operating system is key to reducing system hardware costs, minimizing system resource consumption, and improving system flexibility. Most embedded operating systems adopt a component-based and modular design philosophy, constructing software through interconnection in a building-block manner, thus making them configurable. However, due to the diversity of operating systems, the configuration methods provided by different operating systems vary greatly in complexity. For example, Wind River's VxWoks operating system, with its Tornado development environment providing configuration tools that allow selection and deletion of operating system modules, still relies primarily on manual editing and modification of relevant configuration files within the target system's directory tree. Similarly, Keyin Jingcheng's Delta OS, with its Lambda Tool development environment, allows for simple setting of kernel, file system, and network system parameters. Due to the diversity of hardware platforms, even the same operating system can have different configurations. Application developers must be familiar with different hardware platforms and operating systems to develop viable applications, increasing the difficulty of application development. For embedded application development, multiple operating systems are often provided for developers to choose from. If a unified operating system configuration tool could be provided, application developers wouldn't need to relearn and use new configuration environments for different operating systems, significantly improving development efficiency—a crucial aspect of industry development. This paper applies software reuse technology to the customization process of embedded operating systems, proposing a general model for embedded operating system customization (OSTAILOR), and based on this, researching and designing a configuration trimmer based on embedded Linux. 1. Generalized Model for Embedded Operating System Configuration Using the operating system abstract module as the basic unit of operating system configuration, the generalized model for embedded operating system configuration, OSCFG, is derived. 1.1 Model Overview As shown in Figure 1, the dashed box represents the established operating system configuration model. The two solid boxes on the left represent the inputs to the operating system configuration model: selecting the operating system type and selecting the operating system abstract module. The solid box on the right represents the output configuration result: a specific configuration file. [align=center][img=433,80]http://www.e-works.net.cn/images/128050202526093750.GIF[/img] Figure 1 Operating System Customization Process[/align] The key to the operating system configuration model lies in its generality, that is, maintaining logical transparency to the physical modules divided by the operating system for different operating systems. Therefore, the key points of modeling are as follows: ① Abstracting various operating system modules to become abstract modules corresponding to the configuration model. Abstract modules are stored in the component library in the form of module attribute files for configuration selection. ② The abstract module can ultimately be mapped to entity information corresponding to different operating systems. Under the above premise, the OSTAILOR operating system configuration process model shown in Figure 2 was constructed. The shaded area in the figure realizes the operating system independence of the configuration and can be called the operating system abstraction layer. Figure 2 OSTAILOR Process Model For a specific operating system module entity, it first undergoes module abstraction and is encapsulated into an operating system abstract module visible to the application. Each operating system module contains two key attributes: ① The abstracted module name. Based on this module name, application developers can know the basic functions of this operating system module. ② Module hierarchy; modules belonging to different levels have different module granularities. Generally speaking, the closer the module is to the bottom level, the finer the granularity. After configuration is complete, the user selects the specific operating system to be mapped based on the input. Only after the module configuration is complete can a specific operating system mapping algorithm be selected to map the abstract module to the specific operating system function. [align=center][img=352,232]http://www.e-works.net.cn/images/128050202750000000.GIF[/img] Figure 2 OSTAILOR Process Model[/align] The abstract module configuration layer in Figure 2 also includes the ability to configure the operating system abstract module into a higher-level, more granular module according to the user's selection, for use in this operating system generation or the next customization. In this operating system customization model, the function completed by the layers below the abstract module configuration layer is to complete the mapping to the specific operating system according to the configuration result of the module configuration layer and the user's selection of the operating system type. This part is specific because it is related to the specific embedded operating system. In order to achieve the universality of the configuration, it is necessary to consider how to minimize the specificity. 1.2 Basic Working Principle (1) Configuration Basic Process The basic process of customization is shown in Figure 3. The user's browser queries the component library and displays the available modules to the user, then receives the user's selection of the module and sends the selection result to the file parser. Obtain the attribute file of the corresponding module from the component library. The parsing results are used to generate a module structure mapping diagram. The modules in the module structure diagram exist in an abstract logical form. The physical entity information of the modules can be obtained by searching the component library. Based on the module structure mapping diagram and the physical entity information of each module, the corresponding Makefile or other related configuration files are generated and provided to the corresponding Make tools (compiler, linker, etc.). Finally, the executable file of the system is generated. [align=center][img=462,242]http://www.e-works.net.cn/images/128050202942343750.GIF[/img] Figure 3 Basic configuration process[/align] (2) Hierarchical division of module abstraction Generally speaking, the larger the granularity of the module, the more functions each module contains, and the lower its configurability; while the smaller the granularity of the module, the higher the configuration complexity. In order to achieve the flexibility and convenience of configuration and minimize the parts of the configuration involving the special characteristics of the operating system, we abstract the modules and divide them into multi-level structures. Different levels of modules encapsulate their lower-level modules to form different configuration granularities. The structure is described in three layers, as shown in Figure 4. [align=center][img=500,213]http://www.e-works.net.cn/images/128050203171250000.GIF[/img] Figure 4 Module Abstraction Structure[/align] The lowest layer in Figure 4 is the atomic module, which abstracts the basic functions of the operating system, including tasks, I/O drivers, timers, semaphores, message queues, event groups, mailboxes, pipes, etc. In addition, it includes some basic application functions. It is called an atomic module to indicate that it is an indivisible basic module and the foundation for configuring other layers of modules. The granularity of the atomic module exists at the object code or library file level because the physical entity it maps to exists in the object code or library file. Although it exists as an abstract logical module in the hierarchical structure of Figure 4, it is the layer most closely connected to physical entities and has the finest granularity. Therefore, after the configuration process, different files are mapped through this layer, generating configuration files of different formats to achieve the goal of configuring different operating systems. An atomic-level module only completes a part of a specific function, or only a sub-function of a specific function, and must be combined with other atomic-level modules to play its due role. Therefore, the concept of a functional-level module is proposed at its upper level. Functional-level modules are generated by configuring atomic-level modules. By combining different atomic-level modules, a specific function is completed, and the module granularity is increased. For example, configuring a wireless internet access module requires selecting not only the wireless internet access itself (an atomic-level module) but also atomic-level modules in the operating system that support internet access, such as the TCP/IP protocol stack. By assembling functional-level modules together to complete more powerful functions, application-level modules are formed. Each application-level module is a set of functional modules and also the layer with the largest granularity. For application developers, if they do not want to choose fine-grained modules when developing specific applications, they can directly choose application-level modules to configure the operating system. This modular layered structure can provide developers with different module granularities, allowing users to choose different levels of modules as needed, thereby enhancing the flexibility of the customization process; and its biggest advantage is that for each change in customization requirements, it is not necessary to start from the finest-grained atomic-level module configuration again, but rather to analyze the change in requirements, replace the appropriate granularity module, keep the other parts unchanged, simplify the configuration process, and reduce configuration time. (3) Module layer parsing Module parsing is exactly the opposite of the module configuration process. Module configuration starts from the bottom layer and builds higher-level modules layer by layer; while module parsing starts from the top layer and goes down layer by layer until the mapping relationship of the bottom layer is found, and at the same time, the corresponding relationship diagram is constructed. Based on the encapsulation of modules, each layer of modules only cares about the mapping relationship of the lower-level modules closely related to it, that is, what modules it is composed of in the lower layer. For this reason, when configuring and generating each module, we save its mapping relationship to the lower layer in the database. During layer-by-layer parsing, we use the module name as the top-level node of the relationship graph and look up its mapping relationship to lower-level modules in the database. Based on the lower-level modules involved in the mapping relationship, if a corresponding node does not exist in the relationship graph, a new node is added, each corresponding to a lower-level module name. Based on the mapping relationship, topological relationships are added to the graph. Each new node is then used as a new top-level node, and the process is repeated until the final mapping reaches atomic-level components, thus constructing a complete relationship graph. In other words, the relationship graph generation process is the entire mapping process. The algorithm description is shown in Figure 5. [align=center][img=490,434]http://www.e-works.net.cn/images/128050204730625000.GIF[/img] Figure 5 Description of the parsing algorithm[/align] (4) The final completion of the configuration is up to the completion of the module-level parsing process. All operations have ignored the special characteristics of the operating system; however, embedded systems are diverse, not only in the diversity of operating systems, but also, even the same operating system, corresponding to different processors, their composition is very different. In order to generate a user-customized specific operating system, according to the operating system type selected by the user input, in the relational graph generated by the above parsing process, the nodes with an out-degree of O (that is, the nodes corresponding to atomic- level modules) are selected and mapped to different operating system entities. Then, according to the rules that different compilers and linkers can recognize, different makefile files, config files and resource files are generated. It can be said that the generation of various configuration files marks the completion of the operating system customization process. 2. Implementation of a configuration trimmer based on embedded Linux Using the general model of the customization process, we implemented a configuration trimmer for embedded Linux. The configuration trimmer is integrated as a tool into the PDA mobile phone development platform based on embedded Linux. The configuration trimmer uses the component library manager as a container for its optional abstract modules, while its output configuration file is provided to the project manager, which submits it to the compiler and linker for operating system generation. The relationship between the three is shown in Figure 6. The following is a description of the functions of the three tools. [align=center][img=418,168]http://www.e-works.net.cn/images/128050204936406250.GIF[/img] Figure 6 PDS mobile phone development platform structure[/align] (1) Configuration trimmer ① Displays the existing module information obtained from the component library. ② Configures new modules according to user selection and stores the module information in the component library for use as existing modules in the next customization. ③ Customizes the operating system required for specific application development: Users can select modules of different granularities that already exist in the component library for configuration. When it is necessary to compile and link to generate target code that can be downloaded to the target machine, the corresponding configuration file is generated and sent to the project manager. (2) The component library manager stores operating system abstract module information for the configuration trimmer to query and use. The query content includes: ① configurable module names, which are extracted by the configuration trimmer and displayed on the user interface for user configuration selection; ② mapping information of each module to its next level. Based on this mapping information, a recursive search can be performed, thus supporting the hierarchical resolution and operating system mapping functions of each module in the configuration trimmer. (3) Project Manager The project manager manages the development of applications, and therefore provides the configuration trimmer with the source file path information of the application compiled by the application developer. The biggest feature of embedded software is that the application is often not independent; it is ultimately downloaded to the target machine as binary target code along with the operating system. Therefore, the configuration trimmer needs to write the source file path information obtained from the project manager into the corresponding Makefile file. Taking the application-level module required for the user's application development configuration as an example, the working steps of the configuration trimmer are explained as follows: ① Select the existing application-level module in the component library, customize the operating system, and save the configuration file path in the component library manager. ② When the project manager receives a request to obtain the specific operating system configuration file, search the component library to obtain the saved configuration file path of the specific application. Based on this path and filename, the file is opened and parsed to obtain the number and names of the application-level modules contained in the application, generating an initial relationship graph. ③ Based on the number and names of the application-level modules, the component library is searched to obtain the configuration file name and path of each application-level module. The file is parsed to obtain the corresponding functional-level modules, and the functional-level modules and their corresponding topological relationships are added to the relationship graph. ④ This process is repeated until the corresponding atomic-level modules are found, ultimately generating a complete relationship graph. ⑤ Based on the relationship graph, the component library is searched to map the atomic-level modules to the customized operating system entities. This system utilizes the Linux built-in configuration system, compiling the kernel and generating a user-customized operating system kernel by modifying the existing Makefile and kconfig files in the Linux source code system. Therefore, the entity information of the atomic-level modules corresponding to a specific operating system is the configuration item that needs to be added to the kconfig file, such as selecting the entity information corresponding to the network module, i.e., the "CONFIG_NET=y" configuration item. Conclusion Through research on operating system customization technology, a general model for the operating system customization process, OSTAILOR, was abstracted. Combined with the 863 project "Embedded Software Development Platform for PDA Mobile Phones," an embedded Linux configuration trimmer was implemented. Users can use this tool's user-friendly graphical interface to customize Linux kernel components and application modules, automatically generating various intermediate configuration files, avoiding the tedious manual writing and modification of these files. This demonstrates the feasibility of using this model to generalize the embedded operating system customization process. However, in this model, application developers who customize a specific operating system must use the application programming interface (API) provided by that operating system. If the customized operating system needs to be modified, the corresponding API in the application must be replaced. How to ensure operating system independence for application development during the operating system customization process will be the direction of further research in this project.