A device driver automated validation and code admission control method

Abstract

The application provides a device driver automatic verification and code access control method, comprising: in a code review system, establishing a code change event listening mechanism, when a code submission event is detected, sending a code change notification to a continuous integration platform; when the continuous integration platform receives the code change notification, triggering a corresponding pipeline task, and sequentially completing device driver automatic building, device driver pulling and deployment, test environment initialization of a test device, multi-dimensional automatic test execution, test result collection and analysis, and review result generation and feedback of the whole process; and performing access control on the submitted code according to the review feedback result. The application realizes full-process automatic execution of a device driver from code submission to building, deployment and running test, structures multi-dimensional test results and uses the same for code review decision-making, and finally realizes code access control based on running results.

Description

Technical Field

[0001] This invention relates to the field of code testing technology, and more specifically, to a method for automated verification of device drivers and code access control. Background Technology

[0002] With the continuous iteration and updates of drivers for modern chips (such as GPUs, SoCs, and NPUs), complex content involving kernel-mode driver modules, hardware abstraction layers, graphics / computation rendering stacks, and hardware register interaction logic has emerged. Any code change may introduce rendering anomalies, resource leaks, performance degradation, or system stability issues. Existing device driver verification methods mainly include interface testing, functional rendering / computation testing, and resource stability testing. However, these tests typically exist in the form of independent scripts or tools, lacking a unified scheduling mechanism and making it difficult to effectively integrate with code review systems.

[0003] Meanwhile, while existing continuous integration technologies can automate build and basic testing, device drivers are highly dependent on the real hardware environment. The execution process involves system-level operations such as driver installation, kernel module loading, device initialization, and allocation of specific hardware resources. Existing CI systems typically struggle to complete full runtime environment verification. Therefore, existing technologies suffer from the following problems:

[0004] (1) The build, deployment and testing processes are fragmented and lack a unified scheduling mechanism;

[0005] (2) Driver verification cannot be completed in a real hardware operating environment;

[0006] (3) Test results cannot be fed back to the code review system;

[0007] (4) Lack of code access control mechanism based on actual operation results. Summary of the Invention

[0008] This invention addresses the technical problems existing in the prior art by providing a device driver automated verification and code access control method, which can overcome the problems of the prior art.

[0009] This invention provides a method for automated verification and code access control of device drivers, comprising:

[0010] In the code review system, a code change event listening mechanism is established. When a code commit event is detected, a code change notification is sent to the continuous integration platform.

[0011] When the continuous integration platform receives a code change notification, it triggers the corresponding pipeline task to complete the entire process of automatic building of device drivers, pulling and deploying device drivers, initializing the test environment of test equipment, executing multi-dimensional automated tests, collecting and analyzing test results, and generating and feeding back review results in sequence.

[0012] Access to code submissions will be controlled based on review feedback.

[0013] Based on the above technical solution, the present invention can also be improved as follows.

[0014] Optionally, in the code review system, a code change event listening mechanism is established. When a code commit event is detected, a code change notification is sent to the continuous integration platform, including:

[0015] In the code review system Gerrit, a code change event listening mechanism is established through the Gerrit Trigger plugin. When a new code commit event or code change request event is detected in the code repository, the code review system Gerrit sends the corresponding code change notification to the continuous integration platform Jenkins.

[0016] Optionally, when the continuous integration platform receives a code change notification, it triggers the corresponding pipeline task to sequentially complete the entire process of automatic device driver construction, device driver retrieval and deployment, test environment initialization of test equipment, multi-dimensional automated test execution, test result collection and analysis, and review result generation and feedback, including:

[0017] When the continuous integration platform Jenkins receives a code change notification, it automatically triggers the corresponding pipeline task and pulls the corresponding code change content based on the code repository name, branch information, code version number and commit reference information carried in the code change notification.

[0018] In the collaborative mechanism between the code review system Gerrit and the continuous integration platform Jenkins, Gerrit, as the source of code change events, is only responsible for triggering notifications; Jenkins, as the unified execution and scheduling entity, is responsible for completing the entire process of automatic building of device drivers, cross-platform packaging, automatic deployment, test environment initialization, multi-dimensional test execution, test result analysis, and review feedback.

