CN114489822A - 热启动实现方法的装置 - Google Patents

Abstract

本发明公开了一种热启动实现方法和装置，其中所述方法包括：于固定内存中申请一内存区域；所述内存区域作为用于存放路由信息的软表；将上层生成的路由信息实时存放在所述软表中；在生成的路由信息结构体中，设置一用于标识是否对硬表完成配置的标识位，并在对硬表完成配置后，更新所述标识位。通过所述装置和方法，可以解决现有技术中热启动可能造成软硬表不一致的问题。

Description

热启动实现方法的装置

技术领域

本发明涉及网络通信技术，特别是涉及一种热启动实现方法和装置。

背景技术

直接内存读写热启动(WarmBoot，WB)是在硬件运行而不中断数据转发的情况下重新启动设备驱动程序软件，可应用于如应用软件升级，驱动程序升级和软件挂死恢复等情况下。在热启动过程中，软件通过特殊的初始化顺序，可以不影响转发层面而重新建立内部控制状态。一般情况下，软件内部状态的建立可通过以下方式来完成：

通过从硬件中直接读取寄存器和表，来重新构建软件状态。在芯片配套软件SDK热启动前，可以将数据通过API保存在本地磁盘文件，也可以存储到上层用户指定的外部存储器上。当热启动时通过API从外部储存的数据源读取数据，来重新构建软件状态。

目前比较常见的热启动方式包括：

(1)***升级过程之前，一次性将运行状态相关软表，同步到预设的数据库中，即数据库模式。但由于触发一次WarmBoot Sync到数据库中耗时比较长(可能长达10几分钟)，而在该过程中，上层用户是不能够下发新业务的，所以数据库存储不支持软表及时或者实时更新，只能支持用户有计划的软件升级等功能。另外，由于数据库占用存储内存比较大，而一般嵌入式设备内存都有限，很多情况下难以支持数据库模式，限制了其应用；

(2)针对数据库模式的问题，当前实际应用中，还存在另一种方式，即用户独立开辟一块固定内存，运行时数据软表仍然从***内存中申请。***中定时触发运行时数据，到固定内存中同步。该方案，由于软表是直接存储在内存中，用户保存相关模块的软表，只需要几十毫秒。上层用户或者SDK可以定时主动触发软表保存到固定内存中。

上述方式(2)解决了嵌入式一些设备中不支持数据库，及需要能够支持及时同步场景的问题。由于是直接存储到内存中，读取和恢复都比较快，性能相对数据库存储更好。但仍可能存在一个问题，即存储数据时，还是需要上层或者SDK定时将软表同步到固定内存中。如果正好在软表更改后，但还没来得及同步到固定内存中，此时一旦出现如CPU挂死等问题，则该软表数据会丢失。等到热启动后，有可能造成软硬表不一致问题。

发明内容

本发明实施例所要解决的技术问题是，如何解决现有技术中，热启动可能造成软硬表不一致的问题。

为了解决上述的技术问题，本发明实提供了一种热启动实现方法，其中，包括：于固定内存中申请一内存区域；所述内存区域作为用于存放路由信息的软表；将上层生成的路由信息实时存放在所述软表中；在生成的路由信息结构体中，设置一用于标识是否对硬表完成配置的标识位，并在对硬表完成配置后，更新所述标识位。

上述的热启动实现方法，其中，还包括：当热启动时，分析出路由信息在所述内存区域中的存放地址；根据路由信息结构体中的所述标识位，判断是否完成对硬表配置；如果判定为未完成，则删除所述软表。

上述的热启动实现方法，其中，所述固定内存包括物理介质内存，或者文件***中的文件通过内存映射到用户态形成的虚拟地址空间。

上述的热启动实现方法，其中，SDK执行对所述固定内存的操作，且所述固定内存的大小大于等于SDK运行所需要的内存。

上述的热启动实现方法，其中，所述将上层生成的路由信息实时存放在所述软表中包括：当路由信息更新时，同步更新所述内存区域中的路由信息；以及，当路由信息被删除时，释放所述内存区域。

