Tracking framework and tracking method of microkernel architecture operating system
By providing a tracking framework and methods in the microkernel architecture operating system, tracking of user space, system services and microkernels is solved, and the traditional tracking technology has large performance overhead and cannot meet the needs of microkernel architecture is improved, and the system's real-time and analysis capabilities are improved.
Patent Information
- Application Number
- CN202411842109.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-13
- Publication Date
- 2025-04-15
AI Technical Summary
Traditional tracking technology has a large performance overhead, affects the real-time system, and can only track kernel events, which cannot meet the system tracking needs of the microkernel architecture.
It provides a trace framework and tracking method for operating systems with microkernel architecture, realizes tracking of user space processes, system service processes and microkernels. By writing isolated tracking buffers in parallel by multiple tracking providers, ensuring isolation, and representing the involved process and thread pairs and/or names with indexes, reducing the impact of storage space and performance.
It realizes comprehensive tracking and analysis of the microkernel architecture operating system, provides powerful support and help, and improves the real-time and performance of the system.
Smart Images
Figure CN119829364A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of operating system technology, and in particular to a tracing framework and tracing method for a microkernel architecture operating system. Background Art
[0002] Tracing technology is a tracing tool in the kernel that is used to analyze and debug kernel and application performance issues. It can help developers track various kernel events such as function calls, system calls, interrupt events, timer events, and generate corresponding tracing data. By analyzing this data, developers can understand information such as code execution path, function time consumption, resource usage, etc., so as to optimize performance or troubleshoot. For example, the Linux system's ftrace provides multiple functional components, such as function graph, event tracing, and dynamic tracing, making it widely applicable in different scenarios.
[0003] However, traditional tracing technology has high performance overhead, and some functions need to disable preemption to ensure synchronization, which affects the real-time performance of the system. In addition, it can only track kernel events and cannot meet the system tracing requirements of the microkernel architecture. In view of the characteristics of the microkernel operating system, it is necessary to provide a distributed microservice tracing system framework that collects, aggregates and visualizes diagnostic tracing information from user space processes, system service processes and microkernels. Summary of the invention
[0004] In view of this, the embodiments of the present application provide a tracing framework and tracing method for a microkernel architecture operating system. The embodiments of the present application implement tracing of user space processes, system service processes and microkernel of a microkernel architecture operating system, and multiple tracing providers write tracing data in parallel into mutually isolated tracing buffers to ensure isolation between tracing providers, thereby comprehensively analyzing the execution status and data of kernel space and user space, providing strong support and assistance to developers, and also using indexes to represent the involved process and thread pairs and / or involved names when aggregating tracing data, which takes up little space, reduces the impact on the performance of the tracing object when writing tracing records, and improves the real-time performance of the system.
[0005] In the first aspect, an embodiment of the present application provides a tracing framework for a microkernel architecture operating system, comprising: a tracing client, a tracing manager and several tracing providers, wherein the tracing providers include at least one of the following: a microkernel, a system service, a system component, and a user process; each tracing provider is used to track its internal events and write tracing data to its tracing buffer, and the tracing buffers of each tracing provider are isolated from each other; the tracing manager is used to obtain tracing data from the tracing buffer of each tracing provider, and convert it into a tracing file and send it to the tracing client; in the tracing file, an index is used to represent the process and thread pairs and / or the names involved in the tracing data; the tracing client is used to analyze the tracing data by analyzing the tracing file.
[0006] As described above, the tracking of user space processes, system service processes and microkernels of microkernel architecture operating systems is realized, and multiple tracking providers write tracking data in parallel into mutually isolated tracking buffers, thereby comprehensively analyzing the execution status and data of kernel space and user space, providing strong support and assistance to developers, and also using indexes to represent the involved process and thread pairs and / or involved names when aggregating tracking data, which takes up little space, reduces the impact on the performance of the tracking object when writing tracking records, and improves the real-time performance of the system.
[0007] In a possible implementation of the first aspect, the tracking manager is further used to provide a registration service to each tracking provider, so that each tracking provider registers its tracking service; the tracking client is further used to select a tracking service and a tracking time period to be started from the registered tracking services, and start and stop the selected tracking service through the tracking manager.
[0008] From the above, by each tracing provider registering its tracing service and selecting the tracing service to be started through the tracing manager, it is possible to implement distributed parallel tracing of multiple tracing providers based on microservices, thereby comprehensively analyzing the execution status and data of the kernel space and user space.
[0009] In a possible implementation manner of the first aspect, the tracing manager is further configured to construct a shared memory with the tracing provider when each tracing provider registers its tracing service, as a tracing buffer of the tracing provider.
[0010] As described above, the tracing manager builds a shared memory with each tracing provider, so that the tracing buffers of each tracing provider are isolated from each other, and multiple tracing providers write tracing data in parallel to the isolated tracing buffers.
[0011] In a possible implementation manner of the first aspect, the tracing buffer of each tracing provider includes a permanent buffer and a plurality of rolling buffers, and the priority of data stored in the permanent buffer is higher than that of data in the rolling buffer.
[0012] From the above, the notification sets up a permanent buffer and several rolling buffers, which can not only store important tracing data in the permanent buffer, but also for a large number of ordinary tracing data areas, when each rolling buffer is full, the next rolling buffer starts to be filled, and the tracing manager is notified to take away the data of the full rolling buffer, thereby reducing the probability of tracing data loss.
[0013] In a possible implementation of the first aspect, the tracking manager uses an IDL file to describe the service component interface.
[0014] As mentioned above, using IDL files to describe service component interfaces is independent of any specific programming language, allowing developers to define data types, interfaces, methods, and other software component specifications. These definitions can then be converted into code in multiple programming languages, thereby achieving cross-language communication and integration.
[0015] In a possible implementation of the first aspect, the index corresponding to each process and thread pair is a thread index; the index corresponding to each name is a name index, and the name index includes one of the following: an event index, an event category index, and a task object index, which respectively correspond to the event name, the name of the event category, and the task object name, and the task object includes one of the following: a user space object and a kernel space object.
[0016] From the above, the process and thread pairs, event names, event category names, and task object names involved are represented by thread index and name index, which reduces the space occupied by the tracking file, reduces the impact on the performance of the tracking object when writing the tracking record, and improves the real-time performance of the system.
[0017] In a possible implementation of the first aspect, each of the tracking files includes a number of tracking records, each tracking record includes a record header and a number of record data, each record header includes a record type, size and attribute information corresponding to the record type; when the tracking record involves a process and thread pair, the attribute information includes a corresponding thread index; when the tracking record involves one of the following: an event, an event category, a task object, the attribute information includes a corresponding name index.
[0018] As mentioned above, the trace file is divided into a series of trace records. Each trace record stores UTF-8 strings or binary data, compresses the trace data, and occupies less space, reducing the impact on the performance of the trace object when writing the trace record. The trace record can be flexibly defined through the record header, which has strong scalability.
[0019] In a possible implementation of the first aspect, for each process and thread pair, there is also a thread record in each of the tracking files, the record header of the thread record includes the thread index corresponding to the process and thread pair, and the record data of the thread record includes the process ID and thread ID corresponding to the thread index; for each event, each event category or each task object, there is also a string record in each of the tracking files, the record header of the string record includes the corresponding name index, and the record data of the string record includes the corresponding name.
[0020] From the above, through the string index mechanism, various names are pooled to further compress the tracking data, so that it occupies less space and reduces the impact on the performance of the tracking object when writing tracking records.
[0021] In a possible implementation of the first aspect, each of the tracking files further includes a metadata record, the metadata record has the same structure as the tracking record, the record type of the metadata record is a setting record type, and the attribute information of the metadata record includes a metadata type. For example, when the metadata type is a setting metadata type, the attribute information also includes a tracking provider ID and a tracking provider name length, and the corresponding record data includes a tracking provider name.
[0022] From the above, the tracking file can be flexibly extended by defining new record types, metadata types, storing new information in reserved fields of existing record types, and appending new information to existing record types. It provides the ability to concatenate tracking records with metadata records to form a tracking record archive file.
[0023] In a possible implementation manner of the first aspect, the tracking manager is further configured to divide the tracking file into a plurality of data packets based on a communication protocol for sending the tracking file to the tracking client, each data packet including a plurality of tracking records.
[0024] As described above, by dividing the trace file into several data packets, when the trace manager 120 sends the trace file, there is no need to repack it, thereby improving the real-time performance.
[0025] In a second aspect, an embodiment of the present application provides a tracing method for a microkernel architecture operating system, using the framework described in any implementation scheme of the first aspect to track one of the following objects of the system: a microkernel, a system service, a system component or a user process, including: each tracing provider of the framework tracks its internal events and writes tracing data to its tracing buffer, and the tracing buffers of each tracing provider are isolated from each other; the tracing manager of the framework is used to obtain tracing data from the tracing buffer of the tracing provider, and convert it into a tracing file and send it to the tracing client of the framework; the tracing client is used to analyze the tracing data by analyzing the tracing file.
[0026] As described above, the tracking of user space processes, system service processes and microkernels of microkernel architecture operating systems is realized, and multiple tracking providers write tracking data in parallel into mutually isolated tracking buffers, thereby comprehensively analyzing the execution status and data of kernel space and user space, providing strong support and assistance to developers, and also using indexes to represent the involved process and thread pairs and / or involved names when aggregating tracking data, which takes up little space, reduces the impact on the performance of the tracking object when writing tracking records, and improves the real-time performance of the system.
[0027] In a possible implementation of the second aspect, before each tracking provider performs tracking, the process further includes: each tracking provider registers its tracking service with a tracking manager; a tracking client selects a tracking service and a tracking time period to be started from the registered tracking services, and starts and stops the selected tracking service through the tracking manager.
[0028] From the above, by each tracing provider registering its tracing service and selecting the tracing service to be started through the tracing manager, it is possible to implement distributed parallel tracing of multiple tracing providers based on microservices, thereby comprehensively analyzing the execution status and data of the kernel space and user space.
[0029] In a possible implementation of the second aspect, the following further includes: when each tracing provider registers its tracing service, the tracing manager constructs a shared memory with the tracing provider as a tracing buffer of the tracing provider.
[0030] As described above, the tracing manager builds a shared memory with each tracing provider, so that the tracing buffers of each tracing provider are isolated from each other, and multiple tracing providers write tracing data in parallel to the isolated tracing buffers.
[0031] In a possible implementation manner of the second aspect, the tracking buffer of each tracking provider includes a permanent buffer and a plurality of rolling buffers, and the priority of data stored in the permanent buffer is higher than that of data in the rolling buffer.
[0032] From the above, the notification sets up a permanent buffer and several rolling buffers, which can not only store important tracing data in the permanent buffer, but also for a large number of ordinary tracing data areas, when each rolling buffer is full, the next rolling buffer starts to be filled, and the tracing manager is notified to take away the data of the full rolling buffer, thereby reducing the probability of tracing data loss.
[0033] In a possible implementation of the second aspect, the tracking manager uses an IDL file to describe the service component interface.
[0034] As mentioned above, using IDL files to describe service component interfaces is independent of any specific programming language, allowing developers to define data types, interfaces, methods, and other software component specifications. These definitions can then be converted into code in multiple programming languages, thereby achieving cross-language communication and integration.
[0035] In a possible implementation of the second aspect, the index corresponding to each process and thread pair is a thread index; the index corresponding to each name is a name index, and the name index includes one of the following: an event index, an event category index, and a task object index, which respectively correspond to the event name, the name of the event category, and the task object name, and the task object includes one of the following: a user space object and a kernel space object.
[0036] From the above, the process and thread pairs, event names, event category names, and task object names involved are represented by thread index and name index, which reduces the space occupied by the tracking file, reduces the impact on the performance of the tracking object when writing the tracking record, and improves the real-time performance of the system.
[0037] In a possible implementation of the second aspect, each of the tracking files includes a number of tracking records, each tracking record includes a record header and a number of record data, each record header includes a record type, size and attribute information corresponding to the record type; when the tracking record involves a process and thread pair, the attribute information includes a corresponding thread index; when the tracking record involves one of the following: an event, an event category, a task object, the attribute information includes a corresponding name index.
[0038] As mentioned above, the trace file is divided into a series of trace records. Each trace record stores UTF-8 strings or binary data, compresses the trace data, and occupies less space, reducing the impact on the performance of the trace object when writing the trace record. The trace record can be flexibly defined through the record header, which has strong scalability.
[0039] In a possible implementation of the second aspect, for each process and thread pair, there is also a thread record in each of the tracking files, the record header of the thread record includes the thread index corresponding to the process and thread pair, and the record data of the thread record includes the process ID and thread ID corresponding to the thread index; for each event, each event category or each task object, there is also a string record in each of the tracking files, the record header of the string record includes the corresponding name index, and the record data of the string record includes the corresponding name.
[0040] From the above, through the string index mechanism, various names are pooled to further compress the tracking data, so that it occupies less space and reduces the impact on the performance of the tracking object when writing tracking records.
[0041] In a possible implementation of the second aspect, each of the tracking files further includes a metadata record, the metadata record has the same structure as the tracking record, the record type of the metadata record is a setting record type, and the attribute information of the metadata record includes a metadata type. For example, when the metadata type is a setting metadata type, the attribute information also includes a tracking provider ID and a tracking provider name length, and the corresponding record data includes a tracking provider name.
[0042] From the above, the tracking file can be flexibly extended by defining new record types, metadata types, storing new information in reserved fields of existing record types, and appending new information to existing record types. It provides the ability to concatenate tracking records with metadata records to form a tracking record archive file.
[0043] In a possible implementation of the second aspect, when generating the trace file, the trace manager further divides the trace file into a plurality of data packets based on a communication protocol for sending the trace file to the trace client, each data packet including a plurality of trace records.
[0044] As described above, by dividing the trace file into several data packets, when the trace manager 120 sends the trace file, there is no need to repack it, thereby improving the real-time performance.
[0045] In a third aspect, an embodiment of the present application provides a computing device, including:
[0046] bus;
[0047] A communication interface connected to the bus;
[0048] at least one processor connected to the bus; and
[0049] At least one memory is connected to the bus and stores program instructions, and when the program instructions are executed by the at least one processor, the at least one processor executes any implementation method of the second aspect of the present application.
[0050] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having program instructions stored thereon, wherein when the program instructions are executed by a computer, the computer executes any implementation method described in the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS
[0051] Figure 1 This is a structural diagram of a first embodiment of a tracking framework of a microkernel architecture operating system of the present application;
[0052] Figure 2 A schematic diagram of a trace file format of a trace framework embodiment 2 of a microkernel architecture operating system of the present application;
[0053] Figure 3A A schematic diagram of the structure of metadata records of a tracking framework embodiment 2 of a microkernel architecture operating system of the present application;
[0054] Figure 3B A schematic diagram of the structure of metadata record of metadata type=0 in Embodiment 2 of a tracking framework of a microkernel architecture operating system of the present application;
[0055] Figure 4A A schematic diagram of the structure of thread records in a tracking file of a tracking framework embodiment 2 of a microkernel architecture operating system of the present application;
[0056] Figure 4B A schematic diagram of the structure of a string record in a tracking file of a tracking framework embodiment 2 of a microkernel architecture operating system of the present application;
[0057] Figure 4C A schematic diagram of the structure of event records in a tracking file of Embodiment 2 of a tracking framework of a microkernel architecture operating system of the present application;
[0058] Figure 5A A schematic diagram of the structure of the tracking record of the user space object of the second embodiment of the tracking framework of the microkernel architecture operating system of the present application;
[0059] Figure 5B A schematic diagram of the structure of the tracking record of the kernel space object in the second embodiment of the tracking framework of the microkernel architecture operating system of the present application;
[0060] Figure 6 A schematic diagram of a flow chart of an embodiment of a tracking method for a microkernel architecture operating system of the present application;
[0061] Figure 7 A schematic diagram of the structure of a computing device according to various embodiments of the present application. DETAILED DESCRIPTION
[0062] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.
[0063] In the following description, the terms "first\second\third, etc." or module A, module B, module C, etc. are only used to distinguish similar objects, or to distinguish different embodiments, and do not represent a specific ordering of the objects. It can be understood that the specific order or sequence can be interchanged where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.
[0064] In the following description, the numbers representing the steps, such as S110, S120, etc., do not necessarily mean that the steps must be executed in this manner. If permitted, the order of the previous and next steps can be interchanged, or they can be executed simultaneously.
[0065] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.
[0066] An embodiment of the present application provides a tracing framework and tracing method for a microkernel architecture operating system, wherein the framework includes: a tracing client, a tracing manager, and a plurality of tracing providers, wherein the tracing providers include at least one of the following: a microkernel, a system service, a system component, and a user process; each tracing provider is used to trace its internal events and write tracing data to its tracing buffer, and the tracing buffers of each tracing provider are isolated from each other; the tracing manager is used to obtain tracing data from the tracing buffer of each tracing provider, and convert it into a tracing file and send it to the tracing client; in the tracing file, an index is used to represent the process and thread pairs and / or the names involved in the tracing data; the tracing client is used to analyze the tracing data by analyzing the tracing file.
[0067] The technical solution of the embodiment of the present application realizes the tracking of user space processes, system service processes and microkernel of a microkernel architecture operating system, and multiple tracking providers write tracking data in parallel into mutually isolated tracking buffers to ensure the isolation between tracking providers. When aggregating tracking data, the involved process and thread pairs and / or the involved names are represented by indexes, which takes up little space, reduces the impact on the performance of the tracking object when writing tracking records, and improves the real-time performance of the system.
[0068] The following describes various embodiments of the present application in conjunction with the accompanying drawings. Figure 1 The present application introduces a first embodiment of a tracing framework for a microkernel architecture operating system.
[0069] Figure 1 The structure of a first embodiment of a tracing framework of a microkernel architecture operating system is shown, including: a tracing client 110 , a tracing manager 120 , and a plurality of tracing providers 130 , wherein each tracing provider 130 is further provided with a tracing buffer 140 .
[0070] The tracking provider 130 includes at least one of the following: microkernel, system service, system component, user process. Therefore, this embodiment can track not only the microkernel, system service, system component, but also the user process.
[0071] Each tracing provider 130 is used to trace its internal events and write tracing data to its tracing buffer 140. The tracing interface has been integrated into the code of the tracing provider 130, and interface codes such as Start (tracing start), Stop (tracing stop), Terminate (tracing termination), and GetCategories (getting tracing category information) have also been integrated.
[0072] The trace buffers 140 of each trace provider 130 are isolated from each other. In this embodiment, multiple trace providers 130 write trace data in parallel into the trace buffers 140 isolated from each other. The generated trace data is stored in the memory (TMO in the figure) of the trace buffer 140 of each trace provider 130 and will not be copied to any other location, thereby ensuring isolation between the trace providers.
[0073] The trace manager 120 is used to obtain trace data from the trace buffer 140 of each trace provider 130 , convert the trace data into a trace file, and send the file to the trace client 110 .
[0074] The trace manager 120 is a system service that locates trace data for the trace providers 130. There is only one trace manager 120 in the entire operating system, which ensures that trace records are made in order and isolates the trace providers 130 from the trace clients 110. After the trace is completed, the trace manager 120 stops all active trace providers 130. The trace manager 120 then waits for each trace provider 130 to confirm that it has completed writing the trace event. The trace manager 120 reads and verifies the trace data written to the trace buffer 140 and creates archived trace files (including log files). The trace manager 120 transmits the generated files to the trace client 110 via a local socket or other means.
[0075] In the trace file, the process and thread pairs and / or names involved in the trace data are represented by indexes. Because there will be a large number of process and thread pairs and some names in the trace data, and the process and thread pairs and names are relatively long, the process and thread pairs and names involved in the trace data are represented by indexes, which greatly reduces the space occupied by the trace file, reduces the impact on the performance of the trace object when writing the trace record, and improves the real-time performance of the system.
[0076] The tracing client 110 is used to analyze the tracing data of the corresponding tracing provider 130 by analyzing the tracing files generated by the tracing manager 120, thereby analyzing the internal events including the microkernel, system services, system components, and user processes, helping developers to comprehensively discover problems and improve the performance of the operating system. The tracing client 110 is a component used to process the data generated by the tracing provider 130. The tracing client 110 interacts with the tracing manager 120 and cannot directly affect the operation of the tracing provider 130.
[0077] In one implementation of this embodiment, the tracking manager 120 is also used to provide a registration service to each tracking provider 130, so that each tracking provider 130 registers its tracking service. The tracking provider 130 registers the service to the tracking manager 120. The tracking provider 130 needs to register tracking start, tracking stop, tracking termination, obtaining tracking classification information and other tracking-related services. The tracking client 110 is also used to select the tracking service and tracking time period to be started from the registered tracking services, and start and stop the selected tracking service through the tracking manager 120. By registering the tracking service and selecting the tracking service to be started, multiple tracking providers 130 are tracked in distributed parallel based on microservices.
[0078] In one implementation of this embodiment, the tracing manager 120 is further used to construct a shared memory with the tracing provider when each tracing provider 130 registers its tracing service, as the tracing buffer 140 of the tracing provider 130. The tracing buffer 140 of the tracing provider 130 is implemented with a shared memory, and multiple tracing providers 130 write tracing data in parallel to the shared memory segment constructed by the tracing manager 120. The generated tracing data is stored in the memory and will not be copied to any other location. In addition, the tracing manager 120 can quickly obtain the tracing data, reducing the impact on the tracing providers 130.
[0079] In one implementation of this embodiment, the tracking manager 120 uses an IDL (Interface Definition Language File) file to describe the service component interface. The tracking manager 120 is independent of any specific programming language and allows developers to define data types, interfaces, methods, and other software component specifications. These definitions can then be converted into code in multiple programming languages, thereby achieving cross-language communication and integration.
[0080] In an implementation of this embodiment, the trace buffer 140 of each trace provider 130 includes a permanent buffer and a plurality of rolling buffers, and the priority of data stored in the permanent buffer is higher than that of data in the rolling buffer.
[0081] In one implementation of this embodiment, in the trace file, the index corresponding to each process and thread pair is a thread index; the index corresponding to each name is a name index, and the name index includes one of the following: event index, event category index, task object index, corresponding to event name, event category name, task object name, respectively, and the index can be a pointer; the task object includes one of the following: user space object, kernel space object. By using indexes to represent process and thread pairs, event names, event category names, and task object names, the trace data is further compressed to occupy less space, reduce the impact on the performance of the trace object when writing the trace record, and achieve extremely fast writing speed.
[0082] In one implementation of this embodiment, each of the tracking files includes several tracking records, each tracking record includes a record header and several record data, each record header includes a record type, size and attribute information corresponding to the record type; when the tracking record involves a process and a thread pair, the attribute information includes a corresponding thread index; when the tracking record involves one of the following: an event, an event category, a task object, the attribute information includes a corresponding name index. The tracking file is a series of tracking records, each tracking record stores UTF-8 strings or binary data, compresses the tracking data, makes it occupy less space, reduces the impact on the performance of the tracking object when writing the tracking record, and can flexibly define the tracking record through the record header, which has strong scalability.
[0083] In one implementation of this embodiment, for each process and thread pair, there is also a thread record in each tracking file, the record header of the thread record includes the thread index corresponding to the process and thread pair, and the record data of the thread record includes the process ID and thread ID corresponding to the thread index; for each event, each event category or each task object, there is also a string record in each tracking file, the record header of the string record includes the corresponding name index, and the record data of the string record includes the corresponding name. Through the string index mechanism, various names are pooled, and the tracking data is further compressed to make it occupy less space, reducing the impact on the performance of the tracking object when writing the tracking record.
[0084] In one implementation of the present embodiment, each of the tracking files also includes a metadata record. The metadata record has the same structure as the tracking record, including a record header and a number of record data. Each record header includes a record type, size, and attribute information corresponding to the record type. The record type of the metadata record is a set record type, and the attribute information of the metadata record includes a metadata type, which is used to segment the attribute information. Multiple data records can be flexibly extended through metadata records. Among them, when the metadata type is a set metadata type, the attribute information also includes a tracking provider ID, a tracking provider name length, and the corresponding record data includes a tracking provider name. The tracking file can be flexibly extended in the following ways: define new record types, metadata types, store new information in reserved fields of existing record types, and append new information to existing record types. Provide a method of concatenating tracking records with metadata records to form a tracking record archive file,
[0085] In one implementation of this embodiment, the tracking manager 120 is further used to divide the tracking file into a plurality of data packets based on the communication protocol for sending the tracking file to the tracking client 110, each data packet including a plurality of tracking records. By dividing the tracking file into a plurality of data packets, when the tracking manager 120 sends the tracking file, there is no need to repackage it, thereby improving real-time performance.
[0086] In summary, a tracing framework embodiment 1 of a microkernel architecture operating system realizes the tracing of user space processes, system service processes and microkernels of a microkernel architecture operating system, and multiple tracing providers write tracing data in parallel into mutually isolated tracing buffers to ensure the isolation between tracing providers. When aggregating tracing data, the process and thread pairs and / or names involved are represented by indexes, which takes up little space, reduces the impact on the performance of the tracing object when writing tracing records, and improves the real-time performance of the system. This embodiment provides a complete log and recording mechanism that can record and store captured tracing data, persistent storage and retrievability, and facilitates subsequent analysis and diagnosis. By capturing, recording and analyzing the execution status and data of kernel space and user space, it provides strong support and assistance to developers.
[0087] Combine the following Figures 2 to 5B A second embodiment of a tracing framework for a microkernel architecture operating system of the present application is introduced.
[0088] A tracing framework embodiment 2 of a microkernel architecture operating system inherits a tracing framework embodiment 1 of a microkernel architecture operating system Figure 1 The structure shown has all the advantages of the first embodiment of the tracing framework for a microkernel architecture operating system, and further refines the buffer mode of the tracing provider and the format of the tracing file.
[0089] If the trace buffer 140 of the trace provider 130 is filled up at runtime, the buffering mode will determine the behavior of the trace provider 130. In this embodiment, the buffering mode for the trace provider 130 to fill data into its trace buffer 140 includes two modes: once and circular.
[0090] In the one-shot mode, the trace buffer 140 of the trace provider 130 has only one persistent buffer. If the trace buffer 140 of a trace provider 130 is full, the trace provider 130 stops recording events. This mode ensures that the trace area will not be overwritten. Because the trace buffers 140 between trace providers 130 are isolated from each other, other trace providers 130 can continue to record trace events to their own trace buffers 140 until the trace recording stops.
[0091] In the ring mode, the trace buffer 140 of each trace provider 130 is divided into two parts: a persistent buffer and several rolling buffers. The persistent buffer is used to record important records to avoid loss, and its data has a higher priority than the data in the rolling buffer. When the trace recording is started, the trace provider 130 will write the data filled in the rolling buffer to the first rolling buffer. When a rolling buffer is filled, the trace provider 130 notifies the trace manager 120 that the rolling buffer is full and writes the data to the next rolling buffer. If another rolling buffer is not available, the data will be discarded until the rolling buffer is available.
[0092] Figure 2 The trace file format of the second embodiment of the trace framework of a microkernel architecture operating system is shown.
[0093] The tracking manager 120 sends the tracking file to the tracking client 110 based on the socket, and divides the tracking file into several data packets. Each data packet is the information transmission data unit MTU of a socket. When the tracking manager 120 sends the tracking file, there is no need to repack it, which improves real-time performance.
[0094] Each data packet is a series of trace records connected end-to-end, which stores the information collected by the trace record provider. Each data packet includes several trace record records. Each trace record record (also called event record) is the result of the producer writing a record containing optional user data when an event occurs during the execution process. Each trace record record includes a record header and some record data data. Each record header includes the record type, size and attribute information corresponding to the record type. The attribute information is a variable area, which is defined according to the record type and is easy to expand. The format of the record header Head of each trace record Record is as follows:
[0095] [0..5]: record type,
[0096] [6..15]: record size,
[0097] [16..63]: Depends on the record type, must be zero if not used.
[0098] The tracking file also includes a metadata record. The metadata record has the same structure as the tracking record and is a special tracking record Record. The metadata record is used to identify and separate the partial content of the tracking record generated by each tracking record provider. The metadata record also includes a record header and some record data. The metadata record corresponds to a record type = 0 in the record header. This record type is reserved and is used by the tracking manager 120 when generating a tracking file. The metadata record shall not be issued by the tracking record provider itself.
[0099] Figure 3A The structure of metadata record of the second embodiment of the tracking framework of a microkernel architecture operating system is shown, wherein the format of the record header Head of the metadata record is as follows:
[0100] [0..5]: Record type = 0,
[0101] [6..15]: record size,
[0102] [16..21]: metadata type,
[0103] [22..63]: Depends on the metadata type, must be zero if not used.
[0104] There are many subtypes of metadata records, each containing different information, which can be defined and extended. For example, Figure 3B The structure of the metadata record of metadata type = 0 represents the information of the tracking provider 130. The format of the record header Head of the metadata record of metadata type = 0 is as follows:
[0105] [0..5]: Record type = 0,
[0106] [6..15]: record size,
[0107] [16..21]: metadata type = 0,
[0108] [22..53]: ID of tracking provider 130,
[0109] [54..63]: Tracks the length of the name of provider 130.
[0110] The metadata record of metadata type = 0 has only one record data, which is the name of the tracking recorder.
[0111] Figure 4AThe structure of the thread record is shown. The thread record is also a tracking record Record, including a record header head and two record data data. The record type of the thread record = 1, which is used to record the process ID and thread ID in the process and thread pair corresponding to the thread index.
[0112] Register the process ID and thread ID pair in the thread table and assign it a thread index in the range of 0x01 to 0x3ff. When parsing subsequent records, the thread / process ID can be found through the thread index. The record header format of the thread record is as follows:
[0113] [0..5]: Record type = 1,
[0114] [6..15]: record size,
[0115] [16..25]: thread index,
[0116] [26..63]: Reserved, must be zero.
[0117] The two record data formats of the thread record are as follows:
[0118] The first one, [0..63]: process ID,
[0119] The second one, [0..63]: thread ID.
[0120] Figure 4B The structure of a string record is shown. The string record is also a tracking record Record, including a record header head and 1 record data data. The record type of the string record = 2, which is used to record the name corresponding to the string index.
[0121] Register a string in the string table and assign it a string index in the range of 0x1 to 0x3ff. When parsing subsequent records, the string can be found by the string index. The record header format of the string record is as follows:
[0122] [0..5]: Record type = 2,
[0123] [6..15]: record size,
[0124] [16..25]: string index,
[0125] [26..35]: string length,
[0126] [36..63]: Reserved, must be zero.
[0127] The data format of one record of a string record is as follows:
[0128] [0..63]: string.
[0129] Figure 4C The structure of an event record is shown. An event record is also a tracking record Record, which includes a record header and two record data. The record type of the event record = 3, which is used for event type data. The record header format of the event record is as follows:
[0130] [0..5]: Record type = 3,
[0131] [6..15]: record size,
[0132] [16..33]: event type,
[0133] [34..43]: Process / thread reference (essentially thread index), through which thread ID / process ID pair is found.
[0134] [44..53]: name reference (essentially event name index, string index),
[0135] [54..63]: Event category reference (essentially event category index, string index).
[0136] The two record data formats of the event record are as follows:
[0137] The first one, [0..63]: timestamp,
[0138] The second item, [0..63]: event type specific data.
[0139] From the above, the tracking record Record is extended in the following ways: defining new record types, metadata types, storing new information in reserved fields of existing record types, and appending new information to existing record types. The binary tracking format extended by the above methods makes the tracking record very compact and supports packing information into a small number of bits. Through the string indexing mechanism, strings such as processes and threads can be pooled to further compress the tracking data, making it occupy less space and reducing the impact on the performance of the tracking object when writing the tracking record. It has strong scalability, and users can define new record types as needed, and provide the possibility of concatenating the tracking record with the metadata record to form a tracking record file. Based on the above technology, extremely fast writing speed can be achieved without affecting flexibility.
[0140] Figure 5A The structure of the tracking record Record of the user space object is shown.
[0141] A user space object represents a task in a user process. When the task is started, the user space object is described and a label is assigned to it. The relevant information of the object is added to the user space object table of each process.
[0142] The tracking record Record of the user space object includes a record header and three record data. The format of the record header is as follows:
[0143] [0..5]: Record type = 5,
[0144] [6..15]: record size,
[0145] [16..33]: Process / thread reference (essentially thread index), through which thread ID / process ID pair is found.
[0146] [34..43]: name reference (essentially the name index of the user space object, string index), corresponding to the name of the user space object,
[0147] [44..53]: data volume, corresponding to user-mode data
[0148] [54..63]: Reserved.
[0149] The data format of the three records of the user space object tracking record Record is as follows:
[0150] The first one, [0..63]: timestamp,
[0151] The second item, [0..63]: User object ID,
[0152] The third item, [0..63]: user-mode data.
[0153] When the tracking record usage tool (which may be a tool of the tracking client 110 or a tool of other third-party devices) matches the user object ID value with an entry in the user space object table, it can cross-index the user object ID with the previous user object tracking record Record.
[0154] Figure 5B The structure of the tracking record Record of the kernel space object is shown.
[0155] Kernel space objects represent tasks in the microkernel. When the task is started, the kernel space object is described and a label is assigned to it. The object's related information is added to a global kernel space object table.
[0156] The tracking record Record of the kernel space object includes a record header and three record data. The format of the record header is as follows:
[0157] [0..5]: Record type = 5,
[0158] [6..15]: record size,
[0159] [16..33] Process / thread reference (essentially thread index), through the index to find the thread ID / process ID pair,
[0160] [34..43]: Name reference (essentially the name index of the kernel space object, string index), corresponding to the name of the kernel space object,
[0161] [44..53]: data volume, corresponding to kernel state data
[0162] [54..63]: Reserved.
[0163] The data format of the three records of the kernel space object tracking record Record is as follows:
[0164] The first one, [0..63]: timestamp,
[0165] The second item, [0..63]: kernel object ID,
[0166] The third item, [0..63]: kernel state data.
[0167] When the tracking record usage tool (which can be a tool of the tracking client 110 or a tool of other third-party devices) matches the kernel object ID value with the entry in the kernel space object table, it can cross-index the kernel object ID with the tracking record Record of the previous kernel object.
[0168] Combine the following Figure 6 An embodiment of a tracing method for a microkernel architecture operating system of the present application is introduced.
[0169] A tracking method embodiment of a microkernel architecture operating system tracks a microkernel, system services, system components or user processes through a tracking framework embodiment of a microkernel architecture operating system.
[0170] Figure 6 The flowchart of an embodiment of a tracking method for a microkernel architecture operating system is shown, including steps S610 to S650.
[0171] S610: Each tracking provider registers the tracking service with the tracking manager.
[0172] The tracking provider includes one of the following: microkernel, system service, system component or user process. Each tracking provider registers tracking start, tracking stop, tracking termination, obtaining tracking classification information and other tracking related services.
[0173] During registration, the tracing manager constructs a shared memory with each tracing provider as the tracing buffer of the tracing provider, and the tracing buffers of the tracing providers are isolated from each other.
[0174] S620: The tracking client configures the tracking service and time period to be started through the tracking manager, and starts the tracking service through the tracking manager.
[0175] The tracking manager controls the services registered by each tracking provider.
[0176] S630: Each trace provider traces its internal events and writes trace data into its trace buffer.
[0177] Each trace provider writes trace data to its trace buffer according to its buffer mode. The buffer modes include one-time and circular. For details, please refer to Embodiment 2 of a trace framework for a microkernel architecture operating system.
[0178] S640: The trace manager obtains the trace data from the trace buffer of the trace provider, converts it into a trace file, and sends it to the trace client.
[0179] The trace file includes multiple data packets, each of which is the MTU of a socket. Each data packet includes several trace records, each of which includes a record header and several record data. Some data packets also include metadata records, which have the same structure as the trace record, including a record header and several record data. Each record header includes the record type, size and attribute information corresponding to the record type. The attribute information is a variable area, which is defined according to the record type and is easy to expand. The trace record includes thread records, string records, event records, user space object records, and kernel space object records. The thread record defines the corresponding relationship between the process and thread pair and the thread index. In other trace records, the thread index is used to represent the process and thread pair; each string record defines the corresponding relationship between one of the event name, event category name, and task object name and the corresponding name index in the event index, event category index, and task object index. In other trace records, the name index is used to represent the corresponding name. The record type of the record header of the metadata record is a setting type, and the attribute information of the record header includes the metadata type, which is used to divide the remaining attribute information and the record data data. For the detailed format of the trace file, please refer to the second embodiment of a trace framework of a microkernel architecture operating system.
[0180] S650: The tracking client analyzes the tracking data by analyzing the tracking file.
[0181] When analyzing the tracking data of the user space object, according to matching the user object ID value with the entry in the user space object table, it can cross-index the user object ID with the previous tracking record Record of the user object.
[0182] When analyzing the tracking data of the kernel space object, it can cross-index the kernel object ID with the previous kernel object tracking record Record according to matching the kernel object ID value with the entry in the kernel space object table.
[0183] The present application embodiment also provides a computing device, Figure 7 Detailed introduction.
[0184] The computing device 700 includes a processor 710 , a memory 720 , a communication interface 730 , and a bus 740 .
[0185] It should be understood that the communication interface 730 in the computing device 700 shown in this figure can be used to communicate with other devices.
[0186] The processor 710 may be connected to a memory 720. The memory 720 may be used to store the program code and data. Therefore, the memory 720 may be a storage unit inside the processor 710, or an external storage unit independent of the processor 710, or a component including a storage unit inside the processor 710 and an external storage unit independent of the processor 710.
[0187] Optionally, the computing device 700 may further include a bus 740. The memory 720 and the communication interface 730 may be connected to the processor 710 via the bus 740. The bus 740 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus 740 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the figure is represented by only one line, but it does not mean that there is only one bus or one type of bus.
[0188] It should be understood that in the embodiment of the present application, the processor 710 may adopt a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. Alternatively, the processor 710 may adopt one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiment of the present application.
[0189] The memory 720 may include a read-only memory and a random access memory, and provides instructions and data to the processor 710. A portion of the processor 710 may also include a nonvolatile random access memory. For example, the processor 710 may also store information on the device type.
[0190] When the computing device 700 is running, the processor 710 executes the computer-executable instructions in the memory 720 to perform the operation steps of each method embodiment.
[0191] It should be understood that the computing device 700 according to the embodiment of the present application can correspond to the corresponding subjects in the methods according to the embodiments of the present application, and the above-mentioned and other operations and / or functions of each module in the computing device 700 are respectively for implementing the corresponding processes of each method of the present embodiment, which will not be repeated here for the sake of brevity.
[0192] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.
[0193] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0194] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
[0195] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0196] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
[0197] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.
[0198] The embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, it is used to execute the operating steps of each method embodiment.
[0199] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media.Computer-readable media can be computer-readable signal media or computer-readable storage media.Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or devices, or any combination of the above.More specific examples (non-exhaustive lists) of computer-readable storage media include, electrical connections with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above.In this document, computer-readable storage media can be any tangible medium containing or storing programs, which can be used by instruction execution systems, devices or devices or used in combination with them.
[0200] Computer-readable signal media may include data signals transmitted in baseband or as part of a carrier wave, which carry computer-readable program code. Such transmitted data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, transmit, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.
[0201] The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
[0202] Computer program code for performing the operation of the present application can be written in one or more programming languages or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., using an Internet service provider to connect through the Internet).
[0203] Note that the above are only preferred embodiments of the present application and the technical principles used. Those skilled in the art will understand that the present application is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present application. Therefore, although the present application is described in more detail through the above embodiments, the present application is not limited to the above embodiments, and may also include more other equivalent embodiments without departing from the concept of the present application, all of which belong to the scope of protection of the present application.
Claims
1. A tracing framework for a microkernel architecture operating system, characterized in that: include: A tracing client, a tracing manager and several tracing providers, wherein the tracing provider includes at least one of the following: a microkernel, a system service, a system component, and a user process; Each tracing provider is used to trace its internal events and write tracing data to its tracing buffer. The tracing buffers of each tracing provider are isolated from each other. The trace manager is used to obtain trace data from the trace buffer of each trace provider, convert it into a trace file and send it to the trace client; in the trace file, the process and thread pair and / or the name involved in the trace data are represented by an index; The tracing client is used to analyze the tracing data by analyzing the tracing file.
2. The frame according to claim 1, characterized in that: The tracking manager is also used to provide a registration service to each tracking provider, so that each tracking provider can register its tracking service. The tracking client is also used to select the tracking service and tracking time period to be started from the registered tracking services, and start and stop the selected tracking service through the tracking manager.
3. The frame according to claim 2, characterized in that: The trace manager is also used to build a shared memory with each trace provider as the trace buffer for that trace provider when the trace provider registers its trace service.
4. The frame according to claim 1, characterized in that: The trace buffer of each trace provider includes a permanent buffer and several rolling buffers. The priority of data stored in the permanent buffer is higher than that of data in the rolling buffer.
5. The frame according to claim 1, characterized in that: The tracking manager uses an IDL file to describe the service component interface.
6. The frame according to claim 1, characterized in that: The index corresponding to each process and thread pair is the thread index; The index corresponding to each name is a name index, and the name index includes one of the following: event index, event category index, task object index, corresponding to the event name, event category name, and task object name respectively; wherein the task object includes one of the following: user space object, kernel space object.
7. The frame according to claim 6, characterized in that: Each of the tracking files includes a number of tracking records, each tracking record includes a record header and a number of record data, each record header includes a record type, size and attribute information corresponding to the record type; When the trace record involves a process and thread pair, the attribute information includes a corresponding thread index; When the tracking record involves one of the following: an event, an event category, a task object, the attribute information includes a corresponding name index.
8. The frame according to claim 7, characterized in that: For each process and thread pair, there is also one thread record in each of the tracking files, the record header of the thread record includes a thread index corresponding to the process and thread pair, and the record data of the thread record includes a process ID and a thread ID corresponding to the thread index; For each event, each event category or each task object, there is also a string record in each of the tracking files, the record header of the string record includes a corresponding name index, and the record data of the string record includes a corresponding name.
9. The frame according to claim 7, characterized in that: Each of the tracking files also includes a metadata record. The metadata record has the same structure as the tracking record. The record type of the metadata record is a set record type. The attribute information of the metadata record includes a metadata type.
10. The frame according to claim 9, characterized in that: When the metadata type is a setting metadata type, the attribute information further includes a tracking provider ID and a tracking provider name length, and the corresponding record data includes a tracking provider name.
11. The frame according to claim 7, characterized in that: The tracking manager is further used to divide the tracking file into a plurality of data packets based on the communication protocol for sending the tracking file to the tracking client, each data packet including a plurality of tracking records.
12. A tracking method for a microkernel architecture operating system, characterized in that: Using the framework of any one of claims 1 to 11 to track one of the following objects of the system: a microkernel, a system service, a system component or a user process, comprising: Each trace provider of the framework traces its internal events and writes trace data into its trace buffer, and the trace buffers of each trace provider are isolated from each other; The tracing manager of the framework obtains the tracing data from the tracing buffer of the tracing provider, converts it into a tracing file and sends it to the tracing client of the framework; The tracing client analyzes the tracing data by analyzing the tracing file.
13. A computing device, characterized in that: include, bus; A communication interface connected to the bus; at least one processor connected to the bus; as well as At least one memory is connected to the bus and stores program instructions, and when the program instructions are executed by the at least one processor, the at least one processor executes the method of claim 12.
14. A computer-readable storage medium, characterized in that: Program instructions are stored thereon, and when the program instructions are executed by a computer, the computer is caused to execute the method of claim 12 .