CN107025104A - 内核开发管理***和方法 - Google Patents

Abstract

本发明提供一种内核开发管理***和方法，其中，***包括开发管理模块、测试管理模块、发布管理模块和文件管理模块；开发管理模块，用于根据内核开发规范接收内核开发人员递交的内核补丁，对内核补丁进行代码审查和功能测试，将通过代码审查和功能测试的内核补丁进行归档获得内核主版本；测试管理模块，用于根据内核开发规范对内核主版本进行版本测试；发布管理模块，用于向内核开发人员发布内核开发规范，根据内核开发规范将通过版本测试的内核主版本进行归档获得内核发布版本，并发布内核发布版本。本发明提供的内核开发管理***，可以减少内核开发过程中引入内核缺陷及潜在风险的概率，提高了新内核运行的安全性和稳定性。

Description

内核开发管理***和方法

技术领域

本发明涉及软件开发技术领域，尤其涉及一种内核开发管理***和方法。

背景技术

内核是一个操作***的核心，是基于硬件的第一层软件扩充，提供了操作***的最基本功能，例如：管理硬件、执行任务调度、维护***整体安全和完整性等等。对于内核的开发，要求开发速度快、减少外部修改，还要确保新内核的测试充分性。

目前，基于无互锁流水线级的微处理器(Million Instructions PerSecond，简称MIPS)的内核开发是基于松散的、定时发布的滚动模型，在开源软件平台上实现，通常包括补丁开发、新内核测试和版本发布。具体的，在补丁开发阶段，内核升级被拆分为一个个小的互相独立的单元，称为补丁(patch)，每个补丁通常只做一件事情，并且操作***打上此补丁后依然能够正常编译和工作，每个补丁都要进行代码质量审查和正确性评审，补丁开发完成之后需要递交至软件平台形成新内核，然后对新内核进行测试以保证新内核质量，内核测试手段是多样的，包括单项测试、集成测试、功能测试、性能测试、压力测试、回归测试等等，当新内核通过测试没有问题后，才可以发布。

但是，由于内核开发属于开放式开发，任何人都可以针对内核升级开发补丁，这样将导致补丁编程风格各异，代码修改范围混乱，而且，补丁的开发和测试通常由同一个人完成，这样将导致新内核测试不充分，容易引入内核缺陷及潜在风险。因此，现有的内核开发流程增加了内核开发过程中引入内核缺陷及潜在风险的概率，严重影响了新内核的安全稳定运行。

发明内容

本发明提供一种内核开发管理***和方法，内核开发流程具备明确的内核开发规范，使得内核开发更加规范、清晰、透明，减少了内核开发过程中引入内核缺陷及潜在风险的概率，提高了新内核运行的安全性和稳定性。

本发明提供的内核开发管理***，包括：开发管理模块、测试管理模块、发布管理模块和文件管理模块；

所述文件管理模块，用于根据内核开发规范对内核文件进行分类；

所述开发管理模块，用于根据所述内核开发规范接收内核开发人员递交的内核补丁，对所述内核补丁进行代码审查和功能测试，将通过代码审查和功能测试的内核补丁进行归档获得内核主版本；

所述测试管理模块，用于根据所述内核开发规范对所述内核主版本进行版本测试；

所述发布管理模块，用于向内核开发人员发布所述内核开发规范，根据所述内核开发规范将通过版本测试的内核主版本进行归档获得内核发布版本，并发布所述内核发布版本。

本发明提供的内核开发管理方法，包括：

向内核开发人员发布内核开发规范，以及根据所述内核开发规范对内核文件进行分类；

根据所述内核开发规范接收所述内核开发人员递交的内核补丁，对所述内核补丁进行代码审查和功能测试，将通过代码审查和功能测试的内核补丁进行归档获得内核主版本；

根据所述内核开发规范对所述内核主版本进行版本测试；

根据所述内核开发规范将通过版本测试的内核主版本进行归档获得内核发布版本，并发布所述内核发布版本。

本发明提供一种内核开发管理***和方法，其中，***包括开发管理模块、测试管理模块、发布管理模块和文件管理模块。本发明提供的内核开发管理***，使得整个内核开发过程均遵循内核开发规范，内核开发更加规范、清晰、透明，减少了内核开发过程中引入内核缺陷及潜在风险的概率，提高了新内核运行的安全性和稳定性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例一提供的内核开发管理***的结构示意图；

图2为本发明实施例二提供的内核开发管理***的结构示意图；

图3为本发明实施例一提供的内核开发管理方法的流程图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明提供的内核开发管理***，主要应用于开放式内核开发，例如：基于MIPS处理器的内核开发，也可以应用于闭环式内核开发，例如：Windows操作***的内核开发。

