Processing method and device, electronic equipment and storage medium

Abstract

The invention provides a processing method and device, electronic equipment and a storage medium. The method comprises the steps that a source code file of a first operating system is acquired; compiling the source code file to obtain a first static library of the first operating system, the first static library comprising kernel mode source codes of at least one functional component; obtaining a target function, wherein the target function is used for mapping a first interface of a first operating system required by the functional component to a second interface of a second operating system; and obtaining a target operating system according to the first static library, the target function and the second operating system.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to a processing method, device, electronic device and storage medium. Background Art

[0002] With the rise of edge computing artificial intelligence (AI, Artificial Intelligence), the operating hardware platform of embedded real-time operating system (RTOS, Embedded Real-Time Operating Systems) has been greatly upgraded, and embedded platforms and general-purpose computer platforms are getting closer and closer. Many peripherals of general-purpose computer platforms appear on embedded platforms, such as networks, universal serial buses (USB, Universal Serial Bus), peripheral component interconnect extensions (PCIe, Peripheral Component Interconnect Express), serial ATA (SATA, Serial Advanced Technology Attachment), non-volatile memory expression (NVME, Non-Volatile Memory Express), etc. Therefore, embedded real-time systems are required to support common peripherals on general-purpose operating systems (GPOS, General Purpose Operating Systems), and the hardware requirements for embedded platforms are more diversified. The embedded driver support provided in the relevant technology is increasingly insufficient, which affects the realization of embedded real-time system functions. Therefore, it is necessary to provide a method for improving the driving capability of embedded real-time operating systems. Summary of the invention

[0003] The present disclosure provides a processing method, an apparatus, an electronic device and a storage medium to at least solve the above technical problems existing in the prior art.

[0004] In a first aspect, an embodiment of the present disclosure provides a processing method, including:

[0005] Obtaining a source code file of a first operating system;

[0006] Compile the source code file to obtain a first static library of the first operating system, wherein the first static library includes kernel-state source code of at least one functional component;

[0007] Obtaining a target function, where the target function is used to map a first interface of the first operating system required by the functional component to a second interface of the second operating system;

[0008] A target operating system is obtained according to the first static library, the target function and the second operating system.

[0009] In a second aspect, an embodiment of the present disclosure provides a processing device, including:

[0010] An acquisition module, used to acquire a source code file of the first operating system;

[0011] A first processing module is used to compile the source code file to obtain a first static library of the first operating system, wherein the first static library includes a kernel state source code of at least one functional component;

[0012] A second processing module, used for obtaining a target function, where the target function is used for mapping a first interface of the first operating system required by the functional component to a second interface of the second operating system;

[0013] The third processing module is used to obtain a target operating system according to the first static library, the target function and the second operating system.

[0014] In a third aspect, an embodiment of the present disclosure provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above method when executing the program.

[0015] In a fourth aspect, an embodiment of the present disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the steps of the above method when executed by a processor.

[0016] The processing method, device, electronic device and storage medium provided by the embodiment of the present disclosure are as follows: the source code file of the first operating system is obtained; the source code file is compiled to obtain the first static library of the first operating system, the first static library includes the kernel state source code of at least one functional component; the target function is obtained, the target function is used to map the first interface of the first operating system required by the functional component to the second interface of the second operating system; the target operating system is obtained according to the first static library, the target function and the second operating system. In this way, the source code of the functional component in the first operating system can be migrated as a whole to the second operating system for compatible operation, and the problem of insufficient support for the functional component in the second operating system is solved on the basis of ensuring the characteristics of the second operating system.

[0017] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 A flowchart of a processing method provided by an embodiment of the present disclosure;

[0019] Figure 2 A schematic diagram of the structure of a GPOS provided for an application embodiment of the present disclosure;

[0020] Figure 3 A schematic diagram of the structure of an RTOS with expanded functional components provided in an application embodiment of the present disclosure;

[0021] Figure 4 A schematic diagram of a verification method provided by an embodiment of the present disclosure;

[0022] Figure 5 The application embodiment of the present disclosure provides a flowchart of a method for running a general operating system driver compatibly on a real-time operating system;

[0023] Figure 6 A schematic diagram of the structure of a processing device provided in an embodiment of the present disclosure;

[0024] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0025] In order to make the purpose, features, and advantages of the present disclosure more obvious and easy to understand, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present disclosure.

[0026] Before further elaborating on the technical solution of the present disclosure in combination with the accompanying drawings and specific embodiments, the related technologies and terms involved are first explained.

[0027] An operating system (OS) is a built-in program that coordinates various computer hardware to interact with users. Currently, it is divided into two categories based on application scenarios and design goals:

[0028] 1. General-purpose operating system (GPOS). For example, Linux, FreeBSD, etc. GPOS can be applied to personal computers, servers and other devices, supporting extensive interaction with end users. It can provide diverse functions to meet complex user needs, usually occupying more system resources, and has relatively low requirements for real-time performance.

[0029] 2. Embedded real-time operating system (RTOS). Such as FreeRTOS, RTEMS, etc. RTOS can be applied to IoT devices, embedded control systems, etc., and can respond to external events in real time, such as sensor input. It takes up less resources to adapt to hardware limitations and has high real-time requirements.

[0030] In comparison, GPOS and RTOS have obvious differences in design ideas. GPOS focuses more on functionality and user experience, while RTOS focuses more on real-time and resource optimization. Traditionally, GPOS provides complete driver support, while the peripheral devices connected to RTOS are usually simpler and only require developers to implement a small number of simple drivers to work.

