基于ReWorks的內存日志服務設計與優化

2023-02-17 01:54:22黃河任見佘慶,2錢晨楊帆

計算機應用與軟件 2023年1期

黃河任見佘慶,2 錢晨楊帆

1(上海華元創信軟件有限公司上海 200062) 2(華東師范大學軟件工程學院上海 200062)

0 引言

在嵌入式實時系統[1-2]運行環境中出現故障時，僅依靠操作描述和問題現象的記錄，很難定位故障點[3-4]以及分析引發異常的原因[5-7]，占用實際運行環境來進行故障復現是不現實的，還可能引入新的問題，造成更加嚴重的后果與不良影響[8-9]。

目前，通用的日志服務[10-12]是將當前運行任務和系統所有歷史記錄的日志信息，保存到外部存儲介質文件系統中。當系統需要診斷時，導出日志文件并打開獲取所有的日志記錄信息[8,13-15]。但這種方式主要有以下局限性：外部存儲介質使用壽命有限；訪問速度慢；頻繁的讀寫訪問對系統資源消耗嚴重，增大文件系統損壞的概率，使用效率低[16-17]；讀取所有日志記錄信息，龐大而無序[18]，不易區分，難以實現快速、準確的系統故障診斷與定位。對于嵌入式實時系統來說，異常故障導致看門狗復位系統隨時可能發生，基于文件系統進行日志文件的讀寫訪問被中斷，將可能引起文件系統的不一致性，導致文件系統被破壞和文件數據的丟失。因此，傳統的日志文件系統服務不完全適用于嵌入式實時系統的需求，嵌入式實時系統的日志服務需要具備以下特性：

(1) 獨立性，不依賴過多的外設與系統資源。

(2) 實時性，日志服務須要在看門狗復位系統前，在確定的時間內將所有信息保存記錄下來[4]。

(3) 信息完整性，在記錄和讀取解析日志信息時須進行校驗，保證日志的完整有效性。

銳華[19-20](ReWorks)嵌入式實時操作系統是上海華元創信軟件有限公司在國家科技重大專項課題“核心電子器件、高端通用芯片及基礎軟件產品”中定制發布的面向高安全工業控制領域的嵌入式實時操作系統，支持PowerPC、X86、ARM、龍芯、飛騰、C-sky等主流處理器架構，目前廣泛應用于國防電子、工業控制以及軌道交通領域。飛騰[21]FT-2000A/2是國防科技大學自主研發的國產高性能通用雙核微處理器，兼容ARMv8指令集，主要面向嵌入式裝備和工控領域應用產品。基于銳華(ReWorks)嵌入式實時操作系統需提供可靠、有效的日志服務，能在國產硬件平臺的應用程序出現錯誤，甚至程序崩潰系統異常時，完整記錄錯誤出現時間、異常任務上下文[22]和異常任務棧回溯[23]等程序故障的現場信息[24]，并提供方便備份導出分析的方法。

1 內存日志服務系統設計

日志服務主要包括：熱重啟后內容不被破壞的內存空間管理、異常與用戶信息日志記錄、日志查詢顯示和日志備份導出。ReWorks在FT2000A/2國產硬件平臺上的內存日志服務總體架構如圖1所示。

圖1 ReWorks內存日志服務系統架構

在系統初始化時，通過日志內存管理分配日志服務所需內存空間，并設置非cache訪問，保證內存讀寫一致性。在軟復位時設置內存自刷新模式，保證在熱重啟的情況下該內存空間內的數據不會被破壞，為日志服務提供基礎保障。

出現異常故障時，系統捕獲的異常信息與用戶添加的日志信息以及日志校驗碼將寫入日志內存中，當發生嚴重系統錯誤時看門狗將復位系統，在不掉電的軟重啟過程中，日志信息仍保持在日志內存中。通過日志顯示能夠按照日志的級別與類型、起始編號與條數查詢并顯示內存中記錄的通過校驗有效的日志信息，即使在系統軟重啟后，仍可查詢顯示。日志服務為用戶提供4種接口，分別是日志服務初始化、日志記錄、日志查詢顯示和日志備份。內存日志服務工作原理設計如圖2所示。