为了解决上述的技术问题，本发明实提供了一种热启动实现装置，其中，包括：设置单元，用于于固定内存中申请一内存区域；所述内存区域作为用于存放路由信息的软表；处理单元，用于将上层生成的路由信息实时存放在所述软表中；以及，在生成的路由信息结构体中，设置一用于标识是否对硬表完成配置的标识位，并在对硬表完成配置后，更新所述标识位。

上述的热启动实现装置，其中，所述处理单元还用于，当热启动时，分析出路由信息在所述内存区域中的存放地址；根据路由信息结构体中的所述标识位，判断是否完成对硬表配置；如果判定为未完成，则删除所述软表。

上述的热启动实现装置，其中，所述固定内存包括物理介质内存，或者文件***中的文件通过内存映射到用户态形成的虚拟地址空间。

上述的热启动实现装置，其中，SDK执行对所述固定内存的操作，且所述固定内存的大小大于等于SDK运行所需要的内存。

上述的热启动实现装置，其中，所述处理单元将上层生成的路由信息实时存放在所述软表中包括：当路由信息更新时，同步更新所述内存区域中的路由信息；以及，当路由信息被删除时，释放所述内存区域。

本发明针对现有技术中的问题，通过固定内存中申请一区域作为存放路由信息的SDK软表，达到了实时同步的目的。从而能够避免现有技术需要将软表从实时内存存储到固定内存，在将最终保存数据保存到数据库或者固定内存的过程中，中间存在数据结构的转化，需要一定时间实现数据转化，以及再存储到数据库或者固定内存中等一系列处理操作。本发明能够实现数据的实时同步，支持CPU运行的过程中，即使突然遭遇挂死，在热启动后，也能够完全恢复到CPU挂死之前的状态。另外，由于设置了是否对硬表完成配置的标识位，能够判定是否已对硬表完成配置，可避免出现软硬表不一致的情况。

附图说明

图1是本发明实施例1的流程示意图；

图2是本发明实施例1中步骤S104的流程示意图；；

图3是本发明实施例1固定内存中路由信息头结点的结构示意图。

具体实施方式

现有的热启动方式，针对数据库模式的问题，会为用户独立开辟一块固定内存，运行时数据软表仍然从***内存中申请。***中定时触发运行时数据，到固定内存中同步。该方案，由于软表是直接存储在内存中，用户保存相关模块的软表，只需要几十毫秒。上层用户或者SDK可以定时主动触发软表保存到固定内存中。该方式虽然解决了嵌入式一些设备中不支持数据库，及需要能够支持及时同步场景的问题，但仍可能存在一个问题，即存储数据时，还是需要上层或者SDK定时将软表同步到固定内存中。如果正好在软表更改后，但还没来得及同步到固定内存中，此时一旦出现如CPU挂死等问题，则该软表数据会丢失。等到热启动后，有可能造成软硬表不一致问题。

针对现有技术中的问题，本发明实施例针对现有技术中的问题，通过固定内存中申请一区域作为存放路由信息的SDK软表，达到了实时同步的目的。从而能够避免现有技术需要将软表从实时内存存储到固定内存，在将最终保存数据保存到数据库或者固定内存的过程中，中间存在数据结构的转化，需要一定时间实现数据转化，以及再存储到数据库或者固定内存中等一系列处理操作。本发明能够实现数据的实时同步，支持CPU运行的过程中，即使突然遭遇挂死，在热启动后，也能够完全恢复到CPU挂死之前的状态。另外，由于设置了是否对硬表完成配置的标识位，能够判定是否已对硬表完成配置，可避免出现软硬表不一致的情况。

为使本发明的上述目的、特征和优点能够更为明显易懂，下面结合附图对本发明的具体实施例做详细的说明。

实施例1

本发明实施例的一种热启动实现方法，可广泛应用于所有嵌入式设备，不限于交换网络设备。为了说明方便起见，本实施例以网络路由设备为例进行说明，具体来说，所述热启动实现方法包括：

步骤S101，在固定内存中申请一内存区域；