[0031] As the demand increases, the lack of embedded driver support has affected the realization of RTOS functions. In the related art, the following methods are provided to expand the driver capabilities of RTOS.

[0032] Method 1: Develop a dedicated driver framework for RTOS. You can develop a driver that matches the real-time requirements of RTOS and port it to RTOS. However, the development of a new driver requires writing and testing, and as new hardware and new features continue to increase, corresponding bug fixes are also required. This method has a long development cycle, high technical requirements, and is difficult to keep up with the speed of peripheral updates.

[0033] Method 2: Run the real-time optimized GPOS on the embedded platform. However, on the one hand, running the real-time tailored GPOS may not meet the real-time requirements of the RTOS. On the other hand, many features of the GPOS itself are not needed by the target users of the RTOS, which will introduce additional complexity. However, the real-time performance of the GPOS obtained by this method is not as good as that of a dedicated RTOS, and it will introduce a lot of additional resource overhead.

[0034] Based on this, the present disclosure provides a processing method, including: obtaining a source code file of a first operating system; compiling the source code file to obtain a first static library of the first operating system, the first static library including the kernel state source code of at least one functional component; obtaining a target function, the target function is used to map the first interface of the first operating system required by the functional component to the second interface of the second operating system; according to the first static library, the target function and the second operating system, a target operating system is obtained. In this way, the driver framework source code in the first operating system can be migrated as a whole to the second operating system for compatible operation, solving the problem of insufficient driver capability support in the second operating system.

[0035] Figure 1 A flowchart of a processing method provided by an embodiment of the present disclosure is shown in FIG. Figure 1As shown, the method includes:

[0036] Step 101: Obtain a source code file of a first operating system;

[0037] Step 102: compile the source code file to obtain a first static library of the first operating system, wherein the first static library includes a kernel state source code of at least one functional component;

[0038] Step 103: Obtain a target function, where the target function is used to map a first interface of the first operating system required by the functional component to a second interface of the second operating system;

[0039] Step 104: Obtain a target operating system according to the first static library, the target function and the second operating system.

[0040] In some embodiments, the processing method can be applied to any intelligent electronic device, such as a computer, a server, etc. The electronic device can receive or obtain the source code file of the first operating system and the source code file of the second operating system from other devices. The source code file of the first operating system is allowed to be ported to other operating systems.

[0041] The source code file of the first operating system includes source codes related to various driver functions, such as USB, PCIe and other drivers.

[0042] In some embodiments, the real-time performance of the second operating system is higher than the real-time performance of the first operating system.

[0043] Specifically, the first operating system may be GPOS; the second operating system may be RTOS; the real-time performance of RTOS is higher than that of GPOS.

[0044] In this way, by migrating the functional components of the first operating system (such as GPOS) to the second operating system (such as RTOS), a target operating system is obtained, which can have both the rich functional components of the first operating system to improve driving capabilities and the high real-time performance of the second operating system.

[0045] In some embodiments, obtaining a target operating system according to the first static library, the target function and the second operating system includes:

[0046] Import the first static library and the target function into the second operating system to obtain a target operating system.

[0047] Here, the functional components may include: hardware basic functional components, device bus components, device driver components, device access interfaces, etc.

[0048] For example, hardware basic functional components are used to implement functions that have common characteristics of devices, such as block devices, character devices, network devices, etc.

[0049] The device bus component is used to implement the functions of a certain type of device, such as PCIe, USB, network protocol stack, etc.

[0050] The device driver component is used to implement the functions and drivers of a specific device, such as a network card, USB flash drive, etc.

[0051] The device access interface is used by the operating system to control and access specific devices.

[0052] Here, the first static library and the target function can be imported into the second operating system based on the import rule to obtain the target operating system; the import rule can be implemented by the first script tool to achieve automatic import. The import rule and the first script tool are designed in advance according to the requirements, the first operating system, and the second operating system, and they can achieve the above-mentioned import work, and the specific script and specific code are not limited.

[0053] In this way, automatic import is achieved through the import rules and the first script tool to obtain the target operating system, thereby improving the import efficiency. Furthermore, if there are multiple second operating systems, the first static library and the target function can be imported into each second operating system respectively, that is, multiple functional components of the first operating system can be provided to multiple second operating systems quickly and efficiently.

[0054] In some embodiments, importing the first static library and the target function into the second operating system includes:

[0055] Compiling the source code of the second operating system to obtain a second static library of the second operating system;

[0056] According to the target function, the kernel-mode source code of the at least one functional component and the second static library are linked.

[0057] Here, the first static library of the first operating system includes: kernel-mode source code of at least one functional component.

[0058] For example, the first operating system is GPOS, and the first static library may include: GPOS kernel state source code of at least one functional component.

[0059] For kernel-mode source code, a method for implementing the import of kernel-mode source code of each functional component through a target function is provided, that is, a method for linking the kernel-mode source code of each functional component with a second static library of a second operating system.

[0060] Specifically, the import rules may include: kernel state source code import rules from the first operating system (such as GPOS) to the second operating system (such as RTOS), and kernel state interface namespace conversion rules from the first operating system to the second operating system.

[0061] Among them, the kernel-mode source code import rules from the first operating system to the second operating system include: in the process of importing the kernel-mode source code of each functional component of the first operating system into the source code of the second operating system, the directory structure and relative position of the source code of each functional component in the first operating system and the second operating system remain unchanged before and after the import, and only the required kernel-mode source code needs to be imported.