[0019] Optional, device-driven automated builds include:

[0020] In the continuous integration platform Jenkins, a device-driven automated build process is executed using a pipeline, shared library, and matrix parallel build mechanism. The pipeline task automatically identifies the target platform information to be built based on preset platform configuration parameters. The target platform information includes processor architecture type and operating system type. The processor architecture type includes at least x86_64, aarch64, loongarch64, and sw64, and the operating system type includes at least a Linux distribution or other target operating system.

[0021] Among them, the continuous integration platform Jenkins uses the Matrix parallel build mechanism to treat different combinations of "architecture + operating system" as independent build dimensions, and automatically matches the corresponding build nodes according to the node labels, so as to execute GPU-driven compilation tasks in parallel on multiple build nodes.

[0022] Shared libraries are used to encapsulate unified build logic, including code retrieval, environment initialization, compilation parameter configuration, build command execution, and build result processing.

[0023] During the build process, the continuous integration platform Jenkins automatically pulls the corresponding code version based on the code change information to be reviewed carried in the code change notification, and performs driver compilation operations at the corresponding build node. After the build is completed, the generated driver build artifact is uploaded to the artifact repository.

[0024] The device driver packaging process is then automatically triggered, which pulls the latest driver build artifact for the corresponding platform from the artifact repository, generates a deployable driver installation package, and uploads it to the corresponding directory in the artifact repository.

[0025] Optional, device-driven pull and deployment include:

[0026] Once the device driver installation package is complete, the continuous integration platform's Jenkins pipeline automatically triggers the test preparation process. On the test device, the latest device driver installation package for the corresponding platform is pulled from the artifact repository, and the device driver deployment operation is executed.

[0027] After the driver installation is complete, the test device system will be automatically restarted so that the newly installed device driver can complete system-level loading and initialization.

[0028] Optionally, the test environment initialization of the test equipment includes:

[0029] After the test equipment system restarts, the continuous integration platform Jenkins pipeline automatically executes the test environment initialization process, pulls various test cases and test resources required for testing from the artifact repository, and deploys them to the test equipment;

[0030] Configure the environment variables required for the device driver to run. The environment variables include the driver library path, the graphics interface library path, and the test run path. Start the corresponding test service and automated test environment so that the test task runs in the preset device driver environment.

[0031] Among them, the various tests include at least interface trajectory testing, web graphics rendering testing, and video memory / memory stability testing;

[0032] The process of retrieving various test cases and test resources required for testing from the product warehouse includes:

[0033] A set of trace test files for pulling interface traces;

[0034] Retrieve WebGL CTS test cases for Web graphics rendering testing and initialize the browser's automated runtime environment;

[0035] This program retrieves graphics stress test programs and video test files for video memory / memory stability testing.

[0036] Optional, multidimensional automated test execution includes:

[0037] After the test environment is initialized, the pipeline automatically executes the automated testing tools. Each test task is managed by the automated tools: traversing the test case set, automatically triggering the execution of various test tasks, and uniformly collecting test results.

[0038] Multidimensional testing includes three types of test combinations: interface trajectory testing, web graphics rendering testing, and video memory / memory stability testing. These tests cover the interface execution layer, graphics rendering layer, and resource management layer of the device driver, respectively, to achieve a layered verification system for the correctness of device driver functions, rendering consistency, and resource stability.

[0039] Optional, test result collection and analysis, including:

[0040] After the test is completed, the unified result acquisition module automatically collects the running logs, execution status data and performance monitoring data of each test task, and performs standardized parsing and processing on different types of test results;

[0041] Among them, the interface trajectory test result analysis includes extracting the test case execution status, the Web graphics rendering test result analysis includes extracting the test case pass rate and the number of failed test cases, and the video memory / memory stability test result analysis includes extracting the difference in video memory and system memory usage before and after the test, and determining whether it exceeds the preset threshold.

[0042] All test results are uniformly converted into a structured data model, which includes test type identifier, test pass rate, number of failures, anomaly severity level, and resource anomaly indicators.