当用户上层创建三层路由后，执行步骤S101。本实施例的软表是指软件上的维护表，比如软二层转发表，软三层路由表以及软访问控制表等；相对的，硬表则是指硬件上的维护表，比如芯片二层转发表项，芯片三层路由转发表项以及芯片访问控制表等。本实施例与现有技术的区别在于，所述内存区域作为用于存放路由信息的软表，也即，通过SDK运行过程所需要的软表，是直接从固定内存中进行申请的，不需要再将软表从实时内存，存储到固定内存中，从而实现数据的实时同步。

所述固定内存区别于***内存，是独立于***内存存在，并单独管理的。在CPU重启后，固定内存中的内容可以保持不变。如，软件升级或者CPU异常，固定内存保存数据不会丢失，软件重启后，还可以从固定内存中获取数据恢复软表。在具体实施中，所述固定内存包括各种类型的物理介质内存，或者文件***中的文件通过内存映射(MMAP)到用户态形成的虚拟地址空间。SDK执行对所述固定内存的操作，所述固定内存的大小需要大于等于SDK运行所需要的内存。

下面将对固定内存的初始化，申请的过程进行说明。首先，本实施例的全局变量包括：

(1)g_start_addr：固定内存开始地址(用户空间中虚地址可能不一样，但都会指向同一块内存)；

(2)ipuc_app_id：ipuc存放固定内存中key。每种需要实时在固定内存中存储的软表会分配一个app id；

(3)p_ipuc_app_id_node：指向固定内存中存放IPUC信息的头结点，具体结构如图3的ipuc_app_id_node所示；

(4)ipuc_num：当前设备支持的路由条目数；

(5)ipuc_size：结构体ipuc_info_t的大小。

当路由设备冷启动后，在固定内存上的初始化过程包括：

(1)冷启动过程中，首先会根据路由条目数和当前固定内存偏移地址。

p_ipuc_app_id_node＝g_start_addr；

start_addr+＝sizeof(ctc_wb_appid_t)；

start_addr+＝4*(ipuc_num/32)(跳过这段内存，这段内存用来保存ipuc_num分ipuc_info内存，哪部分当前已经使用，赋值给wb_bmp)。

(2)获取到p_ipuc_app_id_node，赋值相关字段，相关字段初始化如下代码所示。其中wb_bmp是用来表示固定内存中存放ipuc_num份ipuc_info路由信息，哪些是已经使用了，存放真正的路由信息，哪些当前还是空的，没有使用。

p_ipuc_app_id_node->app_id＝ipuc_app_id；

p_ipuc_app_id_node->entry_num＝ipuc_num；

p_ipuc_app_id_node->entry_size＝ipuc_size；

p_ipuc_app_id_node->addr_offset＝p_ipuc_add_id_node-start_addr(偏移地址)；

p_ipuc_app_id_node->wb_bmp[ipuc_num/32]＝0；

start_addr+＝sizeof(ctc_wb_appid_t)；

start_addr+＝p_ipuc_app_id_node->entry_num*p_ipuc_add_id_node*entry_size。

(3)保存p_ipuc_app_id_node节点到g_appid_hash

malloc newhash node；(从***内存申请)

将p_ipuc_add_id_node，存放到***内存hash：g_appid_hash。

步骤S102，将上层生成的路由信息实时存放在所述软表中；

路由相关信息，存放在软表中。本实施例中存放路由的软表为关键软表，如步骤S101所示，从固定内存中申请。串联这些路由信息的其他信息，链表、数组、hash等还是从***内存中申请。

本实施例中新建一条路由，并在固定内存申请一块内存(即上述的软表)存放路由信息的具体执行过程包括：

(1)首先从g_appid_hash中，根据ipuc_app_id，获取到p_ipuc_appid_node；

(2)从固定内存中，获取到可用的内存；

遍历p_ipuc_appid_node->wb_bmp，按照bit查找，查找到第一个为0的bit，对应的ipuc_index。

p_ipuc_app_id_node->valid_cnt++；

p_ipuc_app_id_node->wb_bmp[ipuc_index/32]|＝p_ipuc_app_id_node->wb_bmp[ipuc_index％32]；

p_ipuc_info＝g_start_addr+p_ipuc_app_id_node->addr_offset+X*entry_size；

(3)存放路由相关信息到p_ipuc_info