[0062] The kernel-mode interface namespace conversion rules from the first operating system to the second operating system include: mapping the first interface of the first operating system required by the functional component to the second interface of the second operating system through the target function, so as to link the kernel-mode source code of the functional component and the second static library of the second operating system.

[0063] For example, a functional component depends on interface A in GPOS (such as the use of a USB flash drive, which requires the USB to register an interrupt to detect the USB flash drive. The interrupt depends on interface A, and interface A is used to register interrupt 1 for detection); since it needs to be migrated to RTOS, interface A does not actually exist in RTOS, and registration of interrupt 1 cannot be implemented; here, a target function is constructed to map interface A to interface B in RTOS (that is, the kernel-state source code of the USB functional component and the USB functional component in the second static library of RTOS are linked), and interface B is used to register interrupt 2 for detection, that is, the USB functional component on RTOS can rely on interface B to implement the corresponding USB flash drive detection function for subsequent use of the USB flash drive.

[0064] Here, the first interface may be an underlying functional interface that a functional component in the first operating system relies on;

[0065] The second interface may be an underlying functional interface on which a functional component in the second operating system depends.

[0066] Through the above import rules, the interface of the first operating system (such as GPOS) on which the functional components such as drivers depend is mapped to (or replaced with) the interface of the second operating system (such as RTOS).

[0067] Here, the imported functional components can be determined based on actual conditions. For example, functions that have been implemented by the second operating system, such as hardware drivers and driver frameworks, may not be imported. Figure 2 and Figure 3 For example, Figure 2 is a schematic diagram of the structure of a GPOS. Figure 3This is a structural diagram of an RTOS after functional components are expanded. It can be seen that functional components such as the hardware part of GPOS (including CPU, RAM, network manager, hard disk / flash memory, serial port, USB, PCIe, etc.), general scheduler, device virtual file system (DFS), and interrupt management system (including process management and memory management) are not imported.

[0068] The imported functional components may include, but are not limited to: network protocol stack, network device driver, file system, block device driver, character device layer, and other device layers.

[0069] Of course, in actual application, the functional components to be imported can be selected based on actual needs, and the above examples are not limited. For example, they can also include:

[0070] USB subsystem, including various USB device drivers, such as USB flash drives, keyboards and mice, USB audio or video devices, USB network cards, etc.

[0071] PCIe bus and PCIe devices, including NVMe hard disks, network cards on the PCIe bus, etc.

[0072] ACHI (Advanced Host Controller Interface) bus and SATA (Serial ATA) devices to support SATA hard drives;

[0073] SD (Secure Digital) bus and its devices, such as SD memory cards, eMMC (Embedded MultiMediaCard) and SDIO (Secure Digital InputOutput) Wifi or Bluetooth cards;

[0074] Implementation of network equipment and network protocols, such as FTP (File Transfer Protocol), HTTP (HyperText Transfer Protocol), NFS (Network File System) and other complex network applications;

[0075] HDMI (High-Definition Multimedia Interface) driver and some desktop environment basic components;

[0076] etc.

[0077] Of course, other functional components that the first operating system has but the second operating system does not have may also be included.

[0078] In some embodiments, the first static library further includes: user-mode source code of at least one functional component;

[0079] The method further comprises:

[0080] Modify the system library path of the user-mode source code of the at least one functional component to link the user-mode source code of the at least one functional component with the system library of the second static library;

[0081] The system library is used to connect the user state and kernel state of the first operating system. The system library includes but is not limited to: C standard library and POSIX library.

[0082] Here, the first static library of the first operating system includes: user-mode source code of at least one functional component.

[0083] For example, if the first operating system is GPOS, the first static library may include: GPOS user-mode source code of at least one functional component.

[0084] Specifically, the kernel-mode source code and user-mode source code of the first operating system need to be mapped or imported respectively. Therefore, the import rules may also include: user-mode source code import rules from the first operating system to the second operating system, and user-mode interface namespace conversion rules from the first operating system to the second operating system.

[0085] The rules for importing user-mode source code from the first operating system to the second operating system include: importing the user-mode source code of the first operating system into the source code of the second operating system. Since the user-mode source code of the first operating system is not necessarily in its kernel code tree, the import location is imported according to the directory structure, the directory under the specified second operating system is imported, and only the required user-mode source code of the first operating system is imported. For example, network configuration applications, PCIe configuration space detection applications, etc.

[0086] The user-mode interface namespace conversion rules from the first operating system to the second operating system include: modifying the system library path of the user-mode source code of at least one functional component (such as replacing the system library in GPOS with the RTOS system library path) to link the user-mode source code of at least one functional component with the system library of the second static library.

[0087] Here, the first operating system is GPOS and the second operating system is RTOS. Considering that the GPOS user-mode source code generally relies on virtual device files to access hardware and relies on system calls and C standard libraries to access GPOS kernel-mode functions.

[0088] Combination Figure 2 and Figure 3 As shown, after GPOS is migrated to RTOS, RTOS has no system call part, and GPOS user-mode source code is considered to rely only on system libraries (such as C standard library and POSIX library). The specific driver access is accessed through the virtual device file system. Here, in order to realize the call of GPOS user mode, after compiling the original kernel-mode source code of RTOS into RTOS static library, modify the system library path of the user-mode source code of at least one functional component of GPOS, and link the system library in the compiled LibGPOS static library (that is, the C standard library static library and POSIX library static library in LibGPOS) with the system library in the RTOS static library (that is, the C standard library static library and POSIX static library of RTOS), so as to realize the interaction between the user mode and kernel mode of the migrated GPOS through the system library.