图1为本发明实施例一提供的内核开发管理***的结构示意图。如图1所示，本实施例提供的内核开发管理***，可以包括：开发管理模块11、测试管理模块13、发布管理模块15和文件管理模块17。

文件管理模块17，用于根据内核开发规范对内核文件进行分类。

开发管理模块11，用于根据内核开发规范接收内核开发人员递交的内核补丁，对内核补丁进行代码审查和功能测试，将通过代码审查和功能测试的内核补丁进行归档获得内核主版本。

测试管理模块13，用于根据内核开发规范对内核主版本进行版本测试。

发布管理模块15，用于向内核开发人员发布内核开发规范，根据内核开发规范将通过版本测试的内核主版本进行归档获得内核发布版本，并发布内核发布版本。

在本实施例提供的内核开发管理***中，各模块均遵循内核开发规范进行内核开发流程，下面按照内核开发的时间顺序，详细说明各模块的具体功能。内核开发流程通常包括：内核开发阶段、内核版本测试阶段和内核发布阶段。

首先，在内核开发初始，发布管理模块15向内核开发人员发布内核开发规范，用于规范整个内核开发流程，以及规范各内核开发人员在内核开发过程中各阶段需要执行的职能。文件管理模块17根据内核开发规范对内核文件进行分类，明确各个内核文件的所属类别。

其次，在内核开发阶段，内核开发人员按照内核开发规范进行内核代码开发，形成内核补丁，并将内核补丁递交至开发管理模块11。开发管理模块11根据内核开发规范接收内核补丁，如果内核补丁不符合内核开发规范，则开发管理模块11将不会接收该内核补丁，只有内核补丁符合内核开发规范，开发管理模块11才会接收该内核补丁。开发管理模块11接收内核补丁后，根据内核开发规范对内核补丁进行代码审查和功能测试，对通过代码审查和功能测试的内核补丁进行归档获得所述内核主版本。其中，通过代码审查是指内核补丁经过代码审查后无问题，通过功能测试是指内核补丁经过功能测试后无问题。

然后，在内核版本测试阶段，测试管理模块13根据内核开发规范对内核主版本进行版本测试，发布管理模块15根据内核开发规范将通过版本测试的内核主版本进行归档获得内核发布版本。其中，通过版本测试是指内核主版本经过版本测试后无问题。

最后，在内核发布阶段，发布管理模块15发布各内核发布版本。

可见，本实施例提供的内核开发管理***，开发管理模块11、测试管理模块13、发布管理模块15和文件管理模块17在内核开发过程中，进行的各个事项均是遵循内核开发规范实现的，内核开发过程中各个阶段涉及的内核开发人员以及整个内核开发过程均遵循内核开发规范，因此，通过明确的内核开发规范，使得内核开发过程更加规范、清晰、透明，减少了内核开发过程中引入内核缺陷及潜在风险的概率，提高了新内核运行的安全性和稳定性。

可选的，内核开发管理***还可以包括：需求管理模块。

需求管理模块，用于根据内核开发管理规范对开发需求进行分析和评审，获得需求分析结果。

可选的，文件管理模块17可以包括：规范库、受控库和存档库。其中，规范库，用于存储内核开发规范，受控库，用于存储内核开发过程中的各内核主版本，存档库，用于存储内核开发过程中的各内核发布版本。

需要说明的是，在本实施例中，各模块可以通过现有的任意开源软件、自开发的开源软件、安装有软件的计算机或者服务器实现，本实施例对此不加以限制，例如：开发管理模块11可以通过Gerrit***实现。

需要说明的是，在本实施例中，文件管理模块17对内核文件进行分类，只需要实现将各个内核文件进行类别区分即可，并不需要对各个内核文件进行存储文件夹的重新整理。

需要说明的是，在本实施例中，开发管理模块11接收的内核补丁，可以是任意内核开发人员递交的内核补丁，例如：可以是公司内的内核研发部的内核开发人员递交的内核补丁，也可以是公司内其他研发部门的内核开发人员递交的内核补丁，也可以是其他公司的内核开发人员递交的内核补丁，本实施例对此不加以限制。

需要说明的是，本实施例中的内核补丁，是指通过单项测试的内核补丁，内核补丁的代码开发人员和内核补丁的单向测试人员可以相同，也可以不同，对内核补丁进行单项测试时，可以遵循内核开发规范。

需要说明的是，在本实施例中，内核开发人员和内核开发规范需要根据内核开发的需要进行设置，本实施例对于内核开发人员和内核开发规范的具体实现方式不加以限制。

