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

Abstract

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

Description

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

技术领域

本申请涉及通信技术领域，特别涉及一种驱动配置管理方法、装置、介质、设备及系统。

背景技术

随着物联网(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 OnlyMemory，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可能无法用于轻量级设备的驱动配置管理。

相关技术的另一种方案中，可以通过高级配置与电源接口(AdvancedConfiguration and Power Interface，ACPI)实现电子设备的驱动配置管理。其中，ACPI为一种配置管理框架，在X86体系中广泛使用。具体地，ACPI使用 ACPI源语言(ACPI SourceLanguage，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的信息，具体包括如下字段：

具体地，上述示例的配置源码中分别通过两个字段分别表示设备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的后续处理模块，进行下一步处理。其中，抽象语法树可以简称为语法树(Syntaxtree)。

具体地，本申请实施例涉及的抽象语法树中至少包括节点名称、属性和属性值等信息。其中，节点、属性和属性值等对应于上述示例的配置源码中的不同内容。例如，不同的节点可以对应于上述示例的配置源码中的不同代码段，一组属性和属性值可以对应于配置源码中的各个代码段中的代码的一组Key-Value。

可以理解的是，抽象语法树是源代码(如配置源码)的抽象语法结构的树状表示，树上的每个节点都表示源代码中的一种结构。但是，抽象语法树并不会表示出真实语法出现的每一个细节，比如说，嵌套括号(即“{}”)被隐含在树的结构中，并没有以节点的形式呈现。

作为一种示例，针对上述示例中的配置源码，词法分析器2011和语法分析器2012生成的抽象语法树的内容的说明如下：

参照上述示例的抽象语法树，对本申请提供的抽象语法树进行说明。例如，抽象语法树可以用“CONFNODE”表示节点，“CONFTERM”表示属性，“STRING”表示对应属性的属性值的数据类型为字符(或称字符串)，“|_”用于关联每个属性和对应的属性值；“UINT32”表示的数据类型为无符号32位整数，“UINT8”表示的数据类型为无符号8位整数。

可以理解的是，上述示例的抽象语法树中的两个节点(CONFNODE)之间的属性(CONFTERM)均为前一个节点中的属性。例如，上述“CONFNODE ForestRoot”为语法分析器2012构造出的虚拟根节点“ForestRoot”，“CONFNODE root”表示父节点“root”，对应于上述配置源文件中的代码段root{}，但是嵌套括号 (“{}”)被隐含在树的结构中，而没有以节点的形式呈现。“CONFNODE device0”表示子节点“device0”，对应于上述配置源文件中的代码段device0{}。“CONFNODE device1 NodeCopy 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进行了引用展开，并输出了如下所示的抽象语法树(记为最终抽象语法树)：

具体地，中间处理器2013对上述语法分析器2012生成的抽象语法树中的代码“CONFNODE device1 NodeCopy 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表示不同类型的代码所匹配的代码数值， CodeName表示代码名称，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 dataprefix)、32bit的数据前缀 (32-bit data prefix)以及64bit的数据前缀(64-bit dataprefix)。

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…00FF 0000…”，排列顺序为从左到右从上到下的顺序，即沿着图3示出的列序号从小到大、行序号从小到大的顺序。例如，行序号为“00”和列序号“00000000”指示的字符“0A”为图3示出的二进制配置文件中的第一个字符。

可以理解的是，本申请提供的编译软件显示的行序号和列序号包括但不限于上述图3中的示例，例如，编译软件每行可以显示32个字符，即编译软件显示有32列序号。

另外，在一些实施例中，以图3所示的行序列为“00000000”和“00000010”中的全部字符以及行序列为“00000000”中的全部字符、行序列为“00000020”中列序号为“00-0D”的字符为例，对图3示出的二进制配置文件进行详细说明。具体地，结合表1，按照图3示中从左到右从上到下的顺序，对这些字符进行描述：“0A A0 0A A0”为魔数，用于校验文件类型，即用于检验当前的文件是否为符合表1示出的字节码编码规则等的二进制配置文件。“00 0000 00”表示文件校验位，可以用于表示当前文件是否安全或规范。“40 00 00 00”表示编译器主版本号，如上述配置编译器201的主版本号。“00 00 00 00”用于表示编译器子版本号。“8c 00 00 00”表示文件大小，即140(字节)。“01”表示节点(Config Node)。“72 6f 6f 7400”表示节点名称“root”，其中，“72”、“6f”、“6f”、“74”分别为“r”、“o”、“o”、“t”的ascii码，“00”为结束符。“82 00 00 00”表示“root”节点的大小，即130字节。“02”表示属性(ConfigTerm)，即节点“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语言配置文件中的头文件的示例如下：

需要说明的是，上述头文件中的“#ifndef”、“#define”以及“#endif”为宏定义的一种。条件指示符#ifndef用于检查预编译常量(即“HCS_CONFIG_SAMPLE_HEADER_H”)是否已经被宏定义。如果没有被宏定义,则条件指示符#ifndef的值为真，于是从#ifndef到#endif之间的所有语句都被包含进来进行编译处理。相反，如果条件指示符的值为假，则#ifndef与#endif指示符之间的语句将被忽略。条件指示符#ifndef的最主要目的是防止头文件的重复包含和编译。

可以理解的是，上述头文件中包括：配置结构体的声明(或称为结构体声明) 和配置获取函数声明(或称为函数声明)。例如，上述头文件中定义的配置结构体声明包括struct HdfConfigSampleDevice0、struct HdfConfigSampleDevice1 和structHdfConfigSampleDRoot。上述头文件中的配置获取函数声明可以为“const structHdfConfigSampleRoot*HdfGetSampleModuleConfigRoot(void)”函数。

具体地，首先，C语言配置文件中的头文件用于声明参数和变量，例如在结构体struct HdfConfigSampleDevice0中，针对设备0声明了以下参数：数据类型为常量字符串(const char*)的设备名称“deviceName”，数据类型为16位的无符号整型(uint16_t)的寄存器基地址(regBase)，数据类型为8位的无符号整型(uint8_t)的寄存器基地址(regOffset)，分别对应于上述示例的配置源文件和抽象语法树中针对设备0的相应属性。类似的，本申请实施例这里，对上述结构体struct HdfConfigSampleDevice1中定义的参数的描述不再赘述。其次，在上述结构体struct HdfConfigSampleRoot中，定义了数据类型为常量字符串的“module”，并定义了对应设备0的“HdfConfigSampleDevice0 device0”以及对应设备1的“struct HdfConfigSampleDevice1 device1”。此外，上述头文件中还包括解释说明的内容“It's HDF config auto-gen file,do not modify it manually”，用于向相关技术人员说明此头文件为HDF配置自动生成文件，请勿手动修改。其中，HDF表示硬件驱动统一平台(Hardware Driver Foundation)。

作为一种示例，针对上述示例的配置源文件和抽象语法树，文本配置生成器 2014的C语言配置文件中的内容文件的示例如下：

其中，上述示例的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，在配置树中遍历查找到确定与节点“device0”对应的属性和属性值。

步骤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示出的数据段“.textsection”)，该数据段可以为可读写的数据段。如此，驱动实现代码可以直接访问对应的只读存储数据段的数据地址，并获取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”函数)，进而通过该接口函数获取配置数据地址，该地址为上述只读数据段“.rodatasection”的地址。

步骤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上的包括无线局域网(wirelesslocal 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，蓝牙，音乐，视频，短信息等应用程序。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming 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中任一项所述的驱动配置管理方法。

Images