[0089] Here, the POSIX library is a superset of the C standard library. On the basis of the C standard library, more devices of the RTOS are mapped so that applications from GPOS can be more conveniently integrated into the RTOS.

[0090] For example, the POSIX standard defines a socket interface for network communication. By mapping the network device (such as a network card) in the RTOS to the socket interface, the resulting target operating system can use the network card through the socket interface.

[0091] For another example, POSIX threads (pthreads) are a set of standard multithreaded interfaces. By mapping the pthread interface to the RTOS scheduler, the resulting target operating system can create and manage RTOS tasks through pthreads.

[0092] Since RTOS provides standardized interfaces in the POSIX library through mapping, applications from GPOS can be more easily ported and integrated into RTOS. After the application in GPOS user mode is migrated to RTOS, it can still use the familiar interfaces in the POSIX library to access specific functions and devices of RTOS without large-scale modification or adaptation of the application.

[0093] In the embodiments of the present disclosure, taking into account that certain features of the first operating system may conflict with the design goals and constraints of the second operating system and may not be suitable for use in the second operating system, that is, there may be a problem that certain features of the first operating system and the second operating system may not be compatible, the above-mentioned import rules and script tools are proposed to import the user-mode source code and the kernel-mode source code respectively, so as to import the first operating system into the second operating system and then obtain the target operating system.

[0094] In some embodiments, the method further comprises:

[0095] According to the first rule, the kernel state source code of the functional component is detected to determine the first code;

[0096] Modifying the first code to obtain a second code, where the second code complies with an operating specification of the second operating system;

[0097] According to the second code, obtaining the modified kernel state source code of the functional component;

[0098] The first rule is used to indicate:

[0099] Modifying a first code that complies with the operating specification of a first operating system into a second code that complies with the operating specification of a second operating system; and / or,

[0100] The second code that complies with the operating specification of the second operating system is modified into the first code that complies with the operating specification of the first operating system.

[0101] Specifically, the first rule can be implemented by the second script tool to achieve automatic processing. The first rule and the second script tool are designed in advance according to the requirements, the first operating system, the second operating system, etc., and they can achieve the above work, and the specific script code is not limited.

[0102] Here, the first operating system is GPOS and the second operating system is RTOS. The GPOS source code file can be converted into a static library (referred to as LibGPOS) through the second script tool. Considering that some GPOS source codes are not suitable for direct use in RTOS and need to be modified, the second script tool is used to automatically match and modify the source codes that need to be modified, or the source codes are manually modified in the subsequent continuous integration to be modified into codes that meet the operating specifications of the corresponding operating system.

[0103] It should be noted that the above code modification must be reversible, and the modification position can be controlled by a specific compilation macro definition to ensure that the modified GPOS source code can be returned to GPOS for operation.

[0104] In some embodiments, obtaining the target function includes:

[0105] Determining a kernel thread of the functional component according to the kernel state source code of the functional component;

[0106] The target function of the functional component is constructed according to the kernel thread of the functional component and the interface of the second operating system.

[0107] Here, target function also can be called pile function.In order to successfully call the interface of the second operating system, the first interface of the required first operating system of functional component is mapped to the second interface of the second operating system, build the target function of the kernel state interface of the corresponding first operating system, realize interface mapping.

[0108] The target function may be one or more, and "multiple" means two or more. Each target function may be used for mapping a first interface to a second interface. Through multiple target functions, mapping of multiple first interfaces to multiple second interfaces may be realized.

[0109] In one example, the first interface of the first operating system required by each functional component can be determined based on the kernel thread of each functional component, and then the second interface of the second operating system that can be mapped can be determined based on specific rules. The specific rules can be used to indicate the mapping relationship between each first interface in at least one first interface and different second interfaces. Of course, after the target function is pre-built, the corresponding target function can be directly called through specific rules to achieve mapping.

[0110] In another example, take the first operating system as GPOS, the second operating system as RTOS as example and illustrate.Can create the pile function of GPOS kernel state interface, this pile function is used to realize RTOS kernel state interface.For example, there is a certain functional component to create kernel thread in GPOS, the first script tool can create a source file (i.e. a pile function), the interface mapping required for above-mentioned functional component is given to a certain interface in RTOS and realized, and through the kernel state interface namespace conversion of GPOS, the kernel state source code of the functional component of the GPOS of importing is disclosed to this interface and realized.

[0111] In some embodiments, compiling the source code file to obtain a first static library of the first operating system includes:

[0112] Functionally grouping the source code files to obtain source code corresponding to at least one candidate functional component;

[0113] Screening source code corresponding to the at least one candidate functional component to determine the source code of the at least one functional component;

[0114] A first static library of the first operating system is compiled according to the source code of the at least one functional component.

[0115] Here, the first operating system is GPOS and the second operating system is RTOS. The source files of GPOS can be grouped, and RTOS selects a part of the source files for compilation as needed to obtain the first static library (recorded as libgpos.a). The source files can be grouped according to: base (basic components that all LibGPOS files depend on), network (components that all network-related files depend on), xxx_driver (drivers adapted for specific networks), etc.

[0116] In this way, the files of the required functional components can be conveniently tailored according to the requirements of the second operating system, avoiding the image expansion problem caused by the full compilation of the first operating system.

[0117] In some embodiments, the method further comprises:

[0118] Acquire an updated first operating system, wherein the updated first operating system includes: source code of a newly added functional component;