[0043] Based on the structured data model, a standardized structured test report is generated.

[0044] Optional, review result generation and feedback, including:

[0045] Based on the generated standardized structured test report, set corresponding weight coefficients for different test types;

[0046] Define the scores for each test:

[0047] When the interface trace test passes, F_api = 1; otherwise, F_api = 0.

[0048] When the Web graphics rendering test passes, F_webgl=1; otherwise, F_webgl=0.

[0049] When the video memory / memory stability test passes, F_mem=1; otherwise, F_mem=0.

[0050] Based on the weighting coefficients and scores corresponding to different test types, a comprehensive score is calculated for the code to be reviewed. The comprehensive score is calculated as follows:

[0051] Score=α·F_api+β·F_webgl+γ·F_mem;

[0052] Wherein, Score is the overall score, α is the weight coefficient of the interface trajectory test, β is the weight coefficient of the Web graphics rendering test, and γ is the weight coefficient of the video memory / memory stability test.

[0053] When the overall score Score is greater than or equal to the preset threshold T, the code review result is generated as Verified +1; when the score is less than the threshold T, the code review result is generated as Verified -1, and the corresponding failed test item and the reason for the exception are marked.

[0054] Optionally, the access control for code submission based on review feedback includes:

[0055] The code review results and the standardized structured test report are automatically written back to the code review system, which is used to control whether the submitted code is allowed to enter the merging process based on the code review results, thereby realizing code access control.

[0056] If the code review result is Verified+1, the submitted code is allowed to enter the merging process; if the code review result is Verified-1, the submitted code is not allowed to enter the merging process.

[0057] This invention provides a method for automated verification and code access control of device drivers. In a code review system, a code change event listening mechanism is established. When a code submission event is detected, a code change notification is sent to the continuous integration platform. Upon receiving the code change notification, the continuous integration platform triggers the corresponding pipeline task, sequentially completing the entire process of automatic device driver construction, device driver retrieval and deployment, test environment initialization of the test equipment, multi-dimensional automated test execution, test result collection and analysis, and review result generation and feedback. Access control for submitted code is then implemented based on the review feedback results. This invention achieves fully automated execution of the entire process of device driver development, from code submission to construction, deployment, and runtime testing. It structures multi-dimensional test results and uses them for code review decisions, ultimately achieving code access control based on runtime results. Attached Figure Description

[0058] Figure 1 A flowchart of a device driver automated verification and code access control method provided in one embodiment of the present invention;

[0059] Figure 2 This is a data interaction diagram of a device driver automated verification and code admission control method according to an embodiment of the present invention;

[0060] Figure 3 This is an overall flowchart of a device driver automated verification and code access control method according to an embodiment of the present invention;

[0061] Figure 4 This is a structural block diagram of a device driver automated verification and code access control system provided in one embodiment of the present invention. Detailed Implementation

[0062] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. In addition, the technical features of the various embodiments or individual embodiments provided by the present invention can be arbitrarily combined with each other to form feasible technical solutions. Such combinations are not constrained by the order of steps and / or structural composition patterns, but must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0063] This invention provides an automated verification method for the device driver development process. Through an automated pipeline based on code commit events, it achieves automatic driver construction, real hardware deployment, and runtime environment initialization. Combined with multi-dimensional testing methods, it uniformly verifies the actual runtime behavior of the driver, thereby solving the problems of missing real runtime environment verification, fragmented testing methods, and verification results that cannot comprehensively reflect driver quality in existing technologies. Furthermore, by performing structured analysis of test results and writing them back to the code review system, it achieves code access control driven by runtime results, forming a closed-loop quality control for the entire device driver development process. This method is applicable to code detection and control for multiple device drivers such as NPUs, SOCs, and GPUs.

[0064] Figure 1 The following is a flowchart illustrating a device driver automated verification and code access control method according to an embodiment of the present invention. Figure 1 As shown, the method includes the following steps:

[0065] Step 1: In the code review system, establish a code change event listening mechanism. When a code commit event is detected, send a code change notification to the continuous integration platform.