可选的，作为内核开发人员的一种具体划分方式，内核开发人员可以包括：公司主管、内核开发经理、内核开发组长、开发工程师、测试组长、功能测试工程师、版本测试工程师、发布工程师和配置管理员。

其中，公司主管为内核开发的最高主管，对内核开发各阶段中的所有事项均具有决策权。

内核开发经理和内核开发组长为内核开发过程中内核开发阶段的主管，对内核开发阶段的所有事项具有决策权，其中，内核开发经理的决策权高于内核开发组长的决策权。

测试组长为内核开发过程中内核版本测试阶段的主管，对内核版本测试阶段的所有事项具有决策权。

开发工程师主要进行内核补丁的代码开发和内核补丁的单向测试。

功能测试工程师主要进行内核开发阶段的内核补丁的功能测试。

版本测试工程师主要进行内核版本测试阶段的内核主版本的版本测试。

发布工程师主要进行内核发布版本的发布。

配置管理员主要进行内核发布版本的归档以及配置项变更。

可选的，作为内核开发规范的一种具体实现方式，内核开发规范可以包括：内核编程规范、内核文件分类规范、补丁分类规范、内核测试规范、以及内核开发人员角色和职责规范。

其中，内核编程规范，是指在内核开发人员在进行内核补丁的代码开发时，约束内核开发人员遵循的编程规则。通过设置内核编程规范，可以使得各内核开发人员在进行内核补丁的代码开发时，遵循统一的编程规范，降低了引入编程缺陷的概率。

内核文件分类规范，是指使得内核开发人员明确内核文件明确分类的规范。通过设置内核文件分类规范，可以使得内核开发人员在进行内核补丁的代码开发时，明确代码的修改范围，降低了引入编程缺陷的概率。

补丁分类规范，用于对内核补丁进行明确分类。通过设置补丁分类规范，可以使得内核补丁类别明确，便于内核补丁以及内核版本的维护和管理。

内核测试规范，用于规范内核开发过程中各阶段的测试事项，其中，各阶段的测试事项包括：内核补丁的单向测试、内核补丁的功能测试和内核主版本的版本测试。通过设置内核测试规范，可以使得内核开发人员明确测试内容，提高了内核测试的准确性和全面性。

内核开发人员角色和职责规范，用于明确各开发人员的角色和职责。通过设置内核开发人员角色和职责规范，可以使得各内核开发人员的职责完全清晰、隔离，不同的内核开发人员权限不同，增加了内核开发的透明度和规范性。

本实施例提供一种内核开发管理***，包括：开发管理模块、测试管理模块、发布管理模块和文件管理模块。本实施例提供的内核开发管理***，使得整个内核开发过程均遵循内核开发规范，内核开发更加规范、清晰、透明，减少了内核开发过程中引入内核缺陷及潜在风险的概率，提高了新内核运行的安全性和稳定性。

图2为本发明实施例二提供的内核开发管理***的结构示意图，本实施例在实施例一的基础上，提供了内核开发管理***的一种具体实现方式。如图2所示，本实施例提供的内核开发管理***，可以包括：开发管理模块11、测试管理模块13、发布管理模块15和文件管理模块17。

其中，文件管理模块17包括：分类单元171、规范库173、受控库175和存档库177。

分类单元171，用于根据内核文件名、内核文件后缀类别和内核文件存储目录，将内核文件分类为源文件、配置文件和辅助文件。其中，源文件包括头文件、固定文件、驱动源文件、架构源文件和公共源文件，配置文件包括驱动配置文件、架构配置文件和公共配置文件。

规范库173，用于存储内核开发规范。受控库175，用于存储各内核主版本。存档库177，用于存储各内核发布版本。

其中，开发管理模块11包括接收审查单元111、功能测试单元113和第一归档单元115。

接收审查单元111，用于接收内核开发人员递交的内核补丁，判断内核补丁中是否包括内核补丁编译检查表；若是，则为内核开发组长分配审查权限，根据内核编程规范对内核补丁进行代码审查，将符合内核编程规范的内核补丁确定为第一有效内核补丁。

功能测试单元113，用于为功能测试工程师分配测试权限，根据内核测试规范和第一有效内核补丁的内核文件修改范围，对第一有效内核补丁进行驱动测试、架构测试或者公共测试，将通过驱动测试、架构测试或者公共测试的第一有效内核补丁确定为第二有效内核补丁。

第一归档单元115，用于根据补丁分类规范确定第二有效内核补丁的级别，根据级别为相应的内核开发人员分配归档权限，对第二有效内核补丁进行归档获得内核主版本。