p_ipuc_info->ipda＝ipda；

p_ipuc_info->masklen＝路由掩码；

p_ipuc_info->nexthop＝下一跳出口。

(4)将p_ipuc_info存放到***内存中对应的ipuc_hash_db表。

使用***内存接口malloc，申请hash_bucket_t节点。

hash_bucket_t->data＝p_ipuc_info；

hash_insert(ipuc_hash_db,p_ipuc_info)。

在具体应用中，当删除一条路由时，需要同步从固定内存中释放相应的内存，具体执行过程如下：

(1)将p_ipuc_info从***内存中对应的ipuc_hash_db表释放

hash_free(ipuc_hash_db,p_ipuc_info)；

(2)首先从g_appid_hash中，根据ipuc_app_id，获取到p_ipuc_appid_node；

(3)根据p_ipuc_info地址，算法wb_bmp对应的位，并释放；

ipuc_index＝(p_ipuc_info-g_start_addr-p_ipuc_app_id_node->addr_offset)/entry_size；

p_ipuc_app_id_node->wb_bmp[ipuc_index/32]^＝(1<<p_ipuc_app_id_node->wb_bmp[ipuc_index％32])；

p_ipuc_app_id_node->valid_cnt--。

在具体应用中，当更新路由信息时，需要同步对固定内存中对应的内存区域进行更新，具体执行过程如下：

(1)根据路由信息，从ipuc_hash_db中查找到p_ipuc_info；

ipuc_info.ipda＝ipda；

ipuc_info.masklen＝mask；

p_ipuc_info＝hash_lookup(ipuc_hash_db,&ipuc_info)。

(2)更新对应路由出口信息

p_ipuc_info->nexthop_id＝新的下一跳。

步骤S103，在生成的路由信息结构体中，设置一用于标识是否对硬表完成配置的标识位。

在本发明实施例的路由信息结构体中，标识位在没有完成对硬表配置时置为1，并在对配置芯片，转发表项到硬表完成配置后，更新所述标识位为0清零。通过设置了是否对硬表完成配置的标识位，能够判定是否已对硬表完成配置，可避免出现软硬表不一致的情况。

步骤S104，热启动时，根据固定内存中的路由信息，重新构建软件状态。

当路由模块以热启动方式启动时，此时设备不会配置硬表，而是只重构软表。路由模块根据热启动初始化传入的固定内存地址(即根据固定内存中路由信息指针)，通过偏移计算，得到路由信息存放的地址。

根据路由信息结构体中的所述标识位，判断路由信息中，硬表是否置位。如果置位(本实施例中标识位为1)，则代表实际硬表没有下发到芯片中，存在软硬表不一致现象，删除该软表信息。如果该标识位为0，则代表该软表，对应转发表项存在，处理正常，完成软件状态的重构。

具体来说，当热启动路由表重建后的上述操作包括：

(1)重建***g_appid_hash；

根据固定内存g_start_addr。

先赋值给g_appid_node，根据g_appid_node，算出当前g_appid_node占用固定内存大小。

(2)路由模块初始化时，重建路由表项

首次从g_appid_hash中，查找到p_ipuc_app_id_node；

遍历循环p_ipuc_app_id_node->wb_bmp；

对应的wb_bmp中bit置位，则根据地址偏移获取到p_ipuc_info；

for(index＝0；index<p_ipuc_app_id_node->ipuc_num；index++)；

if(p_ipuc_app_id_node->wb_bmp[index/32]&(1<<

p_ipuc_app_id_node->wb_bmp[index％32]))

{

p_ipuc_info＝g_start_addr+p_ipuc_app_id_node->addr_offset+index*entry_size

hash_bucket＝malloc(sizeof(hash_bucket_t))//从***内存申请

hash_bucket->data＝p_ipuc_info

hash_insert(ipuc_hash_db,p_ipuc_info)

}

本发明实施例，通过SDK软表直接从固定内存中申请，实现了数据的实时同步，支持CPU运行过程中，在突然挂死并热启动后，能够完全恢复到CPU挂死之前的状态，从而使设备和网络的健壮性得到进一步提升。

实施例二