[0066] Understandably, see Figure 2 This invention mainly includes a code review system (event source), a continuous integration platform (scheduling core), an artifact repository, and a test equipment cluster (real hardware environment) to achieve automated verification of device drivers.

[0067] In the code review system (Gerrit), a code change event listening mechanism is established through the Gerrit Trigger plugin. When a new patchset commit event (patchset-created) or a code change request event is detected in the code repository, Gerrit sends the corresponding change notification to the continuous build system (Jenkins).

[0068] Step 2: When the continuous integration platform receives a code change notification, it triggers the corresponding pipeline task to complete the entire process of automatic device driver building, device driver retrieval and deployment, test environment initialization of test equipment, multi-dimensional automated test execution, test result collection and analysis, and review result generation and feedback.

[0069] Combination Figure 3 After receiving a code change notification, Jenkins automatically triggers the corresponding pipeline task based on the code repository name, branch information, patch set version number, and commit reference (RefSpec) information carried in the code change event, and pulls the corresponding code change content to execute the subsequent verification process.

[0070] In the collaboration mechanism between the code review system Gerrit and the continuous integration platform Jenkins, Gerrit acts as the source of code change events and is only responsible for triggering notifications; Jenkins acts as the unified execution and scheduling entity and is responsible for completing the entire process of subsequent build, deployment and testing.

[0071] In this embodiment of the invention, the entire pipeline task mainly includes the automatic construction of device drivers, the pulling and deployment of device drivers, the initialization of the test environment of test equipment, the execution of multi-dimensional automated tests, the collection and analysis of test results, and the generation and feedback of review results.

[0072] The automatic construction of device drivers mainly includes the following steps:

[0073] In Jenkins, a Pipeline + Shared Library + Matrix (parallel build) mechanism is used to execute the GPU-driven automated build process. The pipeline task automatically identifies the target platform information to be built based on preset platform configuration parameters, including processor architecture type and operating system type. The processor architecture types include x86_64, aarch64, loongarch64, sw64, etc., and the operating system type includes Linux distributions or other target operating systems.

[0074] Jenkins uses the Matrix build mechanism to treat different combinations of "architecture + operating system" as independent build dimensions and automatically matches the corresponding build nodes based on node labels. This allows GPU driver compilation tasks to be executed in parallel on multiple build nodes, enabling a single pipeline to build multiple platform driver versions in parallel.

[0075] The shared library encapsulates unified build logic, including code retrieval, environment initialization, compilation parameter configuration, build command execution, and build result processing, thereby reducing redundant configurations between different platform build processes and improving the consistency and maintainability of multi-platform build processes.

[0076] During the build process, Jenkins automatically pulls the code version of the corresponding patchset based on the code change information to be reviewed carried in the Gerrit event, and performs driver compilation operations on the corresponding build node. After the build is completed, the generated driver build artifact is uploaded to the artifact repository (Nexus).

[0077] The driver packaging process is then automatically triggered, which pulls the latest build artifact for the corresponding platform from the artifact repository, generates a deployable driver installation package, and uploads it to the corresponding directory of the artifact repository for subsequent automatic deployment and test execution.

[0078] The steps for pulling and deploying the device driver are as follows:

[0079] After the driver is packaged, the Jenkins pipeline automatically triggers the test preparation process. On the test device, the latest GPU driver installation package for the corresponding platform is pulled from the artifact repository, and the driver deployment operation is performed. During driver deployment, it first checks whether the system already has a GPU driver installed. If so, it uses a package management tool to uninstall the existing GPU driver, thus cleaning up the runtime environment of the old version driver; this is done by executing: `dpkg -P`. <driver-package>Uninstall the already installed driver package. Then, execute the installation script (install.sh) within the driver installation package. This script automatically installs the GPU driver using a package management tool. Internally, the installation script uses the dpkg command to deploy the corresponding deb format driver package and performs operations such as driver file copying, kernel module installation, and runtime environment configuration. After driver installation is complete, the test device system is automatically restarted to allow the newly installed GPU driver to complete system-level loading and initialization.