其中，测试管理模块13具体用于：为版本测试工程师分配测试权限，根据内核测试规范对内核主版本进行版本测试。

其中，发布管理模块15包括：公告单元151、第二归档单元153和版本发布单元155。

公告单元151，用于向内核开发人员发布内核开发规范。

第二归档单元153，用于为配置管理员分配归档权限，对通过版本测试的内核主版本进行归档获得内核发布版本。

版本发布单元155，用于为发布工程师分配发布权限，发布内核发布版本。

需要说明的是，在本实施例中，驱动配置文件是与驱动源文件相对应的配置文件，架构配置文件是与架构源文件相对应的配置文件，公共配置文件是与公共源文件相对应的配置文件。

需要说明的是，在本实施例中，接收审查单元111为内核开发组长分配审查权限，是指内核开发组长有权限总体安排内核补丁代码审查的各事项以及总体把控内核补丁代码审查的进度，第一归档单元115根据第二有效内核补丁的级别为相应的内核开发人员分配归档权限，是指相应的内核开发人员有权限判断内核补丁是否合入内核主版本。

下面按照内核开发的时间顺序，详细说明本实施例提供的内核开发管理***中各模块的具体功能。

首先，在内核开发初始，发布管理模块15向内核开发人员发布内核开发规范。并且，文件管理模块17根据内核开发规范对内核文件进行分类，明确各个内核文件的所属类别。

其中，内核开发规范可以包括：内核编程规范、内核文件分类规范、补丁分类规范、内核测试规范、以及内核开发人员角色和职责规范。

作为内核编程规范的一种具体实现方式，表1示出了内核编程规范中的具体要求，如表1所示，内核编程规范可以包括：地址空间配置规则、物理地址空间访问规则、全局变量使用规则、编译约定和补丁递交要求。

表1

作为内核文件分类规范的一种具体实现方式，表2示出了内核文件分类规范中的内核文件分类项目以及具体分类要求。

表2

作为补丁分类规范的一种具体实现方式，表3示出了补丁分类规范中的具体要求，如表3所示，补丁分类规范可以包括：补丁级别、补丁名称、补丁执行权限、内核文件修改范围和典型事例，其中，补丁执行权限是指判断是否将内核补丁合入内核主版本的决策权限。

表3

在表3中，内核补丁定义为5个级别，按照内核补丁执行权限从高到低，依次为主干级、公共级、芯片级、架构级和驱动级，各级别内核补丁的具体要求如下：

1级，驱动级。涉及设备驱动的添加与功能完善，源码文件与配置文件的修改范围限定于driver目录，对配置与编译文件的修改一般限定于新增驱动的支持。测试工作以模块级测试为主。

2级，架构级。涉及体系架构相关的功能添加与完善。可以修改架构相关文件，但不允许对配置文件进行修改。测试以体系架构相关的白盒测试为主。

3级，芯片级。涉及对新增桥片或***架构(如单路到双路)的支持。允许修改架构和公共部分的源码文件与配置文件。测试以白盒测试与***黑盒测试相结合。内核开发组长需要提交书面的设计方案与测试报告报内核开发经理审批。

4级，公共级。涉及内核公共部分代码的修改，与上游社区版本的同步更新也属于本级范畴。允许对所有源码文件和配置文件进行修改。内核开发组长需要提交书面的设计方案与测试报告报内核开发经理审批，必要时由内核开发经理牵头组织公司层面的评审会进行审批。

5级，主干级。内核主版本的升级(例如：内核的移植)。对所有源码文件和配置文件进行修改。内核开发组长需要提交书面的设计方案与测试报告报内核开发经理备案，必须由内核开发经理牵头组织公司层面的评审会，由公司主管审批。

作为内核测试规范的一种具体实现方式，表4～表7分别示出了内核测试规范中驱动测试、架构测试、公共测试和版本测试的测试项目以及具体要求。其中更好，驱动测试、架构测试、公共测试主要应用于内核补丁的单向测试、内核补丁的功能测试，版本测试主要应用于内核主版本的版本测试。

表4

表5

表6

表7

作为内核开发人员角色和职责规范的一种具体实现方式，表8示出了内核开发人员角色和职责规范中的具体要求，如表8所示，内核开发人员可以包括：公司主管、内核开发经理、内核开发组长、开发工程师、测试组长、功能测试工程师、版本测试工程师、发布工程师和配置管理员。

表8