[0119] According to the source code of the newly added functional component, updating the first static library;

[0120] Obtaining the objective function corresponding to the newly added functional component;

[0121] A target operating system is obtained according to the updated first static library, the target function, the target function corresponding to the newly added functional component and the second operating system.

[0122] In one example, after obtaining the updated first operating system, the new hardware can be quickly adapted through the above-mentioned update operation, thereby achieving convenient update synchronization between the first operating system and the second operating system. The second operating system can quickly adapt to the support for new hardware features on the first operating system, further reducing the difficulty of subsequent maintenance and updating of the driver code on the second operating system.

[0123] In another example, the first operating system is GPOS and the second operating system is RTOS. After the first static library, LibGPOS, is verified, LibGPOS can be returned to GPOS through the export source code rules from RTOS to GPOS, and then GPOS can be built; if the GPOS version is updated, the new version can be synchronized through the code branch management tool, merged with the version returned from LibGPOS, and then the above import operation can be performed to merge the new features into RTOS, and since the previous changes still exist, the workload of each update will not be much.

[0124] In some embodiments, the method further comprises:

[0125] Running the image file of the target operating system;

[0126] The at least one functional component is called to obtain the operation result of each functional component, wherein the operation result indicates whether the functional component is successfully operated.

[0127] Here, a verification method is provided, that is, pre-running the image file of the target operating system, and calling each functional component to obtain the running result of each functional component to determine whether each functional component runs successfully. If it is successfully characterized that the above-mentioned target operating system can run, if a functional component cannot run, targeted modifications can be made, such as re-importing the source code of the corresponding functional component, checking the imported source code, etc., which are not limited here.

[0128] Through the method provided by the embodiment of the present disclosure, on the one hand, the driver framework of the first operating system (such as GPOS) is reused, and the driver framework that has been mature and widely tested on the first operating system can be utilized, including those complex drivers that are usually difficult to directly port to the second operating system (such as RTOS), such as USB and PCIe, etc., thereby avoiding the huge waste of resources and project risks caused by re-developing these complex drivers in the second operating system.

[0129] On the other hand, real-time performance is maintained, that is, a driver framework is added on the basis of the second operating system, and the task management and interrupt handling mechanism of the second operating system are not affected, ensuring the predictability of system response time and behavior. Compared with real-time optimization of the first operating system, running the first operating system after real-time optimization (such as RT-Linux), the target operating system has better real-time performance, which can greatly improve the system response performance and real-time guarantee.

[0130] The present disclosure also provides a verification method, such as Figure 4 As shown in the figure, the embedded hardware platform has DDR, Flash, NVMe, and SoC. Among them, SoC (System on a Chip) is the system on chip; DDR (Double Data Rate) is the running memory. NVMe is a solid-state drive that stores the kernel-mode and user-mode executable files of GPOS (respectively denoted as GPOS_Kernel.img and GPOS_App.img), as well as the executable file of RTOS (denoted as RTOS.img). Flash is a storage medium that stores the boot firmware of the hardware platform (denoted as Bootloader.img).

[0131] Start the embedded system, including:

[0132] 1) Complete the basic hardware configuration and the initialization of necessary hardware drivers such as Flash, DDR, NVMe, and load Bootloader.img;

[0133] 2) According to user operation, the operating system (OS) image is started. After the Bootloader.img is started, the user can choose to start GPOS or RTOS (that is, select GPOS_Kernel.img, GPOS_App.img, or select RTOS.img). After starting the OS, high-speed hardware peripherals such as USB, PCIe, ETH, and low-speed hardware peripherals such as I2C, SPI, and SDIO are initialized.

[0134] In actual application, users can implement startup operations and specific startup configurations through methods such as automatic startup scripts. The verification environment mainly relies on running RTOS and GPOS separately to provide a basis for function import.

[0135] like Figure 5 As shown, the application embodiment of the present disclosure provides a method for running a general purpose operating system (GPOS) driver on a real-time operating system (RTOS), the method comprising:

[0136] Step 501: Obtain GPOS source code and GPOS source code import rules;

[0137] Here, GPOS source code includes but is not limited to: drivers that need to be integrated into RTOS. Here, GPOS source code allows porting to RTOS, such as USB, PCIe and other drivers that are compatible with the target hardware.

[0138] Here, the import rules can be implemented through an import script tool (such as the first script tool mentioned above), and the import process can be automatically implemented. The import between different RTOS and GPOS can have different import rules and be implemented through different import tool scripts.

[0139] Step 502, compile the GPOS source code into a static library;

[0140] Here, compile the GPOS source code into a static library (referred to as LibGPOS), which may include:

[0141] Use the compilation script tool (referred to as libgpos.make) to group the GPOS source code, and select some of the source files according to RTOS requirements to compile them into a static library (referred to as libgpos.a).

[0142] The source code files can be grouped in the following ways: base (basic components that all LibGPOS files depend on), network (components that all network-related files depend on), xxx_driver (drivers adapted for specific networks), etc. In this way, RTOS can easily cut the required source files, avoiding the image expansion problem caused by full compilation of GPOS.

[0143] Step 503: Import the static library into the RTOS using the import rules to obtain the target operating system;

[0144] Here, the static library is imported into the RTOS using import rules, including:

[0145] The stub function is generated by using the import script tool, and the mapping of the kernel state interface of the functional component is realized through the stub function.