[0080] Since GPU drivers are system-level drivers, their operation depends on the operating system kernel module, device nodes, and graphics service initialization process. After the driver is installed, simply deploying the installation package does not make the driver effective immediately. By restarting the system, the corresponding kernel module of the GPU driver can be reloaded and the GPU device node can be re-identified, thereby ensuring that subsequent tests run in the target driver environment and improving the accuracy and consistency of the verification results.

[0081] The test environment initialization steps include:

[0082] After the system restarts, the Jenkins pipeline automatically executes the test environment initialization process, pulls various test cases and test resources required for testing from the artifact repository, and deploys them to the test equipment.

[0083] The various tests mainly include interface trace testing, Web graphics rendering testing, and video memory / memory stability testing. The test cases and test resources required for each type of test are pulled from the artifact repository, including: pulling the trace test file set for interface trace testing, pulling the WebGL CTS test cases for Web graphics rendering testing, and initializing the browser automated runtime environment; and pulling the graphics stress test program and video test files for video memory / memory stability testing.

[0084] Subsequently, configure the environment variables required for the GPU driver to run, including parameters such as the driver library path, graphics interface library path, and test run path, and start the corresponding test service and automated test environment to ensure that subsequent test tasks run in the preset GPU driver environment.

[0085] Multidimensional automated test execution includes the following steps:

[0086] After the test environment is initialized, the pipeline automatically executes the automated testing tool, which manages all test tasks. It iterates through the test case set, automatically triggers various test tasks, and collects test results uniformly. Multi-dimensional testing includes three test combinations: interface trajectory testing, web graphics rendering testing, and video memory / memory stability testing. These tests cover the GPU driver's interface execution layer, graphics rendering layer, and resource management layer, respectively, achieving a layered verification system for driver functionality correctness, rendering consistency, and resource stability.

[0087] The testing process for each type of test is explained below.

[0088] (1) API trace testing:

[0089] The interface trace test is implemented using the apitrace automated testing tool to verify the rendering consistency of the GPU driver during graphics interface calls. Specifically, firstly, the test device pulls a pre-recorded set of trace test cases and corresponding baseline images from the artifact repository; then, the automated testing tool on the host computer remotely connects to the test device and executes each trace test case sequentially according to the test case set file, generating the corresponding runtime rendering images during driver operation.

[0090] After the test is completed, the automated testing tool transmits the runtime rendered image to the host computer and compares it with the pre-stored benchmark image at the pixel level. When the image difference is within the preset threshold range, the test case is deemed to pass; otherwise, it is deemed to fail.

[0091] (2) Web graphics rendering test (WebGL test):

[0092] Web graphics rendering testing verifies the correctness of the GPU driver's operation in web graphics rendering scenarios by running a WebGL compatibility test suite through a browser. Specifically, the test system first starts a local test server and a pre-defined browser process; then, an automated script drives the browser to execute the WebGL CTS (Compatibility TestSuite) test suite. During the test, the browser interface outputs the number of passed and failed tests in real time; the automated testing tool obtains the browser output results through polling and parses them to generate test statistics. When the number of failed tests exceeds a preset threshold, the web graphics rendering test is considered a failure; otherwise, the test is considered a pass.

[0093] (3) Video memory / memory stability test:

[0094] The video memory / system memory stability test is used to detect video memory leaks and abnormal system memory usage during GPU driver operation. Specifically, before executing the stress test, the test system first reads the video memory and system memory status information corresponding to the GPU driver and records the initial available capacity. Then, multiple graphics stress test programs and video playback programs are run simultaneously for a preset time to simulate high-load operation of the GPU driver. After the stress test, the relevant application processes are closed, the video memory and system memory status information is read again, and the resource difference before and after the test is calculated. When the difference in video memory or system memory exceeds a preset threshold, it is determined that there is a video memory leak or memory anomaly, and the test result is Fail; otherwise, the test is Pass.

[0095] After the test execution is complete, the unified result acquisition module automatically collects the runtime logs, execution status data, and performance monitoring data of each test task, and performs standardized parsing processing on different types of test results. Specifically, this includes:

[0096] (1) Interface trace test result analysis: extract the test case execution status (Pass / Fail);