其次，在内核开发阶段，内核开发人员按照内核开发规范进行内核代码开发，形成内核补丁，并将内核补丁递交至开发管理模块11。接收审查单元111根据内核开发规范接收内核补丁，当内核补丁中包括内核补丁编译检查表时，接收审查单元111才会接收该内核补丁，为内核开发组长分配审查权限，功能测试单元113为功能测试工程师分配测试权限，对符合内核编程规范的第一有效内核补丁进行功能测试，第一归档单元115确定第二有效内核补丁的级别后，为相应的内核开发人员分配归档权限，对第二有效内核补丁进行归档获得内核主版本。

可选的，第一归档单元115具体用于：

若第二有效内核补丁的内核文件修改范围为驱动源文件和驱动配置文件，则确定第二有效内核补丁的级别为驱动级，为内核开发组长分配驱动级补丁归档权限。

若第二有效内核补丁的内核文件修改范围为驱动源文件和架构源文件，则确定第二有效内核补丁的级别为架构级，为内核开发组长分配架构级补丁归档权限。

若第二有效内核补丁的内核文件修改范围为架构源文件、架构配置文件、公共源文件和公共配置文件，则确定第二有效内核补丁的级别为芯片级，为内核开发经理分配架构级补丁归档权限。

若第二有效内核补丁的内核文件修改范围为驱动源文件、驱动配置文件、架构源文件、架构配置文件、公共源文件和公共配置文件，则确定第二有效内核补丁的级别为公共级或者主干级，为内核开发经理或者公司主管分配公共级补丁归档权限或者主干级补丁归档权限。

然后，在内核版本测试阶段，测试管理模块13为版本测试工程师分配测试权限，根据内核测试规范对内核主版本进行版本测试。发布管理模块15中的第二归档单元153为配置管理员分配归档权限，将通过版本测试的内核主版本进行归档获得内核发布版本。

最后，在内核发布阶段，发布管理模块15中的版本发布单元155为发布工程师分配发布权限，发布各内核发布版本。

可见，本实施例提供的内核开发管理***，只有内核开发组长才有权限对内核补丁进行代码审查，只有功能测试工程师才有权限对内核补丁进行功能测试，只有与内核补丁级别相对应的内核开发人员才能将相应级别的内核补丁进行归档合入内核主版本，只有版本测试工程师才有权限对内核主版本进行版本测试，只有配置管理员才有权限对内核主版本进行归档获得内核发布版本，只有发布工程师才有权限进行内核发布版本的发布，在整个内核开发过程中，内核补丁的代码开发与单向测试、内核补丁的递交、内核补丁的代码审查和功能测试、内核补丁合入内核主版本、内核主版本的版本测试，内核发布版本的发布，各个阶段均遵循内核开发规范，使得内核开发更加规范、清晰、透明，减少了内核开发过程中引入内核缺陷及潜在风险的概率，提高了新内核运行的安全性和稳定性。

本实施例提供了一种内核开发管理***，包括：开发管理模块、测试管理模块、发布管理模块和文件管理模块，其中，文件管理模块包括分类单元、规范库、受控库和存档库，开发管理模块包括接收审查单元、功能测试单元和第一归档单元，发布管理模块包括公告单元、第二归档单元和版本发布单元。本实施例提供的内核开发管理***，使得整个内核开发过程均遵循内核开发规范，内核开发更加规范、清晰、透明，减少了内核开发过程中引入内核缺陷及潜在风险的概率，提高了新内核运行的安全性和稳定性。

图3为本发明实施例一提供的内核开发管理方法的流程图。如图3所示，本实施例提供的内核开发管理方法，执行主体为图1～图2所示的任一实施例提供的内核开发管理***，本实施例提供的内核开发管理方法，可以包括：

步骤101、向内核开发人员发布内核开发规范，以及根据内核开发规范对内核文件进行分类。

步骤102、根据内核开发规范接收内核开发人员递交的内核补丁，对内核补丁进行代码审查和功能测试，将通过代码审查和功能测试的内核补丁进行归档获得内核主版本。

步骤103、根据内核开发规范对内核主版本进行版本测试。

步骤104、根据内核开发规范将通过版本测试的内核主版本进行归档获得内核发布版本，并发布内核发布版本。

可选的，内核开发规范可以包括：内核编程规范、内核文件分类规范、补丁分类规范、内核测试规范、以及内核开发人员角色和职责规范。

可选的，步骤101中，根据内核开发规范对内核文件进行分类，可以包括：

根据内核文件名、内核文件后缀类别和内核文件存储目录，将内核文件分类为源文件、配置文件和辅助文件。其中，源文件包括头文件、固定文件、驱动源文件、架构源文件和公共源文件；配置文件包括驱动配置文件、架构配置文件和公共配置文件。

