WO2022042252A1 - 驱动配置管理方法、装置、介质、设备及系统 - Google Patents

驱动配置管理方法、装置、介质、设备及系统 Download PDF

Info

Publication number
WO2022042252A1
WO2022042252A1 PCT/CN2021/110860 CN2021110860W WO2022042252A1 WO 2022042252 A1 WO2022042252 A1 WO 2022042252A1 CN 2021110860 W CN2021110860 W CN 2021110860W WO 2022042252 A1 WO2022042252 A1 WO 2022042252A1
Authority
WO
WIPO (PCT)
Prior art keywords
configuration
electronic device
target
file
configuration file
Prior art date
Application number
PCT/CN2021/110860
Other languages
English (en)
French (fr)
Inventor
袁博
陈风
谭延营
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN202110112587.5A external-priority patent/CN114116022A/zh
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP21860092.2A priority Critical patent/EP4198720A4/en
Publication of WO2022042252A1 publication Critical patent/WO2022042252A1/zh
Priority to US18/175,113 priority patent/US20230214231A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/44—Encoding
    • G06F8/443—Optimisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/44—Encoding
    • G06F8/447—Target code generation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/51—Source to source
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/42—Syntactic analysis

Definitions

  • the present application relates to the field of communication technologies, and in particular, to a drive configuration management method, apparatus, medium, device, and system.
  • IoT Internet of Things
  • drivers referred to as drivers or drivers
  • the hardware platforms used by IoT devices often have very limited hardware resources, such as read-only memory (ROM), random access memory (RAM), central processing
  • ROM read-only memory
  • RAM random access memory
  • CPU Central Processing Unit
  • the hardware-related configuration code in the driver of the current IoT device is generally written directly in the driver implementation code in the form of macros or constants. If you want to adapt to a new platform, you often need to copy the driver code and modify it. Configure the code, which causes the corruption of the code structure, reduces the maintainability and portability of the code, and increases the difficulty of code reuse. Therefore, the hardware-related configuration code and function code in the requirement-driven implementation code are decoupled, so that the driver can focus more on the business functions of the device, and the porting and configuration management are simpler.
  • Embodiments of the present application provide a drive configuration management method, apparatus, medium, and device, which can implement drive configuration management on the limited hardware resources of a lightweight platform, and implement configuration management while supporting both a lightweight platform and a full-weight platform .
  • an embodiment of the present application provides a drive configuration management method, which is applied to managing devices, including: determining target information, where the target information is used to represent the computing capability of the electronic device; A target configuration file in target file format; sends a target configuration file to an electronic device.
  • the target information may characterize whether the electronic device is a lightweight device or a full-weight device, such as characterizing the electronic device 100b or the electronic device 100a hereinafter.
  • the above-mentioned target information is information of the computing capability of the electronic device, or is a compilation parameter indicating the following target file format.
  • the object file format may be the C language format or the binary format described below.
  • the above target file format can be a file format that conforms to the computing capability of the electronic device, so that the performance of the lightweight device can be guaranteed in the process of driver configuration, and the high flexibility and complete hardware of the full-scale device can also be realized.
  • Topological description capability can be a file format that conforms to the computing capability of the electronic device, so that the performance of the lightweight device can be guaranteed in the process of driver configuration, and the high flexibility and complete hardware of the full-scale device can also be realized.
  • the target configuration file supports direct invocation of the driver implementation code of the electronic device.
  • the first type of computing capability represents the computing capability of the lightweight device, indicating that the current electronic device is a lightweight device
  • the selected compilation parameter is the compilation parameter corresponding to the lightweight device, that is, the determined target information corresponds to for lightweight devices.
  • the target configuration file in the target file format usually occupies a small storage space, which is convenient for the driver implementation code in the electronic device to directly call, and can ensure the performance of the electronic device (such as a lightweight device) and realize the driver configuration at the same time.
  • the target file format is implemented in at least one of the following languages: C language, C++ language, and Java language.
  • the format of the object file is the C language format hereinafter, that is, the adopted language is the C language.
  • the above-mentioned sending the target configuration file to the electronic device includes: outputting the target configuration file to a read-only storage area in the electronic device. In this way, the security of the target configuration file can be guaranteed and cannot be easily tampered with.
  • the method further includes: compiling a driver implementation of the electronic device based on the target configuration file Code; a file that outputs the driver implementation code to a readable and writable storage area in an electronic device.
  • the parameters or functions in the driver implementation code are made to correspond to the target configuration file, and the target configuration file can be directly called by the driver implementation code subsequently.
  • the target file format is a binary format.
  • the second type of computing capability represents the computing capability of a full-scale device, indicating that the current electronic device is a full-scale device, then the selected compilation parameters are the compilation parameters corresponding to the full-scale device, that is, the determined target information corresponds to Full-scale equipment.
  • the above-mentioned target configuration file is compiled and obtained by the management device according to predefined bytecode rules, and the target configuration file supports the electronic device to parse it according to the predefined bytecode rules, and then the target configuration file is parsed by the electronic device according to the predefined bytecode rules.
  • the code call is implemented through the driver. It is understandable that the bytecode preserves the configuration topology to the greatest extent, and can easily perform various traversal operations during parsing. Compared with the generated C language configuration file, the RAM and ROM overhead of electronic devices are also reduced. It will be slightly larger, and it is more suitable for environments that do not have extreme performance requirements, that is, it is suitable for full-scale equipment.
  • the computing capability of the above-mentioned electronic device includes at least one of the following: the clock frequency of the processor in the electronic device, the capacity of the random access memory RAM of the electronic master device, the Read-only memory ROM capacity.
  • the RAM and ROM of the electronic device may be the RAM and ROM of the processor in the electronic device.
  • the above-mentioned determining the target information includes: receiving a user's target operation on a target control, where the target control is used to trigger the selection of one piece of information from at least two pieces of information, the at least two pieces of information being the same as the At least two file formats are in one-to-one correspondence; in response to the target operation, the information selected by the target control is determined as the target information.
  • the target control can be the compilation parameter option 411 below, for example, the “binary configuration” selected by the compilation parameter option 411 corresponds to the secondary format (ie, a file format), and the “C language configuration” selected by the compilation parameter option 411 ” corresponds to the C language format (ie, a file format).
  • converting the configuration source file into a target configuration file in a target file format according to the target information includes: converting the configuration source file into multiple syntax unit sequences; verifying multiple Whether the syntax unit sequence conforms to the predefined syntax rules (for example, it is used to check whether there are syntax errors in multiple syntax unit sequences); if multiple syntax unit sequences conform to the predefined syntax rules, convert multiple syntax unit sequences to abstract Syntax tree; update the abstract syntax tree according to the first syntax rule, the first syntax rule includes at least redefinition check and reference expansion processing; according to the target information, convert the abstract syntax tree into a target configuration file in the target file format.
  • the above-mentioned predefined grammar, the first grammar rule, etc. may be predetermined by relevant technical personnel according to actual requirements, which are not specifically limited in the embodiment of the present application.
  • an embodiment of the present application provides a drive configuration management method, which is applied to an electronic device, including: acquiring a target configuration file in a target file format, wherein the target file format corresponds to the computing capability of the electronic device; based on the target configuration files, configures and drives hardware in electronic devices. Specifically, obtaining the target configuration file by the electronic device may be receiving the target configuration file from the management device.
  • the above-mentioned configuring and driving the hardware in the electronic device based on the target configuration file includes: when the computing capability is the first type of computing capability, calling the target configuration through the driver implementation code files to configure and drive hardware in electronic devices.
  • the target file format is implemented in at least one of the following languages: C language, C++ language, and Java language.
  • the target configuration file is stored in a read-only storage area in the electronic device.
  • the above method further includes: obtaining a driver implementation code of the electronic device, the driver implementation code is compiled based on the target configuration file, and the driver implementation code is stored in the electronic device. Write storage area.
  • the above-mentioned configuring and driving the hardware in the electronic device based on the target configuration file includes: when the target file format is binary format, according to the predefined bytecode rules The target configuration file is parsed into a configuration tree, and then the configuration tree is called by the driver implementation code of the electronic device to configure and drive the hardware in the electronic device.
  • the computing capability of the electronic device includes at least one of the following: a clock frequency of a processor in the electronic device, a capacity of a random access memory (RAM) of the electronic device, a read-only memory of the electronic device The capacity of the memory ROM.
  • an embodiment of the present application provides a drive configuration management apparatus, which can be applied to management equipment, including: a determination module for determining target information, where the target information is used to represent the computing capability of the electronic device; a conversion module for determining according to The target information determined by the module converts the configuration source file into the target configuration file in the target file format; the sending module is used for sending the conversion module to the electronic device to obtain the target configuration file for conversion.
  • the target configuration file supports direct invocation of the driver implementation code of the electronic device.
  • the object file format is implemented in at least one of the following languages: C language, C++ language, and Java language.
  • the sending module is specifically configured to output the target configuration file to a read-only storage area in the electronic device.
  • the above device for driving configuration management further includes: a compiling module, configured to convert the configuration source file into a target configuration file using the target file format according to the target information by the conversion module, based on the target
  • the configuration file compiles the driver implementation code of the electronic device; the above-mentioned sending module is also used to output the file of the driver implementation code to the readable and writable storage area in the electronic device.
  • the target file format is a binary format.
  • the target configuration file is compiled and obtained by the management device according to predefined bytecode rules, and the target configuration file supports the electronic device to parse it according to the predefined bytecode rules, and then the target configuration file is parsed by the electronic device according to the predefined bytecode rules.
  • the code call is implemented through the driver.
  • the computing capability of the electronic device includes at least one of the following: the clock frequency of the processor in the electronic device, the capacity of the random access memory RAM of the electronic master device, the Read-only memory ROM capacity.
  • the above-mentioned determining the target information includes: receiving a user's target operation on the target control, the target control being used to trigger the selection of one information from at least two pieces of information, the at least two pieces of information being the same as the At least two file formats are in one-to-one correspondence; in response to the target operation, the information selected by the target control is determined as the target information.
  • the above conversion module is specifically configured to convert the configuration source file into multiple syntax unit sequences; verify whether the multiple syntax unit sequences conform to predefined syntax rules; When the sequence conforms to the predefined grammar rules, convert multiple grammar unit sequences into abstract grammar trees; update the abstract grammar tree according to the first grammar rule, and the first grammar rule at least includes redefinition checking and reference expansion processing; according to the target information, Converts an abstract syntax tree to an object configuration file in object file format.
  • an embodiment of the present application provides a drive configuration management device, which can be applied to an electronic device, including: an acquisition module configured to acquire a target configuration file in a target file format, wherein the target file format is related to the calculation of the electronic device The capability corresponds; the configuration module is used to configure and drive the hardware in the electronic device based on the target configuration file obtained by the obtaining module.
  • the above-mentioned configuring and driving the hardware in the electronic device based on the target configuration file includes: when the computing capability is the first type of computing capability, calling the target configuration through the driver implementation code files to configure and drive hardware in electronic devices.
  • the target file format is implemented in at least one of the following languages: C language, C++ language, and Java language.
  • the above target configuration file is stored in a read-only storage area in the electronic device.
  • the above acquisition module is further configured to acquire the driver implementation code of the electronic device, the driver implementation code is compiled based on the target configuration file, and the driver implementation code is stored in the electronic device. readable and writable storage area.
  • the above configuration module is specifically used to parse the target configuration file into a configuration tree according to a predefined bytecode rule when the target file format is a binary format, and then pass The driver implementation code of the electronic device calls the configuration tree to configure and drive the hardware in the electronic device.
  • the computing capability of the electronic device includes at least one of the following: the clock frequency of the processor in the electronic device, the capacity of the random access memory (RAM) of the electronic device, The capacity of the read-only memory ROM of the electronic device.
  • an embodiment of the present application provides a computer-readable medium, where an instruction is stored on the computer-readable medium, and the instruction, when executed on an electronic device, causes the electronic device to perform the first aspect and any one of the above-mentioned first aspect.
  • an embodiment of the present application provides an electronic device, including: a memory for storing instructions, and a processor for executing the instructions to implement the first aspect and any possible implementation manners thereof
  • the drive configuration management method in this case, the electronic device in the sixth aspect is the management device described in this document
  • the drive configuration management method in the second aspect and any of its possible implementations in this case, in the sixth aspect
  • the electronic device is a demand-driven configuration electronic device managed by the management device).
  • FIG. 1 shows a schematic structural diagram of a drive configuration management system according to some embodiments of the present application
  • FIG. 2 shows a schematic structural diagram of a drive configuration management system according to some embodiments of the present application
  • Fig. 3 shows a code schematic diagram of a binary configuration file according to some embodiments of the present application
  • FIG. 4A shows a schematic diagram of a driver configuration interface according to some embodiments of the present application.
  • FIG. 4B shows a schematic diagram of a driver configuration interface according to some embodiments of the present application.
  • 4C shows a schematic diagram of a driver configuration interface according to some embodiments of the present application.
  • 4D shows a schematic diagram of a driver configuration interface according to some embodiments of the present application.
  • 4E shows a schematic diagram of a driver configuration interface according to some embodiments of the present application.
  • 4F shows a schematic diagram of a driver configuration interface according to some embodiments of the present application.
  • 4G shows a schematic diagram of a driver configuration interface according to some embodiments of the present application.
  • 4H shows a schematic diagram of a driver configuration interface according to some embodiments of the present application.
  • 4I shows a schematic diagram of a driver configuration interface according to some embodiments of the present application.
  • Fig. 5 shows a schematic diagram of a method for driving configuration management according to some embodiments of the present application
  • FIG. 6 shows a schematic structural diagram of a drive configuration management system according to some embodiments of the present application.
  • Fig. 7 shows a schematic diagram of a method for driving configuration management according to some embodiments of the present application.
  • FIG. 8 is a schematic diagram illustrating a method for driving configuration management according to some embodiments of the present application.
  • FIG. 9 shows a schematic structural diagram of a drive configuration management system according to some embodiments of the present application.
  • FIG. 10 is a schematic diagram illustrating a method for driving configuration management according to some embodiments of the present application.
  • FIG. 11 is a schematic diagram illustrating a method for driving configuration management according to some embodiments of the present application.
  • FIG. 12 is a schematic diagram illustrating a method for driving configuration management according to some embodiments of the present application.
  • Fig. 13 shows a schematic diagram of a device for driving configuration management according to some embodiments of the present application
  • Fig. 14 shows a schematic diagram of a device for driving configuration management according to some embodiments of the present application
  • Fig. 15 shows a schematic structural diagram of an electronic device according to some embodiments of the present application.
  • FIG. 16 shows a block diagram of a software structure of an electronic device according to some embodiments of the present application.
  • Illustrative embodiments of the present application include, but are not limited to, a drive configuration management method, apparatus, medium, and device.
  • the driving configuration management method provided by the embodiment of the present application is applied in the scenario of performing driving configuration management on an electronic device.
  • the electronic device can configure the hardware by invoking the driver program through the operating system, and drive the hardware to work, for example, configure and drive the hardware such as a graphics card, a sound card, a scanner, a camera, and a modem (Modem) to work.
  • an electronic device generally needs to obtain a configuration file, and use the configuration file to configure related hardware through a driver, so as to drive the hardware to work.
  • the electronic device involved in the embodiments of the present application may include a lightweight device or a full-weight device, but is not limited thereto.
  • the above-mentioned operating system may include, but is not limited to, a Linux system, an Android (Android) system, and the like.
  • the lightweight device provided by the embodiment of the present application generally adopts a microprocessor with ultra-low power consumption, long standby time, and low cost (such as an ARM Cortex-M series microprocessor).
  • This type of processor generally has a lower clock frequency, a smaller random access memory (Random Access Memory, RAM), and a smaller capacity read-only memory (Read Only Memory, ROM).
  • RAM Random Access Memory
  • ROM Read Only Memory
  • the capacities of RAM and ROM are generally in the K to M level, and hereinafter, a lightweight platform is used to refer to such a processor platform.
  • the lightweight devices involved in the embodiments of the present application include, but are not limited to, the above-mentioned IoT devices, wristbands, and other devices.
  • the above-mentioned lightweight environment refers to an environment or system including one or more lightweight devices and a management device that interacts with the lightweight devices, for example, the management device is used to distribute and configure hardware to these lightweight devices related configuration files.
  • the full-scale device (or the heavy-duty device) provided by the embodiments of the present application generally has a battery with a large capacity, does not require ultra-low power consumption, and needs to have high performance to ensure user experience.
  • full-scale devices generally use higher-performance microprocessors (such as ARM Cortex-A series microprocessors), which generally have larger-capacity RAM and ROM (generally above the G level).
  • the full-scale devices involved in the embodiments of the present application include but are not limited to the above-mentioned mobile phones or tablet computers.
  • the above-mentioned lightweight environment refers to an environment or system including one or more full-scale devices and a management device that interacts with the full-scale devices. Configure the relevant configuration files.
  • the lightweight device and the full-weight device of the present application can be measured by the computing power of the electronic device.
  • the computing capability of the electronic device includes at least one of the following: the clock frequency of the processor in the electronic device, the capacity of the RAM of the processor, and the capacity of the ROM of the processor. It can be understood that the higher the clock frequency of the processor, the larger the capacity of the RAM of the electronic device, and the larger the capacity of the ROM of the electronic device, the stronger the computing power of the electronic device, which corresponds to the above-mentioned full-scale device.
  • the computing power of an electronic device can also be characterized by the model number of the processor in the electronic device, for example, the lightweight device is characterized by the model number of the ARM Cortex-M series microprocessor, and the model number of the ARM Cortex-A series microprocessor can be characterized. Characterize full-scale devices.
  • the processor and the memory (RAM or ROM) in the above electronic device are implemented by independent modules, respectively.
  • the above-mentioned RAM and ROM that measure the computing power of the electronic device may be referred to as the RAM of the electronic device. and ROM.
  • the above electronic device is implemented by an integrated module
  • the processor and memory (RAM or ROM) in the electronic device are integrated into a chip or system by using an integrated module, then the above electronic device is The RAM and ROM in the device can also be considered the RAM and ROM of that processor.
  • the management device 200 suitable for this application may be a server, a desktop computer, a notebook computer, and the like. It can be understood that, in some embodiments, the server may be a hardware server, or may be embedded in a virtualized environment. For example, according to some embodiments of the present application, a server may be a virtual machine executing on a hardware server including one or more other virtual machines, ie a cloud server.
  • the electronic device 100a and the electronic device 100b may communicate with the management device 200 through various wired connection methods, or wirelessly communicate through various wireless methods.
  • DTS Device Tree Source
  • DTB binary format device tree binary data
  • BootLoader passes the starting position of the DTB file to the kernel as a parameter, and each module of the kernel can read the configuration content in the DTB file through parsing.
  • the DTB file and the code for parsing the DTB file need to occupy a lot of ROM and/or RAM overhead in the electronic device, which may not be able to carry it for lightweight devices such as IoT devices, so that DTS may not be used for lightweight devices. Drive configuration management.
  • the driver configuration management of the electronic device can be realized through the Advanced Configuration and Power Interface (Advanced Configuration and Power Interface, ACPI).
  • ACPI is a configuration management framework, which is widely used in the X86 system.
  • ACPI uses ACPI source language (ACPI Source Language, ASL) to describe hardware resources and control methods, and compiles ASL files into binary files of ACPI machine language (ACPI Machine Language, AML) through a compiler, and starts the system of electronic equipment.
  • ASL ACPI Source Language
  • AML ACPI Machine Language
  • the system can call the AML parser interface to parse the configuration or execute the control interface code.
  • ASL is more complex than DTB's configuration syntax, it is more expensive for developers to learn, and the memory (such as ROM and/or RAM) overhead of AML files and AML parsers is larger, mainly used in computers with X86 architecture platform, not for lightweight devices.
  • the embodiment of the present application provides a driver configuration management method, which can realize the driver on the limited hardware resources of the lightweight platform.
  • Configuration management, and the realization of configuration management framework can support both lightweight platforms and full-scale platforms.
  • an embodiment of the present application provides a drive configuration management method, which defines a set of configuration description syntax for configuration files, and a unified configuration description syntax can be used to generate electronic devices with different performance or power consumption requirements, respectively.
  • configuration file required for consumption For example, a configuration file in C language format (hereinafter referred to as a C language configuration file, that is, the configuration file is C language code) can be generated in a lightweight environment, so that the drivers of lightweight devices such as IoT devices and bracelets can pass The C language code is directly called to obtain the hardware-related configuration, which avoids the storage and parsing overhead of the configuration file by the lightweight device, and ensures the high performance of the lightweight device.
  • a configuration file in binary format (hereinafter referred to as binary configuration file) can be generated in a full-scale environment, so that drivers in full-scale devices such as mobile phones and tablet computers can use the configuration parsing interface provided by the configuration framework to obtain hardware-related configuration files.
  • configuration and the mode of obtaining the configuration through the configuration parsing interface has the complete hardware description capability. Therefore, the above process of driving configuration management not only ensures the performance of the lightweight device, but also realizes the high flexibility and complete hardware topology description capability of the full-scale device.
  • the present application has the following advantages: first, it realizes the portability and maintainability of the driver implementation code, realizes the decoupling of the driver business and the configuration (such as the decoupling of the driver implementation code and the configuration file), and realizes the driver implementation code porting or Adapting to a new platform requires only code changes. Secondly, since the application can use a set of configuration description syntax to generate configuration files in different file formats, the reusability of the configuration source code of the configuration files is improved, and a set of codes can support multiple platforms at the same time (such as the following lightweight platforms and Full-scale platform), the configuration of different platforms can be adaptive.
  • the system 10 includes an electronic device 100 a , an electronic device 100 b and a management device 200 .
  • the management device 200 is configured to send a configuration file conforming to the performance and power consumption of the receiving device to the electronic device 100a and the electronic device 100b, respectively.
  • the electronic device 100a may be a full-scale device, and the electronic device 100b may be a lightweight device.
  • the electronic device 100a is a mobile phone
  • the electronic device 100b is a wristband
  • the management device 200 is a desktop A computer is shown as an example.
  • the management device 200 may send a configuration file, such as a binary configuration file, conforming to the performance and power consumption of the full-weight device to the electronic device 100a; and power consumption profiles, such as C language profiles.
  • the system 10 shown in FIG. 1 may include any number of electronic devices, and is not limited to one lightweight device (ie, electronic device 100b ) and one full-weight device (ie, electronic device 100a ) shown in FIG. 1 .
  • the management device 200 suitable for the present application may be a server, a desktop computer, a notebook computer, or the like.
  • the server may be a hardware server, or it may be embedded in a virtualized environment.
  • a server may be a virtual machine executing on a hardware server including one or more other virtual machines, ie a cloud server.
  • the electronic device 100a and the electronic device 100b may communicate with the management device 200 in various wired connection manners, or perform wireless communication in various wireless manners, which are not specifically limited in this embodiment of the present application.
  • the management device 200 in the driver configuration management system 10 may include a configuration compiler 201 for generating configuration files in different formats for electronic devices with different performance and power consumption using a unified configuration description syntax. It can be understood that the management device 200 may select compilation parameters (or target information) based on the computing capability of the electronic device, that is, the target file format of the configuration file of the selected electronic device. It can be understood that the computing capability of an electronic device can be characterized by a compilation parameter. Specifically, the system framework that drives the configuration management system 10 can be divided into a configuration compilation phase and a configuration usage phase according to the compilation and use of configuration files.
  • the management device 200 can generate a configuration file in a corresponding format (or a file format) through the configuration compiler according to the set compilation parameters, where the compilation parameters correspond to the performance and power consumption of the electronic device.
  • the configuration and use stage can be implemented by the electronic device 100a and the electronic device 100b in the system 10, specifically, these electronic devices obtain the configuration file from the management device 200, and configure and drive the hardware.
  • the management device 200 may determine the computing capability of the electronic device by itself, and then select the compilation parameters. For example, after the management device 200 establishes a connection with the electronic device, it can capture information about the computing capability of the electronic device, including but not limited to the clock frequency of the processor in the electronic device, the RAM capacity of the processor, the The capacity of the ROM, for example, may also be information such as the battery capacity of the electronic device or the model of the processor. In addition, after the management device 200 establishes a connection with the electronic device, the electronic device may also actively report information of its own computing capability to the management device.
  • the management device 200 selects the compilation parameters based on the computing capability of the electronic device 100b, it may be determined that the computing capability is the first type of computing capability, and the first type of computing capability represents the computing capability of the lightweight device, Then, the selected compilation parameter is the compilation parameter corresponding to the lightweight device, and the file format corresponding to the compilation parameter is the text format (ie, the format of the first language).
  • the management device 200 selects the compilation parameters based on the computing capability of the electronic device 100a, if it is determined that the computing capability is the second type of computing capability, and the second type of computing capability represents the computing capability of the full-scale device, then select The compilation parameters are those corresponding to full-scale devices, and the file format corresponding to the selected compilation parameters can be binary format.
  • the management device 200 may select compilation parameters in response to a user's operation, that is, determine the computing capability of the electronic device, and then select a file format corresponding to the compilation parameters. At this time, the computing capability of the electronic device is determined by the user, and then the user can manually select the compilation parameters representing the computing capability of the electronic device in the user interface provided by the management device 200.
  • the compilation parameters are mainly selected by the user's operation to select the file format for generating the final configuration file. The specific implementation will be described below, and will not be repeated here.
  • the management device 200 includes a configuration compiler 201 for converting the text of the configuration source file into a required output format (such as binary format or C language). format, etc.).
  • the configuration compiler 201 includes a lexical analyzer 2011 , a syntax analyzer 2012 , an intermediate processor 2013 , a text configuration generator (eg, a C language configuration generator) 2014 and a binary configuration generator 2015 .
  • the configuration compiler 201 expands the grammar in the abstract syntax tree through the intermediate processor 2013 and generates it the final abstract syntax tree.
  • the configuration compiler 201 uses the binary configuration generator 2015 to process the final abstract syntax tree into a binary configuration file and output to the electronic device 100a.
  • the configuration compiler 201 uses the text configuration generator 2014 to process the above-mentioned final abstract syntax tree into a C language configuration file, and output it to the electronic device 100b.
  • the electronic device 100a may include a configuration parser 101 for parsing the binary configuration file into a configuration tree.
  • the driver implementation code of the electronic device 100a parses the topology structure of the configuration tree through the read interface of the configuration parser 101 and reads the configuration attribute content in the configuration tree.
  • the driver implementation code of the electronic device 100b directly calls the function interface and structure definition in the C language configuration file to obtain the configuration content related to the hardware.
  • each part of the configuration compilation phase and the configuration usage phase involved in driving the configuration management system 10 will be described in detail below. describe.
  • a configuration source file is a configuration source file organized according to a configuration description grammar, which is a text format with a Key-Value (ie, key-value) as the main body designed to facilitate configuration management.
  • the code in the configuration source file may be referred to as the configuration source code.
  • the configuration source file is used to describe the configuration of each hardware in the electronic device. For example, the configuration source file is used to describe whether the front camera in the electronic device is enabled and what functions (or permissions) are enabled, whether the rear camera is enabled and What functions are turned on, whether the touch screen is turned on and what functions are turned on, etc.
  • the configuration source file is specifically used to describe information of one or more pieces of hardware, such as information such as the name of each piece of hardware, the base address of the register, and the offset value of the register. It can be understood that some hardware registers in an electronic device are used for special purposes, and accessing a certain hardware register by the electronic device will cause the underlying hardware to perform a certain corresponding operation. For example, the electronic device accesses the registers of the front camera to configure and drive the front device head accordingly.
  • the configuration source code in the configuration source file provided by the embodiment of the present application includes the information of the device 0 and the information of the device 1 in the electronic device, and specifically includes the following fields:
  • device 0 and device 1 are respectively represented by two fields.
  • the content before each symbol "//" is the code itself, and the content after the symbol "//" is the explanation of the line of code.
  • device0 is used to represent device 0, for example, device 0 may be a front-facing camera of an electronic device.
  • the register base address of 0 is 0xff00, and the data type of 0xff00 is a hexadecimal value;
  • device1 is used to represent device 1, for example, device 1 may be a rear camera in an electronic device.
  • the code “device1:device0" is used to indicate that the configuration of device 1 replicates the configuration of device 0.
  • the register base address of device 1 replicates the register base address of device 0, that is, the register base address of device 1 is also 0xff00.
  • the text format of the Key-Value expressed by the configuration description grammar is described.
  • module is the Key
  • “sample” is the Value
  • regBase is the Key
  • 0xff00 is the Value.
  • the function of the lexical analyzer 2011 is to read the strings (or file descriptors) in the configuration source file, convert these strings into a sequence of syntax units, and then output the sequence of syntax units to the syntax analyzer 2012 for use .
  • the above-mentioned syntax units may include, but are not limited to, data types such as strings, brackets, and keywords.
  • ⁇ type string, value: sample ⁇ , ⁇ type: symbol, value: ; ⁇ .
  • the type in the syntax unit represents the data type of the string, and the value represents the value of the string.
  • the syntax unit sequence output by the lexical analyzer 2011 may be referred to as a syntax unit stream, or a token stream.
  • the syntax analyzer 2012 is used to syntactically check the syntax unit sequences output by the lexical analyzer 2011, verifying whether these syntax unit sequences conform to the predefined description syntax, and can prompt the location and content of errors .
  • the syntax analyzer 2012 is also used to convert the syntax unit sequence into an abstract syntax tree (Abstract Syntax Tree, AST) that is convenient for program processing, and transmit the abstract syntax tree to the subsequent processing module of the configuration compiler 201 for further processing.
  • the abstract syntax tree may be referred to as a syntax tree (Syntax tree).
  • the abstract syntax tree involved in the embodiments of the present application includes at least information such as node names, attributes, and attribute values.
  • nodes, attributes, and attribute values correspond to different contents in the configuration source code of the above example.
  • different nodes may correspond to different code segments in the configuration source code of the above example
  • a set of attributes and attribute values may correspond to a set of Key-Values of codes in each code segment in the configuration source code.
  • an abstract syntax tree is a tree-like representation of an abstract syntax structure of source code (eg, configuration source code), and each node on the tree represents a structure in the source code.
  • source code eg, configuration source code
  • each node on the tree represents a structure in the source code.
  • the abstract syntax tree does not represent every detail of the appearance of the real grammar, for example, nested brackets (ie " ⁇ ") are implied in the structure of the tree and are not presented in the form of nodes.
  • the description of the content of the abstract syntax tree generated by the lexical analyzer 2011 and the syntax analyzer 2012 is as follows:
  • an abstract syntax tree can use "CONFNODE” to represent a node, "CONFTERM” to represent an attribute, "STRING” to indicate that the data type of the attribute value of the corresponding attribute is character (or string), and "
  • the data type represented by "UINT32” is an unsigned 32-bit integer, and the data type represented by "UINT8” is an unsigned 8-bit integer.
  • CONFTERM the attributes (CONFTERM) between two nodes (CONFNODE) in the abstract syntax tree of the above example are all attributes in the previous node.
  • CONFNODE ForestRoot is the virtual root node “ForestRoot” constructed by the parser 2012
  • CONFNODE root represents the parent node “root”, corresponding to the code segment root ⁇ in the above configuration source file, but nested Parentheses (" ⁇ ") are implied in the structure of the tree and are not presented as nodes.
  • CONFNODE device0 represents the child node “device0”, which corresponds to the code segment device0 ⁇ in the above configuration source file.
  • CONFNODE device1NodeCopy device0 represents the child node “device1”, which corresponds to the code segment "device1:device0 ⁇ ” in the above configuration source file.
  • the intermediate processor 2013 is used for processing the syntax that cannot be processed by the parser 2012, such as redefinition checking, reference expansion and other processing. After being processed by the intermediate processor 2013, the abstract syntax tree can be output to the subsequent binary configuration generator 2015 and text configuration generator 2014.
  • the intermediate processor 2013 performs reference expansion, and outputs the following abstract syntax tree (referred to as the final abstract syntax tree):
  • the intermediate processor 2013 refers to the final abstract syntax tree generated by the expansion processing of the code "CONFNODE device1NodeCopy device0" in the abstract syntax tree generated by the above-mentioned syntax analyzer 2012, so that the abstract syntax tree expands the attribute "device1" in the node “device1".
  • regBase and the attribute value "ff00” whose data type is an unsigned 32-bit integer.
  • the binary configuration generator 2015 outputs the content of the abstract syntax tree as a binary configuration file according to the custom bytecode rule in the embodiment of the present application.
  • the bytecode encoding table provided by this application is shown in Table 1:
  • Code Value represents the code value matched by different types of codes
  • Code Name represents the code name
  • Arguments represents the parameter
  • Description is the supplementary description of the code. It can be understood that the code names, code values and other information of different types of codes are different.
  • the code name "Config Node” represents the node, the corresponding code value is "0x01", and the corresponding parameters include the node name (Node Name) whose data type is character (String) and the data type (Double Word, DWord) The node length (Length), where the node length is used to indicate how many bytes a node contains in total, and the DWORD double word is 4 bytes with a total of 32 bits.
  • the code name "NodeRef” indicates the node configuration, the corresponding code value is "0x03", and the corresponding parameter includes the hash code (HashCode) whose data type is DWord, which is used to refer to another node and is used to quickly access another node.
  • HashCode hash code
  • the code name "Array” represents an array, the corresponding code value is "0x04", and the corresponding parameters include the value (Count) whose data type is word (Word), and the array length (Length) whose data type is double word (DWord). ), and array data (data).
  • the code name "String” represents a character string, the corresponding code value is "0x14", and the corresponding parameter is the ascii code (ascii end of' ⁇ 0') ending with ' ⁇ 0' (ie 0x00), the corresponding Described as a string data prefix.
  • the configuration compiler 201 may be implemented by compiling software.
  • the compiling software may provide a user interface (referred to as a configuration management interface) for displaying the compiling process of the configuration file by the configuration compiler 201 to the user, such as displaying the configuration source code, the abstract syntax tree, and the syntax of the abstract syntax tree Check the results, and the final configuration file compilation output results (such as output success or output failure).
  • the binary configuration generator 2015 can generate the configuration code in the binary configuration file shown in FIG. 3 from the abstract syntax tree processed by the intermediate processor 2013 according to the above-mentioned custom bytecode rules.
  • the content shown in FIG. 3 not only includes the configuration code in the binary configuration file, but also includes a mark on how each character of the configuration code is arranged and displayed, and an explanation of each line of characters.
  • the characters in the binary configuration file shown in FIG. 3 are all hexadecimal values.
  • the numbers “1-11” in the leftmost column in the content shown in FIG. 3 are used to indicate the number of lines of code compiled in the compilation software a where the configuration compiler 201 is located.
  • the "0ffset" in the first line is used to indicate that each character in the binary configuration file shows the line number and column number displayed in the compilation software a in Fig. 3, "00 01 02 03 ... 0E” shown in the first line in Fig. 3 0F" these 16 column numbers, and the row numbers of "000000000 000000010...000000090" shown in the first column in Figure 3.
  • the serial numbers of the respective rows and the serial numbers of the columns shown in FIG. 3 are used to facilitate the relevant technical personnel to locate and query the respective codes in the binary configuration file.
  • the binary configuration file shown in Fig. 3 includes "0A A0 0A A0...00 FF 00 00", and the arrangement order is from left to right and from top to bottom, that is, along the column numbers shown in Fig. 3 from small to small To large, the order of row numbers from small to large.
  • the character "0A” indicated by the row number "00” and the column number "00000000” is the first character in the binary configuration file shown in FIG. 3 .
  • each line of the compiling software can display 32 characters, that is, the compiling software displays 32 columns of serial numbers.
  • the row sequence shown in FIG. 3 is all characters in “00000000” and “00000010”, the row sequence is all characters in “00000000”, and the row sequence is “00000020”.
  • the column number is The characters of "00-0D” are taken as an example, and the binary configuration file shown in FIG. 3 will be described in detail. Specifically, in combination with Table 1, these characters are described in the order from left to right and top to bottom as shown in Figure 3: "0A A0 0A A0" is a magic number, which is used to verify the file type, that is, it is used to verify the Whether the current file is a binary configuration file that complies with the bytecode encoding rules shown in Table 1.
  • "00 00 00 00 00" represents the file check digit, which can be used to indicate whether the current file is safe or normal.
  • "40 00 00 00” represents the major version number of the compiler, and the major version number of the compiler 201 is configured as described above.
  • "00 00 00 00” is used to indicate the compiler subversion number.
  • "8c 00 00 00” represents the file size, which is 140 (bytes).
  • "01” represents a node (Config Node).
  • "72 6f 6f 74 00" represents the node name "root", where "72", “6f", “6f”, and “74” are the ascii of "r”, "o", “o”, and “t” respectively code, "00" is the terminator.
  • the text configuration generator 2014 is used to generate a language (eg, a low-level oriented language) implementation based on the C language or C++ language, which has a smaller file size and is easier to compile using.
  • a language eg, a low-level oriented language
  • C++ language e.g., a C language configuration generator
  • the text configuration generator 2014 is configured to generate a C language configuration file composed of C language data structures and functions from the content in the abstract syntax tree, so that the driver implementation code in the electronic device can directly call functions and access functions
  • the variable gets the configuration that should be associated. That is, the C language configuration file includes two parts, the header file and the content file.
  • the C language configuration file mainly includes configuration content stored in a structure, and a configuration obtaining interface function generated for obtaining the configuration.
  • an example of the header file in the C language configuration file generated by the text configuration generator 2014 is as follows:
  • conditional indicator #ifndef is used to check whether a precompiled constant (ie "HCS_CONFIG_SAMPLE_HEADER_H") has been defined by a macro. If not defined by a macro, the conditional indicator #ifndef is true, so all statements from #ifndef to #endif are included for compilation. Conversely, if the condition indicator evaluates to false, the statements between the #ifndef and #endif indicators are ignored.
  • the main purpose of the conditional indicator #ifndef is to prevent repeated inclusion and compilation of header files.
  • the above header file includes: a declaration of a configuration structure (or called a structure declaration) and a configuration acquisition function declaration (or called a function declaration).
  • the configuration structure declaration defined in the above header file includes struct HdfConfigSampleDevice0, struct HdfConfigSampleDevice1, and struct HdfConfigSampleDRoot.
  • the configuration acquisition function declaration in the above header file can be a "const struct HdfConfigSampleRoot*HdfGetSampleModuleConfigRoot(void)" function.
  • the header file in the C language configuration file is used to declare parameters and variables.
  • the following parameters are declared for device 0: the device name whose data type is a constant string (const char*) "deviceName”, the data type is the register base address (regBase) of the 16-bit unsigned integer (uint16_t), and the data type is the register base address (regOffset) of the 8-bit unsigned integer (uint8_t), corresponding to the above Example configuration source file and corresponding properties for device 0 in the abstract syntax tree.
  • header file also includes the content of the explanation "It's HDF config auto-gen file, do not modify it manually", which is used to explain to the relevant technical personnel that this header file is an HDF configuration auto-gen file, please do not modify it manually.
  • HDF stands for Hardware Driver Foundation.
  • an example of the content file in the C language configuration file of the text configuration generator 2014 is as follows:
  • the content file in the C language configuration file of the above example includes configuration variable definitions (or structure definitions) and interface functions.
  • the configuration variable definition includes the "g_hdfConfigSampleModuleRoot” variable in the above example, which stores configuration information and whose structure is consistent with that in the configuration source file.
  • the above interface function can be the "HdfGetSampleModuleConfigRoot” function in the above example, and its function is to obtain the address of the configuration data structure, and the address can be the address where the configuration structure (ie the configuration content) in the content file is located.
  • the content file in the C language configuration file of the above example defines the value of the parameter module, the value of each parameter of device 0 and device 1, respectively corresponding to the configuration source file and abstraction of the above example The corresponding attribute value in the syntax tree.
  • the above content file defines the device name "deviceName” as foo, the register offset "regOffset” as 0x1, and the register base address "regBase” as 0xff00.
  • the configuration parser 101 is configured to read the data in the binary configuration file and parse the data content according to the bytecode format, thereby reconstructing a configuration tree consistent with the structure of the configuration source file (ie, the configuration source code).
  • the configuration parser 101 also provides a series of interfaces for the driver implementation code to query, traverse, and read the configuration content from the binary configuration file. It can be understood that the bytecode rules shown in Table 1 above are preset in the electronic device 100a.
  • the electronic device 100a also includes driver implementation codes (or referred to as driver implementations). Specifically, in the configuration and use stage, the electronic device 100a may acquire the binary configuration file output by the management device 200 through the binary configuration generator 2015 in the configuration compiler 201 . Subsequently, the electronic device 100a can call the configuration parser 101 through the driver implementation to load the binary configuration file to configure and drive the relevant hardware in the electronic device 100a, such as the front camera and the rear camera in the electronic device 100a.
  • driver implementation codes or referred to as driver implementations.
  • the electronic device 100a includes driver implementation codes (referred to as driver implementations for short). Specifically, in the configuration and use stage, the electronic device 100b may acquire the C language configuration file output by the management device 200 through the text configuration generator 2014 in the configuration compiler 201 . Subsequently, the electronic device 100a can directly call the C language configuration file through the driver implementation to configure and drive the relevant hardware in the electronic device 100a, such as the front camera and the rear camera in the electronic device 100a.
  • driver implementation codes referred to as driver implementations for short.
  • the binary configuration file is used to configure and drive the front-facing camera in the electronic device 100a to start and enable the normal photographing function and the beauty photographing function of the front-facing camera, And configure and drive the rear camera to start and enable the conventional camera function and panorama shooting function of the rear camera.
  • the C language configuration file is used to configure and drive the conventional photographing function of the front camera, and configure and drive the conventional photographing function of the rear camera.
  • the binary configuration file is used to configure and drive the screen-on/off function, tap touch function, specific gesture touch function, and fingerprint touch function of the touch screen in the electronic device 100a.
  • the C language configuration file is used to configure and drive the screen-on/off function and the click-to-touch function of the touch screen in the electronic device 100b.
  • the management device 200 when configuring the compiler 201 to compile, invokes the compiler program through a command line, and sets the input file path, output file path, and compilation parameters that control the output binary configuration file and C language configuration and other compilation options Passed to the compiler through parameters.
  • the input file path represents the configuration source file path
  • the output file path represents the generated product output path of the configuration compiler 201.
  • the output path of the binary configuration file is the path from the configuration compiler 201 to the electronic device 100a
  • the output of the C language configuration file The path is the path from the configuration compiler 201 to the electronic device 100b.
  • the configuration compiler 201 opens the configuration source file from the file system or the file image according to the input file path, and transmits it to the lexical analyzer 2011 to start the compilation process.
  • the configuration source code in the configuration source file is converted into an abstract syntax tree after being processed by the lexical analyzer 2011 and the syntax analyzer 2012.
  • the intermediate processor 2013 judges which generator to call through the compilation parameters, such as the binary configuration generator 2015 or Text Configuration Generator 2014.
  • the configuration compiler 201 selects the binary configuration generator 2015 for output by default.
  • FIG. 4A it is a configuration management interface for configuring the compilation software a where the compiler 201 is located.
  • the interface includes a functional area 41 , a functional area 42 , a code display area 43 , a compilation result display area 44 and a list area 45 .
  • the function area 41 includes the "Edit (E)” option and the compilation parameter option 411, and the "Edit (E)” option is used to support the user to edit the code in the code display area 43, such as the code display area 43 in FIG. 4A .
  • the compilation parameter option 411 is used to select the format of the configuration file generated by the configuration compiler 201, such as binary configuration and C language configuration, but not limited to this. It can be understood that the compilation parameter option 411 selects “binary configuration” shown in FIG. 4A , indicating that the compilation parameter is “-b”, indicating that the configuration compiler 201 selects the binary configuration generator 2015 to generate a binary configuration file during the compilation process.
  • FIG. 4A the format of the configuration file generated by the configuration compiler 201
  • the compilation parameter option 411 selects “binary configuration” shown in FIG. 4A , indicating that the compilation parameter is “-b”, indicating that the configuration compiler 201 selects the binary configuration generator 2015 to generate a binary configuration file during the compilation process.
  • the user can operate the compilation parameter option 411, pop up the option “C language configuration”, and operate the option “C language configuration” to control the compilation parameter option 411 to select the “C language configuration” shown in FIG. 4C.
  • the compilation parameter option 411 in the configuration compiler 201 selects "binary configuration" by default, that is, the output of the binary configuration generator 2015 is used by default, and the user may not operate the compilation parameter option 411 at this time.
  • the functional area 42 includes an option “compile”, an option “compile and output”, an option “input file path”, an option “output file path”, and the like.
  • the option “compile” is used to trigger the configuration compiler 201 to compile the configuration source code to obtain a configuration file in a set format.
  • the option “compile and output” is used to trigger the configuration compiler 201 to compile the configuration source code to obtain the configuration file in the set format, and output the generated configuration file to the electronic device, such as the electronic device 100a or the electronic device 100b.
  • the option “input path” is used to support the user to set the configuration source file path.
  • the option “output file path” is used to support the user to set the path of the output file of the configuration compiler 201 .
  • the option "input file path” and the option “output file path” are not included in the function area 42, but are set through some sub-options in the option "file (F)" in the function area 41 .
  • the code display area 43 is used to display the configuration source code, the abstract syntax tree, and the subsequently compiled binary configuration file or C language configuration file.
  • the compilation result display area 44 is used to display the configuration source code, abstract syntax tree, and subsequently compiled binary configuration file or C language configuration file during the compilation process whether there are errors, where and what errors occurred, and whether the compilation is successful or not. compilation result.
  • the list area 45 is used to display a list of the configuration source code, abstract syntax tree, and binary configuration files or C language configuration files generated during the compilation process of the configuration compiler 201 .
  • the configuration compiler 201 can display the configuration source code in the code display area 43 as shown in FIG. 4A , and display the list item “configuration source code” in the list area 45 .
  • the configuration compiler 201 can generate the abstract syntax tree and the code in the final configuration file.
  • the content that the configuration compiler 201 can update and display in the list area 45 includes at least one of the following items: the list item “Syntax Abstract Tree 1” corresponding to the abstract syntax tree generated by the syntax processor 2012 shown in FIG.
  • FIG. 4E FIG.
  • the list item "Syntax Abstract Tree 2" corresponding to the abstract syntax tree generated by the intermediate processor 2013 shown in 4F, the binary configuration file code generated by the binary configuration generator 2015 shown in FIG. 4G. Or, the header file in the C language configuration file code generated by the text configuration generator 2014 shown in FIG. 4H , and the content file in the C language configuration file code generated by the text configuration generator 2014 shown in FIG. 4I .
  • each list item in the above-mentioned list area 45 can be operated by the user, and trigger the code display area 43 to display the corresponding code.
  • the configuration compiler 201 displays the list item in a special format (the bold display format shown in FIG. 4E ).
  • the user can operate the mouse or touch screen, such as including but not limited to clicking. operate.
  • the mouse or touch screen such as including but not limited to clicking. operate.
  • the cursor “arrow” of the mouse is used as an example to illustrate the user's operations on various options or contents.
  • the configuration compiler 201 may sequentially display FIG. 4D -4G shown content. It can be understood that, in the case where the above-mentioned compilation parameter option 411 selects “C language configuration” by default, and the option “compile” and the option “compile and output” are operated by the user, the contents displayed in sequence by the configuration compiler 201 are the same as those shown in FIG. 4D . The content shown in -4G is similar and will not be repeated here.
  • an error occurs in a line of code in the configuration source code of the above configuration source file as an example to describe the location and content of the error prompted by the syntax analyzer 2012.
  • the management The device 200 inputs the configuration source code to the parser 2012, and the parser 2012 will output that there is an error in this line of code, and the error is a repeated label ";”.
  • the code "module "sample”;;” in the interface shown in FIG.
  • 4D is displayed in a special format (the underlined display format), and in the compilation result display area, "Error prompt: Location: Line 2, Error content: ;;Repeat". Subsequently, the user can revise the content in the configuration source file, and the revised configuration source code is displayed on the configuration management interface as shown in FIG. 4A .
  • the specific implementation of the driving configuration management method will be described according to the various components in the management device 200 and the electronic device 100a and the electronic device 100b in the above example.
  • FIG. 5 shows a schematic flowchart of a drive configuration management method provided in an embodiment of the present application.
  • the logical sequence of the driving configuration management method provided by the embodiments of the present application is shown in the method flowchart, in some cases, the steps shown or described may be performed in a sequence different from that here.
  • the driver configuration management method shown in FIG. 5 is applied to the configuration compilation stage, including steps 501-506.
  • Step 501 the configuration compilation starts, the management device 200 uses the configuration compiler 201 to open the configuration source code in the configuration source file, obtains file descriptors of the configuration source file, and inputs these file descriptors to the lexical analyzer 2011 .
  • the management device 200 inputs the configuration source code in the configuration source file to the configuration compiler 201 .
  • the file descriptor of the configuration source can be a string in the configuration source.
  • the management device 200 may display the configuration management interface including the configuration source code as shown in FIG. 4A .
  • Step 502 The management device 200 uses the lexical analyzer 2012 to process the configuration source file into a syntax unit stream (ie, syntax unit sequence, or Token stream), and outputs the syntax unit stream to the syntax analyzer 2012 .
  • a syntax unit stream ie, syntax unit sequence, or Token stream
  • Step 503 The management device 200 uses the syntax analyzer 2012 of the configuration compiler 201 to perform syntax checking on the syntax unit stream, converts syntax units in the syntax unit stream into an abstract syntax tree, and outputs the abstract syntax tree to the intermediate processor 2013 .
  • the management device 200 performs a syntax check on the syntax unit stream, and can obtain whether there is an error in the syntax unit stream. If there is an error in the syntax unit stream, the management device 200 can control the configuration compiler 201 to prompt the user of the location and content of the error through the configuration management interface. The user can then manually correct the error by following the prompts. If there is no error in the syntax unit stream, or the user has corrected the error, the management device 200 may control the configuration compiler 201 to convert the syntax unit stream into an abstract syntax tree and output the abstract syntax tree to the intermediate processor 2013 . It can be understood that if there is an error in the grammatical unit stream, it can indicate that there is an error in the configuration source code.
  • the management device 200 can refer to the content shown in FIG. 4B for an example of the location and content of the error prompted by the management device 200, and then the modified configuration source code can refer to FIG. 4A. content shown. And, the management device 200 can refer to the content shown in FIG. 4E using the syntax abstract tree generated by the syntax processor 2012 .
  • Step 504 The management device 200 uses the intermediate processor 2013 to process the abstract syntax tree output by the parser 2012 to obtain the processed abstract syntax tree, reads the compilation parameters, and selects a generator, that is, selects the binary configuration generator 2015 or the text Configuration Generator 2014.
  • the processing of the abstract syntax tree by the intermediate processor 2013 includes, but is not limited to, redefinition checking and reference expansion in the above example. It can be understood that, the intermediate processor 2013 processes the obtained abstract syntax tree, corrects the redefinition error, or realizes the reference expansion of the statement.
  • the syntax abstraction tree generated by the management device 200 using the syntax processor 2012 may refer to the content shown in FIG. 4F .
  • the management device 200 uses the configuration compiler 201 to read whether the compilation parameter is "-b" or "-t". 4A and 4C, the management device 200 can determine whether the compilation parameter option 411 in the configuration compiler 201 is selected as "binary configuration” or "C language configuration” to select the corresponding generator.
  • Step 505 The management device 200 determines whether the binary configuration file needs to be output.
  • step 506 If it is determined that the binary configuration file needs to be output, that is, the compilation parameter is selected as "binary configuration" (ie "-b"), then the following step 506 is executed, and the compilation process is ended; if it is determined that the binary configuration file is not required to be output, then The following step 507 is performed. In addition, if an error occurs in the judgment process of steps 505 and 507, the compilation process is ended.
  • Step 506 The management device 200 uses the binary configuration generator 2015 to output the abstract syntax tree generated by the intermediate processor 2013 as a binary configuration file.
  • the configuration compiler 201 is in the binary configuration generation mode, and the management device 200 can display the content shown with reference to the above-described FIG. 4G .
  • the management device 200 may output the generated binary configuration file to the electronic device 100a (ie, a full-scale device).
  • Step 507 The management device 200 determines whether to output the C language configuration file.
  • the compilation parameter is selected as "C language configuration" (ie "-t")
  • the following step 508 is performed; if an error occurs in the determination process, the compilation process is ended.
  • Step 508 The management device 200 uses the text configuration generator 2014 to output the abstract syntax tree generated by the intermediate processor 2013 as a C language configuration file.
  • the configuration compiler 201 is in the C language configuration generation mode.
  • the management device 200 may display the contents shown with reference to the above-mentioned FIGS. 4H and 4I .
  • the management device 200 may output the generated binary configuration file to the electronic device 100b (ie, a lightweight device).
  • FIG. 6 a schematic diagram of an application flow of the drive configuration management system 10 in a full-scale environment is shown.
  • the configuration nodes included in the configuration source code and each configuration attribute therein are briefly shown.
  • the management device 200 generates an abstract syntax tree using the lexical analyzer 2011 , the syntax analyzer 2012 and the intermediate processor 2013 in sequence, and outputs the binary configuration file to the electronic device 100 a through the binary configuration generator 2015 .
  • the electronic device 100a invokes the configuration parser 101 to load the binary configuration file using the driver implementation.
  • the configuration compiler selects the compilation parameter as "-b", that is, selects the binary configuration generator 2015.
  • the drive configuration management method includes the following steps:
  • Steps 501 to 505 are the same as the steps described in conjunction with FIG. 5 in the foregoing embodiment, and are not repeated here.
  • step 505 when it is determined in step 505 that the binary configuration file needs to be output, that is, when the compilation parameter is “-b”, the executed steps are replaced by steps 5061-5064 from step 506 shown in FIG. 5 .
  • Step 5061 The management device 200 outputs the abstract syntax tree generated by the intermediate processor 2013 to the binary configuration generator 2015 .
  • Step 5062 The management device 200 uses the binary configuration generator 2015 to traverse the abstract syntax tree.
  • the abstract syntax tree is a tree structure constructed by sibling child notation
  • the manner of traversing the abstract syntax tree by the binary configuration generator 2015 includes but is not limited to depth traversal and reverse depth traversal.
  • the depth traversal is performed for each subtree (including itself) in the order of the child node first and then the sibling nodes of the child node.
  • the traversal sequence is root, module, sample, device0, deviceName, foo...
  • the reverse depth traversal of the tree is to traverse each subtree (including itself) in the order of the sibling nodes of the child node, and the child node later.
  • the traversal order is sample, module, foo, deviceName, device0...root.
  • Step 5063 The management device 200 uses the binary configuration generator 2015 to output configuration node data.
  • Step 5064 The management device 200 uses the binary configuration generator 2015 to output configuration attribute data.
  • the binary configuration generator 2015 traverses the abstract syntax tree passed by the intermediate processor 2013, and outputs the configuration content as a binary configuration file according to the bytecode encoding table introduced above, including the above configuration node data and configuration attribute data.
  • configuration node data and configuration attribute data reference may be made to the content shown in FIG. 4G and the content of the above example, and details are not repeated here.
  • the binary configuration file retains the topology information in the configuration source file when it is output, that is, it saves the relationship between nodes, such as node parent-child relationship, sibling relationship, etc., which is used to describe the configuration between the configurations. Relationship.
  • the configuration source code when the application is applied in a full-scale environment, the configuration source code outputs a binary configuration file in bytecode format through the configuration compiler, and the bytecode preserves the configuration topology to the greatest extent, which can be easily resolved during parsing. It is convenient to perform various traversal operations.
  • the RAM and ROM overhead of electronic devices ie processing time, power consumption, and storage space, etc.
  • step 507 and step 508 which are the same as the steps described in conjunction with FIG. 5 in the foregoing embodiment, and are not repeated here.
  • the drive configuration management method provided by the embodiment of the present application further includes the following steps:
  • Step 801 When the driver is loaded, the electronic device 100a starts the configuration parser 101.
  • Step 802 The electronic device 100a uses the configuration parser 101 to read the binary configuration file corresponding to the configuration source code.
  • the electronic device 100a can add the binary configuration file to the system image of the electronic device 100a through the file system or directly packaged into the image.
  • the configuration parser 101 is used to load the binary configuration file, that is, the binary storage format is converted into a configuration tree in memory (see steps 803-806 below for details), which is convenient for query and traversal.
  • the configuration parser 101 provides a traversing and reading interface for the driver to use, and the driver implementation code of the electronic device 100a uses the configuration parsing interface to obtain the configuration content according to its own needs.
  • Step 803 The electronic device 100a uses the configuration parser 101 to verify the validity of the binary configuration file.
  • the electronic device 100a can check the suffix of the binary configuration file, or check whether the magic number in the binary configuration file is a predefined value (such as "0A A0 0A A0" in the above example), to check the validity of the binary configuration file.
  • a predefined value such as "0A A0 0A A0" in the above example.
  • step 804 If it is detected that the binary configuration file is valid, the following step 804 is continued, otherwise, the configuration and use process ends.
  • Step 804 The electronic device 100a uses the configuration parser 101 to parse the binary configuration file according to the bytecode rule. Specifically, for the process of parsing the binary configuration file according to the bytecode, reference may be made to the description in the example related to Table 1 above, and details are not repeated here.
  • Step 805 The electronic device 100a uses the configuration parser 101 to determine whether the parsing of the binary configuration file is successful.
  • step 806 If the parsing is successful, the following step 806 is performed, otherwise, the configuration and use flow is ended. It can be understood that the successful parsing indicates that the characters in the binary configuration file conform to the above bytecode rules, and all characters have been parsed.
  • Step 806 The electronic device 100a uses the configuration parser 101 to construct a configuration tree with the binary configuration file.
  • Step 807 The electronic device 100a uses the driver implementation code to traverse the configuration tree.
  • the electronic device 100a may first determine the hardware that needs to obtain information in the configuration number, and then traverse the configuration tree for the required hardware. For example, if the electronic device 100a needs to obtain the information of the device 0 (such as the front camera), the electronic device 100a can traverse the configuration tree for the device 0 to find the determined node "device 0".
  • Step 808 The electronic device 100a uses the driver implementation code to parse the required configuration property value.
  • the electronic device 100a may traverse the configuration tree for device 0 to find the attribute and attribute value that is determined to correspond to the node "device 0".
  • Step 809 The electronic device 100a initializes the hardware by using the configuration attribute through the driver implementation code.
  • the electronic device 100a may perform an operation of initializing the hardware of the device 0.
  • Step 810 The loading of the hardware driver of the electronic device 100a is completed.
  • the electronic device 100a has completed the driving of the front camera and the rear camera.
  • FIG. 9 a schematic diagram of an application flow of the drive configuration management system 10 in a lightweight environment is shown.
  • configuration nodes included in the configuration source code and various configuration attributes therein are briefly shown, and for details, refer to the configuration source code shown in FIG. 4A above.
  • the management device 200 generates an abstract syntax tree using the lexical analyzer 2011, the syntax analyzer 2012 and the intermediate processor 2013 in sequence, and outputs the C language configuration file to the electronic device 100b through the text configuration generator 2014. Subsequently, the electronic device 100b uses the driver implementation code to call the C language configuration file.
  • the configuration compiler selects the compilation parameter as "-t", that is, selects the text configuration generator 2014.
  • the drive configuration management method provided by the embodiment of the present application includes the following steps:
  • Steps 501 to 505 are the same as the descriptions of the steps described in conjunction with FIG. 5 in the foregoing embodiment, and are not repeated here.
  • step 505 it is judged that the C language configuration file needs to be output, that is, the compilation parameter is "-t", and the executed steps are replaced by steps 5081-5084 in FIG. 10 from step 508 shown in FIG. 5 .
  • step 505 is performed first and then step 507 , while the method shown in FIG. 10 is different in that step 507 is performed first and then step 505 is performed. Then, the judging process becomes that the management device 200 first judges whether the C language configuration file needs to be output, and then judges whether to output the binary configuration file.
  • Step 5081 The management device 200 outputs the abstract syntax tree generated by the intermediate processor 2013 to the C language configuration generator 2014.
  • the configuration source code is output by the configuration compiler 201 to the C language configuration file code
  • the C language configuration file code will participate in the compilation of the driver code.
  • the configuration part code corresponding to the C language configuration file is compiled by the C language compiler into the read-only data segment of the electronic device 100b (the data segment “.rodata section” shown in FIG. 9 ), and the content of the data segment can only be read It cannot be modified, which ensures the security of the configuration data in the C language configuration file.
  • the functional code (that is, the code other than the configuration code) will be stored in other data sections of the electronic device 100b (the data section “.text section” shown in FIG. 9 ),
  • the data segment may be a readable and writable data segment.
  • the driver implementation code can directly access the data address of the corresponding read-only storage data segment, and obtain the configuration content of the C language configuration file, eliminating the overhead of configuration analysis of the electronic device 100b (ie, the full-scale device), and realizing the device performance maximized effect.
  • the C language compiler involved in this embodiment of the present application is the above-mentioned text configuration generator 2014 .
  • the process of compiling the driver implementation code and the code in the C language configuration file by the text configuration generator uses the C language, and the text configuration generator is referred to as a C language compiler. Not limiting.
  • Step 5082 The management device 200 uses the C language configuration generator 2014 to output the configuration structure declaration.
  • the C language configuration generator 2014 traverses the abstract syntax tree, and the output configuration structure declaration can be struct HdfConfigSampleDevice0, struct HdfConfigSampleDevice1, and struct HdfConfigSampleDRoot in the above example.
  • Step 5083 The management device 200 uses the C language configuration generator 2014 to output the function declaration.
  • the C language configuration generator 2014 traverses the abstract syntax tree, and outputs the declaration of the configuration acquisition function, such as the "const struct HdfConfigSampleRoot*HdfGetSampleModuleConfigRoot(void)" function in the example, to the configuration header file.
  • Step 5084 The management device 200 uses the C language configuration generator 2014 to output the structure definition, that is, the configuration structure definition.
  • the C language configuration generator 2014 traverses the abstract syntax tree and outputs configuration variable definitions (ie, structure definitions), such as the "g_hdfConfigSampleModuleRoot" variable in the example, which stores the configuration information, and its structure is the same as that in the configuration source file. structure is consistent.
  • Step 5085 The management device 200 uses the C language configuration generator 2014 to output the function implementation, that is, the configuration interface function implementation.
  • the C language configuration generator 2014 traverses the abstract syntax tree and outputs the function implementation, such as the "HdfGetSampleModuleConfigRoot" function in the above example, its function is to obtain the address of the configuration data structure and output it to the C language configuration file. in the content file.
  • the drive configuration management method provided by the embodiment of the present application further includes the following steps:
  • Step 1101 When the driver is loaded, the electronic device 100b uses the driver implementation code to call the C language configuration file to obtain the address of the configuration data structure (ie, the configuration structure), such as the address of the read-only data section ".rodata section".
  • the configuration data structure ie, the configuration structure
  • the electronic device 100b calls the header file in the C language configuration file, declares the interface function in the header file, accesses the interface function in the content file (such as the "HdfGetSampleModuleConfigRoot” function in the above example), and then obtains the configuration through the interface function Data address, which is the address of the above read-only data section ".rodata section".
  • Step 1102 The electronic device 100b uses the driver implementation code to access the configuration data structure to read the configuration content.
  • the electronic device 100b reads out the code in the C language configuration file from the read-only data segment ".rodata section", that is, accesses the configuration content represented by the configuration structure in the content file.
  • Step 1103 The electronic device 100b initializes the hardware by using the configuration attribute through the driver implementation code.
  • the electronic device 100b reads the header file and the content file from the C language configuration file, thereby obtaining the configuration content (ie, configuration attributes) represented by the configuration structure in the content file, and obtains the device 0 as described above. Corresponding properties to initialize device 0.
  • Step 1104 The loading of the hardware driver of the electronic device 100b is completed.
  • the electronic device 100a has completed the driving of the front camera and the rear camera.
  • the driver configuration management method provided by this application can be used on a lightweight platform or a full-weight platform, and the performance and flexibility of interest in respective scenarios are realized in two ways of use, that is, to solve the problem that the lightweight platform is more concerned about Performance, full-scale platforms pay more attention to the difference in flexibility. Further, the problem of coupling between code and configuration is solved.
  • a specific process of the drive configuration management method provided by the embodiment of the present application may include the following steps 1021-1204:
  • Step 1201 The management device 200 determines target information, where the target information is used to characterize the computing capability of the electronic device (eg, the electronic device 100a or the electronic device 100b described above).
  • the target information is used to characterize the computing capability of the electronic device (eg, the electronic device 100a or the electronic device 100b described above).
  • the above-mentioned target information is information of the computing capability of the electronic device, or is a compilation parameter indicating the following target file format.
  • Step 1202 The management device 200 converts the configuration source file into a target configuration file in the target file format according to the target information.
  • the configuration source file in step 1202 corresponds to the electronic device indicated by the target information.
  • the management device 200 specifically generates a configuration file in C language format for the electronic device 100b (ie, a lightweight device), and generates a configuration file in a binary format for the electronic device 100a (ie, a full-weight device).
  • Step 1203 The management device 200 sends the target configuration file to the electronic device.
  • the management device 200 may establish a wireless communication connection or a wired communication connection with the electronic device, and then send the target file to the electronic device.
  • Step 1204 The electronic device configures and drives the hardware in the electronic device based on the acquired target configuration file.
  • steps 1021 to 1024 can refer to the corresponding implementation details in the above method embodiments, so that in the process of driving configuration management, the performance of the lightweight device can be guaranteed, and the full-scale device can also be realized. High flexibility of the device, complete hardware topology description capability.
  • the main body that executes the above method for driving configuration management may be referred to as a driving configuration management apparatus.
  • the above-mentioned drive configuration management apparatus may be divided into one or more modules, for example, each module may be divided corresponding to each function, or two or more functions may be integrated into one processing module.
  • the above-mentioned integrated modules may be implemented in the form of hardware or in the form of software modules. It should be noted that, the division of modules in the embodiments of the present application is schematic, and is only a logical function division, and there may be other division manners in actual implementation.
  • the above-mentioned drive configuration management device may be a device for executing the configuration in the management device.
  • a control module or device that drives the configuration management method may be a device for executing the configuration in the management device.
  • the above-mentioned drive configuration management apparatus may be used in the electronic device to perform drive configuration management A control module or apparatus for the method.
  • FIG. 13 shows a possible schematic structural diagram of the drive configuration management apparatus provided in the above-mentioned embodiment, where the drive configuration management apparatus is applied to management equipment.
  • the drive configuration management apparatus 1300 includes: a determination module 1301 for determining target information, which is used to represent the computing capability of the electronic device; a conversion module 1302 for determining the target information according to the determination module 1301, Convert the configuration source file into a target configuration file in a target file format; the sending module 1303 is configured to send the target configuration file converted by the conversion module 1302 to the electronic device.
  • FIG. 14 shows a possible schematic structural diagram of the drive configuration management apparatus provided in the above-mentioned embodiment, and the drive configuration management apparatus is applied to a management device for managing electronic devices that require configuration hardware.
  • the device 1400 for driving configuration management includes: an obtaining module 1401 for obtaining a target configuration file in a target file format, wherein the target file format corresponds to the computing capability of the electronic device; a configuration module 1402 for using Based on the target configuration file obtained by the obtaining module 1401, the hardware in the electronic device is configured and driven.
  • the drive configuration management apparatus 1300 shown in FIG. 13 corresponds to the drive configuration management method performed by the management device provided in this application, and the drive configuration management apparatus 1400 shown in FIG. Corresponding to the drive configuration management method, the technical details in the specific description of the method embodiments provided by the present application are still applicable to the drive configuration management apparatus shown in FIG. 13 and FIG. 14 . Repeat.
  • FIG. 15 shows a schematic structural diagram of an electronic device 100 (eg, electronic device 100a or electronic device 100b).
  • the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charge management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2 , mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, buttons 190, motor 191, indicator 192, camera 193, display screen 194, and Subscriber identification module (subscriber identification module, SIM) card interface 195 and so on.
  • SIM Subscriber identification module
  • the sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, and ambient light. Sensor 180L, bone conduction sensor 180M, etc.
  • the structures illustrated in the embodiments of the present application do not constitute a specific limitation on the electronic device 100 .
  • the electronic device 100 may include more or less components than shown, or combine some components, or separate some components, or arrange different components.
  • the illustrated components may be implemented in hardware, software, or a combination of software and hardware.
  • the processor 110 may include one or more processing units, wherein different processing units may be independent devices or may be integrated in one or more processors.
  • a memory may also be provided in the processor 110 for storing instructions and data.
  • the memory in processor 110 is cache memory. This memory may hold instructions or data that have just been used or recycled by the processor 110 . If the processor 110 needs to use the instruction or data again, it can be called directly from the memory. Repeated accesses are avoided and the latency of the processor 110 is reduced, thereby increasing the efficiency of the system.
  • the interface connection relationship between the modules illustrated in the embodiments of the present application is only a schematic illustration, and does not constitute a structural limitation of the electronic device 100 .
  • the electronic device 100 may also adopt different interface connection manners in the foregoing embodiments, or a combination of multiple interface connection manners.
  • the wireless communication function of the electronic device 100 may be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modulation and demodulation processor, the baseband processor, and the like.
  • the electronic device 100 may establish wireless communication with the management device 200 through a wireless communication function.
  • the wireless communication module 160 can provide applications on the electronic device 100 including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), bluetooth (BT), global navigation satellites Wireless communication solutions such as global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared technology (IR).
  • WLAN wireless local area networks
  • BT Bluetooth
  • GNSS global navigation satellite system
  • FM frequency modulation
  • NFC near field communication
  • IR infrared technology
  • the electronic device 100 implements a display function through the GPU, the display screen 194, and the application processor, etc., for example, displaying the driver management interface in the above example.
  • the GPU is a microprocessor for image processing, and is connected to the display screen 194 and the application processor.
  • the GPU is used to perform mathematical and geometric calculations for graphics rendering.
  • Processor 110 may include one or more GPUs that execute program instructions to generate or alter display information.
  • the electronic device 100 may implement a shooting function through an ISP, a camera 193, a video codec, a GPU, a display screen 194, an application processor, and the like.
  • the external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100 .
  • the external memory card communicates with the processor 110 through the external memory interface 120 to realize the data storage function. For example, files such as music, video, the aforementioned binary configuration files or C language configuration files are saved in an external memory card.
  • Internal memory 121 may be used to store computer executable program code, which includes instructions.
  • the processor 110 executes various functional applications and data processing of the electronic device 100 by executing the instructions stored in the internal memory 121, such as executing the above-mentioned process of calling the binary configuration file through the driver implementation code using the configuration parser 101, or realizing the process of calling the binary configuration file through the driver.
  • the implementation code uses the process of directly calling the C language configuration file.
  • the internal memory 121 may include a storage program area and a storage data area.
  • the storage program area can store an operating system, an application program required for at least one function (such as a sound playback function, an image playback function, etc.), and the like.
  • the hardware architecture of the management device (eg, the management device 200 ) provided in the embodiment of the present application can also be implemented by the hardware architecture of the electronic device 100 shown in FIG. 15 , which is not described in detail in the embodiment of the present application.
  • the processor 110 can support the management device 200 to generate a text configuration file such as a C language configuration file for a lightweight device (such as the electronic device 100b ), and for A full-scale device, such as electronic device 100a, generates a secondary configuration file.
  • the wireless communication function provided by the mobile communication module 150, the wireless communication module 160 and other modules can support the management device 200 to send the generated configuration file to the electronic device.
  • the GPU, the display screen 194, and the application processor and other modules are used to support the management device 200 to display the driver configuration management interface and interact with the user.
  • the software system of the electronic device 100 may adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture.
  • the embodiments of the present application take an Android system with a layered architecture as an example to exemplarily describe the software structure of the electronic device 100 .
  • FIG. 16 is a block diagram of a software structure of an electronic device (eg, an electronic device 100a or an electronic device 100b) according to an embodiment of the present application.
  • the layered architecture divides the software into several layers, and each layer has a clear role and division of labor. Layers communicate with each other through software interfaces.
  • the Android system is divided into four layers, which are, from top to bottom, an application layer, an application framework layer, an Android runtime (Android runtime) and a system library, and a kernel layer.
  • the application layer can include a series of application packages.
  • the application package can include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message and so on.
  • the application framework layer provides an application programming interface (application programming interface, API) and a programming framework for applications in the application layer.
  • the application framework layer includes some predefined functions.
  • the application framework layer may include window managers, content providers, view systems, telephony managers, resource managers, notification managers, and the like.
  • a window manager is used to manage window programs.
  • the window manager can get the size of the display screen, determine whether there is a status bar, lock the screen, take screenshots, etc.
  • Content providers are used to store and retrieve data and make these data accessible to applications.
  • the data may include video, images, audio, calls made and received, browsing history and bookmarks, a phone book, and the like.
  • the view system includes visual controls, such as controls for displaying text, controls for displaying pictures, and so on. View systems can be used to build applications.
  • a display interface can consist of one or more views.
  • the display interface including the short message notification icon may include a view for displaying text and a view for displaying pictures.
  • the phone manager is used to provide the communication function of the electronic device 100 .
  • the management of call status including connecting, hanging up, etc.).
  • the resource manager provides various resources for the application, such as localization strings, icons, pictures, layout files, video files and so on.
  • the notification manager enables applications to display notification information in the status bar, which can be used to convey notification-type messages, and can disappear automatically after a brief pause without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc.
  • the notification manager can also display notifications in the status bar at the top of the system in the form of graphs or scroll bar text, such as notifications of applications running in the background, and notifications on the screen in the form of dialog windows. For example, text information is prompted in the status bar, a prompt sound is issued, the electronic device vibrates, and the indicator light flashes.
  • Android Runtime includes core libraries and a virtual machine. Android runtime is responsible for scheduling and management of the Android system.
  • the core library consists of two parts: one is the function functions that the java language needs to call, and the other is the core library of Android.
  • the application layer and the application framework layer run in virtual machines.
  • the virtual machine executes the java files of the application layer and the application framework layer as binary files.
  • the virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, safety and exception management, and garbage collection.
  • a system library can include multiple functional modules. For example: surface manager (surface manager), media library (Media Libraries), 3D graphics processing library (eg: OpenGL ES), 2D graphics engine (eg: SGL), etc.
  • surface manager surface manager
  • media library Media Libraries
  • 3D graphics processing library eg: OpenGL ES
  • 2D graphics engine eg: SGL
  • the Surface Manager is used to manage the display subsystem and provides a fusion of 2D and 3D layers for multiple applications.
  • the media library supports playback and recording of a variety of commonly used audio and video formats, as well as still image files.
  • the media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.
  • the 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.
  • 2D graphics engine is a drawing engine for 2D drawing.
  • the kernel layer is the layer between hardware and software.
  • the kernel layer contains at least display drivers, camera drivers, audio drivers, and sensor drivers.
  • the above-mentioned driver that interacts with a binary configuration file or a C language configuration file (such as the above-mentioned interface function, that is, "HdfGetSampleModuleConfigRoot" in the example is used to obtain the configuration).
  • Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of these implementation methods.
  • Embodiments of the present application may be implemented as a computer program or program code executing on a programmable system including at least one processor, a storage system (including volatile and nonvolatile memory and/or storage elements) , at least one input device, and at least one output device.
  • Program code may be applied to input instructions to perform the functions described herein and to generate output information.
  • the output information can be applied to one or more output devices in a known manner.
  • a processing system includes any system having a processor such as, for example, a digital signal processor (DSP), microcontroller, application specific integrated circuit (ASIC), or microprocessor.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • the program code may be implemented in a high-level procedural language or an object-oriented programming language to communicate with the processing system.
  • the program code may also be implemented in assembly or machine language, if desired.
  • the mechanisms described in this application are not limited in scope to any particular programming language. In either case, the language may be a compiled language or an interpreted language.
  • the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof.
  • the disclosed embodiments can also be implemented as instructions carried by or stored on one or more transitory or non-transitory machine-readable (eg, computer-readable) storage media, which can be executed by one or more processors read and execute.
  • the instructions may be distributed over a network or over other computer-readable media.
  • a machine-readable medium can include any mechanism for storing or transmitting information in a form readable by a machine (eg, a computer), including, but not limited to, floppy disks, optical disks, optical disks, read only memories (CD-ROMs), magnetic Optical Disc, Read Only Memory (ROM), Random Access Memory (RAM), Erasable Programmable Read Only Memory (EPROM), Electrically Erasable Programmable Read Only Memory (EEPROM), Magnetic or Optical Cards, Flash Memory, or Tangible machine-readable storage for transmitting information (eg, carrier waves, infrared signal digital signals, etc.) using the Internet in electrical, optical, acoustic, or other forms of propagating signals.
  • machine-readable media includes any type of machine-readable media suitable for storing or transmitting electronic instructions or information in a form readable by a machine (eg, a computer).
  • each unit/module mentioned in each device embodiment of this application is a logical unit/module.
  • a logical unit/module may be a physical unit/module or a physical unit/module.
  • a part of a module can also be implemented by a combination of multiple physical units/modules.
  • the physical implementation of these logical units/modules is not the most important, and the combination of functions implemented by these logical units/modules is the solution to the problem of this application. The crux of the technical question raised.
  • the above-mentioned device embodiments of the present application do not introduce units/modules that are not closely related to solving the technical problems raised in the present application, which does not mean that the above-mentioned device embodiments do not exist. other units/modules.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