圖2 日志服務工作原理設計圖

日志服務初始化內容包括內存地址和日志內存數據結構，初始化之后即可使用日志記錄、顯示和備份功能。內存日志服務的關鍵基礎數據結構是日志內存環形資源池。日志內存數據結構主要包括日志內存的魔數、單元大小、總空間、版本、初始化次數、重啟次數等基本配置參數和日志單元環形鏈表，日志內存數據結構如下：

struct err_log

{

u32 magic;/*日志魔數*/

u32 payload_size;/*日志單元大小*/

u32 size;/*日志內存總大小*/

u32 os_version;/*操作系統版本*/

u32 gen_count;/*日志初始化次數*/

u32boot_count;/*系統軟重啟次數*/

ERR_LOG_NODE_LIST nodeList;/*日志單元鏈表*/

};

日志內存環形鏈表由日志單元總數、空閑單元號、已記錄單元數、校驗數和內存日志單元節點構成，日志內存環形鏈表數據結構如下：

typedef struct err_log_node_list

{

u32 max_node_count;/*最大節點數*/

u32 nextNode;/*空閑日志單元節點號*/

u32 nodeCount;/*已使用日志單元數*/

u32 check_sum;/*環形鏈表校驗數*/

ERR_LOG_NODE node[1];/*日志單元節點*/

} ERR_LOG_NODE_LIST;

內存日志單元包含單元節點狀態、位置、提交狀態、校驗數和記錄日志數據存儲區入口，內存日志單元數據結構如下：

typedef struct err_log_node

{

u32 status;/*當前日志單元節點狀態*/

u32 position;/*日志單元節點位置*/

u32 committed;/*單元提交狀態*/

u32 check_sum;/* 日志單元校驗數*/

char data[1];/*日志單元記錄數據入口*/

} ERR_LOG_NODE;

日志服務首先初始化內存日志數據結構的基本信息，再建立由內存日志單元構成的環形鏈表而形成的資源池。記錄日志時，先從資源池取出一個日志單元，根據入參配置情況保存日志基礎信息、異常信息、上下文信息、棧回溯信息和用戶信息到日志單元的記錄數據存儲區中，經校驗完整性后再提交到日志資源池。查詢顯示或備份導出內存日志時，都是通過日志數據單元遍歷迭代器，從日志內存環形資源池中讀取符合相應條件的日志單元中記錄的日志數據。

1.1 日志服務初始化

日志服務初始化時指定內存日志地址和大小，并可選擇是否保留日志內存中已有數據。初始化成功后，即可使用日志記錄系統運行時的系統異常與用戶自定義日志信息。日志服務初始化的軟件工作流程如圖3所示。

圖3 日志服務初始化流程

1.2 日志記錄

日志記錄首先獲取當前任務ID、CPU ID與日志地址；判斷日志內存數據結構有效后，申請一個日志記錄單元；再將獲取的日志級別與類型、時間、源文件名、行號、用戶自定義信息、CPU異常信息、上下文寄存器信息、任務棧回溯信息等重要的異常線程信息插入日志內存中。最后將生成當前日志記錄單元的校驗碼和日志記錄單元一并提交插入日志內存環形鏈表，以此為信息完整性提供支撐。日志記錄的軟件工作流程如圖4所示。

圖4 日志記錄流程

1.3 日志顯示

日志顯示能夠按照日志的級別與類型、起始編號與條數查詢并顯示記錄的日志信息。日志顯示軟件流程如圖5所示。

圖5 日志顯示軟件流程

1.4 日志備份