可选的，步骤102，根据内核开发规范接收内核开发人员递交的内核补丁，对内核补丁进行代码审查和功能测试，将通过代码审查和功能测试的内核补丁进行归档获得内核主版本，可以包括：

接收内核开发人员递交的内核补丁，判断内核补丁中是否包括内核补丁编译检查表。若是，则为内核开发组长分配审查权限，根据内核编程规范对内核补丁进行代码审查，将符合内核编程规范的内核补丁确定为第一有效内核补丁。

为功能测试工程师分配测试权限，根据内核测试规范和第一有效内核补丁的内核文件修改范围，对第一有效内核补丁进行驱动测试、架构测试或者公共测试，将通过驱动测试、架构测试或者公共测试的第一有效内核补丁确定为第二有效内核补丁。

根据补丁分类规范确定第二有效内核补丁的级别，根据级别为相应的内核开发人员分配归档权限，对第二有效内核补丁进行归档获得内核主版本。

进一步的，内核补丁的级别可以包括：驱动级、架构级、芯片级、公共级和主干级。根据补丁分类规范确定第二有效内核补丁的级别，根据级别为相应的内核开发人员分配归档权限，可以包括：

若第二有效内核补丁的内核文件修改范围为驱动源文件和驱动配置文件，则确定第二有效内核补丁的级别为驱动级，为内核开发组长分配驱动级补丁归档权限。

若第二有效内核补丁的内核文件修改范围为驱动源文件和架构源文件，则确定第二有效内核补丁的级别为架构级，为内核开发组长分配架构级补丁归档权限。

若第二有效内核补丁的内核文件修改范围为架构源文件、架构配置文件、公共源文件和公共配置文件，则确定第二有效内核补丁的级别为芯片级，为内核开发经理分配架构级补丁归档权限。

若第二有效内核补丁的内核文件修改范围为驱动源文件、驱动配置文件、架构源文件、架构配置文件、公共源文件和公共配置文件，则确定第二有效内核补丁的级别为公共级或者主干级，为内核开发经理或者公司主管分配公共级补丁归档权限或者主干级补丁归档权限。

可选的，步骤103，根据内核开发规范对内核主版本进行版本测试，可以包括：

为版本测试工程师分配测试权限，根据内核测试规范对内核主版本进行版本测试。

可选的，步骤104，根据内核开发规范将通过版本测试的内核主版本进行归档获得内核发布版本，并发布内核发布版本，可以包括：

为配置管理员分配归档权限，对通过版本测试的内核主版本进行归档获得内核发布版本。

为发布工程师分配发布权限，发布内核发布版本。

可选的，内核编程规范可以包括：地址空间配置规则、物理地址空间访问规则、全局变量使用规则、编译约定和补丁递交要求。

可选的，内核开发人员可以包括：公司主管、内核开发经理、内核开发组长、开发工程师、测试组长、功能测试工程师、版本测试工程师、发布工程师和配置管理员。

可选的，内核开发管理方法还可以包括：

步骤一、通过规范库存储内核开发规范。

步骤二、通过受控库存储内核开发过程中的各内核主版本。

步骤三、通过存档库存储内核开发过程中的各内核发布版本。

其中，步骤一可以在步骤101之前。步骤二可以在步骤102之后。步骤三可以在步骤104中根据内核开发规范将通过版本测试的内核主版本进行归档获得内核发布版本之后，在步骤104中发布内核发布版本之前。

本发明提供一种内核开发管理方法，包括：向内核开发人员发布内核开发规范，以及根据内核开发规范对内核文件进行分类，根据内核开发规范接收内核开发人员递交的内核补丁，对内核补丁进行代码审查和功能测试，将通过代码审查和功能测试的内核补丁进行归档获得内核主版本，根据内核开发规范对内核主版本进行版本测试，根据内核开发规范将通过版本测试的内核主版本进行归档获得内核发布版本，并发布内核发布版本。本发明提供的内核开发管理方法，使得整个内核开发过程均遵循内核开发规范，内核开发更加规范、清晰、透明，减少了内核开发过程中引入内核缺陷及潜在风险的概率，提高了新内核运行的安全性和稳定性。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (20)

1.一种内核开发管理***，其特征在于，包括：开发管理模块、测试管理模块、发布管理模块和文件管理模块；

所述文件管理模块，用于根据内核开发规范对内核文件进行分类；

所述开发管理模块，用于根据所述内核开发规范接收内核开发人员递交的内核补丁，对所述内核补丁进行代码审查和功能测试，将通过代码审查和功能测试的内核补丁进行归档获得内核主版本；