[0097] (2) Web graphics rendering test result analysis: extract the pass rate and number of failed test cases;

[0098] (3) Analysis of video memory / system memory stability test results: Extract the difference in video memory and system memory usage before and after the test, and determine whether it exceeds the preset threshold.

[0099] Based on this, all test results are uniformly converted into a structured data model, including: test type identifier, test pass rate, number of failures, anomaly severity level, and resource anomaly indicators. Finally, a standardized structured test report is generated for subsequent scoring calculations and review decisions.

[0100] Based on the generated standardized structured test report, the results of different test types are comprehensively scored according to preset weight coefficients.

[0101] Different weighting coefficients are set for different test types: the interface trajectory test has a weight of α, the Web graphics rendering test has a weight of β, and the video memory / memory stability test has a weight of γ.

[0102] The scores for each test are defined as follows:

[0103] When the interface trajectory test passes, F_api=1; otherwise, F_api=0.

[0104] When the Web graphics rendering test passes, F_webgl=1; otherwise, F_webgl=0.

[0105] When the video memory / memory stability test passes, F_mem=1; otherwise, F_mem=0.

[0106] The overall score is calculated as follows:

[0107] Score=α·F_api+β·F_webgl+γ·F_mem

[0108] When the overall score Score is greater than or equal to the preset threshold T, the code review result is generated as Verified +1; when the score is less than the threshold T, the code review result is generated as Verified -1, and the corresponding failed test item and the reason for the exception are marked.

[0109] Step 3: Implement access control for submitted code based on the review feedback results.

[0110] Understandably, the code review results and structured test reports are automatically written back to the code review system to control whether code is allowed to enter the merging process, thereby implementing a code admission control mechanism based on multi-dimensional test results. Specifically, if the code review result is Verified+1, the submitted code is allowed to enter the merging process; if the code review result is Verified-1, the submitted code is not allowed to enter the merging process.

[0111] See Figure 4 This invention provides an embodiment of an automated verification and code access control system for device drivers. The system mainly includes a code event monitoring module 41 and a pipeline scheduling module 42. The pipeline scheduling module 42 comprises a driver construction module 421, a driver packaging module 422, a driver deployment module 423, an environment initialization module 424, a test execution module 425, a test result acquisition module 426, a test result analysis module 427, a scoring calculation module 428, and a review feedback module 429.

[0112] Among them, the code monitoring module 41 is responsible for monitoring code submissions, generating pipeline tasks, and triggering continuous build projects.

[0113] The pipeline scheduling module 42 is used to complete the entire process of automatically building device drivers, pulling and deploying device drivers, initializing the test environment of test equipment, executing multi-dimensional automated tests, collecting and analyzing test results, and generating and feeding back review results in sequence according to the pipeline tasks.

[0114] Among them, the driver build module 421 is used to execute the automatic build process of the device driver using pipeline, Shared Library+ and Matrix parallel build mechanisms.

[0115] The driver packaging module 422 is used to generate driver installation packages for various driver platforms.

[0116] The driver deployment module 423 is used to pull the latest device driver installation package for the corresponding platform from the product warehouse in the test equipment and perform driver deployment operations.

[0117] The environment initialization module 424 is used to pull various test cases and test resources required for testing from the product warehouse and deploy them to the test equipment.

[0118] Test execution module 425 is used to execute various test tasks and generate test results.

[0119] The test result acquisition module 426 is used to collect test results for various types of tests.

[0120] The test result analysis module 427 is used to parse various test results and generate structured data models.

[0121] The scoring calculation module 428 is used to generate a structured data model, calculate the comprehensive test score of the code to be reviewed, and generate the code review results.

[0122] The review feedback module 429 is used to automatically write back the code review results to the code review system, which controls whether the code is allowed to enter the merging process, thereby realizing a code access control mechanism based on multi-dimensional test results.

[0123] It is understood that the device driver automated verification and code access control system provided by the present invention corresponds to the device driver automated verification and code access control method provided in the foregoing embodiments. The relevant technical features of the device driver automated verification and code access control system can be referred to the relevant technical features of the device driver automated verification and code access control method, and will not be repeated here.