[0146] Specifically, when linking LibGPOS to RTOS, the kernel-mode interface of the original GPOS can be replaced with the kernel-mode interface of the RTOS. In addition, the imported GPOS source code can be modified and adapted as necessary to map the interface of GPOS to the RTOS, which is equivalent to realizing the RTOS reference image.

[0147] Here, the static library is imported into the RTOS using the import rules, which also include:

[0148] Compile the original kernel code of RTOS into RTOS static library, and link the compiled C standard library static library and POSIX library static library in LibGPOS with the C standard library static library and POSIX library static library in RTOS static library.

[0149] If the pile function of the kernel state interface on RTOS has all been realized, and the static library link in the user state has also been completed, the image file of the target operating system can be generated.Here, by the pile function of the interface in the kernel state on RTOS, the interface of the GPOS that each functional component in the kernel state depends on is replaced with the interface of RTOS, namely realizes the migration of the kernel state of GPOS.By the static library link in the user state, realize the user state of the GPOS migrated and the interaction of the kernel state.

[0150] In some embodiments, the method may further include:

[0151] Step 504: Verify whether the function provided by LibGPOS is successful.

[0152] Here, LibGPOS and RTOS are linked together into the RTOS application image, and the virtual device file system on the RTOS provides driver support for the upper-layer application. Test verification is performed in the current hardware environment. This process may require continuous integration (CI) and continuous deployment (CD) to continuously verify the imported driver functions. The above verification process can be controlled by conditional compilation rules, that is, gradually expanding the number of drivers compiled into LibGPOS, and verifying and integrating step by step.

[0153] In some embodiments, the method may further include:

[0154] Step 505: Export the LibGPOS code and return it to the GPOS source code. If a GPOS update is received, the above steps 502 and 503 can be repeated to integrate the newly added driver functions.

[0155] Specifically, since the driver function integration is incremental, the previously integrated functions can continue to be used. The key to compatible operation of GPOS driver on RTOS is to find the corresponding implementation on RTOS for each functional component on GPOS, implement functional component mapping by formulating import rules, and also cut out the functional components that are not needed after compatible operation, optimize the task scheduling and memory management components (performance optimization) according to the real-time requirements of RTOS, and continuously test and verify the integrated functions.

[0156] In actual application, in order to run the driver framework on GPOS, RTOS itself needs to provide a series of support, including:

[0157] 1) RTOS multi-tasking environment to ensure that the RTOS task management and synchronization mechanisms are robust enough to support concurrent execution of GPOS kernel-state code;

[0158] Here, the multi-tasking execution environment includes: using a single address space (compared to GPOS, RTOS generally cuts out virtual memory support and directly uses physical memory), running a real-time scheduler (replacing the non-preemptive non-real-time scheduler used on GPOS), being able to respond to and handle hardware interrupt events (cutting out non-real-time links such as soft interrupts), preparing a debugging serial port, and completing the power-on startup of the RTOS by starting the assembly file.

[0159] Optimize interrupt handlers and dynamic memory management to meet the performance requirements of the GPOS driver.

[0160] 2) RTOS virtual device file system so that the GPOS driver can seamlessly access hardware resources;

[0161] Here, a virtual device file system is used to reserve mechanical hard disks, solid-state drives, SD cards, and Flash as block devices, network cards as network devices, serial ports, SPI, I2C, etc. as character devices, and USB, PCIe, etc. as bus devices. Bus devices can mount other devices. In the early stage, RTOS did not support the above devices, waiting for the GPOS driver framework to support them.

[0162] 3) POSIX library of RTOS, the above virtual device file system is a virtual file system compatible with the POSIX library.

[0163] Here, the POSIX library is a superset of the C standard library. On the basis of the C standard library, more RTOS devices are mapped, such as the socket interface and network device mapping, the pthread interface and the RTOS scheduler mapping. In this way, the network card can be used through the socket, and the RTOS tasks can be created and managed through pthread. Subsequent applications from GPOS can be more conveniently integrated into the RTOS.

[0164] By providing a complete set of POSIX libraries, the compatibility and portability of GPOS user-mode code is ensured.

[0165] 4) RTOS kernel interface mapping;

[0166] Here, only the user-mode code in GPOS will rely on the support of the C standard library and POSIX library. The GPOS kernel-mode code only relies on the kernel-mode interface of GPOS. By implementing the kernel-mode interface of GPOS with the kernel-mode interface of RTOS, it can be compatible with running on RTOS without modifying the GPOS import code as much as possible.

[0167] In addition, considering the differences in kernel-mode interfaces, an adaptation layer or middleware is provided for differences in memory management, task control, and synchronization primitives to reduce the amount of modification to the GPOS code.

[0168] 5) RTOS C standard library;

[0169] Here, the C standard library is used to map some devices that can be controlled by the C standard library, such as binding the control state I / O function printf of the C standard library to the serial port character device, and then the serial port output can be controlled by printf; in addition, applications on GPOS usually access GPOS kernel functions through system calls, for example, a specific command word is controlled under the ioctrl system call under the USB device / dev / usb0. There is no distinction between user state and kernel state in RTOS. The standard system call of GPOS can be encapsulated in the C standard library support and then mapped to the system call interface. In this way, subsequent applications from GPOS can be more conveniently integrated into RTOS.

[0170] C standard library You can choose or develop a C standard library implementation that is compatible with the RTOS to ensure that function calls in the GPOS user-mode code can work properly.

[0171] 6) Device tree parser for RTOS so that RTOS can understand and configure the hardware description used in GPOS;