所述测试管理模块，用于根据所述内核开发规范对所述内核主版本进行版本测试；

所述发布管理模块，用于向所述内核开发人员发布所述内核开发规范，根据所述内核开发规范将通过版本测试的内核主版本进行归档获得内核发布版本，并发布所述内核发布版本。

2.根据权利要求1所述的***，其特征在于，所述内核开发规范包括：内核编程规范、内核文件分类规范、补丁分类规范、内核测试规范、以及内核开发人员角色和职责规范。

3.根据权利要求2所述的***，其特征在于，所述文件管理模块包括：分类单元；

所述分类单元，用于根据内核文件名、内核文件后缀类别和内核文件存储目录，将所述内核文件分类为源文件、配置文件和辅助文件；其中，所述源文件包括头文件、固定文件、驱动源文件、架构源文件和公共源文件；所述配置文件包括驱动配置文件、架构配置文件和公共配置文件。

4.根据权利要求3所述的***，其特征在于，所述开发管理模块包括：接收审查单元、功能测试单元和第一归档单元；

所述接收审查单元，用于接收内核开发人员递交的所述内核补丁，判断所述内核补丁中是否包括内核补丁编译检查表；若是，则为内核开发组长分配审查权限，根据所述内核编程规范对所述内核补丁进行代码审查，将符合所述内核编程规范的内核补丁确定为第一有效内核补丁；

所述功能测试单元，用于为功能测试工程师分配测试权限，根据所述内核测试规范和所述第一有效内核补丁的内核文件修改范围，对所述第一有效内核补丁进行驱动测试、架构测试或者公共测试，将通过驱动测试、架构测试或者公共测试的所述第一有效内核补丁确定为第二有效内核补丁；

所述第一归档单元，用于根据所述补丁分类规范确定所述第二有效内核补丁的级别，根据所述级别为相应的内核开发人员分配归档权限，对所述第二有效内核补丁进行归档获得所述内核主版本。

5.根据权利要求4所述的***，其特征在于，所述级别包括：驱动级、架构级、芯片级、公共级和主干级，所述第一归档单元具体用于：

若所述第二有效内核补丁的内核文件修改范围为驱动源文件和驱动配置文件，则确定所述第二有效内核补丁的级别为所述驱动级，为内核开发组长分配驱动级补丁归档权限；

若所述第二有效内核补丁的内核文件修改范围为驱动源文件和架构源文件，则确定所述第二有效内核补丁的级别为所述架构级，为内核开发组长分配架构级补丁归档权限；

若所述第二有效内核补丁的内核文件修改范围为架构源文件、架构配置文件、公共源文件和公共配置文件，则确定所述第二有效内核补丁的级别为所述芯片级，为内核开发经理分配架构级补丁归档权限；

若所述第二有效内核补丁的内核文件修改范围为驱动源文件、驱动配置文件、架构源文件、架构配置文件、公共源文件和公共配置文件，则确定所述第二有效内核补丁的级别为所述公共级或者主干级，为内核开发经理或者公司主管分配公共级补丁归档权限或者主干级补丁归档权限。

6.根据权利要求2所述的***，其特征在于，所述测试管理模块具体用于：

为版本测试工程师分配测试权限，根据所述内核测试规范对所述内核主版本进行版本测试。

7.根据权利要求2所述的***，其特征在于，所述发布管理模块包括：公告单元、第二归档单元和版本发布单元；

所述公告单元，用于向所述内核开发人员发布所述内核开发规范；

所述第二归档单元，用于为配置管理员分配归档权限，对通过版本测试的内核主版本进行归档获得所述内核发布版本；

所述版本发布单元，用于为发布工程师分配发布权限，发布所述内核发布版本。

8.根据权利要求1至7任一所述的***，其特征在于，所述内核编程规范包括：地址空间配置规则、物理地址空间访问规则、全局变量使用规则、编译约定和补丁递交要求。

9.根据权利要求1至7任一所述的***，其特征在于，所述内核开发人员包括：公司主管、内核开发经理、内核开发组长、开发工程师、测试组长、功能测试工程师、版本测试工程师、发布工程师和配置管理员。

10.根据权利要求1至7任一所述的***，其特征在于，所述文件管理模块包括：规范库、受控库和存档库；

所述规范库，用于存储所述内核开发规范；

所述受控库，用于存储内核开发过程中的各所述内核主版本；

所述存档库，用于存储内核开发过程中的各所述内核发布版本。

11.一种内核开发管理方法，其特征在于，包括：

向内核开发人员发布内核开发规范，以及根据所述内核开发规范对内核文件进行分类；