为了解决现有技术中的问题，本实施例还公开了一种热启动实现装置，包括：

设置单元，用于于固定内存中申请一内存区域；所述内存区域作为用于存放路由信息的软表；

处理单元，用于将上层生成的路由信息实时存放在所述软表中；以及，在生成的路由信息结构体中，设置一用于标识是否对硬表完成配置的标识位，并在对硬表完成配置后，更新所述标识位。

在具体实施中，所述处理单元还用于，当热启动时，分析出路由信息在所述内存区域中的存放地址；根据路由信息结构体中的所述标识位，判断是否完成对硬表配置；如果判定为未完成，则删除所述软表。

在具体实施中，所述固定内存包括物理介质内存，或者文件***中的文件通过内存映射到用户态形成的虚拟地址空间。

在具体实施中，SDK执行对所述固定内存的操作，且所述固定内存的大小大于等于SDK运行所需要的内存。

在具体实施中，所述处理单元将上层生成的路由信息实时存放在所述软表中包括：当路由信息更新时，同步更新所述内存区域中的路由信息；以及，当路由信息被删除时，释放所述内存区域。

本领域技术人员可以理解的是，本实施例2的一种热启动实现装置与实施例1的热启动实现装置方法为基于同一发明构思，因此关于相关实施例的内容可以参照前文相应内容处，此处不再赘述。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：ROM、RAM、磁盘或光盘等。

虽然本发明披露如上，但本发明并非限定于此。任何本领域技术人员，在不脱离本发明的精神和范围内，均可作各种更动与修改，因此本发明的保护范围应当以权利要求所限定的范围为准。

Claims (10)

1.一种热启动实现方法，其特征在于，包括：

于固定内存中申请一内存区域；所述内存区域作为用于存放路由信息的软表；

将上层生成的路由信息实时存放在所述软表中；

在生成的路由信息结构体中，设置一用于标识是否对硬表完成配置的标识位，并在对硬表完成配置后，更新所述标识位。

2.如权利要求1所述的热启动实现方法，其特征在于，还包括：

当热启动时，分析出路由信息在所述内存区域中的存放地址；

根据路由信息结构体中的所述标识位，判断是否完成对硬表配置；如果判定为未完成，则删除所述软表。

3.如权利要求1所述的热启动实现方法，其特征在于，

所述固定内存包括物理介质内存，或者文件***中的文件通过内存映射到用户态形成的虚拟地址空间。

4.如权利要求1所述的热启动实现方法，其特征在于，SDK执行对所述固定内存的操作，且所述固定内存的大小大于等于SDK运行所需要的内存。

5.如权利要求1所述的热启动实现方法，其特征在于，所述将上层生成的路由信息实时存放在所述软表中包括：

当路由信息更新时，同步更新所述内存区域中的路由信息；以及，

当路由信息被删除时，释放所述内存区域。

6.一种热启动实现装置，其特征在于，包括：

设置单元，用于于固定内存中申请一内存区域；所述内存区域作为用于存放路由信息的软表；

处理单元，用于将上层生成的路由信息实时存放在所述软表中；以及，

在生成的路由信息结构体中，设置一用于标识是否对硬表完成配置的标识位，并在对硬表完成配置后，更新所述标识位。

7.如权利要求6所述的热启动实现装置，其特征在于，所述处理单元还用于，

当热启动时，分析出路由信息在所述内存区域中的存放地址；

根据路由信息结构体中的所述标识位，判断是否完成对硬表配置；如果判定为未完成，则删除所述软表。

8.如权利要求6所述的热启动实现装置，其特征在于，

所述固定内存包括物理介质内存，或者文件***中的文件通过内存映射到用户态形成的虚拟地址空间。

9.如权利要求6所述的热启动实现装置，其特征在于，SDK执行对所述固定内存的操作，且所述固定内存的大小大于等于SDK运行所需要的内存。

10.如权利要求6所述的热启动实现装置，其特征在于，所述处理单元将上层生成的路由信息实时存放在所述软表中包括：

当路由信息更新时，同步更新所述内存区域中的路由信息；以及，

当路由信息被删除时，释放所述内存区域。

Images