[0124] This invention provides a method and system for automated verification and code admission control of device drivers. Through a code submission event-driven pipeline, it automates the entire process of device driver development, from code changes to building, real hardware deployment, runtime testing, and result feedback, significantly reducing manual intervention and improving development efficiency. Unified scheduling of multi-dimensional tests in a real hardware environment ensures that verification results closely reflect actual usage scenarios, improving the ability to identify problems. Through a test result-driven scoring and automatic write-back mechanism, it achieves automated closed-loop control of code admission, fundamentally improving the code quality and system stability of device drivers (GPUs, NPUs, SOCs, etc.).

[0125] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0126] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0127] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0128] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0129] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0130] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0131] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for automated verification and code access control of device drivers, characterized in that, include: In the code review system, a code change event listening mechanism is established. When a code commit event is detected, a code change notification is sent to the continuous integration platform. When the continuous integration platform receives a code change notification, it triggers the corresponding pipeline task to complete the entire process of automatic building of device drivers, pulling and deploying device drivers, initializing the test environment of test equipment, executing multi-dimensional automated tests, collecting and analyzing test results, and generating and feeding back review results in sequence. Access to code submissions will be controlled based on review feedback.

2. The device driver automated verification and code access control method according to claim 1, characterized in that, The code review system establishes a code change event listening mechanism. When a code commit event is detected, a code change notification is sent to the continuous integration platform, including: In the code review system Gerrit, a code change event listening mechanism is established through the Gerrit Trigger plugin. When a new code commit event or code change request event is detected in the code repository, the code review system Gerrit sends the corresponding code change notification to the continuous integration platform Jenkins.

3. The device driver automated verification and code access control method according to claim 1, characterized in that, When the continuous integration platform receives a code change notification, it triggers the corresponding pipeline task, sequentially completing the entire process of automatic device driver construction, device driver retrieval and deployment, test environment initialization of test equipment, multi-dimensional automated test execution, test result collection and analysis, and review result generation and feedback, including: When the continuous integration platform Jenkins receives a code change notification, it automatically triggers the corresponding pipeline task and pulls the corresponding code change content based on the code repository name, branch information, code version number and commit reference information carried in the code change notification. In the collaborative mechanism between the code review system Gerrit and the continuous integration platform Jenkins, Gerrit, as the source of code change events, is only responsible for triggering notifications; Jenkins, as the unified execution and scheduling entity, is responsible for completing the entire process of automatic building of device drivers, cross-platform packaging, automatic deployment, test environment initialization, multi-dimensional test execution, test result analysis, and review feedback.

4. The device driver automated verification and code access control method according to claim 1 or 3, characterized in that, Automatic build of device drivers, including: In the continuous integration platform Jenkins, a device-driven automated build process is executed using a pipeline, shared library, and matrix parallel build mechanism. The pipeline task automatically identifies the target platform information to be built based on preset platform configuration parameters. The target platform information includes processor architecture type and operating system type. The processor architecture type includes at least x86_64, aarch64, loongarch64, and sw64, and the operating system type includes at least a Linux distribution or other target operating system. Among them, the continuous integration platform Jenkins uses the Matrix parallel build mechanism to treat different combinations of "architecture + operating system" as independent build dimensions, and automatically matches the corresponding build nodes according to the node labels, so as to execute GPU-driven compilation tasks in parallel on multiple build nodes. Shared libraries are used to encapsulate unified build logic, including code retrieval, environment initialization, compilation parameter configuration, build command execution, and build result processing. During the build process, the continuous integration platform Jenkins automatically pulls the corresponding code version based on the code change information to be reviewed carried in the code change notification, and performs driver compilation operations at the corresponding build node. After the build is completed, the generated driver build artifact is uploaded to the artifact repository. The device driver packaging process is then automatically triggered, which pulls the latest driver build artifact for the corresponding platform from the artifact repository, generates a deployable driver installation package, and uploads it to the corresponding directory in the artifact repository.