用戶可以根據日志內存容量及實際情況，將內存中的日志信息按照日志的起始編號與條數保存到文件系統中，為分析與歸檔系統運行故障統計提供幫助，其設計流程與日志顯示類似。同時，當用戶選擇日志備份功能時還可以將掉電情況下的日志信息保存在硬盤、FLASH、SD卡等存儲設備中，實現掉電情況下的日志保存。

2 日志服務測試與分析

2.1 日志服務功能測試分析

本文設計的銳華(ReWorks)嵌入式實時操作系統的內存日志服務，基于國產飛騰FT-2000A/2平臺模塊(主頻1 GHz/ 2 GB DDR/ 256 GB SSD)開展日志服務功能測試。在日志服務初始化成功后，通過制造一個未定義指令異常，系統捕獲到ARM體系架構的異常信息與用戶添加的日志信息將寫入日志內存環形緩沖區中。通過日志顯示能夠查詢并顯示內存中記錄的日志信息，如圖6所示。

圖6 日志信息顯示截圖

圖6中ReWorks操作系統Shell控制臺的日志信息顯示所示，日志管理信息包含：日志內存總大小、單條日志大小、最大記錄條數、記錄日志數等；日志基礎信息包含：日志的等級、所屬模塊、啟動次數、系統版本、CPU ID、日期時間、任務名和日志插入點等信息；用戶記錄信息包含內容與長度；異常信息描述包含：任務ID、異常號、中斷嵌套層數、異常名稱和錯誤地址；上下文信息包含相關通用寄存器和狀態寄存器信息；棧回溯信息則顯示的是出現問題點的任務調用函數棧回溯。通過查看日志信息，可以很快定位到故障點在任務p3的函數exception_uni偏移0xc處，并分析出現問題的原因是由于未定義指令“0xeeeeeeee”造成的，且即使在系統軟重啟后，仍可查詢顯示日志內存中的該條日志信息。

由于內存日志服務功能僅依賴CPU和內存，且在記錄操作過程中不存在阻塞操作，因而能夠在中斷上下文中進行日志記錄。用戶也可以備份內存中記錄的日志信息到外部存儲的文件系統中，為分析與歸檔系統運行故障統計提供幫助。

2.2 日志服務性能分析與優化

1) 實時性優化。日志服務的記錄性能主要體現在記錄一條日志信息所消耗的時間。基于FT-2000A/2模塊開展內存日志服務性能測試，記錄各項日志信息進行性能分析。

為便于分析內存日志性能，初始化日志單元大小為4 096字節，日志管理、日志基礎、異常、上下文寄存器和棧回溯信息內容確定，所占空間大小相對固定。用戶信息從100字節起以100字節的步長增加到8 000字節，記錄所有信息內存日志所需時間如圖7所示。可看出，當記錄所有日志信息大小超過日志單元大小后，記錄時間仍然隨著用戶信息的增加而增大。該現象說明記錄用戶信息大小的不確定將導致日志記錄時間的不確定，這將影響實時系統的確定性。

圖7 內存日志記錄性能圖

經分析調試，發現字符串拷貝函數strlcpy接口性能函數存在不收斂情況。為保證嵌入式系統接口調用的實時性和確定性，對字符拷貝函數strlcpy與strncpy接口性能做了對比，如圖8所示。

圖8 往4 096字節內存拷貝不同大小內存的性能對比

圖 8為針對目的地址內存4 096字節大小，分別采用strlcpy和strncpy拷貝限制4 096字節長度內存，而源地址內存大小從100字節以100字節的步長增加到6 000字節。可看出，隨著拷貝源信息的增加，在限制長度4 096字節之后，strncpy拷貝時間收斂，而strlcpy呈發散趨勢，拷貝時間隨著源地址內容的增大而增加。對于上述現象，分析如下：

strlcpy的原型為size_t strlcpy(char *dest, const char *src, size_t size)。當size小于等于源地址src長度時，拷貝size-1個字符到目的地址dest中，并自動在字符串末尾填充結束符“