根据所述内核开发规范接收所述内核开发人员递交的内核补丁，对所述内核补丁进行代码审查和功能测试，将通过代码审查和功能测试的内核补丁进行归档获得内核主版本；

根据所述内核开发规范对所述内核主版本进行版本测试；

根据所述内核开发规范将通过版本测试的内核主版本进行归档获得内核发布版本，并发布所述内核发布版本。

12.根据权利要求11所述的方法，其特征在于，所述内核开发规范包括：内核编程规范、内核文件分类规范、补丁分类规范、内核测试规范、以及内核开发人员角色和职责规范。

13.根据权利要求12所述的方法，其特征在于，所述根据所述内核开发规范对内核文件进行分类，包括：

根据内核文件名、内核文件后缀类别和内核文件存储目录，将所述内核文件分类为源文件、配置文件和辅助文件；其中，所述源文件包括头文件、固定文件、驱动源文件、架构源文件和公共源文件；所述配置文件包括驱动配置文件、架构配置文件和公共配置文件。

14.根据权利要求13所述的方法，其特征在于，所述根据所述内核开发规范接收内核开发人员递交的内核补丁，对所述内核补丁进行代码审查和功能测试，将通过代码审查和功能测试的内核补丁进行归档获得内核主版本，包括：

接收内核开发人员递交的所述内核补丁，判断所述内核补丁中是否包括内核补丁编译检查表；若是，则为内核开发组长分配审查权限，根据所述内核编程规范对所述内核补丁进行代码审查，将符合所述内核编程规范的内核补丁确定为第一有效内核补丁；

为功能测试工程师分配测试权限，根据所述内核测试规范和所述第一有效内核补丁的内核文件修改范围，对所述第一有效内核补丁进行驱动测试、架构测试或者公共测试，将通过驱动测试、架构测试或者公共测试的所述第一有效内核补丁确定为第二有效内核补丁；

根据所述补丁分类规范确定所述第二有效内核补丁的级别，根据所述级别为相应的内核开发人员分配归档权限，对所述第二有效内核补丁进行归档获得所述内核主版本。

15.根据权利要求14所述的方法，其特征在于，所述级别包括：驱动级、架构级、芯片级、公共级和主干级，所述根据所述补丁分类规范确定所述第二有效内核补丁的级别，根据所述级别为相应的内核开发人员分配归档权限，包括：

若所述第二有效内核补丁的内核文件修改范围为驱动源文件和驱动配置文件，则确定所述第二有效内核补丁的级别为所述驱动级，为内核开发组长分配驱动级补丁归档权限；

若所述第二有效内核补丁的内核文件修改范围为驱动源文件和架构源文件，则确定所述第二有效内核补丁的级别为所述架构级，为内核开发组长分配架构级补丁归档权限；

若所述第二有效内核补丁的内核文件修改范围为架构源文件、架构配置文件、公共源文件和公共配置文件，则确定所述第二有效内核补丁的级别为所述芯片级，为内核开发经理分配架构级补丁归档权限；

若所述第二有效内核补丁的内核文件修改范围为驱动源文件、驱动配置文件、架构源文件、架构配置文件、公共源文件和公共配置文件，则确定所述第二有效内核补丁的级别为所述公共级或者主干级，为内核开发经理或者公司主管分配公共级补丁归档权限或者主干级补丁归档权限。

16.根据权利要求12所述的方法，其特征在于，所述根据所述内核开发规范对所述内核主版本进行版本测试，包括：

为版本测试工程师分配测试权限，根据所述内核测试规范对所述内核主版本进行版本测试。

17.根据权利要求12所述的方法，其特征在于，所述根据所述内核开发规范将通过版本测试的内核主版本进行归档获得内核发布版本，并发布所述内核发布版本，包括：

为配置管理员分配归档权限，对通过版本测试的内核主版本进行归档获得所述内核发布版本；

为发布工程师分配发布权限，发布所述内核发布版本。

18.根据权利要求11至17任一所述的方法，其特征在于，所述内核编程规范包括：地址空间配置规则、物理地址空间访问规则、全局变量使用规则、编译约定和补丁递交要求。

19.根据权利要求11至17任一所述的方法，其特征在于，所述内核开发人员包括：公司主管、内核开发经理、内核开发组长、开发工程师、测试组长、功能测试工程师、版本测试工程师、发布工程师和配置管理员。

20.根据权利要求11至17任一所述的方法，其特征在于，还包括：

通过规范库存储所述内核开发规范；

通过受控库存储内核开发过程中的各所述内核主版本；

通过存档库存储内核开发过程中的各所述内核发布版本。