[0172] Here, currently GPOS uses device tree to describe hardware device information. During the initialization process, the device tree information is parsed to determine which driver to call to complete the device enablement and subsequent work. RTOS generally does not support device tree. Therefore, RTOS can support device tree parser in advance so that the imported driver and driver initialization process on GPOS can be modified as little as possible in the future. After adding the device tree parser, a process of identifying and initializing devices can be added to the RTOS startup initialization process. The usual practice is to register the device initialization function entry in an array and add device information to automatically call a certain device initialization function.

[0173] Figure 6 A schematic diagram of the structure of a processing device provided in an embodiment of the present disclosure; Figure 6 As shown, the processing device comprises:

[0174] An acquisition module, used to acquire a source code file of the first operating system;

[0175] A first processing module is used to compile the source code file to obtain a first static library of the first operating system, wherein the first static library includes a kernel state source code of at least one functional component;

[0176] A second processing module, used for obtaining a target function, where the target function is used for mapping a first interface of the first operating system required by the functional component to a second interface of the second operating system;

[0177] The third processing module is used to obtain a target operating system according to the first static library, the target function and the second operating system.

[0178] In some embodiments, the third processing module is used to import the first static library and the target function into the second operating system to obtain a target operating system.

[0179] In some embodiments, the third processing module is used to compile the source code of the second operating system to obtain a second static library of the second operating system;

[0180] According to the target function, the kernel-mode source code of the at least one functional component and the second static library are linked.

[0181] In some embodiments, the first static library further includes: user-mode source code of at least one functional component;

[0182] The third processing module is further used to modify the system library path of the user-mode source code of the at least one functional component to link the user-mode source code of the at least one functional component with the system library of the second static library;

[0183] The system library is used to connect the user state and kernel state of the first operating system.

[0184] In some embodiments, the third processing module is further used to detect the kernel state source code of the functional component according to the first rule to determine the first code;

[0185] Modifying the first code to obtain a second code, where the second code complies with an operating specification of the second operating system;

[0186] According to the second code, obtaining the modified kernel state source code of the functional component;

[0187] The first rule is used to indicate:

[0188] Modifying a first code that complies with the operating specification of a first operating system into a second code that complies with the operating specification of a second operating system; and / or,

[0189] The second code that complies with the operating specification of the second operating system is modified into the first code that complies with the operating specification of the first operating system.

[0190] In some embodiments, the second processing module is further used to determine the kernel thread of the functional component according to the kernel state source code of the functional component;

[0191] The target function of the functional component is constructed according to the kernel thread of the functional component and the interface of the second operating system.

[0192] In some embodiments, the first processing module is used to functionally group the source code files to obtain source code corresponding to at least one candidate functional component;

[0193] Screening source code corresponding to the at least one candidate functional component to determine the source code of the at least one functional component;

[0194] A first static library of the first operating system is compiled according to the source code of the at least one functional component.

[0195] In some embodiments, the acquisition module is further used to acquire an updated first operating system, wherein the updated first operating system includes: source code of a newly added functional component;

[0196] The first processing module is further used to update the first static library according to the source code of the newly added functional component;

[0197] The second processing module is further used to obtain the objective function corresponding to the newly added functional component;

[0198] The third processing module is further used to obtain a target operating system according to the updated first static library, the target function, the target function corresponding to the newly added functional component, and the second operating system.

[0199] In some embodiments, the apparatus further comprises: a fourth processing module, configured to run the image file of the target operating system;

[0200] The at least one functional component is called to obtain the operation result of each functional component, wherein the operation result indicates whether the functional component is successfully operated.

[0201] In some embodiments, the real-time performance of the second operating system is higher than the real-time performance of the first operating system.

[0202] It should be noted that: the processing device provided in the above embodiment only uses the division of the above program modules as an example to illustrate when implementing the corresponding processing method. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the processing device is divided into different program modules to complete all or part of the processing described above. In addition, the device provided in the above embodiment and the embodiment of the corresponding method belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0203] Figure 7 A schematic diagram of the structure of an electronic device provided by an embodiment of the present disclosure is shown in FIG. Figure 7As shown, the communication device 70 includes: a processor 701 and a memory 702 for storing a computer program that can be run on the processor; the processor 701 is used to execute the processing method when running the computer program.

[0204] In actual application, the communication device 70 may further include: at least one network interface 703. The various components in the communication device 70 are coupled together via a bus system 704. It is understood that the bus system 704 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 704 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, Figure 7 In the figure, various buses are marked as bus system 704. There may be at least one processor 701. The network interface 703 is used for wired or wireless communication between the communication device 70 and other devices.

[0205] The memory 702 in the embodiment of the present disclosure is used to store various types of data to support the operation of the communication device 70 .

[0206] The method disclosed in the above-mentioned embodiment of the present disclosure can be applied to the processor 701, or implemented by the processor 701. The processor 701 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above-mentioned method can be completed by the hardware integrated logic circuit in the processor 701 or the instruction in the form of software. The above-mentioned processor 701 can be a general-purpose processor, a digital signal processor (DSP, DiGital Signal Processor), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The processor 701 can implement or execute the disclosed methods, steps and logic block diagrams in the embodiment of the present disclosure. The general-purpose processor can be a microprocessor or any conventional processor, etc. The steps of the method disclosed in the embodiment of the present disclosure can be directly embodied as a hardware decoding processor to execute, or the hardware and software modules in the decoding processor can be combined to execute. The software module can be located in a storage medium, which is located in the memory 702. The processor 701 reads the information in the memory 702 and completes the steps of the above-mentioned method in combination with its hardware.

