一种通信设备Live Update功能实现的方法
阅读：332发布：2020-05-11
专利汇可以提供一种通信设备Live Update功能实现的方法专利检索，专利查询，专利分析的服务。并且本 发明 公开了一种通信设备Live Update功能实现的方法，主要包括定义patch文件类型，定义patch安装类型，patch激活类型，patch函数命名，平台及CPU的差异的实现，编译动态库及打包， 补丁 冗余备份主控多 进程 及多单板并发激活,用户告警、事件的提示等步骤。本发明对于一些需要立即修复的bug且能用hot补丁解决的可以用hot补丁立即解决,当一些初始化静态全局对象需要增加或者减少时可以通过一次性补丁解决；本发明技术方案的bug的修复不需要发布新的版本，具有开发周期短、测试针对性强、业务中断时间短、维护性强等优点。，下面是一种通信设备Live Update功能实现的方法专利的具体信息内容。
1.一种通信设备Live Update功能实现的方法，其特征在于，主要包括：
1)定义patch文件类型；
2)定义patch安装类型；
3)patch激活类型；
4)patch函数命名；
5)平台及CPU的差异的实现；
6)编译动态库及打包；
7)补丁冗余备份；
8)主控多进程及多单板并发激活；
9)用户告警、事件的提示。
2.根据权利要求1所述的通信设备Live Update功能实现的方法，其特征在于，所述的定义patch文件类型，主要包括：
1.1)文件类型out；
1.2)文件类型rbf、bin；
1.3)文件类型process。
3.根据权利要求1所述的通信设备Live Update功能实现的方法，其特征在于，所述的定义patch安装类型，主要包括：
2.1)hot热补丁；
2.2)warm补丁；
2.3)cold补丁。
4.根据权利要求1所述的通信设备Live Update功能实现的方法，其特征在于，所述的patch激活类型，主要包括：
3.1)激活(install)；
3.2)取消激活(uninstall)。
5.根据权利要求1所述的通信设备Live Update功能实现的方法，其特征在于，所述的patch函数命名，主要包括：
4.1)普通函数补丁的命名；
4.2)一次性函数补丁函数的命名；
4.3)一次性补丁卸载函数的命名；
4.4)patch中新增加的函数的命名。
6.根据权利要求1所述的通信设备Live Update功能实现的方法，其特征在于，所述的平台及CPU的差异的实现中，平台的差异实现主要包括：
5.1)Linux操作系统平台的实现；
5.2)Vxworks操作系统平台的实现；
CPU的差异实现主要包括：
5.3)Power PC架构的实现；
Power PC中寄存器r11为空闲寄存器，可以用于临时存放；
5.4)ARM架构的实现；
ARM中可以用r12作为跳转的地址；
5.5)MIPS架构的实现。
7.根据权利要求3所述的通信设备Live Update功能实现的方法，其特征在于，所述的编译动态库及打包：
对于目标文件的生成是用动态库的形式发布，为了支持编译的动态库能从版本文件中找到原函数的地址，需要做如下处理：
在版本文件的主函数中加入-rdynamic的编译选项，或者是-export-dynamic的链接选项；
在编译目标文件的时候加入-fPIC和—shared的编译选项；
当动态库制作完成后，用打包压缩工具制作成最后的压缩包发给测试或者客户。
8.根据权利要求3所述的通信设备Live Update功能实现的方法，其特征在于，所述的补丁冗余备份：
通信设备是有两块MCP的，MCP之间是冗余备份的，当激活patch的时候同步到备用。
9.根据权利要求3所述的通信设备Live Update功能实现的方法，其特征在于，所述的主控多进程及多单板并发激活：
上位机(EMS/CLI)会下发激活patch的命令，通信设备(网元)除了激活主进程(rcpd)外，还需要激活主控中的其它进程(eswp、cfgd、DSWP.out、oswp)，同时当多个单板在位的时候还需要同时激活单板上的patch，实现并发激活。
10.根据权利要求4所述的通信设备Live Update功能实现的方法，其特征在于，所述的用户告警、事件的提示：
9.1)patch激活成功事件；
9.2)patch安装失败告警；
9.3)patch预激活失败事件。
一种通信设备Live Update功能实现的方法
技术领域
背景技术
[0002] 目前主流的通信设备软件开发流程是在一个较长的周期内把该版本涉及的功能开发完，充分测试后发布给市场客户，由于测试实验室不能完全覆盖客户的应用需求，会在较多的方面存在可大可小的差异，这些差异包括:
[0003] 1.网络拓扑不同；
[0004] 2.运行环境不同；
[0005] 3.配置顺序不同；
[0006] 4.运行周期不同。
[0008] 1.针对代码问题发布新的版本；
[0010] 3.针对业务卡复位可解决的实行复位业务子卡；
[0011] 4.针对冗余系统的且倒换能解决的实行倒换处理。
[0012] 通信设备最主要的是能传输可靠的带宽，给用户提供稳定的业务。但是以上方案在实行的过程中都有可能给客户带来一些明显的或是潜在的业务影响，如需要对整个设备重启才能修复好的或是要复位单块业务子卡才能解决的bug，那么在重启后到设备能正常操作的这段时间内，客户的业务是断的。所以这种情况下开发通信设备Live Update功能的实现显的特别的重要和有意义。
发明内容
[0013] 本发明的目的就是要解决和减少技术支持、研发、运营商等的压力，使得在设备出现bug的时候能尽可能在风险较小、业务中断时间较短的情况下得到修复，并且是在设备运行的状态下对通信设备进行升级，从而使问题得到解决。
[0014] 本发明的技术方案是这样的：
[0015] 本发明公开了一种通信设备Live Update功能实现的方法，主要包括：
[0016] 1)定义patch文件类型；
[0017] 2)定义patch安装类型；
[0018] 3)patch激活类型；
[0019] 4)patch函数命名；
[0020] 5)平台及CPU的差异的实现；
[0021] 6)编译动态库及打包；
[0022] 7)补丁冗余备份；
[0024] 9)用户告警、事件的提示。
[0025] 作为进一步地改进，本发明所述的定义patch文件类型，主要包括：
[0026] 1.1)文件类型out
[0027] 1.2)文件类型rbf、bin
[0028] 1.3)文件类型process
[0029] 作为进一步地改进，本发明所述的定义patch安装类型，主要包括：
[0030] 2.1)hot热补丁
[0031] 2.2)warm补丁
[0032] 2.3)cold补丁
[0033] 作为进一步地改进，本发明所述的patch激活类型，主要包括：
[0034] 3.1)激活(install)
[0035] 3.2)取消激活(uninstall)
[0036] 作为进一步地改进，本发明所述的patch函数命名，主要包括：
[0037] 4.1)普通函数补丁的命名
[0038] 4.2)一次性补丁函数的命名
[0039] 4.3)一次性补丁卸载函数的命名
[0040] 4.4)patch中新增加的函数的命名
[0041] 作为进一步地改进，本发明所述的平台及CPU的差异的实现中，平台的差异实现主要包括：
[0043] 5.2)Vxworks操作系统平台的实现
[0044] CPU的差异实现主要包括：
[0045] 5.3)Power PC架构的实现
[0046] Power PC中寄存器r11为空闲寄存器，可以用于临时存放；
[0047] 5.4)ARM架构的实现
[0048] ARM中可以用r12作为跳转的地址；
[0049] 5.5)MIPS架构的实现
[0050] 作为进一步地改进，本发明所述的编译动态库及打包：
[0051] 对于目标文件的生成是用动态库的形式发布，为了支持编译的动态库能从版本文件中找到原函数的地址，需要做如下处理：
[0052] 在版本文件的主函数中加入-rdynamic的编译选项，或者是-export-dynamic的链接选项；
[0053] 在编译目标文件的时候加入-fPIC和—shared的编译选项；
[0054] 当动态库制作完成后，用打包压缩工具制作成最后的压缩包发给测试或者客户。
[0055] 作为进一步地改进，本发明所述的补丁冗余备份：
[0056] 通信设备是有两块MCP的，MCP之间是冗余备份的，当激活patch的时候同步到备用。
[0057] 作为进一步地改进，本发明所述的主控多进程及多单板并发激活：
[0058] 上位机(如EMS/CLI)会下发激活patch的命令，通信设备(网元)收到后除了激活主进程(rcpd)外，还需要激活主控中的其它进程(eswp、cfgd、DSWP.out、oswp)，同时当多个单板在位的时候还需要同时激活单板上的patch，实现并发激活。
[0059] 作为进一步地改进，本发明所述的用户告警、事件的提示：
[0060] 9.1)patch激活成功事件；
[0061] 9.2)patch安装失败告警；
[0062] 9.3)patch预激活失败事件。
[0063] 本发明的有益效果如下：
[0064] 1、本发明技术方案中的1.1)，2.1)，3.1),4.1),5.1),6)，8)以实现对于一些需要立即修复的bug且能用hot补丁解决的可以用hot补丁立即解决；
[0065] 2、本发明技术方案1.2),2.3),3.1)以实现当涉及硬件的FPGA等出现问题时可以通过rbf/bin补丁来解决；
[0066] 3、本发明技术方案1.1)，2.1)，3.1)，4.2)，6)，8)以实现当一些初始化静态全局对象需要增加或者减少时可以通过一次性补丁解决；
[0067] 4、本发明技术方案1.1)，2.1)，3.1)，4.4)，6)，8)以实现由于patch可以新增加函数及C++的成员函数，可以通过patch解决一些较大的功能问题；
[0068] 5、本发明技术方案8)以实现控制平面和数据平面对应的板卡可以并行激活，保证了业务与控制的管理；
[0069] 6、本发明技术方案5)以实现平台、多CPU架构的支持，从而使得在不同的业务板卡出现bug时可以得到修复；
[0070] 7、本发明技术方案7)以实现由于核心数据板卡也是冗余备份的，在核心数据板卡出现bug时且需要cold/warm解决时，结合板卡管理可以使得数据板卡一块块复位，从而保证了业务不受影响；
[0071] 8、本发明技术方案8)以实现嵌入式设备拥有多进程，这就决定了多人开发各个进程，支持了多进程的并发激活可以让代码出现bug有所有保障。
[0072] 本发明的通信设备Live Update功能实现的方法，具体是指在设备运行态时对设备存在的bug进行在线修复，这种bug包括嵌入式设备某个进程上的应用程序bug、硬件产生的bug、BSP(板级升级包)驱动产生的bug、协议状态机的bug，甚至是Live Update自身的bug等。这种bug的修复不需要发布新的版本，具有开发周期短、测试针对性强、业务中断时间短、维护性强等优点。附图说明
[0073] 图1是patch函数跳转简图；
[0074] 图2是函数及patch文件书写规则；
[0075] 图3是patch的汇编指令机制；
[0076] 图4是编译动态库并打包压缩；
[0077] 图5是patch文件描述示意图；
[0078] 图6是patch冗余备份；
[0079] 图7是多进程及多子卡patch并行激活。
具体实施方式
[0080] 本发明公开了一种通信设备Live Update功能实现的方法，主要包括：
[0081] 1)定义patch文件类型
[0082] 主要有以下几种：
[0083] 1.1)文件类型out
[0084] out类型的补丁是针对应用程序代码的，这种类型的代码是纯软件的，解决逻辑上的业务功能。单板和主控都可以有out补丁，通过文件名的不同加以区分。out补丁就是把文件编译成动态库。
[0085] 1.2)文件类型rbf、bin
[0086] rbf是指跟硬件相关的一些控制FPGA的可编程逻辑器件；bin是指很多脚本、应用程序打包成的一个可执行程序。也就是说当硬件相关的代码出现bug的时候也可以通过patch解决。
[0087] 1.3)文件类型process
[0088] 在以Linux为平台的嵌入式设备中，很多都是多进程、多线程的一个设备，当涉及修改的代码较多，或者本Live Update无法完成函数级别替换时，支持整个进程(process)的Live Update。
[0089] 由于进程的文件较大，大的有好几百M,所以必须对编译好的可执行程序进行压缩，这样可以减小patch的大小，同时也可以节省系统的内存。
[0090] 2)定义patch安装类型
[0091] 对于具体的某一个发布的patch，可以指明这个patch将要激活的动作，具体有如下几种：
[0092] 2.1)hot热补丁
[0093] 作为hot热补丁，意思是当对这个patch激活后，函数立即得到的替换，功能得到修复。
[0094] 2.2)warm补丁
[0095] 该补丁意思是要对MCP、子卡做软复位才能生效，对MCP做软复位的时候，跑在子卡上的业务是不受影响的；当业务子卡软复位的时候，管理层面的是不受影响的。
[0096] 2.3)cold补丁
[0097] 该补丁意思是要对MCP、子卡做硬复位才能生效。很多系统初始化的代码，由于在系统硬复位的时候才能被调用到，所以对应的patch也需要做cold复位，还有一个原因是有些板卡不支持软复位，只能硬复位解决。
[0098] 3)patch激活类型
[0099] patch激活类型与3)描述的patch安装类型是不一样的，安装类型是影响MCP、子卡的复位情况的，而激活类型主要有如下两种：
[0100] 3.1)激活(install)
[0101] 该类型表示当前patch是要激活的，是针对新的patch而言的。
[0102] 3.2)取消激活(uninstall)
[0103] 该类型表示之前的patch要取消激活，是针对之前发布的patch的。因为之前发布的patch也有可能有bug或者要对之前发布的patch加一些新的功能，所以可以采取uninstall这个patch，install新的patch，从而达到对原来patch的修改。
[0104] 4)patch函数命名
[0105] 为了区分是不是patch函数，我们要对要打补丁的函数进行名称修饰，具体有如下几种：
[0106] 4.1)普通函数补丁的命名
[0107] 对于普通函数必须以_lup_patch_作为函数的结尾，比如old函数是int function_a(int a),那么patch函数必须是int function a lup_patch_(int a)。
[0108] 4.2)一次性补丁函数的命名
[0109] 一次性补丁是指在patch激活的过程中会被调用，且只会被调用一次，它没有原有的函数，是在新的目标文件中被新定义的。
[0110] 函数名称固定为int lup_init_once_lup_patch_()。
[0111] 4.3)一次性补丁卸载函数的命名
[0112] 由于应用场合的不同，可能需要对一次性补丁进行uninstall，但是如果一次性补丁中有创建一个临时任务、申请了内存、信号量等资源时，当uninstall时就会存在资源泄露，所以必须提供机会让一次性补丁有卸载时释放资源，具体是在写一次性补丁的时候同时写好一次性补丁的卸载函数。
[0113] 一次性补丁的卸载函数有固定的名称为int lup_uninstall_lup_patch_()。
[0114] 4.4)patch中新增加的函数的命名
[0115] 对于patch中新增加的函数，就跟写普通的代码一样，但是要注意的是新增加的函数不能以_lup_patch_结尾，否则会被当做patch函数。
[0116] 5)平台及CPU的差异的实现
[0117] 对于一个可移植性的功能，需要考虑在不同的平台下的支持，这种平台的系统是有差异的，这些差异包括系统函数、应用库、CPU等。
[0118] 具体有如下平台：
[0119] 5.1)Linux操作系统平台的实现
[0120] Linux是一个多进程多线程的操作系统，需要考虑多进程共享的情况[0121] 5.2)Vxworks操作系统平台的实现
[0122] Vxworks是一个多线程的操作系统，它只有一个进程
[0123] 由于MCP、子卡使用不用的CPU。CPU架构的不同带来的是汇编指令的不同，同时不同的CPU大小端字节序也是不同的。因此需要对不同的CPU做各自不同的处理，具体有如下CPU架构：
[0124] 5.3)Power PC架构的实现
[0125] 大端的CPU
[0126] 5.4)ARM架构的实现
[0127] 小端的CPU
[0128] 5.5)MIPS架构的实现
[0129] 大端的CPU
[0130] 6)编译动态库及打包
[0131] 对于目标文件的生成，是用动态库的形式发布的。为了支持编译的动态库能从版本文件中找到原函数的地址，需要做如下处理：
[0132] 在版本文件的主函数中加入-rdynamic的编译选项，或者是-export-dynamic的链接选项，目的是把函数加到动态符号表中去，这样通过linux的动态加载函数dlopen()、dlsym()等就能成功。
[0133] 在编译目标文件的时候加入-fPIC和—shared的编译选项，使得该目标文件是一个动态库。
[0134] 当动态库制作完成后，就可以用打包压缩工具制作成最后的压缩包发给测试或者客户。
[0135] 7)补丁冗余备份
[0136] 为了提高系统的稳定性及可靠性，产品在设计的时候都要做冗余备份，也就是说MCP是有两块的，有主备之分。当激活一个patch的时候除了把当前工作的主用给激活外，还需要对备用的MCP也激活，这样当MCP做倒换的时候主备用的patch是一致的，功能也就一致。
[0137] 8)主控多进程及多单板并行激活
[0138] 对于嵌入式通信设备往往是多进程的，目前主进程设备通过消息队列发给多个从进程设备，从而实现多进程的并发激活。支持的进程有：
[0139] rcpd(设备的管理进程，也是激活patch的主进程)、cfgd(配置进程，负责数据管理)、eswp(负责路由的配置，同时也是CFPAL的核心进程)、oswp(数据平面协议进程)、DSWP.out(控制平面协议进程)
[0140] 9)用户告警、事件的提示
[0141] 为了提高友好性，需要对激活成功或失败的补丁进行提示，这样研发人员就可以第一时间查看。再则由于现场应用的复杂性(如CPU利用率过高、内存使用不足等)，测试过的patch在现场部署的时候也有失败的可能，所以需要结合告警和事件来通知使用的人patch激活的状态，从而采取一些措施。
[0142] 9.1)patch激活成功事件；
[0143] 9.2)patch安装失败告警；
[0144] 9.3)patch预激活失败事件。
[0146] 首先对技术方案中的英文缩写进行列表说明：
[0147]英文缩写 具体描述
MCP 主控卡
CLI 命令行界面
Live Update 在线升级和更新
PPC 一种CPU处理器
MIPS 一种CPU处理器
ARM 一种CPU处理器
Vxworks 风河操作系统
Linux 嵌入式操作系统
Patch 补丁
TA 影响业务
Bug 一种程序错误
ELF 可执行连接文件格式
BootScok 内部的文件传输协议
rcpd 主控管理的进程名字
cfgd 主控配置的进程名字
DSWP.out 协议处理的进程名字
MCP 主控卡
CLI 命令行界面
Live Update 在线升级和更新
PPC 一种CPU处理器
MIPS 一种CPU处理器
ARM 一种CPU处理器
Vxworks 风河操作系统
Linux 嵌入式操作系统
Patch 补丁
TA 影响业务
Bug 一种程序错误
ELF 可执行连接文件格式
BootScok 内部的文件传输协议
rcpd 主控管理的进程名字
cfgd 主控配置的进程名字
DSWP.out 协议处理的进程名字
[0148] 本发明公开了的一种通信设备Live Update功能实现的方法，主要功能包括：
[0149] 1)定义patch文件的类型
[0150] 1.1)文件类型out
[0151] 1.2)文件类型rbf、bin
[0152] 1.3)文件类型process
[0153] 2)patch安装类型
[0154] 2.1)hot热补丁
[0155] 补丁的核心是函数的跳转，函数的跳转与C语言的名称修饰有很大的关系，因为函数跳转的前提是要找到patch前后的符号表。
[0156] 符号表对于C和C++代码是不一样的，具体差别是：
[0157] C代码的符号表跟实际的代码的符号是一样的，开头和结尾不会加上别的符号进行修饰；而C++的符号表对于C++普通函数和C++成员函数是不一致的，C++的普通函数以_Z开头，然后加上函数名称，C++的类的成员函数则是会在原函数前加上_ZN，C++的符号修饰还与函数的参数相关，这也是C++能实现函数重载的重要原因。
[0158] 代码编译的时候就会对函数进行名称修饰，这个编译器决定的，同样patch函数在编译的时候也会对名称进行修饰，这样就可以通过patch函数找到原函数的符号表。
[0159] 如图1所示，函数的跳转简图。正常的流程是函数A调用函数B，但是现在函数B出现了Bug，必须对函数B进行修改，并发布patch，当hot补丁激活后，函数的调用流程就变为函数A调用B_lup_patch_()。
[0160] 2.2)warm补丁
[0161] 2.3)cold补丁
[0162] 3)patch激活类型
[0163] 3.1)激活(install)
[0164] 3.2)取消激活(uninstall)
[0165] 4)patch函数命名
[0166] 4.1)普通函数补丁的命名
[0167] 4.2)一次性补丁函数的命名
[0168] 4.3)一次性补丁卸载函数的命名
[0169] 4.4)patch中新增加的函数的命名
[0170] 如图2所示，函数及patch文件书写规则，描述了具体的内容。如文件file.c里面的函数A出现了Bug，那么可以编写函数及文件如下：
[0171] 新起一个文件且命名为file_patch.c，然后里面包含函数A_lup_patch_。
[0172] 5)平台及CPU的差异的实现
[0173] 5.1)Linux操作系统平台的实现
[0174] 5.2)Vxworks操作系统平台的实现
[0175] 5.3)Power PC架构的实现
[0176] 5.4)ARM架构的实现
[0177] 5.5)MIPS架构的实现
[0178] CPU架构的不同，对应的是汇编指令的不同，可以通过linux命令objdump来查看具体一个函数的汇编代码。
[0179] 通过把一个函数反汇编，可以得到一个函数的入口是有许多的汇编代码组成的，而入口函数的前4条汇编指令是跳转指令，所以得到这个信息后就可以修改前面的汇编指令从而使得函数的汇编代码得到替换。
[0180] 如图3所示，patch的汇编指令机制。当加载好动态库后可以得到patch函数B_lup_patch_的地址，然后通过把patch符号表中11个字符_lup_patch_剥去可以得到补丁函数对应的原函数B的地址，得到两个地址之后，就可以根据不同的CPU架构修改原函数B的前面4条汇编指令。
[0181] 6)编译动态库及打包
[0182] 在编译目标文件(object)的时候，需要接个C和C++的编译选项，使得源代码是动态的且能被其它的外部的代码能找到，另外一个是要使得该目标文件的代码是与位置无关的，这样多个进程可以共享代码段，节省内存资源。
[0183] 如图4所示为编译目标文件为动态库，且打包成压缩文件的过程。首先把patch文件编译成目标文件(如A.o),然后把目标文件A.o加上编译选项后编译成动态库，之后就可以对每一个动态库进行打包，压缩成bg_patch.romfs文件。
[0184] 在打包的过程中，可以对每一个补丁做描述，这样就可以清晰的知道这个补丁解决了什么问题，该问题对应什么问题单号，安装了这个补丁会不会对业务有影响，如果有影响可以及时的提示给客户，同时对于主控中的多进程补丁，还必须指定这个问题是在哪个进程上解决，还有这个补丁对应的是什么网元，网元上的什么版本等等。这样可以做到对问题的有效追溯及能正确的安装上这个补丁。具体如图5所示patch文件描述图中对每个patch的描述。描述完成后可以点击pack.bat脚本，这样就可以打包成最后的压缩包bg_patch.romfs文件了。
[0185] 7)补丁冗余备份
[0186] 如图6所示patch冗余备份，冗余备份指的是MCP的上的备份，因为设备有两块MCP，主用的rcpd会通过ftp模块把patch同步到备用的MCP板卡上，同步完成后会发个消息给备用板卡，告诉它激活patch，收到消息后备用MCP板卡激活patch流程跟主用MCP是一致的。
[0187] 8)主控多进程及多单板并行激活
[0188] 目前在通信设备中主控有多个进程，而业务子卡上只有一个进程。如图7所示多进程及多子卡patch并行激活。当rcpd收到EMS/CLI上下发的激活命令后，rcpd会通过管道告诉主控上的其它进程，如eswp、cfgd、DSWP.out、oswp等，同时如果有子卡的补丁，也会把相应的补丁同步给子卡。这样补丁就会在各个进程或者子卡上被激活。
[0189] 因为激活补丁的时候补丁文件只存在于主控上，所以当某一块单板需要激活补丁的时候首先要做的就是从主控中把补丁文件从主控中下载到单板上。下载的过程分两种，一个是运行态，一个是启动态(boot态)。
[0190] 运行态的时候，板卡轮询模块负责轮询版本不一致，不一致时进行升级。当激活patch的时候，主控MCP上的rcpd会有一个版本号，该版本号包括正常的大包版本号及patch号。子卡在未激活patch的时候只有大包的版本号，没有patch的版本号，所以此时子卡与MCP的版本号是不一致的，当板卡管理模块轮询到不一致的时候就会对子卡进行patch升级。升级后主控与子卡的版本就会一致。
[0191] 启动态是指在子卡复位的阶段，子卡到主控测获取patch的过程。这个过程采用的是bootsock，bootsock是内部定义的一种私有协议，它通过IDPROM来辨别每个板卡的差异。
[0192] 9)用户告警、事件的提示
[0193] 9.1)patch激活成功事件；
[0194] 9.2)patch安装失败告警；
[0195] 9.3)patch预激活失败事件；
[0196] patch预激活是与立即激活对应的，可以设定一个对业务中断最少的时间，然后这个时间到了之后会自动把patch激活。
[0197] 实施例
[0198] 当出现问题的时候，研发需要分析该bug能不能通过patch解决，如果能通过patch解决，那么做成hot、warm还是cold，同时还是分析能不能对业务造成影响。下面以文件vrrp_opt.c里面的bsp_vrrpStatusUpdateInit()出现bug为例：
[0199] 首先因为这个是一个应用软件上的代码，根据1)定义patch文件类型，可以定义这是一种out补丁可以把该patch归为MCP板卡out，可以命名为bg_patch_mcp_v1.out。由于bsp_vrrpStatusUpdateInit是个初始化的函数，必须复位后才能生效，因此根据2)定义patch安装类型，可以把该patch定义成warm补丁。目的是修改这个函数，因此根据3)patch激活类型，可以把这个补丁的激活类型设定为install补丁。此次要修改的函数在原来的版本中是存在的，而不是一个新加的函数，也不是一次性的补丁函数，可以根据4)patch函数命名中的普通函数补丁的命名，命名bsp_vrrpStatusUpdateInit_lup_patch_()。对于一个特定的补丁，肯定知道这个补丁将要运行的平台及CPU，此次是5)平台的差异的实现中的Linux操作系统平台。MCP平台的CPU架构是Power PC架构的，按照Power PC中的大端字节序来处理。之后就可以根据6)编译动态库及打包，把压缩文件bg_patch.romfs发布给测试或者客户了。测试或者客户可以激活这个patch，激活的时候，patch会同步到备用的MCP上7)补丁的冗余备份，同时会在8)主控多进程及多单板并发激活中把rcpd的进程给激活patch。激活成功后可以根据9)用户告警、事件的提示，得到patch激活成功事件。
[0200] 以上所述并非是对本发明的限制，应当指出：对于本技术领域的普通技术人员来说，在不脱离本发明实质范围的前提下，还可以做出若干变化、改型、添加或替换，这些改进和润饰也应视为本发明的保护范围。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 应用升级方法及装置 | 2020-05-08 | 936 |
| 基于代码变更历史的软件代码质量问题自动修复方法、系统及介质 | 2020-05-08 | 587 |
| 一种用于脱硫尾气烟囱的光固化纳米防腐材料及其施工工艺 | 2020-05-11 | 8 |
| 一种智能配变终端智慧运维系统 | 2020-05-11 | 42 |
| 应用的热修复方法和装置 | 2020-05-08 | 552 |
| 基于邻域回归与局部信息的图像重建方法 | 2020-05-08 | 556 |
| 漏洞检测方法、装置、电子设备及可读存储介质 | 2020-05-11 | 164 |
| 一种操作系统补丁批量自动化更新管理方法及系统 | 2020-05-11 | 669 |
| 电子红包检测策略更新方法、装置及终端设备 | 2020-05-11 | 173 |
| 面向源代码双极性软件安全漏洞图谱构建方法 | 2020-05-11 | 893 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
QQ群二维码
意见反馈
意见反馈