5. The device driver automated verification and code access control method according to claim 4, characterized in that, Device driver pulling and deployment includes: Once the device driver installation package is complete, the continuous integration platform's Jenkins pipeline automatically triggers the test preparation process. On the test device, the latest device driver installation package for the corresponding platform is pulled from the artifact repository, and the device driver deployment operation is executed. After the driver installation is complete, the test device system will be automatically restarted so that the newly installed device driver can complete system-level loading and initialization.

6. The device driver automated verification and code access control method according to claim 5, characterized in that, Initialize the test environment for the test equipment, including: After the test equipment system restarts, the continuous integration platform Jenkins pipeline automatically executes the test environment initialization process, pulls various test cases and test resources required for testing from the artifact repository, and deploys them to the test equipment; Configure the environment variables required for the device driver to run. The environment variables include the driver library path, the graphics interface library path, and the test run path. Start the corresponding test service and automated test environment so that the test task runs in the preset device driver environment. Among them, the various tests include at least interface trajectory testing, web graphics rendering testing, and video memory / memory stability testing; The process of retrieving various test cases and test resources required for testing from the product warehouse includes: A set of trace test files for pulling interface traces; Retrieve WebGL CTS test cases for Web graphics rendering testing and initialize the browser's automated runtime environment; This program retrieves graphics stress test programs and video test files for video memory / memory stability testing.

7. The device driver automated verification and code access control method according to claim 6, characterized in that, Multidimensional automated test execution includes: After the test environment is initialized, the pipeline automatically executes the automated testing tools. Each test task is managed by the automated tools: traversing the test case set, automatically triggering the execution of various test tasks, and uniformly collecting test results. Multidimensional testing includes three types of test combinations: interface trajectory testing, web graphics rendering testing, and video memory / memory stability testing. These tests cover the interface execution layer, graphics rendering layer, and resource management layer of the device driver, respectively, to achieve a layered verification system for the correctness of device driver functions, rendering consistency, and resource stability.

8. The device driver automated verification and code access control method according to claim 7, characterized in that, Test results collection and analysis, including: After the test is completed, the unified result acquisition module automatically collects the running logs, execution status data and performance monitoring data of each test task, and performs standardized parsing and processing on different types of test results; Among them, the interface trajectory test result analysis includes extracting the test case execution status, the Web graphics rendering test result analysis includes extracting the test case pass rate and the number of failed test cases, and the video memory / memory stability test result analysis includes extracting the difference in video memory and system memory usage before and after the test, and determining whether it exceeds the preset threshold. All test results are uniformly converted into a structured data model, which includes test type identifier, test pass rate, number of failures, anomaly severity level, and resource anomaly indicators. Based on the structured data model, a standardized structured test report is generated.

9. The device driver automated verification and code access control method according to claim 8, characterized in that, The generation and feedback of review results include: Based on the generated standardized structured test report, set corresponding weight coefficients for different test types; Define the score for each test: When the interface trace test passes, F_api = 1; otherwise, F_api = 0. When the Web graphics rendering test passes, F_webgl=1; otherwise, F_webgl=0. When the video memory / memory stability test passes, F_mem=1; otherwise, F_mem=0. Based on the weighting coefficients and scores corresponding to different test types, a comprehensive score is calculated for the code to be reviewed. The comprehensive score is calculated as follows: Score=α·F_api+β·F_webgl+γ·F_mem; Wherein, Score is the overall score, α is the weight coefficient of the interface trajectory test, β is the weight coefficient of the Web graphics rendering test, and γ is the weight coefficient of the video memory / memory stability test. When the overall score Score is greater than or equal to the preset threshold T, the code review result is generated as Verified +1; when the score is less than the threshold T, the code review result is generated as Verified -1, and the corresponding failed test item and the reason for the exception are marked.

10. The device driver automated verification and code access control method according to claim 9, characterized in that, The access control for code submission based on review feedback includes: The code review results and the standardized structured test report are automatically written back to the code review system, which is used to control whether the submitted code is allowed to enter the merging process based on the code review results, thereby realizing code access control. If the code review result is Verified+1, the submitted code is allowed to enter the merging process; if the code review result is Verified-1, the submitted code is not allowed to enter the merging process.

Images