[0207] In an exemplary embodiment, the communication device 70 may be implemented by one or more application specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to execute the aforementioned method.

[0208] The embodiment of the present disclosure further provides a computer-readable storage medium on which a computer program is stored; when the computer program is executed by a processor, the processing method is executed.

[0209] In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method can be implemented in other ways. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored, or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0210] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0211] In addition, all functional units in the embodiments of the present disclosure may be integrated into one processing unit, or each unit may be separately configured as a unit, or two or more units may be integrated into one unit; the above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0212] A person of ordinary skill in the art can understand that: all or part of the steps of implementing the above method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above method embodiment; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), disks or optical disks, etc. Various media that can store program codes.

[0213] Alternatively, if the above-mentioned integrated unit of the present disclosure is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present disclosure can essentially or in other words, the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in each embodiment of the present disclosure. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROM, RAM, magnetic disks or optical disks.

[0214] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps recorded in this disclosure can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solutions disclosed in this disclosure can be achieved, and this document does not limit this.

[0215] In the above description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it can be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0216] Unless otherwise defined, all technical and scientific terms used in this disclosure have the same meaning as those commonly understood by those skilled in the art to which this disclosure belongs. The terms used in this disclosure are only for the purpose of describing the embodiments of this disclosure and are not intended to limit this disclosure.

[0217] It should be understood that in the various embodiments of the present disclosure, the size of the serial number of each implementation process does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present disclosure.

[0218] In the above description, the terms "first\second" involved are only used to distinguish similar objects and do not represent a specific ordering of objects. The terms "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. It is understandable that "first\second" can be interchanged in a specific order or sequence where permitted, so that the embodiments of the present disclosure described here can be implemented in an order other than that illustrated or described here. In the description of the present disclosure, the meaning of "multiple" is two or more, unless otherwise clearly and specifically defined.

[0219] The above is only a specific embodiment of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any person skilled in the art who is familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present disclosure, which should be included in the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be based on the protection scope of the claims.

Claims

1. A processing method, characterized in that: The method comprises: Obtaining a source code file of a first operating system; Compile the source code file to obtain a first static library of the first operating system, wherein the first static library includes kernel-state source code of at least one functional component; Obtaining a target function, where the target function is used to map a first interface of the first operating system required by the functional component to a second interface of the second operating system; A target operating system is obtained according to the first static library, the target function and the second operating system.

2. The method according to claim 1, characterized in that: Obtaining a target operating system according to the first static library, the target function and the second operating system, including: Import the first static library and the target function into the second operating system to obtain a target operating system.

3. The method according to claim 2, characterized in that The step of importing the first static library and the target function into the second operating system includes: Compiling the source code of the second operating system to obtain a second static library of the second operating system; According to the target function, the kernel-mode source code of the at least one functional component and the second static library are linked.

4. The method according to any one of claims 1 to 3, characterized in that: The first static library also includes: user-mode source code of at least one functional component; The method further comprises: Modify the system library path of the user-mode source code of the at least one functional component to link the user-mode source code of the at least one functional component with the system library of the second static library; The system library is used to connect the user state and kernel state of the first operating system.

5. The method according to claim 1 or 2, characterized in that: The method further comprises: According to the first rule, the kernel state source code of the functional component is detected to determine the first code; Modifying the first code to obtain a second code, where the second code complies with an operating specification of the second operating system; According to the second code, obtaining the modified kernel state source code of the functional component; The first rule is used to indicate: Modifying a first code that complies with the operating specification of a first operating system into a second code that complies with the operating specification of a second operating system; and / or, The second code that complies with the operating specification of the second operating system is modified into the first code that complies with the operating specification of the first operating system.

6. The method according to claim 1, characterized in that The obtaining of the objective function comprises: Determining a kernel thread of the functional component according to the kernel state source code of the functional component; The target function of the functional component is constructed according to the kernel thread of the functional component and the interface of the second operating system.

7. The method according to claim 1, characterized in that The compiling the source code file to obtain a first static library of the first operating system includes: Functionally grouping the source code files to obtain source code corresponding to at least one candidate functional component; Screening source code corresponding to the at least one candidate functional component to determine the source code of the at least one functional component; A first static library of the first operating system is compiled according to the source code of the at least one functional component.

8. The method according to claim 1, characterized in that The method further comprises: Acquire an updated first operating system, wherein the updated first operating system includes: source code of a newly added functional component; According to the source code of the newly added functional component, updating the first static library; Obtaining the objective function corresponding to the newly added functional component; A target operating system is obtained according to the updated first static library, the target function, the target function corresponding to the newly added functional component and the second operating system.

9. The method according to claim 1, characterized in that: The method further comprises: Running the image file of the target operating system; The at least one functional component is called to obtain the operation result of each functional component, wherein the operation result indicates whether the functional component is successfully operated.

10. The method according to claim 1, characterized in that The real-time performance of the second operating system is higher than that of the first operating system.

11. A processing device, characterized in that: The device comprises: An acquisition module, used to acquire a source code file of the first operating system; A first processing module is used to compile the source code file to obtain a first static library of the first operating system, wherein the first static library includes a kernel state source code of at least one functional component; A second processing module, used for obtaining a target function, where the target function is used for mapping a first interface of the first operating system required by the functional component to a second interface of the second operating system; The third processing module is used to obtain a target operating system according to the first static library, the target function and the second operating system.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps of the method according to any one of claims 1 to 10 are implemented.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.

Images