一种驱动配置管理方法、装置、介质及设备，应用于通信技术领域，能够在轻量级平台有限的硬件资源上实现驱动配置管理，并实现配置管理同时支持轻量级平台和全量级平台。具体地，该方法应用于管理设备（200），包括：确定目标信息，目标信息用于表征电子设备（100a，100b）的计算能力；根据目标信息，将配置源文件转换为采用目标文件格式的目标配置文件；向电子设备（100a，100b）发送目标配置文件。该方法具体应用于管理设备（200）针对不同计算能力的电子设备（100a，100b）生成并发送不同格式的配置文件的场景中。

Description

驱动配置管理方法、装置、介质、设备及系统
本申请要求于2020年08月29日提交国家知识产权局、申请号为202010890830.1、申请名称为“一种驱动配置管理方法、装置和系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。并且，本申请还要求于2021年01月27日提交国家知识产权局、申请号为202110112587.5、申请名称为“驱动配置管理方法、装置、介质、设备及系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域，特别涉及一种驱动配置管理方法、装置、介质、设备及系统。
背景技术
随着物联网(Internet of Things，IoT)智能设备的快速发展，IoT设备的形态不断丰富、操作系统层出不穷，这需求开发人员开发出适用于IoT设备的设备驱动程序(Driver，简称驱动程序或驱动)。
考虑成本和低功耗等因素，IoT设备采用的硬件平台往往只有很有限的硬件资源，如只读存储器(read-only memory，ROM)、随机存取存储器(Random Access Memory，RAM)、中央处理器(Central Processing Unit，CPU)等性能均非常有限。从而，当前IoT设备的驱动程序中与硬件相关的配置代码一般采用宏或者常量的方式直接编写在驱动实现代码中，如果要适配新的平台往往需要将驱动代码重新复制一份并修改其中的配置代码，这造成了代码架构的腐化，降低了代码的可维护性、可移植性，增加了代码复用的困难。因此，需求驱动实现代码中与硬件相关的配置代码和功能代码解耦，使驱动程序更专注于设备的业务功能，并且移植与配置管理更简单。
发明内容
本申请实施例提供了一种驱动配置管理方法、装置、介质、设备，能够在轻量级平台有限的硬件资源上实现驱动配置管理，并实现配置管理同时支持轻量级平台和全量级平台。
第一方面，本申请实施例提供了一种驱动配置管理方法，应用于管理设备，包括：确定目标信息，目标信息用于表征电子设备的计算能力；根据目标信息，将配置源文件转换为采用目标文件格式的目标配置文件；向电子设备发送目标配置文件。具体地，目标信息可以表征电子设备是轻量级设备还是全量级设备，如表征下文中的电子设备100b或电子设备100a。上述目标信息为电子设备的计算能力的信息，或者为指示下述目标文件格式的编译参数。例如，目标文件格式可以为下文中的C语言格式或二进制格式。其中，上述目标文件格式可以为符合电子设备的计算能力的文件格式，如此可以在驱动配置的过程中，保证轻量级设备的性能，还可以实现全量级设备的高灵活性、完整的硬件拓扑结构描述能力。
在上述第一方面的一种可能的实现中，在上述目标信息表征的计算能力为第一类计算能力的情况下，目标配置文件支持电子设备的驱动实现代码直接调用。具体地，第一类计算 能力表示轻量级设备的计算能力，说明当前电子设备为轻量级设备，那么选定的编译参数为与轻量级设备对应的编译参数，即确定的目标信息对应于轻量级设备。此时，采用目标文件格式的目标配置文件所占存储空间通常较小，方便电子设备中的驱动实现代码直接调用，可以保证电子设备(如轻量级设备)的性能的同时实现驱动配置。
在上述第一方面的一种可能的实现中，目标文件格式采用以下至少一项语言实现：C语言，C++语言，java语言。例如，目标文件格式为下文中的C语言格式，即采用的语言为C语言。
在上述第一方面的一种可能的实现中，上述向电子设备发送目标配置文件，包括：向电子设备中的只读存储区域输出目标配置文件。如此，可以保证目标配置文件的安全性而不能被轻易篡改。
在上述第一方面的一种可能的实现中，在根据目标信息，将配置源文件转换为采用目标文件格式的目标配置文件之后，上述方法还包括：基于目标配置文件，编译电子设备的驱动实现代码；向电子设备中的可读写存储区域输出驱动实现代码的文件。如此，使得驱动实现代码中的参数或者函数与目标配置文件对应，后续可以实现通过驱动实现代码直接调用目标配置文件。
在上述第一方面的一种可能的实现中，在目标信息表征的计算能力为第二类计算能力的情况下，目标文件格式为二进制格式。其中，第二类计算能力表示全量级设备的计算能力，说明当前电子设备为全量级设备，那么选定的编译参数为与全量级设备对应的编译参数，即确定的目标信息对应于全量级设备。
在上述第一方面的一种可能的实现中，上述目标配置文件由管理设备按照预定义字节码规则编译得到，并且目标配置文件支持电子设备按照预定义字节码规则解析后再由电子设备通过驱动实现代码调用。可以理解的是，字节码最大程度的保留了配置的拓扑结构，可以在解析的时候很方便的进行各种遍历操作，相比生成的C语言配置文件，对电子设备的RAM、ROM开销也会稍大，更加适用对性能没有极致要求的环境，即适用于全量级设备。
在上述第一方面的一种可能的实现中，上述电子设备的计算能力包括以下至少一项：电子设备中的处理器的时钟频率，电子主设备的随机存取存储器RAM的容量、电子设备的只读内存ROM的容量。例如，电子设备的RAM和ROM，可以为该电子设备中的处理器中的RAM和ROM。
在上述第一方面的一种可能的实现中，上述确定目标信息，包括：接收用户对目标控件的目标操作，目标控件用于触发从至少两个信息中选定一个信息，至少两个信息与至少两种文件格式一一对应；响应于目标操作，将目标控件选定的信息确定为目标信息。其中，目标控件可以为下文中编译参数选项411，例如编译参数选项411选定的“二进制配置”对应于二级制格式(即一种文件格式)，编译参数选项411选定的“C语言配置”对应于C语言格式(即一种文件格式)。
在上述第一方面的一种可能的实现中，上述根据目标信息，将配置源文件转换为采用目标文件格式的目标配置文件，包括：将配置源文件转化为多个语法单元序列；验证多个语法单元序列是否符合预定义语法规则(如用于检查多个语法单元序列中是否有语法错误)；在多个语法单元序列符合预定义语法规则的情况下，将多个语法单元序列转换为抽象语法树； 按照第一语法规则更新抽象语法树，第一语法规则至少包括重定义检查和引用展开处理；根据目标信息，将抽象语法树转换为采用目标文件格式的目标配置文件。其中，上述预定义语法、第一语法规则等可以为相关技术人员根据实际需求预先确定的，本申请实施例对此不做具体限定。
第二方面，本申请实施例提供了一种驱动配置管理方法，应用于电子设备，包括：获取采用目标文件格式的目标配置文件，其中，目标文件格式与电子设备的计算能力对应；基于目标配置文件，配置并驱动电子设备中的硬件。具体地，电子设备获取目标配置文件可以为从管理设备接收目标配置文件。
在上述第二方面的一种可能的实现中，上述基于目标配置文件，配置并驱动电子设备中的硬件，包括：在计算能力为第一类计算能力的情况下，通过驱动实现代码调用目标配置文件，以配置并驱动电子设备中的硬件。
在上述第一方面的一种可能的实现中，目标文件格式采用以下至少一种语言实现：C语言，C++语言，java语言。
在上述第二方面的一种可能的实现中，目标配置文件存储在电子设备中的只读存储区域中。
在上述第二方面的一种可能的实现中，上述方法还包括：获取电子设备的驱动实现代码，驱动实现代码是基于目标配置文件编译得到的，且驱动实现代码存储在电子设备中的可读写存储区域。
在上述第二方面的一种可能的实现中，上述基于目标配置文件，配置并驱动电子设备中的硬件，包括：在目标文件格式为二进制格式的情况下，按照预定义的字节码规则将目标配置文件解析为配置树，再通过电子设备的驱动实现代码调用配置树，以配置并驱动电子设备中的硬件。
在上述第二方面的一种可能的实现中，电子设备的计算能力包括以下至少一项：电子设备中的处理器的时钟频率，电子设备的随机存取存储器RAM的容量、电子设备的只读内存ROM的容量。
类似的，对第二方面中的描述可以参照第一方面中的相关描述，此处不再赘述。
第三方面，本申请实施例提供了驱动配置管理装置，可以应用于管理设备，包括：确定模块，用于确定目标信息，目标信息用于表征电子设备的计算能力；转换模块，用于根据确定模块确定的目标信息，将配置源文件转换为采用目标文件格式的目标配置文件；发送模块，用于向电子设备发送转换模块转换得到目标配置文件。
在上述第三方面的一种可能的实现中，在上述目标信息表征的计算能力为第一类计算能力的情况下，目标配置文件支持电子设备的驱动实现代码直接调用。
在上述第三方面的一种可能的实现中，目标文件格式采用以下至少一项语言实现：C语言，C++语言，java语言。
在上述第三方面的一种可能的实现中，上述发送模块，具体用于向电子设备中的只读存储区域输出目标配置文件。
在上述第三方面的一种可能的实现中，上述驱动配置管理装置还包括：编译模块，用于转换模块根据目标信息，将配置源文件转换为采用目标文件格式的目标配置文件之后，基 于目标配置文件，编译电子设备的驱动实现代码；上述发送模块，还用于向电子设备中的可读写存储区域输出驱动实现代码的文件。
在上述第三方面的一种可能的实现中，在目标信息表征的计算能力为第二类计算能力的情况下，目标文件格式为二进制格式。
在上述第三方面的一种可能的实现中，上述目标配置文件由管理设备按照预定义字节码规则编译得到，并且目标配置文件支持电子设备按照预定义字节码规则解析后再由电子设备通过驱动实现代码调用。
在上述第三方面的一种可能的实现中，上述电子设备的计算能力包括以下至少一项：电子设备中的处理器的时钟频率，电子主设备的随机存取存储器RAM的容量、电子设备的只读内存ROM的容量。
在上述第三方面的一种可能的实现中，上述确定目标信息，包括：接收用户对目标控件的目标操作，目标控件用于触发从至少两个信息中选定一个信息，至少两个信息与至少两种文件格式一一对应；响应于目标操作，将目标控件选定的信息确定为目标信息。
在上述第三方面的一种可能的实现中，上述转换模块，具体用于将配置源文件转化为多个语法单元序列；验证多个语法单元序列是否符合预定义语法规则；在多个语法单元序列符合预定义语法规则的情况下，将多个语法单元序列转换为抽象语法树；按照第一语法规则更新抽象语法树，第一语法规则至少包括重定义检查和引用展开处理；根据目标信息，将抽象语法树转换为采用目标文件格式的目标配置文件。
第四方面，本申请实施例提供了一种驱动配置管理装置，可以应用于电子设备，包括：获取模块，用于获取采用目标文件格式的目标配置文件，其中，目标文件格式与电子设备的计算能力对应；配置模块，用于基于获取模块获取的目标配置文件，配置并驱动电子设备中的硬件。
在上述第四方面的一种可能的实现中，上述基于目标配置文件，配置并驱动电子设备中的硬件，包括：在计算能力为第一类计算能力的情况下，通过驱动实现代码调用目标配置文件，以配置并驱动电子设备中的硬件。
在上述第一方面的一种可能的实现中，目标文件格式采用以下至少一种语言实现：C语言，C++语言，java语言。
在上述第四方面的一种可能的实现中，上述目标配置文件存储在电子设备中的只读存储区域中。
在上述第四方面的一种可能的实现中，上述获取模块，还用于获取电子设备的驱动实现代码，该驱动实现代码是基于目标配置文件编译得到的，且驱动实现代码存储在电子设备中的可读写存储区域。
在上述第四方面的一种可能的实现中，上述配置模块，具体用于在目标文件格式为二进制格式的情况下，按照预定义的字节码规则将目标配置文件解析为配置树，再通过电子设备的驱动实现代码调用配置树，以配置并驱动电子设备中的硬件。
在上述第四方面的一种可能的实现中，上述电子设备的计算能力包括以下至少一项：所述电子设备中的处理器的时钟频率，所述电子设备的随机存取存储器RAM的容量、所述电子设备的只读内存ROM的容量。
第五方面，本申请实施例提供了一种计算机可读介质，该计算机可读介质上存储有指令，所述指令在电子设备上执行时使所述电子设备执行上述第一方面及其任一种可能的实现方式中的驱动配置管理方法，或者第二方面及其任一种可能的实现方式中的驱动配置管理方法。
第六方面，本申请实施例提供了一种电子设备，包括：存储器，用于存储指令，以及处理器，用于执行所述指令以实现上述第一方面及其任一种可能的实现方式中的驱动配置管理方法(此时第六方面中的电子设备为本文中描述的管理设备)，或者第二方面及其任一种可能的实现方式中的驱动配置管理方法(此时第六方面中的电子设备为管理设备所管理的需求驱动配置的电子设备)。
附图说明
图1根据本申请的一些实施例，示出了一种驱动配置管理系统的结构示意图；
图2根据本申请的一些实施例，示出了一种驱动配置管理系统的结构示意图；
图3根据本申请的一些实施例，示出了一种二进制配置文件的代码示意图；
图4A根据本申请的一些实施例，示出了一种驱动配置界面的示意图；
图4B根据本申请的一些实施例，示出了一种驱动配置界面的示意图；
图4C根据本申请的一些实施例，示出了一种驱动配置界面的示意图；
图4D根据本申请的一些实施例，示出了一种驱动配置界面的示意图；
图4E根据本申请的一些实施例，示出了一种驱动配置界面的示意图；
图4F根据本申请的一些实施例，示出了一种驱动配置界面的示意图；
图4G根据本申请的一些实施例，示出了一种驱动配置界面的示意图；
图4H根据本申请的一些实施例，示出了一种驱动配置界面的示意图；
图4I根据本申请的一些实施例，示出了一种驱动配置界面的示意图；
图5根据本申请的一些实施例，示出了一种驱动配置管理方法的示意图；
图6根据本申请的一些实施例，示出了一种驱动配置管理系统的结构示意图；
图7根据本申请的一些实施例，示出了一种驱动配置管理方法的示意图；
图8根据本申请的一些实施例，示出了一种驱动配置管理方法的示意图；
图9根据本申请的一些实施例，示出了一种驱动配置管理系统的结构示意图；
图10根据本申请的一些实施例，示出了一种驱动配置管理方法的示意图；
图11根据本申请的一些实施例，示出了一种驱动配置管理方法的示意图；
图12根据本申请的一些实施例，示出了一种驱动配置管理方法的示意图；
图13根据本申请的一些实施例，示出了一种驱动配置管理装置的示意图；
图14根据本申请的一些实施例，示出了一种驱动配置管理装置的示意图；
图15根据本申请的一些实施例，示出了一种电子设备的结构示意图；
图16根据本申请的一些实施例，示出了一种电子设备的软件结构框图。
具体实施方式
本申请的说明性实施例包括但不限于一种驱动配置管理方法、装置、介质、设备。
本申请实施例提供的驱动配置管理方法，应用于对电子设备进行驱动配置管理的场景中。其中，电子设备可以通过操作系统调用驱动程序对硬件进行配置，并驱动这些硬件工作， 例如配置并驱动显卡、声卡、扫描仪、摄像头、调制解调器(Modem)等硬件工作。具体地，电子设备一般需求获取配置文件，并通过驱动程序使用该配置文件对相关的硬件进行配置，以驱动这些硬件工作。其中，本申请实施例涉及的电子设备可以包括轻量级设备或全量级设备，但不限于此。此外，上述操作系统可以包括但不限于Linux系统、安卓(Android)系统等。
需要说明的是，本申请实施例提供的轻量级设备，一般采用超低功耗、长待机、低成本的微处理器(如ARM Cortex-M系列微处理器)。该类处理器一般具有较低的时钟频率，较小的随机存取存储器(Random Access Memory，RAM)、较小容量的只读内存(Read Only Memory，ROM)。例如，RAM和ROM的容量一般为K到M级别，下文使用轻量级平台代指此类处理器平台。当然，本申请实施例所涉及的轻量级设备包括但不限于上述IoT设备、手环等设备。另外，上述轻量级环境指的是包括一个或多个轻量级设备以及与轻量级设备交互的管理设备的环境或系统，例如管理设备用于向这些轻量级设备下发与硬件配置相关的配置文件。
本申请实施例提供的全量级设备(或称重量级设备)，通常具有较大容量的电池，无需超低功耗，且为了保证用户体验需要具备较高性能。具体地，全量级设备一般会采用较高性能的微处理器(如ARM Cortex-A系列微处理器)，该类处理器一般拥有较大容量的RAM、ROM(一般G级别以上)，下文使用全量级平台代指此类处理器平台。当然，本申请实施例所涉及的全量级设备，包括但不限于上述手机或平板电脑。另外，上述轻量级环境指的是包括一个或多个全量级设备以及与全量级设备交互的管理设备的环境或系统，例如该管理设备可以用于向全量级设备下发与硬件配置相关的配置文件。
具体地，本申请的轻量级设备和全量级设备可以通过电子设备的计算能力衡量。在一些实施例中，电子设备的计算能力包括以下至少一项：电子设备中的处理器的时钟频率，处理器的RAM的容量、处理器的ROM的容量。可以理解的是，处理器的时钟频率越高、电子设备的RAM的容量越大、电子设备的ROM的容量越大，说明电子设备的计算能力越强，对应于上述全量级设备。而处理器的时钟频率越低、电子设备的RAM的容量越小、电子设备的ROM的容量越小，说明电子设备的计算能力越差，对应于上述轻量级设备。此外，电子设备的计算能力还可以通过电子设备中的处理器的型号表征，如通过ARM Cortex-M系列微处理器的型号表征轻量级设备，并通过ARM Cortex-A系列微处理器的型号表征全量级设备。
在一种可能的实现方式中，上述电子设备中的处理器和存储器(RAM或ROM)分别通过独立的模块实现，此时上述衡量电子设备的计算能力的RAM和ROM可以称为电子设备的RAM和ROM。
在另一种可能的实现方式中，在上述电子设备采用集成模块实现的情况下，如果电子设备中的处理器和存储器(RAM或ROM)采用集成模块集成在一块芯片或系统中，那么上述电子设备中的RAM和ROM也可以认为是该处理器的RAM和ROM。
适用于本申请的管理设备200可以为服务器、台式计算机、笔记本电脑等。可以理解，在一些实施例中，服务器可以是硬件服务器，也可以植入虚拟化环境中。例如，根据本申请的一些实施例，服务器可以是在包括一个或多个其他虚拟机的硬件服务器上执行的虚拟机，即云服务器。电子设备100a和电子设备100b可以与管理设备200通过各种有线连接方式进行通信，或者通过各种无线方式进行无线通信。
相关技术的一种方案中，可以通过设备树源码(Device Tree Source，DTS)实现电子设备的驱动管理。其中，DTS是Linux系统对设备硬件拓扑和硬件资源配置进行描述的配置管理框架。具体地，DTS在Linux系统中的典型应用为：DTS的文本源码在编译阶段被编译器编译为二进制格式的设备树二进制数据(Devicetree Blob，DTB)的文件，在Linux系统启动时电子设备通过引导程序(BootLoader)将DTB的文件的起始位置作为参数传递到内核，内核的各模块通过解析即可读取DTB文件中的配置内容。然而，DTB文件与解析DTB文件的代码需要占用电子设备中较多ROM和/或RAM开销，对于IoT设备等轻量级设备来说可能无法承载，从而导致DTS可能无法用于轻量级设备的驱动配置管理。
相关技术的另一种方案中，可以通过高级配置与电源接口(Advanced Configuration and Power Interface，ACPI)实现电子设备的驱动配置管理。其中，ACPI为一种配置管理框架，在X86体系中广泛使用。具体地，ACPI使用ACPI源语言(ACPI Source Language，ASL)描述硬件资源与控制方法，通过编译器将ASL文件编译为ACPI机器语言(ACPI Machine Language，AML)的二进制文件，在电子设备的系统启动时通过AML解释器加载AML的二进制文件，系统可以调用AML解析器接口解析配置或者执行控制接口代码。然而，ASL比DTB的配置语法更加复杂，对于开发人员来说学习成本更高，并且AML文件和AML解析器的内存(如ROM和/或RAM)开销较大，主要应用在X86体系结构的计算机平台，而不适用于轻量级设备。
如此，上述相关技术中的两种方案均不适用于轻量级设备，为了解决该问题，本申请实施例提供了一种驱动配置管理方法，可以在轻量级平台有限的硬件资源上实现驱动配置管理，并实现配置管理框架能同时支持轻量级平台和全量级平台。
具体地，本申请实施例提供一种驱动配置管理方法，定义了一套配置文件的配置描述语法，可以使用统一的配置描述语法针对性能或功耗要求不同的电子设备，分别生成符合性能和功耗要求的配置文件。例如，在轻量级环境中可以生成C语言格式的配置文件(下文简称为C语言配置文件，即该配置文件为C语言代码)，使得IoT设备、手环等轻量级设备的驱动程序通过直接调用C语言代码获取与硬件相关的配置，免除了轻量级设备对于配置文件的存储和解析开销，保证了轻量级设备的较大性能。在全量级环境中可以生成二进制格式的配置文件(下文简称为二进制配置文件)，使得手机、平板电脑等全量级设备中的驱动程序可以使用配置框架提供的配置解析接口获取与硬件相关的配置，而通过配置解析接口获取配置的模式具备完整的硬件描述能力。从而，上述驱动配置管理的过程，不仅保证了轻量级设备的性能，还实现了全量级设备的高灵活性、完整的硬件拓扑结构描述能力。
这样一来，本申请具有以下优点：首先，实现了驱动实现代码可移植、可维护性提升，实现了驱动业务与配置解耦(如驱动实现代码与配置文件解耦)，驱动实现代码移植或适应新平台只需要修改代码即可完成。其次，由于本申请生成不同文件格式的配置文件可以使用一套配置描述语法，因此提升了配置文件的配置源码的复用能力，一套代码可以同时支持多个平台(如下述轻量级平台和全量级平台)，不同平台的配置可以自适应。
下面将结合附图对本申请的实施例作进一步地详细描述。
参考图1，本申请的一些实施例提供了一种驱动配置管理系统10，该系统10包括电子设备100a、电子设备100b和管理设备200。具体地，管理设备200用于分别向电子设备100a 和电子设备100b发送符合接收设备的性能和功耗的配置文件。
在一些实施例中，电子设备100a可以为全量级设备，电子设备100b可以为轻量级设备，例如，图1仅以电子设备100a为手机，电子设备100b为手环、管理设备200以台式电脑为例示出。那么，根据本申请的一些实施例，管理设备200可以向电子设备100a发送符合全量级设备的性能和功耗的配置文件，如二进制配置文件；向电子设备100b发送符合轻量级设备的性能和功耗的配置文件，如C语言配置文件。此外，图1示出的系统10可以包括任意数量的电子设备，而不限于图1示出的一个轻量级设备(即电子设备100b)和一个全量级设备(即电子设备100a)。
可以理解的是，适用于本申请的管理设备200可以为服务器、台式计算机、笔记本电脑等。在一些实施例中，服务器可以是硬件服务器，也可以植入虚拟化环境中。例如，根据本申请的一些实施例，服务器可以是在包括一个或多个其他虚拟机的硬件服务器上执行的虚拟机，即云服务器。电子设备100a和电子设备100b可以与管理设备200通过各种有线连接方式进行通信，或者通过各种无线方式进行无线通信，本申请实施例对此不做具体限定。
根据本申请的一些实施例，驱动配置管理系统10中的管理设备200可以包括配置编译器201，用于使用统一的配置描述语法针对性能和功耗不同的电子设备生成不同格式的配置文件。可以理解的是，管理设备200可以基于电子设备的计算能力，选定编译参数(或称目标信息)，即选定电子设备的配置文件的目标文件格式。可以理解的是，电子设备的计算能力可以通过编译参数表征。具体地，驱动配置管理系统10的系统框架可以按照配置文件的编译和使用分为配置编译阶段和配置使用阶段。可以理解的是，配置编译阶段可以由管理设备200通过配置编译器根据设定的编译参数生成对应格式(或称文件格式)的配置文件，该编译参数与电子设备的性能和功耗相对应。另外，配置使用阶段可以由系统10中的电子设备100a和电子设备100b实现，具体由这些电子设备从管理设备200获取配置文件，并对硬件进行配置和驱动。
在一些实施例中，管理设备200可以自行确定电子设备的计算能力，进而选定编译参数。例如，管理设备200在与电子设备建立连接后，可以抓取电子设备的计算能力的信息，包括但不限于电子设备中的处理器的时钟频率，该处理器的RAM的容量、该处理器的ROM的容量，例如还可以为电子设备的电池容量或处理器型号等信息。此外，在管理设备200与电子设备建立连接后，电子设备还可以主动向管理设备上报自身的计算能力的信息。
作为一种示例，在管理设备200基于电子设备100b的计算能力选定编译参数时，可以确定该计算能力为第一类计算能力，而该第一类计算能力表示轻量级设备的计算能力，那么选定的编译参数为与轻量级设备对应的编译参数，该编译参数对应的文件格式为文本格式(即第一语言的格式)。类似的，在管理设备200基于电子设备100a的计算能力选定编译参数，如确定该计算能力为第二类计算能力，而该第二类计算能力表示全量级设备的计算能力，那么选定的编译参数为与全量级设备对应的编译参数，此时选定的编译参数对应的文件格式可以为二进制格式。
此外，在一些实施例中，管理设备200可以响应于用户的操作选定编译参数，即确定电子设备的计算能力，进而选定与编译参数对应的文件格式。此时，电子设备的计算能力是由用户判断得到的，进而用户可以手动在管理设备200提供的用户界面中选定表征电子设备 的计算能力的编译参数。本申请实施例以下，主要以用户的操作选定编译参数以选定生成最终的配置文件的文件格式。具体地是实现方式将在下文中描述，此处不在赘述。
更具体地，在一些示例性的实施例中，如图2所示，管理设备200包括配置编译器201，为用于将配置源文件的文本转换为需要的输出格式(如二进制格式或者C语言格式等)的工具。配置编译器201中包括词法分析器2011、语法分析器2012、中间处理器2013、文本配置生成器(如C语言配置生成器)2014和二进制配置生成器2015。具体地，在配置编译阶段，配置源文件依次经过词法分析器2011、语法分析器2012解析为抽象语法树之后，配置编译器201再通过中间处理器2013对抽象语法树中的语法进行展开后生成了最终抽象语法树。例如，在全量级环境下，配置编译器201使用二进制配置生成器2015将最终抽象语法树处理为二进制配置文件，并输出至电子设备100a。在轻量级环境下，配置编译器201使用文本配置生成器2014将上述最终抽象语法树处理为C语言配置文件，并输出至电子设备100b。
继续参照图2，电子设备100a中可以包括配置解析器101，该配置解析器101用于将二进制配置文件解析为配置树。在配置使用阶段，全量级环境下，电子设备100a的驱动实现代码通过配置解析器101的读取接口解析配置树的拓扑结构并读取配置树中的配置属性内容。另外，轻量级环境下，电子设备100b的驱动实现代码直接调用C语言配置文件中的函数接口与结构体定义获取与硬件相关的配置内容。
根据本申请的一些实施例，下面结合上述图2示出的管理设备200、电子设备100a和电子设备100b，对驱动配置管理系统10所涉及的配置编译阶段和配置使用阶段中的各个部分进行详细描述。
1、配置源文件：
配置源文件是按照配置描述语法组织的配置源码文件，配置描述语法是为了便于配置的管理而设计的一种Key-Value(即，键-值)为主体的文本格式。其中，配置源文件中的代码可以称为配置源码。具体地，配置源文件用于描述电子设备中的各个硬件的配置，例如，配置源文件用于描述电子设备中的前置摄像头是否开启以及开启哪些功能(或权限)，后置摄像头是否开启以及开启哪些功能，触控屏是否开启以及开启哪些功能等。
在一些实施例中，配置源文件具体用于描述一个或多个硬件的信息，如每个硬件的名称、寄存器基地址以及寄存器偏移值等信息。可以理解的是，电子设备中的某些硬件的寄存器用于特殊用途，电子设备访问某个硬件的寄存器会导致底层硬件执行某种对应的操作。例如，电子设备访问前置摄像头的寄存器以对前置设备头进行相应的配置和驱动。
作为一种示例，本申请实施例提供的配置源文件中的配置源码包括电子设备中的设备0的信息和设备1的信息，具体包括如下字段：
Figure PCTCN2021110860-appb-000001
Figure PCTCN2021110860-appb-000002
具体地，上述示例的配置源码中分别通过两个字段分别表示设备0和设备1。上述示例的配置源码中，每个符号“//”之前的内容为代码本身，符号“//”之后的内容为对该行代码的解释说明。
举例来说，“device0”用于表示设备0，例如，设备0可以是电子设备的前置摄像头。在代码段device0{}中，代码“deviceName＝"foo"；”用于描述设备0的名称为foo，"foo"的数据类型为字符；代码“regBase＝0xff00；”用于表示电子设备中设备0的寄存器基地址为0xff00，且0xff00的数据类型为十六进制的数值；代码“regOffset＝0x1；”用于表示设备0的寄存器偏移量为0x1，且0x1的数据类型为十六进制的数值。
另外，“device1”用于表示设备1，例如，设备1可以是电子设备中的后置摄像头。首先，代码“device1:device0”用于表示设备1的配置复制设备0的配置，例如设备1的寄存器基地址复制设备0的寄存器基地址，即设备1的寄存器基地址也为0xff00。其次，在代码段device1:device0{}中，代码“deviceName＝"bar"；”用于描述设备1的名称为bar，"bar"的数据类型为字符串；代码“regOffset＝0x2；”用于表示设备1的寄存器偏移量为0x2，且0x2的数据类型为十六进制的数值。
此外，上述示例的配置源码中示出的代码“module＝"sample"；”用于表示该配置源文件描述的模块或设备，例如，用于表示需求获取配置文件的上述电子设备100a或电子设备100b。
另外，以上述示例的配置源码为例，对配置描述语法所表述的Key-Value的文本格式进行说明。举例来说，代码“module＝"sample"；”，代码“deviceName＝"foo"；”，代码“regBase＝0xff00；”等均为Key-Value文本格式。其中，在代码“module＝"sample"；”中，module为Key，"sample"为Value；在代码“regBase＝0xff00；”中，regBase为Key，0xff00为Value。
2、对配置编译器201中的各个部件的相关描述：
(1)词法分析器2011：
词法分析器2011的作用是读取配置源文件中的字符串(或称文件描述符)，并将这些字符串转化成一个个语法单元序列，再将这些语法单元序列输出给语法分析器2012使用。例如，上述语法单元可以包括但不限于字符串、括号、关键字等数据类型。
作为一种示例，以上文示出的配置源码中的代码“module＝"sample"；”为例对词法分析器2011的工作过程进行说明。具体地，对于代码“module＝"sample"；”而言，词法分析器2011可以分析并输出如下4个语法单元组成的语法单元序列：
{type：文本，value：module}，{type：符号，value：＝}；
{type：字符串，value：sample}，{type：符号，value：；}。
可以理解的是，本申请实施例中，语法单元中的type表示字符串的数据类型，value表示字符串的取值。此外，本申请实施例中，可以将词法分析器2011输出的语法单元序列可以称为语法单元流，或Token流。
(2)语法分析器2012：
语法分析器(syntactic analysis，也称为parsing)2012用于对词法分析器2011输出的语法单元序列进行语法检查，验证这些语法单元序列是否符合预先定义的描述语法，并能够提示错误的位置和内容。同时，语法分析器2012还用于把语法单元序列转换成方便程序处理的抽象语法树(Abstract Syntax Tree，AST)，并将抽象语法树传递给配置编译器201的后续处理模块，进行下一步处理。其中，抽象语法树可以简称为语法树(Syntax tree)。
具体地，本申请实施例涉及的抽象语法树中至少包括节点名称、属性和属性值等信息。其中，节点、属性和属性值等对应于上述示例的配置源码中的不同内容。例如，不同的节点可以对应于上述示例的配置源码中的不同代码段，一组属性和属性值可以对应于配置源码中的各个代码段中的代码的一组Key-Value。
可以理解的是，抽象语法树是源代码(如配置源码)的抽象语法结构的树状表示，树上的每个节点都表示源代码中的一种结构。但是，抽象语法树并不会表示出真实语法出现的每一个细节，比如说，嵌套括号(即“{}”)被隐含在树的结构中，并没有以节点的形式呈现。
作为一种示例，针对上述示例中的配置源码，词法分析器2011和语法分析器2012生成的抽象语法树的内容的说明如下：
Figure PCTCN2021110860-appb-000003
参照上述示例的抽象语法树，对本申请提供的抽象语法树进行说明。例如，抽象语法树可以用“CONFNODE”表示节点，“CONFTERM”表示属性，“STRING”表示对应属性的属性值的数据类型为字符(或称字符串)，“|_”用于关联每个属性和对应的属性值；“UINT32”表示的数据类型为无符号32位整数，“UINT8”表示的数据类型为无符号8位整数。
可以理解的是，上述示例的抽象语法树中的两个节点(CONFNODE)之间的属性(CONFTERM)均为前一个节点中的属性。例如，上述“CONFNODE ForestRoot”为语法分析器2012构造出的虚拟根节点“ForestRoot”，“CONFNODE root”表示父节点“root”，对应于上述配置源文件中的代码段root{}，但是嵌套括号(“{}”)被隐含在树的结构中，而没有以节点的形式呈现。“CONFNODE device0”表示子节点“device0”，对应于上述配置源文件中的代码段device0{}。“CONFNODE device1NodeCopy device0”表示子节点“device1”，对应于上述配置源文件中的代码段“device1：device0{}”。
并且，上述示例的抽象语法树中的第4和5行的内容表示属性module，以及其属性值为字符串"sample"，这两行代码对应于上述配置源文件中的代码“module＝"sample"；”。再如，上述示例的抽象语法树中的第8和9行的内容表示属性regBase，以及其属性值为无符号32位整数的ff00，这两行代码对应于上述配置源文件中的代码“regBase＝0xff00；”。类似的，对于上述示例的抽象语法树中的其他属性的描述，可以参照属性module和属性regBase的描述，此处不再赘述。
(3)中间处理器2013：
中间处理器2013，用于负责对语法分析器2012中无法处理的语法进行处理，比如重定义检查、引用展开等处理。抽象语法树经过中间处理器2013的处理后就可以进行输出至后续的二进制配置生成器2015和文本配置生成器2014。
作为一种示例，针对上述语法分析器2012输出的抽象语法树，中间处理器2013进行了引用展开，并输出了如下所示的抽象语法树(记为最终抽象语法树)：
Figure PCTCN2021110860-appb-000004
具体地，中间处理器2013对上述语法分析器2012生成的抽象语法树中的代码“CONFNODE device1NodeCopy device0”进行引用展开处理生成的最终抽象语法树，使得抽象语法 树在节点“device1”中展开属性“regBase”，以及其数据类型为无符号32位整数属性值“ff00”。
(4)二进制配置生成器2015：
二进制配置生成器2015按照本申请实施例中自定义的字节码规则将抽象语法树的内容输出为二进制配置文件。在一些实施例中，本申请提供的字节码编码表如表一所示：
表一
Code Value Code Name Arguments Description
0x01 Config Node Node Name(String),Length(DWord)  
0x02 Config Term Term Name(String),Term Value  
0x03 NodeRef HashCode(DWord)  
0x04 Array Count(Word),Length(DWord),data  
0x10 Byte data(byte) 8-bit data prefix
0x11 WORD data(word) 16-bit data prefix
0x12 DWORD data(dword) 32-bit data prefix
0x13 QWORD data(qword) 64-bit data prefix
0x14 String ascii end of'\0' string data prefix
其中，在上述表1中，Code Value表示不同类型的代码所匹配的代码数值，Code Name表示代码名称，Arguments表示参数，Description是对代码的补充描述。可以理解的是，不同类型代码的代码名称、代码数值等信息均不同。
以下对上述表1中的各个部分进行具体说明：
1)代码名称“Config Node”表示节点，对应的代码数值为“0x01”，对应的参数包括数据类型为字符(String)的节点名称(Node Name)和数据类型为双字(Double Word，DWord)的节点长度(Length)，其中节点长度用于指示一个节点总共包含多少个字节，DWORD双字即为4个字节共32位。
2)代码名称“Config Term”表示属性，对应的代码数值为“0x02”，对应的参数包括数据类型为字符(String)的属性名称(Term Name)，以及属性值(Term Value)。
3)代码名称“NodeRef”表示节点配置，对应的代码数值为“0x03”，对应的参数包括数据类型为DWord的哈希码(HashCode)，用于对另一节点的引用，用于快速访问另一节点内容。
4)代码名称“Array”表示数组，对应的代码数值为“0x04”，对应的参数包括数据类型为字(Word)的数值(Count),和数据类型为双字(DWord)的数组长度(Length)，以及数组数据(data)。
5)代码名称“Byte”、“WORD”、“DWORD”、“QWORD”，分别表示字节、字、双字和四字，对应的代码数值分别为“0x10”、“0x11”、“0x12”和“0x13”，对应的参数分别为数据类型为字节(byte)、字(word)、双字(dword)和四字(qword)的数据(data)，对应的描述(Description)分别为8位(bit)的数据前缀(8-bit data prefix)、16bit的数据前缀(16-bit data prefix)、32bit的数据前缀(32-bit data prefix)以及64bit的数据前缀(64-bit data prefix)。
6)代码名称“String”表示字符串，对应的代码数值为“0x14”，对应的参数为以'\0'(即0x00)为结尾的ascii码(ascii end of'\0')，对应的描述为字符串数据亲前缀(string data prefix)。
可以理解的是，本申请实施例中，配置编译器201可以通过编译软件实现。在一些实施例中，编译软件可以提供用户界面(记为配置管理界面)，用于向用户展示配置编译器201对配置文件的编译过程，如显示配置源码、抽象语法树，抽象语法树的语法检查结果，以及最终配置文件的编译输出结果(如输出成功或者输出失败)。
作为一种示例，二进制配置生成器2015可以按照上述自定义的字节码规则，将中间处理器2013处理得到的抽象语法树生成如图3所示的二进制配置文件中的配置代码。另外，图3示出的内容不仅包括二进制配置文件中的配置代码，还包括对配置代码的各个字符如何排列显示的标记，以及各行字符的解释说明。其中，图3所示的二进制配置文件中的字符均为16进制的数值。
具体地，图3示出的内容中最左边1列的数字“1-11”用于表示配置编译器201所在的编译软件a中编译的代码的行数。第一行中的“0ffset”用于指示二进制配置文件中各个字符在图3示出编译软件a中显示的行序号和列序号，图3中第一行所示的“00 01 02 03 … 0E 0F”这16个列序号，图3中第一列所示的“000000000 000000010…000000090…”这些行序号。图3中示出的各个行的序号和列的序号用于方便相关技术人员定位并查询该二进制配置文件中的各个代码。具体地，图3示出的二进制配置文件包括“0A A0 0A A0…00 FF 00 00…”，排列顺序为从左到右从上到下的顺序，即沿着图3示出的列序号从小到大、行序号从小到大的顺序。例如，行序号为“00”和列序号“00000000”指示的字符“0A”为图3示出的二进制配置文件中的第一个字符。
可以理解的是，本申请提供的编译软件显示的行序号和列序号包括但不限于上述图3中的示例，例如，编译软件每行可以显示32个字符，即编译软件显示有32列序号。
另外，在一些实施例中，以图3所示的行序列为“00000000”和“00000010”中的全部字符以及行序列为“00000000”中的全部字符、行序列为“00000020”中列序号为“00-0D”的字符为例，对图3示出的二进制配置文件进行详细说明。具体地，结合表1，按照图3示中从左到右从上到下的顺序，对这些字符进行描述：“0A A0 0A A0”为魔数，用于校验文件类型，即用于检验当前的文件是否为符合表1示出的字节码编码规则等的二进制配置文件。“00 00 00 00”表示文件校验位，可以用于表示当前文件是否安全或规范。“40 00 00 00”表示编译器主版本号，如上述配置编译器201的主版本号。“00 00 00 00”用于表示编译器子版本号。“8c 00 00 00”表示文件大小，即140(字节)。“01”表示节点(Config Node)。“72 6f 6f 74 00”表示节点名称“root”，其中，“72”、“6f”、“6f”、“74”分别为“r”、“o”、“o”、“t”的ascii码，“00”为结束符。“82 00 00 00”表示“root”节点的大小，即130字节。“02”表示属性(Config Term)，即节点“root”中的属性。“6d 6f 64 75 6c 65 00”表示属性名称“module”，其中，“6d”、“6f”、“64”、“75”、“6c”、“65”分别为“m”、“o”、“d”、“u”、“l”、“e”的ascii码，“00”为结束符。“14”表示字符串(String)。“73 61 6d 70 6c 65 00”表示字符串内容“sample”，其中“73”、“61”、“6d”、“70”、“6c”、“65”分别为“s”、“a”、“m”、“p”、“l”、“e”的ascii码，“00”为结束符。
(5)文本配置生成器2014：
在一些实施例中，文本配置生成器2014用于基于C语言或C++语言生成文件较小且编译使用较为容易的语言(如面向底层的语言)实现。本申请实施例以下，仅以文本配置生成器2014为C语言配置生成器为例进行说明。
根据本申请的一些实施例，文本配置生成器2014，用于将抽象语法树中的内容生成C语言数据结构和函数组成的C语言配置文件，供电子设备中的驱动实现代码直接调用函数和访问变量获取与应将相关的配置。即C语言配置文件包括头文件和内容文件两部分。具体地，在一些实施例中，C语言配置文件主要包含以结构体存储的配置内容，以及为了获取配置生成的配置获取接口函数。
作为一种示例，针对上述示例的配置源文件和抽象语法树，文本配置生成器2014生成的C语言配置文件中的头文件的示例如下：
Figure PCTCN2021110860-appb-000005
需要说明的是，上述头文件中的“#ifndef”、“#define”以及“#endif”为宏定义的一种。条件指示符#ifndef用于检查预编译常量(即“HCS_CONFIG_SAMPLE_HEADER_H”)是否已经被宏定义。如果没有被宏定义,则条件指示符#ifndef的值为真，于是从#ifndef到#endif之间的所有语句都被包含进来进行编译处理。相反，如果条件指示符的值为假，则 #ifndef与#endif指示符之间的语句将被忽略。条件指示符#ifndef的最主要目的是防止头文件的重复包含和编译。
可以理解的是，上述头文件中包括：配置结构体的声明(或称为结构体声明)和配置获取函数声明(或称为函数声明)。例如，上述头文件中定义的配置结构体声明包括struct HdfConfigSampleDevice0、struct HdfConfigSampleDevice1和struct HdfConfigSampleDRoot。上述头文件中的配置获取函数声明可以为“const struct HdfConfigSampleRoot*HdfGetSampleModuleConfigRoot(void)”函数。
具体地，首先，C语言配置文件中的头文件用于声明参数和变量，例如在结构体struct HdfConfigSampleDevice0中，针对设备0声明了以下参数：数据类型为常量字符串(const char*)的设备名称“deviceName”，数据类型为16位的无符号整型(uint16_t)的寄存器基地址(regBase)，数据类型为8位的无符号整型(uint8_t)的寄存器基地址(regOffset)，分别对应于上述示例的配置源文件和抽象语法树中针对设备0的相应属性。类似的，本申请实施例这里，对上述结构体struct HdfConfigSampleDevice1中定义的参数的描述不再赘述。其次，在上述结构体struct HdfConfigSampleRoot中，定义了数据类型为常量字符串的“module”，并定义了对应设备0的“HdfConfigSampleDevice0device0”以及对应设备1的“struct HdfConfigSampleDevice1device1”。此外，上述头文件中还包括解释说明的内容“It's HDF config auto-gen file,do not modify it manually”，用于向相关技术人员说明此头文件为HDF配置自动生成文件，请勿手动修改。其中，HDF表示硬件驱动统一平台(Hardware Driver Foundation)。
作为一种示例，针对上述示例的配置源文件和抽象语法树，文本配置生成器2014的C语言配置文件中的内容文件的示例如下：
Figure PCTCN2021110860-appb-000006
Figure PCTCN2021110860-appb-000007
其中，上述示例的C语言配置文件中的内容文件中包括配置变量定义(或称结构体定义)和接口函数。例如，配置变量定义包括上述示例中的“g_hdfConfigSampleModuleRoot”变量，该变量保存了配置信息，其结构与配置源文件中的结构一致。上述接口函数可以为上述示例中的“HdfGetSampleModuleConfigRoot”函数，其作用是获取配置数据结构的地址，该地址可以为内容文件中的配置结构体(即配置内容)所在的地址。
具体地，上述示例的C语言配置文件中的内容文件，变量g_hdfConfigSampleModuleRoot”，定义了参数module的取值，设备0和设备1的各个参数的取值，分别对应于上述示例的配置源文件和抽象语法树中相应的属性值。例如，针对设备0，上述内容文件定义了设备名称“deviceName”为foo，寄存器偏移量“regOffset”为0x1，寄存器基地址“regBase”为0xff00。
3、对电子设备100a中的配置解析器101的相关描述：
配置解析器101，用于读取二进制配置文件中的数据并按照字节码的格式解析数据内容，从而重新构造出与配置源文件(即配置源码)结构一致的配置树。另外，配置解析器101还提供了一系列接口供驱动实现代码从二进制配置文件中查询、遍历、读取配置内容。可以理解的是，电子设备100a中预先设置有上述表1示出的字节码规则。
可以理解，电子设备100a中还包括驱动实现代码(或称为驱动实现)。具体地，在配置使用阶段，电子设备100a可以获取管理设备200通过配置编译器201中的二进制配置生成器2015输出的二进制配置文件。随后，电子设备100a可以通过驱动实现调用配置解析器101来加载二进制配置文件，以配置并驱动电子设备100a中的相关硬件，如电子设备100a中的前置摄像头和后置摄像头。
4、对电子设备100b的相关描述：
电子设备100a中包括驱动实现代码(简称为驱动实现)。具体地，在配置使用阶段，电子设备100b可以获取管理设备200通过配置编译器201中的文本配置生成器2014输出的C语言配置文件。随后，电子设备100a可以通过驱动实现直接调用C语言配置文件，以配置并驱动电子设备100a中的相关硬件，如电子设备100a中的前置摄像头和后置摄像头。
此外，在一些实施例中，作为一种示例，对于电子设备100a，二进制配置文件用于配置并驱动电子设备100a中的前置摄像头启动并开启该前置摄像头的常规拍照功能和美颜拍摄功能，以及配置并驱动后置摄像头启动并开启后置摄像头的常规拍照功能和全景拍摄功能等。而对于电子设备100b而言，C语言配置文件用于配置并驱动前置摄像头的常规拍照功能，配置并驱动后置摄像头的常规拍照功能。
作为另一种示例，对于电子设备100a，二进制配置文件用于配置并驱动电子设备100a中的触控屏的亮灭屏功能、点击触控功能、特定手势触控功能、指纹触控功能。对于电子设备100b，C语言配置文件用于配置并驱动电子设备100b中的触控屏的亮灭屏功能和点击触控功能。
在一些实施例中，在配置编译器201进行编译时，管理设备200通过命令行调用编译器程序，将输入文件路径、输出文件路径以及控制输出二进制配置文件与C语言配置的编译参数等编译选项通过参数传递给编译器。其中，输入文件路径表示配置源文件路径，输出文件路径表示配置编译器201的生成产物输出路径，如二进制配置文件的输出路径为配置编译器201至电子设备100a的路径，C语言配置文件的输出路径为配置编译器201至电子设备100b的路径。配置编译器201按照输入文件路径从文件系统或文件镜像中打开配置源文件，并传递给词法分析器2011，启动编译流程。配置源文件中的配置源码经过词法分析器2011和语法分析器2012处理后转换为抽象语法树，中间处理器2013在完成中间处理后通过编译参数判断调用哪个生成器，如二进制配置生成器2015或文本配置生成器2014。例如，编译参数为“-t”，表示配置编译器201使用文本配置生成器2014输出C语言配置文件；编译参数为“-b”，表示配置编译器201使用二进制配置生成器2015输出二进制配置文件，如果没有通过命令指定编译参数，则配置编译器201默认选择二进制配置生成器2015进行输出。
参照图4A所示，为配置编译器201所在的编译软件a的一种配置管理界面，该界面中包括功能区域41、功能区域42、代码显示区域43、编译结果显示区域44和列表区域45。
其中，功能区域41中包括“编辑(E)”选项和编译参数选项411，而“编辑(E)”选项用于支持用户在代码显示区域43中编辑代码，如图4A中的代码显示区域43示出的配置源码。编译参数选项411用于选择配置编译器201生成配置文件的格式，例如二进制配置和C语言配置等，但不限于此。可以理解的是，编译参数选项411选定图4A示出的“二进制配置”，说明编译参数为“-b”，表示配置编译器201编译过程中选择二进制配置生成器2015生成二进制配置文件。另外，参照图4B所示用户可以操作编译参数选项411，弹出选项“C语言配置”，并操作选项“C语言配置”，以控制编译参数选项411选定图4C示出的“C语言配置”，说明编译参数为“-t”，表示配置编译器201编译过程中选择文本配置生成器2014生成C语言配置文件。在一些实施例中，配置编译器201中的编译参数选项411默认选定“二进制配置”，即默认使用二进制配置生成器2015输出，此时用户可以不操作该编译参数选项411。
功能区域42中包括选项“编译”、选项“编译并输出”、选项“输入文件路径”以及选项“输出文件路径”等。其中，选项“编译”用于触发配置编译器201对配置源码进行编译以得到设定格式的配置文件。选项“编译并输出”，用于触发配置编译器201对配置源码进行编译以得到设定格式的配置文件，并将生成的配置文件输出至电子设备，如电子设备100a或电子设备100b。选项“输入路径”用于支持用户设定配置源文件路径。选项“输出文件路径”用于支持用户设定配置编译器201输出文件的路径。在另外一些实施例中，功能区域42中不包括选项“输入文件路径”以及选项“输出文件路径”，而是通过功能区域41中的选项“文件(F)”中的一些子选项来进行设置。
代码显示区域43用于显示配置源码、抽象语法树、以及后续编译出的二进制配置文件或C语言配置文件。
编译结果显示区域44用于显示配置源码、抽象语法树、以及后续编译出的二进制配置文件或C语言配置文件编译过程中是否存在错误、出现错误的位置和出现了什么错误，以及显示编译是否成功的编译结果。
列表区域45用于显示配置编译器201编译过程中产生的配置源码、抽象语法树、以及后续编译出的二进制配置文件或C语言配置文件等文件的列表。在一些实施例中，配置编译器201打开配置源文件之后，就可以如图4A在代码显示区域43显示配置源码，并在列表区域45中显示列表项“配置源码”。另外，随着配置编译器201的编译过程的进行，配置编译器201可以生成抽象语法树以及最终的配置文件中的代码。同时，配置编译器201可以在列表区域45中更新显示的内容包括以下至少一项：图4E中示出的与语法处理器2012生成的抽象语法树对应的列表项“语法抽象树1”，图4F中示出的与中间处理器2013生成的抽象语法树对应的列表项“语法抽象树2”，图4G示出的二进制配置生成器2015生成的二进制配置文件代码。或者，图4H示出的文本配置生成器2014生成的C语言配置文件代码中的头文件，以及图4I示出的文本配置生成器2014生成的C语言配置文件代码中的内容文件。
在一些实施例中，上述列表区域45中的各个列表项可以由用户操作，并触发代码显示区域43显示相应的代码。此外，列表区域45中的某个列表项被选中时，配置编译器201以特殊格式(如图4E示出的加粗显示格式)显示该列表项。
可以理解的是，本申请实施例中，对于管理设备200显示的编译软件a的一种配置管理界面中的各个选项或内容，用户可以通过鼠标或者触控屏进行操作，如包括但不限于点击操作。例如，上述图4A-4I中仅以鼠标的光标“箭头”为例，说明用户对各个选项或内容的操作。
在本申请的一些实施例中，在上述编译参数选项411选定“二进制配置”，且选项“编译”、选项“编译并输出”被用户操作的情况下，配置编译器201可以依次显示图4D-4G所示的内容。可以理解的是，在上述编译参数选项411默认选定“C语言配置”，且选项“编译”、选项“编译并输出”被用户操作的情况下，配置编译器201依次显示的内容与图4D-4G所示的内容类似，此处不再赘述。
此外，在一些实施例中，以上述配置源文件的配置源码中的一行代码出现错误为例，对语法分析器2012提示错误的位置和内容进行说明。作为一种示例，结合上文中示例出的配置源码，假设该配置源文件中的代码“module＝"sample"；”替换为“module＝"sample"；；”，那么如图4D所示，管理设备200将该配置源码输入到语法分析器2012，语法分析器2012将输出该行代码出现错误，错误为出现重复的标号“；”。具体地，图4D示出的界面中的代码“module＝"sample"；；”以特殊格式(如下划线显示格式)显示，并在编译结果显示区域显示有“错误提示：位置：第2行，错误内容：；；重复”。随后，用户可以对配置源文件中的内容进行修正，如图4A所示的配置管理界面上显示有修正后的配置源码。
驱动配置管理方法的具体实现：
根据本申请的一些实施例，根据上述示例的管理设备200中的各个部件以及电子设备100a和电子设备100b，对驱动配置管理方法的具体实现进行描述。
在一种具体地实施例中，基于图3示出的驱动配置管理系统10，图5示出了本申请实施例中提供的一种驱动配置管理方法的流程示意图。其中，虽然在方法流程图中示出了本申请实施例提供的驱动配置管理方法的逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。例如，图5中示出的驱动配置管理方法应用于配置编译阶段，包括步骤501-506。
步骤501：配置编译开始，管理设备200使用配置编译器201打开配置源文件中的配置源码，得到配置源文件的文件描述符，并将这些文件描述符输入至词法分析器2011。
可以理解的是，管理设备200将配置源文件中的配置源码输入至配置编译器201。另外，配置源码的文件描述符可以为配置源码中的字符串。此时，管理设备200可以显示如图4A所示的包括配置源码的配置管理界面。
步骤502：管理设备200使用词法分析器2012将配置源文件处理为语法单元流(即语法单元序列，或Token流)，并将语法单元流输出至语法分析器2012。
步骤503：管理设备200使用配置编译器201的语法分析器2012对语法单元流进行语法检查，将语法单元流中的语法单元转化为抽象语法树，并将该抽象语法树输出至中间处理器2013。
在一些实施例中，上述步骤503中管理设备200对语法单元流进行语法检查，可以得到语法单元流中是否存在错误。如果语法单元流中存在错误，管理设备200可以控制配置编译器201通过配置管理界面向用户提示错误的位置和内容。随后，用户可以根据提示手动修正错误。如果语法单元流中不存在错误，或者用户已经修正错误，那么管理设备200可以控制配置编译器201将语法单元流转化为抽象语法树，并将该抽象语法树输出至中间处理器2013。可以理解的是，语法单元流存在错误，可以表示配置源码中存在错误，例如管理设备200提示错误的位置和内容的示例可以参照图4B所示的内容，进而修正后的配置源码可以参照图4A所示的内容。以及，管理设备200使用语法处理器2012生成的语法抽象树可以参照图4E所示的内容。
步骤504：管理设备200使用中间处理器2013对语法分析器2012输出的抽象语法树进行处理得到处理后的抽象语法树，并读取编译参数，选择生成器，即选择二进制配置生成器2015或文本配置生成器2014。
其中，中间处理器2013对抽象语法树的处理包括但不限于上述示例中的重定义检查和引用展开等。可以理解的是，中间处理器2013处理得到的抽象语法树，修改了重定义的错误，或者实现了语句的引用展开。例如，管理设备200使用语法处理器2012生成的语法抽象树可以参照图4F所示的内容。
可以理解的是，管理设备200使用配置编译器201读取编译参数为“-b”还是“-t”。具体地，参照上述图4A和图4C所示，管理设备200可以判断配置编译器201中的编译参数选项411选定为“二进制配置”还是“C语言配置”，以选择对应的生成器。
步骤505：管理设备200判断是否需要输出二进制配置文件。
如果判断得到需要输出二进制配置文件，即编译参数选定为“二进制配置”(即“-b”)，则执行下述步骤506，并结束编译流程；如果判断得到不需要输出二进制配置文件，则执行下述步骤507。此外，如果步骤505和步骤507的判断过程发生错误，则结束编译过程。
步骤506：管理设备200使用二进制配置生成器2015，将中间处理器2013生成的抽象语法树输出为二进制配置文件。此时，配置编译器201处于二进制配置生成模式，并且管理设备200可以显示参照上述图4G所示的内容。此外，管理设备200可以将生成的二进制配置文件输出至电子设备100a(即全量级设备)。
步骤507：管理设备200判断是否输出C语言配置文件。
如果判断得到需要输出C语言配置文件，即编译参数选定为“C语言配置”(即“-t”)，则执行下述步骤508；如果判断过程发生错误，则结束编译流程。
步骤508：管理设备200使用文本配置生成器2014，将中间处理器2013生成的抽象语法树输出为C语言配置文件。此时，配置编译器201处于C语言配置生成模式。并且，管理设备200可以显示参照上述图4H和图4I所示的内容。此外，管理设备200可以将生成的二进制配置文件输出至电子设备100b(即轻量级设备)。
二进制配置生成模式下驱动配置管理方法的具体实现：
根据本申请的一些实施例，结合图3示出的驱动配置管理系统10，如图6所示，驱动配置管理系统10在全量级环境中的应用流程示意图。图6中，简略示出了配置源码中包括的配置节点以及其中的各个配置属性，具体参照上述图4A示出的配置源码。进而，管理设备200依次使用词法分析器2011、语法分析器2012和中间处理器2013生成抽象语法树，并通过二进制配置生成器2015向电子设备100a输出二进制配置文件。随后，电子设备100a使用驱动实现调用配置解析器101加载该二进制配置文件。
进一步的，基于图6示出的驱动配置管理系统10的应用流程，结合图5所示的方法，在配置编译阶段配置编译器选定编译参数为“-b”,即选择二进制配置生成器2015生成二进制配置文件的场景中，如图7所示，本申请实施例提供的驱动配置管理方法包括如下步骤：
步骤501-步骤505，与上述实施例中结合图5的描述的各步骤相同，此处不再赘述。
在图7示出的方法中，在步骤505判断得到需要输出二进制配置文件，即编译参数为“-b”时，执行的步骤由图5示出的步骤506替换为步骤5061-5064。
步骤5061：管理设备200将中间处理器2013生成的抽象语法树，输出至二进制配置生成器2015。
步骤5062：管理设备200使用二进制配置生成器2015遍历抽象语法树。
可以理解的是，在一些实施例中，抽象语法树是兄弟孩子表示法构造的树形结构，二进制配置生成器2015遍历抽象语法树的方式包括但不限于深度遍历、反向深度遍历。其中，深度遍历是对于每一个子树(包括本身)以先孩子节点后孩子节点的兄弟节点的顺序进行的遍历。例如，对于上述示例的间处理器2013输出的抽象语法树而言，遍历的顺序为root、module、sample、device0、deviceName、foo…。此外，树的反向深度遍历是对于每一个子树(包括本身)，以先孩子节点的兄弟节点、后孩子节点的顺序进行遍历。例如，对于上述示例的间处理器2013输出的抽象语法树而言，遍历的顺序为sample、module、foo、deviceName、device0…root。
以上只是示例性说明，本申请不限于此，其他的方式遍历也涵盖在本申请意欲保护的范围之内。
步骤5063：管理设备200使用二进制配置生成器2015输出配置节点数据。
步骤5064：管理设备200使用二进制配置生成器2015输出配置属性数据。
可以理解的是，二进制配置生成器2015遍历中间处理器2013传递的抽象语法树，按照前文介绍的字节码编码表对配置内容输出为二进制配置文件，包括上述配置节点数据和配置属性数据。此外，该配置节点数据和配置属性数据可以参照上述图4G示出的内容以及上述示例的内容，此处不再赘述。
具体地，二进制配置文件在输出时保留了配置源文件中的拓扑信息，即保存了节点与节点之间的关系，如节点父子关系、兄弟关系等，这在配置使用时用于描述配置之间的关系。
也就是说，本申请在全量级环境中应用时，配置源码经过配置编译器输出字节码格式的二进制配置文件，字节码最大程度的保留了配置的拓扑结构，可以在解析的时候很方便的进行各种遍历操作，相比生成的C语言配置文件，对电子设备的RAM、ROM开销(即处理时间、功耗及占用存储空间等)也会稍大，更加适用对性能没有极致要求的环境。
此外，图7示出的方法还包括步骤507和步骤508，与上述实施例中结合图5的描述的各步骤相同，此处不再赘述。
相应的，在图6示出的全量级环境中，结合图7所述的方法，在配置使用阶段，如图8所示，本申请实施例提供的驱动配置管理方法还包括如下步骤：
步骤801：在驱动加载时，电子设备100a启动配置解析器101。
步骤802：电子设备100a使用配置解析器101读取与配置源码对应的二进制配置文件。
可以理解的是，在配置编译器201生成二进制配置文件后，电子设备100a可以通过文件系统或者直接打包进镜像的方式添加二进制配置文件到电子设备100a的系统镜像，驱动实现代码需要使用配置的时候首先通过配置解析器101加载二进制的配置文件，即把二进制的存储格式转换为内存中的配置树(详见下述步骤803-806)，便于查询和遍历。配置解析器101提供了遍历和读取接口供驱动使用，电子设备100a的驱动实现代码根据自身需要使用配置解析接口获取配置内容。
步骤803：电子设备100a使用配置解析器101检验二进制配置文件合法性。
例如，电子设备100a可以查看二进制配置文件的后缀，或者检验二进制配置文件中的魔数是否为预定义的数值(如上述示例中的“0A A0 0A A0”)，来检验二进制配置文件合法性。其中，如果后缀为预定义后缀，或者魔数是否为预定义的数值，则合法，反之，则不合法。
在检测到二进制配置文件合法的情况下，继续执行下述步骤804，否则结束配置使用流程。
步骤804：电子设备100a使用配置解析器101根据字节码规则解析二进制配置文件。具体地，根据字节码解析二进制配置文件的过程可以参照上述表1相关的示例中的描述，此处不再赘述。
步骤805：电子设备100a使用配置解析器101判断对二进制配置文件解析是否成功。
如果解析成功，则执行下述步骤806，否则结束配置使用流程。可以理解的是，解析成功说明二进制配置文件中的字符是符合上述字节码规则的，并且所有字符均解析完毕。
步骤806：电子设备100a使用配置解析器101构造出与二进制配置文件的配置树。
步骤807：电子设备100a使用驱动实现代码遍历配置树。
具体地，电子设备100a可以先确定出在配置数中需求获取信息的硬件，进而针对需求的硬件在遍历配置树。例如，电子设备100a需求获取设备0(如前置摄像头)的信息，那么电子设备100a可以针对设备0，在配置树中遍历查找到确定节点“device 0”。
步骤808：电子设备100a使用驱动实现代码解析需要的配置属性值。
例如，电子设备100a可以针对设备0，在配置树中遍历查找到确定与节点“device 0” 对应的属性和属性值。
步骤809：电子设备100a通过驱动实现代码使用配置属性初始化硬件。
例如，电子设备100a在获取到设备0的属性和属性值等信息之后，可以对设备0进行初始化硬件的操作。
步骤810：电子设备100a的硬件驱动加载完成。例如，电子设备100a完成了对前置摄像头和后置摄像头的驱动。
C语言配置生成模式：
根据本申请的一些实施例，结合图3示出的驱动配置管理系统10，如图9所示，驱动配置管理系统10在轻量级环境中的应用流程示意图。图9中，简略示出了配置源码中包括的配置节点以及其中的各个配置属性，具体参照上述图4A示出的配置源码。进而，管理设备200依次使用词法分析器2011、语法分析器2012和中间处理器2013生成抽象语法树，并通过文本配置生成器2014向电子设备100b输出C语言配置文件。随后，电子设备100b使用驱动实现代码调用该C语言配置文件。
进一步的，基于图9示出的驱动配置管理系统10的应用流程，结合图5所示的方法，在配置编译阶段配置编译器选定编译参数为“-t”,即选择文本配置生成器2014生成C语言配置文件的场景中，如图10所示，本申请实施例提供的驱动配置管理方法包括如下步骤：
步骤501-步骤505，与上述实施例中结合图5的描述的各步骤的描述相同，此处不再赘述。
在步骤505判断得到需要输出C语言配置文件，即编译参数为“-t”，执行的步骤由图5示出的步骤508替换为图10中的步骤5081-5084。此外，图5中是先执行步骤505再步骤507，而图10示出的方法的不同之处是先执行步骤507再执行步骤505。那么判断过程变为管理设备200先判断是否需要输出C语言配置文件，之后再判断是否输出二进制配置文件。
步骤5081：管理设备200将中间处理器2013生成的抽象语法树，输出至C语言配置生成器2014。
可以理解的是，本申请在轻量级环境中应用时，配置源码经过配置编译器201输出C语言配置文件代码之后，该C语言配置文件代码将参与驱动代码编译。并且，C语言配置文件对应的配置部分代码被C语言编译器编译到电子设备100b的只读数据段(如图9示出的数据段“.rodata section”)，该数据段内容只可读取不可修改，保证了C语言配置文件中的配置数据的安全性。此外，驱动实现代码在编译完成之后，功能性的代码(即除了配置代码之外的代码)将存储在电子设备100b的其他数据段(如图9示出的数据段“.text section”)，该数据段可以为可读写的数据段。如此，驱动实现代码可以直接访问对应的只读存储数据段的数据地址，并获取C语言配置文件的配置内容，消除了电子设备100b(即全量级设备)配置解析的开销，实现了设备性能最大化的效果。
可以理解的是，本申请实施例涉及的C语言编译器就是上述文本配置生成器2014。本申请实施例这里，仅为了清楚说明文本配置生成器编译驱动实现代码和C语言配置文件中的代码的过程使用的是C语言，而将文本配置生成器称为C语言编译器，对其本质不造成限定。
步骤5082：管理设备200使用C语言配置生成器2014输出配置结构体声明。
可以理解的是，C语言配置生成器2014遍历抽象语法树，输出的配置结构体声明可以 为上述实例中的struct HdfConfigSampleDevice0、struct HdfConfigSampleDevice1、struct HdfConfigSampleDRoot。
步骤5083：管理设备200使用C语言配置生成器2014输出函数声明。
可以理解的是，C语言配置生成器2014遍历抽象语法树，输出配置获取函数的声明如示例中的“const struct HdfConfigSampleRoot*HdfGetSampleModuleConfigRoot(void)”函数到配置头文件。
步骤5084：管理设备200使用C语言配置生成器2014输出结构体定义，即配置结构体定义。
可以理解的是，C语言配置生成器2014遍历抽象语法树，输出配置变量定义(即结构体定义)，如示例中的“g_hdfConfigSampleModuleRoot”变量，该变量保存了配置信息，其结构与配置源文件中的结构一致。
步骤5085：管理设备200使用C语言配置生成器2014输出函数实现，即配置接口函数实现。
可以理解的是，C语言配置生成器2014遍历抽象语法树，输出函数实现，如上述如示例中的“HdfGetSampleModuleConfigRoot”函数，其作用是获取配置数据结构的地址，并将其输出到C语言配置文件的内容文件中。
相应的，在图9示出的轻量级环境中，结合图10所述的方法，在配置使用阶段，如图11所示，本申请实施例提供的驱动配置管理方法还包括如下步骤：
步骤1101：在驱动加载时，电子设备100b使用驱动实现代码调用C语言配置文件获取配置数据结构(即配置结构体)地址，例如上述只读数据段“.rodata section”的地址。
具体地，电子设备100b调用C语言配置文件中的头文件，通过头文件中的接口函数声明，访问内容文件中的接口函数(如上述示例的“HdfGetSampleModuleConfigRoot”函数)，进而通过该接口函数获取配置数据地址，该地址为上述只读数据段“.rodata section”的地址。
步骤1102：电子设备100b使用驱动实现代码访问配置数据结构读取配置内容。
可以理解的是，电子设备100b从只读数据段“.rodata section”中读取出C语言配置文件中的代码，即访问内容文件中的配置结构体表示的配置内容。
步骤1103：电子设备100b通过驱动实现代码使用配置属性初始化硬件。
可以理解的是，电子设备100b从C语言配置文件中读取了头文件和内容文件，从而获取的了内容文件中的配置结构体表示的配置内容(即配置属性)，如上述获取得到设备0对应的各个属性以初始化设备0。
步骤1104：电子设备100b的硬件驱动加载完成。例如，电子设备100a完成了对前置摄像头和后置摄像头的驱动。
如此，本申请提供的驱动配置管理方法可以在轻量级平台使用也可以在全量级平台使用，用两种使用方式实现了各自场景下关注的性能和灵活性，即解决轻量化平台更关注性能、全量平台更关注灵活性的差异。进一步的，解决了代码与配置耦合的问题。
如图12所示，为本申请实施例提供的驱动配置管理方法的一种具体流程，例如该方法可以包括下述步骤1021-步骤1204：
步骤1201：管理设备200确定目标信息，该目标信息用于表征电子设备(如上述电子设备100a或电子设备100b)的计算能力。
在一种实施例中，上述目标信息为电子设备的计算能力的信息，或者为指示下述目标文件格式的编译参数。
步骤1202：管理设备200根据目标信息，将配置源文件转换为采用目标文件格式的目标配置文件。
可以理解的是，步骤1202中的配置源文件对应于目标信息所指示的电子设备。管理设备200具体针对电子设备100b(即轻量级设备)生成C语言格式的配置文件，针对电子设备100a(即全量级设备)生成二进制格式的配置文件。
步骤1203：管理设备200向电子设备发送目标配置文件。
例如，管理设备200可以与电子设备建立无线通信连接或有线通信连接，进而向电子设备发送目标文件。
步骤1204：电子设备基于获取的目标配置文件，配置并驱动电子设备中的硬件。
具体地，步骤电子设备调用目标配置文件配置的方式，可以参照上述实施例中电子设备100a和电子设备100b调用配置文件的方式，此处不再赘述。
此外，步骤1021-步骤1024的具体实施的其他细节均可以参照上述方法实施例中对应的实施细节，从而在驱动配置管理的过程中，可以保证轻量级设备的性能，还可以实现全量级设备的高灵活性、完整的硬件拓扑结构描述能力。
本申请实施例中执行上述驱动配置管理方法的主体可以称为驱动配置管理装置。具体地，上述驱动配置管理装置可以划分为一个或多个模块，例如，可以对应各个功能划分各个模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
可以理解的是，在本申请实施例提供的驱动配置管理方法，应用于管理一个或多个需求配置硬件的电子设备的管理设备时，上述驱动配置管理装置可以为该管理设备中的用于执行驱动配置管理方法的控制模块或装置。
在本申请实施例提供的驱动配置管理方法，应用于需求配置硬件的电子设备(如电子设备100a或电子设备100b)时，上述驱动配置管理装置可以为该电子设备中的用于执行驱动配置管理方法的控制模块或装置。
图13示出了上述实施例中所提供的驱动配置管理装置的一种可能的结构示意图，该驱动配置管理装置应用于管理设备。如图13所示，驱动配置管理装置1300，包括：确定模块1301，用于确定目标信息，目标信息用于表征电子设备的计算能力；转换模块1302，用于根据确定模块1301确定的目标信息，将配置源文件转换为采用目标文件格式的目标配置文件；发送模块1303，用于向上述电子设备发送转换模块1302转换得到目标配置文件。
图14示出了上述实施例中所提供的驱动配置管理装置的一种可能的结构示意图，该驱动配置管理装置应用于管理需求配置硬件的电子设备的管理设备。如图14所示，驱动配置管理装置1400，包括：获取模块1401，用于获取采用目标文件格式的目标配置文件，其中，该目标文件格式与该电子设备的计算能力对应；配置模块1402，用于基于获取模块1401获 取的目标配置文件，配置并驱动该电子设备中的硬件。
可以理解的是，图13所示的驱动配置管理装置1300与本申请提供的管理设备执行的驱动配置管理方法相对应，图14所示的驱动配置管理装置1400与本申请提供的电子设备执行的驱动配置管理方法相对应，以上关于本申请提供的方法实施例中的具体描述中的技术细节依然适用于图13和图14所示的驱动配置管理装置，具体描述请参见上文，在此不再赘述。
图15示出了电子设备100(如电子设备100a或电子设备100b)的结构示意图。电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。
可以理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
处理器110可以包括一个或多个处理单元，其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
可以理解的是，本申请实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备100的结构限定。在本申请另一些实施例中，电子设备100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。
电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。例如，电子设备100可以通过无线通信功能与管理设备200建立无线通信。
无线通信模块160可以提供应用在电子设备100上的包括无线局域网(wireless local area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。
电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能，例如显示上述示例中的驱动管理界面。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU 用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。
电子设备100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。
外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频，上述二进制配置文件或C语言配置文件等文件保存在外部存储卡中。
内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种功能应用以及数据处理，如执行上述通过驱动实现代码使用配置解析器101调用二进制配置文件的流程，或者实现通过驱动实现代码使用直接调用C语言配置文件的流程。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。
此外，本申请实施例提供的管理设备(如管理设备200)的硬件架构也可以通过图15示出电子设备100的硬件结构实现，本申请实施例对此不再赘述。
具体地，在管理设备200基于图15示出硬件结构实现的情况下，处理器110可以支持管理设备200针对轻量级设备(如电子设备100b)生成C语言配置文件等文本配置文件，并针对全量级设备(如电子设备100a)生成二级制配置文件。移动通信模块150，无线通信模块160等模块提供的无线通信功能可以支持管理设备200向电子设备发送生成的配置文件。GPU，显示屏194，以及应用处理器等模块，用于支持管理设备200显示驱动配置管理界面与用户交互。
电子设备100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明电子设备100的软件结构。
图16是本申请实施例的电子设备(如电子设备100a或电子设备100b)的软件结构框图。分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。应用程序层可以包括一系列应用程序包。
如图16所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。
应用程序框架层为应用程序层的应用程序提供应用编程接口(application programming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。
如图16所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。
窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。
内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以 包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。
视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。
电话管理器用于提供电子设备100的通信功能。例如通话状态的管理(包括接通，挂断等)。
资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。
通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。
Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。
核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。
应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。
系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。
表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。
媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。
三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。
2D图形引擎是2D绘图的绘图引擎。
内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。例如，上述与二进制配置文件或者C语言配置文件交互的驱动(如上述接口函数，即示例中的“HdfGetSampleModuleConfigRoot”用于获取配置)。
本申请公开的机制的各实施例可以被实现在硬件、软件、固件或这些实现方法的组合中。本申请的实施例可实现为在可编程系统上执行的计算机程序或程序代码，该可编程系统包括至少一个处理器、存储系统(包括易失性和非易失性存储器和/或存储元件)、至少一个输入设备以及至少一个输出设备。
可将程序代码应用于输入指令，以执行本申请描述的各功能并生成输出信息。可以按已知方式将输出信息应用于一个或多个输出设备。为了本申请的目的，处理系统包括具有诸如例如数字信号处理器(DSP)、微控制器、专用集成电路(ASIC)或微处理器之类的处理器的任何系统。
程序代码可以用高级程序化语言或面向对象的编程语言来实现，以便与处理系统通信。在需要时，也可用汇编语言或机器语言来实现程序代码。事实上，本申请中描述的机制不限于任何特定编程语言的范围。在任一情形下，该语言可以是编译语言或解释语言。
在一些情况下，所公开的实施例可以以硬件、固件、软件或其任何组合来实现。所公开的实施例还可以被实现为由一个或多个暂时或非暂时性机器可读(例如，计算机可读)存储介质承载或存储在其上的指令，其可以由一个或多个处理器读取和执行。例如，指令可以通过网络或通过其他计算机可读介质分发。因此，机器可读介质可以包括用于以机器(例如，计算机)可读的形式存储或传输信息的任何机制，包括但不限于，软盘、光盘、光碟、只读存储器(CD-ROMs)、磁光盘、只读存储器(ROM)、随机存取存储器(RAM)、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)、磁卡或光卡、闪存、或用于利用因特网以电、光、声或其他形式的传播信号来传输信息(例如，载波、红外信号数字信号等)的有形的机器可读存储器。因此，机器可读介质包括适合于以机器(例如，计算机)可读的形式存储或传输电子指令或信息的任何类型的机器可读介质。
在附图中，可以以特定布置和/或顺序示出一些结构或方法特征。然而，应该理解，可能不需要这样的特定布置和/或排序。而是，在一些实施例中，这些特征可以以不同于说明性附图中所示的方式和/或顺序来布置。另外，在特定图中包括结构或方法特征并不意味着暗示在所有实施例中都需要这样的特征，并且在一些实施例中，可以不包括这些特征或者可以与其他特征组合。
需要说明的是，本申请各设备实施例中提到的各单元/模块都是逻辑单元/模块，在物理上，一个逻辑单元/模块可以是一个物理单元/模块，也可以是一个物理单元/模块的一部分，还可以以多个物理单元/模块的组合实现，这些逻辑单元/模块本身的物理实现方式并不是最重要的，这些逻辑单元/模块所实现的功能的组合才是解决本申请所提出的技术问题的关键。此外，为了突出本申请的创新部分，本申请上述各设备实施例并没有将与解决本申请所提出的技术问题关系不太密切的单元/模块引入，这并不表明上述设备实施例并不存在其它的单元/模块。
需要说明的是，在本专利的示例和说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
虽然通过参照本申请的某些优选实施例，已经对本申请进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本申请的精神和范围。

Claims (21)

  1. 一种驱动配置管理方法，应用于管理设备，其特征在于，包括：
    确定目标信息，所述目标信息用于表征电子设备的计算能力；
    根据所述目标信息，将配置源文件转换为采用目标文件格式的目标配置文件；
    向所述电子设备发送所述目标配置文件。
  2. 根据权利要求1所述的方法，其特征在于，
    在所述计算能力为第一类计算能力的情况下，所述目标配置文件支持所述电子设备的驱动实现代码直接调用。
  3. 根据权利要求2所述的方法，其特征在于，所述目标文件格式采用以下至少一项语言实现：C语言，C++语言，java语言。
  4. 根据权利要求1至3中任一项所述的方法，其特征在于，所述向所述电子设备发送所述目标配置文件，包括：
    向所述电子设备中的只读存储区域输出所述目标配置文件。
  5. 根据权利要求1至4中任一项所述的方法，其特征在于，所述在根据所述目标信息，将配置源文件转换为采用目标文件格式的目标配置文件之后，所述方法还包括：
    基于所述目标配置文件，编译所述电子设备的驱动实现代码；
    向所述电子设备中的可读写存储区域输出所述驱动实现代码的文件。
  6. 根据权利要求1所述的方法，其特征在于，
    在所述计算能力为第二类计算能力的情况下，所述目标文件格式为二进制格式。
  7. 根据权利要求6所述的方法，其特征在于，
    所述目标配置文件由所述管理设备按照预定义字节码规则编译得到，并且所述目标配置文件支持所述电子设备按照所述预定义字节码规则解析后再由所述电子设备通过驱动实现代码调用。
  8. 根据权利要求1至7中任一项所述的方法，其特征在于，所述电子设备的计算能力包括以下至少一项：所述电子设备中的处理器的时钟频率、所述电子设备的随机存取存储器RAM的容量、所述电子设备的只读内存ROM的容量。
  9. 根据权利要求1至8中任一项所述的方法，其特征在于，所述确定目标信息，包括：
    接收用户对目标控件的目标操作，所述目标控件用于触发从至少两个信息中选定一个信息，所述至少两个信息与至少两种文件格式一一对应；
    响应于所述目标操作，将所述目标控件选定的信息确定为所述目标信息。
  10. 根据权利要求1至9中任一项所述的方法，其特征在于，所述根据所述目标信息，将配置源文件转换为采用目标文件格式的目标配置文件，包括：
    将所述配置源文件转化为多个语法单元序列；
    验证所述多个语法单元序列是否符合预定义语法规则；
    在所述多个语法单元序列符合所述预定义语法规则的情况下，将所述多个语法单元序列转换为抽象语法树；
    按照第一语法规则更新所述抽象语法树，所述第一语法规则至少包括重定义检查和引 用展开处理；
    根据所述目标信息，将所述抽象语法树转换为采用所述目标文件格式的所述目标配置文件。
  11. 一种驱动配置管理方法，应用于电子设备，其特征在于，包括：
    获取采用目标文件格式的目标配置文件，其中，所述目标文件格式与所述电子设备的计算能力对应；
    基于所述目标配置文件，配置并驱动所述电子设备中的硬件。
  12. 根据权利要求11所述的方法，其特征在于，
    所述基于所述目标配置文件，配置并驱动所述电子设备中的硬件，包括：
    在所述计算能力为第一类计算能力的情况下，通过驱动实现代码调用所述目标配置文件，以配置并驱动所述电子设备中的硬件。
  13. 根据权利要求12所述的方法，其特征在于，所述目标文件格式采用以下至少一种语言实现：C语言，C++语言，java语言。
  14. 根据权利要求11至13中任一项所述的方法，其特征在于，
    所述目标配置文件存储在所述电子设备中的只读存储区域中。
  15. 根据权利要求11至14中任一项所述的方法，其特征在于，所述方法还包括：
    获取所述电子设备的驱动实现代码，所述驱动实现代码是基于所述目标配置文件编译得到的，且所述驱动实现代码存储在所述电子设备中的可读写存储区域。
  16. 根据权利要求11所述的方法，其特征在于，所述基于所述目标配置文件，配置并驱动所述电子设备中的硬件，包括：
    在所述目标文件格式为二进制格式的情况下，按照预定义的字节码规则将所述目标配置文件解析为配置树，再通过所述电子设备的驱动实现代码调用所述配置树，以配置并驱动所述电子设备中的硬件。
  17. 根据权利要求11至16中任一项所述的方法，其特征在于，所述电子设备的计算能力包括以下至少一项：所述电子设备中的处理器的时钟频率、所述电子设备的随机存取存储器RAM的容量、所述电子设备的只读内存ROM的容量。
  18. 一种驱动配置管理装置，其特征在于，包括：
    确定模块，用于确定目标信息，所述目标信息用于表征电子设备的计算能力；
    转换模块，用于根据所述确定模块确定的所述目标信息，将配置源文件转换为采用目标文件格式的目标配置文件；
    发送模块，用于向所述电子设备发送所述转换模块转换得到所述目标配置文件。
  19. 一种驱动配置管理装置，其特征在于，包括：
    获取模块，用于获取采用目标文件格式的目标配置文件，其中，所述目标文件格式与电子设备的计算能力对应；
    配置模块，用于基于所述获取模块获取的所述目标配置文件，配置并驱动所述电子设备中的硬件。
  20. 一种计算机可读介质，其特征在于，所述计算机可读介质上存储有指令，所述指令在电子设备上执行时使所述电子设备执行权利要求1至17中任一项所述的驱动配置管理方 法。
  21. 一种电子设备，其特征在于，包括：存储器，用于存储指令，以及处理器，用于执行所述指令以实现如权利要求1至17中任一项所述的驱动配置管理方法。
PCT/CN2021/110860 2020-08-29 2021-08-05 驱动配置管理方法、装置、介质、设备及系统 WO2022042252A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP21860092.2A EP4198720A4 (en) 2020-08-29 2021-08-05 METHOD AND DEVICE FOR MANAGING A DRIVER CONFIGURATION, MEDIUM, DEVICE AND SYSTEM
US18/175,113 US20230214231A1 (en) 2020-08-29 2023-02-27 Driver Configuration Management Method and Apparatus, Medium, Device, and System

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN202010890830 2020-08-29
CN202010890830.1 2020-08-29
CN202110112587.5A CN114116022A (zh) 2020-08-29 2021-01-27 驱动配置管理方法、装置、介质、设备及系统
CN202110112587.5 2021-01-27

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/175,113 Continuation US20230214231A1 (en) 2020-08-29 2023-02-27 Driver Configuration Management Method and Apparatus, Medium, Device, and System

Publications (1)

Publication Number Publication Date
WO2022042252A1 true WO2022042252A1 (zh) 2022-03-03

Family

ID=80352664

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/110860 WO2022042252A1 (zh) 2020-08-29 2021-08-05 驱动配置管理方法、装置、介质、设备及系统

Country Status (4)

Country Link
US (1) US20230214231A1 (zh)
EP (1) EP4198720A4 (zh)
CN (1) CN114398086B (zh)
WO (1) WO2022042252A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114595199A (zh) * 2022-05-10 2022-06-07 太平金融科技服务（上海）有限公司 文件解析方法、装置、计算机设备和存储介质
CN115793989A (zh) * 2023-02-06 2023-03-14 江苏华存电子科技有限公司 一种基于NAND的NVMe KV SSD数据管理方法

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12057997B1 (en) * 2023-10-03 2024-08-06 Cloud Linux Software, Inc. Systems and methods for automated conversion and management of web server configuration files
CN118200134A (zh) * 2024-04-08 2024-06-14 泰思物联网科技(广州)有限公司 一种基于云计算的数据管理系统及方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1581098A (zh) * 2004-05-20 2005-02-16 北京大学 模拟器构造方法
CN102193788A (zh) * 2010-03-12 2011-09-21 复旦大学 基于动态二进制翻译的跨平台驱动程序复用方法
US20120066773A1 (en) * 2010-09-15 2012-03-15 Bank Of America Information safeguard tool
CN109343854A (zh) * 2018-09-18 2019-02-15 武汉精立电子技术有限公司 基于zynq系统的智能自动化编译方法及系统
CN109582376A (zh) * 2018-12-04 2019-04-05 中国航空工业集团公司西安航空计算技术研究所 一种轻量级设备控制方法
CN111522558A (zh) * 2020-07-06 2020-08-11 嘉兴太美医疗科技有限公司 基于Java的动态配置规则的方法、装置、系统和可读介质

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090064196A1 (en) * 2007-08-31 2009-03-05 Microsoft Corporation Model based device driver code generation
US20130139183A1 (en) * 2011-11-28 2013-05-30 Wyse Technology Inc. Creation or installation of a disk image for a target device having one of a plurality of hardware platforms
CN103914315B (zh) * 2012-12-31 2017-05-24 展讯通信（上海）有限公司 驱动程序的配置方法
CN103631632B (zh) * 2013-11-29 2017-08-04 华为技术有限公司 移植方法及源到源编译器
CN106445504A (zh) * 2016-08-31 2017-02-22 上海斐讯数据通信技术有限公司 一种移动终端设备驱动的升级方法及系统
CN111198677A (zh) * 2018-10-30 2020-05-26 阿里巴巴集团控股有限公司 一种设备对象生成方法、装置及设备
CN110096278B (zh) * 2019-04-24 2022-12-20 南京东源磐能能源科技股份有限公司 一种可扩展的嵌入式人机接口工具实现方法
CN110389755B (zh) * 2019-07-24 2023-09-08 网易（杭州）网络有限公司 代码处理方法及装置、电子设备和计算机可读存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1581098A (zh) * 2004-05-20 2005-02-16 北京大学 模拟器构造方法
CN102193788A (zh) * 2010-03-12 2011-09-21 复旦大学 基于动态二进制翻译的跨平台驱动程序复用方法
US20120066773A1 (en) * 2010-09-15 2012-03-15 Bank Of America Information safeguard tool
CN109343854A (zh) * 2018-09-18 2019-02-15 武汉精立电子技术有限公司 基于zynq系统的智能自动化编译方法及系统
CN109582376A (zh) * 2018-12-04 2019-04-05 中国航空工业集团公司西安航空计算技术研究所 一种轻量级设备控制方法
CN111522558A (zh) * 2020-07-06 2020-08-11 嘉兴太美医疗科技有限公司 基于Java的动态配置规则的方法、装置、系统和可读介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4198720A4

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114595199A (zh) * 2022-05-10 2022-06-07 太平金融科技服务（上海）有限公司 文件解析方法、装置、计算机设备和存储介质
CN114595199B (zh) * 2022-05-10 2022-09-02 太平金融科技服务（上海）有限公司 文件解析方法、装置、计算机设备和存储介质
CN115793989A (zh) * 2023-02-06 2023-03-14 江苏华存电子科技有限公司 一种基于NAND的NVMe KV SSD数据管理方法

Also Published As

Publication number Publication date
CN114398086A (zh) 2022-04-26
CN114398086B (zh) 2022-11-25
EP4198720A4 (en) 2024-01-24
US20230214231A1 (en) 2023-07-06
EP4198720A1 (en) 2023-06-21

Similar Documents

Publication Publication Date Title
WO2022042252A1 (zh) 驱动配置管理方法、装置、介质、设备及系统
US10839141B2 (en) System and method for provisioning a mobile software application to a mobile device
US8863082B2 (en) Transformational context-aware data source management
US9536023B2 (en) Code generation for using an element in a first model to call a portion of a second model
US9483240B1 (en) Data binding dependency analysis
US20050091230A1 (en) Software build extensibility
CN106796521B (zh) 独立于产品发布的api版本控制
CN116263657A (zh) 处理单元、软件模块、方法和程序代码
US10656926B2 (en) Compact type layouts
CN114625439A (zh) 基于微前端架构的子应用运行方法、电子设备及存储介质
CN114116022A (zh) 驱动配置管理方法、装置、介质、设备及系统
US8924924B2 (en) Representing the structure of a data format using a class-based representation
WO2021249118A1 (zh) 生成、注册ui服务包、以及加载ui服务的方法及装置
EP4216052A1 (en) Method for developing mvvm architecture-based application, and terminal
US9015728B2 (en) Methods, apparatus, and systems to access runtime values of object instances
CN118094031A (zh) 子应用页面处理方法、装置、计算机设备和存储介质
CN112765676A (zh) 一种智能合约执行方法、智能合约执行装置及节点设备
CN116679912A (zh) 代码生成方法、装置、设备、存储介质及计算机程序
CN118259899A (zh) 一种跨平台、企业级桌面软件开发框架

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21860092

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021860092

Country of ref document: EP

Effective date: 20230313

NENP Non-entry into the national phase

Ref country code: DE