Software development method and electronic device

Abstract

The application relates to the technical field of switches, in particular to a software development method and an electronic device. The software development method comprises the following steps: loading a virtual driver in a software development environment, creating a driver file node of a simulated hardware device corresponding to a real hardware device and an access node associated with the driver file node of the simulated hardware device, setting a debugging state of a virtual system in the virtual driver in response to receiving a debugging instruction, returning state information of the simulated hardware device generated based on debugging memory data if the debugging state is a first debugging state, returning state information of the simulated hardware device generated based on preset simulated hardware data if the debugging state is a second debugging state, and completing development of to-be-developed software according to the state information. The method solves the technical problem that software development depends on hardware devices and hardware-software development cannot be performed in advance before software development, and achieves the technical effect of shortening a software development cycle by simulating a hardware-software development process.

Description

Technical Field

[0001] This application relates to the field of switch technology, and more particularly to a software development method and an electronic device. Background Technology

[0002] In current switch equipment development, open-source systems are commonly used as the foundational platform. These systems provide complete test command sets, backend services, and container management mechanisms to control and accept hardware devices. However, these systems are highly dependent on interface middleware, whose development relies on the availability of hardware drivers. Developers must wait for the actual switch hardware to be assembled, firmware to be stable, and the underlying drivers to be successfully installed before they can begin software development and verification. This strong hardware dependency causes software development to lag significantly behind hardware progress, extending the overall project cycle. Furthermore, once the hardware is ready, multiple modules such as software, drivers, and firmware need to be integrated and debugged simultaneously. Problems often erupt at this stage, leading to high debugging complexity and further impacting development efficiency. Therefore, this application proposes a software development method that decouples software and hardware dependencies and simulates the hardware-software development process to shorten the software development cycle. Summary of the Invention

[0003] This application provides a software development method, apparatus, electronic device, and computer-readable storage medium to at least solve the technical problem that software development relies on hardware devices and makes it impossible to perform hardware and software development in advance before software development.

[0004] This application provides a software development method, which includes: loading a virtual driver in a software development environment, the virtual driver being used to create a driver file node for a simulated hardware device corresponding to a real hardware device; creating an access node associated with the driver file node of the simulated hardware device, the access node being used to provide the software with a device interface for accessing the simulated hardware device; in response to receiving a debugging instruction through the access node, setting the debugging state of the virtual system in the virtual driver, wherein the debugging state includes a first debugging state and a second debugging state; in response to the debugging state being the first debugging state, returning the status information of the simulated hardware device generated based on debug memory data; and in response to the debugging state being the second debugging state, returning the status information of the simulated hardware device generated based on preset simulated hardware data.

[0005] This application also provides an electronic device, which includes: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described software development methods.

[0006] This application loads a virtual driver in the software development environment, creating a driver file node that fully corresponds to the real hardware device through software simulation. This provides an operational device foundation for upper-layer applications in the absence of physical hardware. Furthermore, by creating a standard access node associated with the driver file node and conforming to industry specifications, it connects the upper-layer software with the lower-layer simulation environment, ensuring software migration and interface consistency between the simulation and real environments. It also introduces a dynamically configurable debug state. When a debug command is received through the access node, the virtual driver can be set to either a first or second debug state, forming a dual response. In the first debug state, the system returns status information generated based on dynamically modifiable debug memory data, allowing developers to actively simulate various anomalies and boundary conditions. In the second debug state, it returns stable status information generated based on preset simulated hardware data, simulating normal hardware operation scenarios. This state-based response expands the breadth of test coverage, enabling earlier software development and shortening project cycles, providing a verification platform for early multi-module joint debugging and problem discovery.

[0007] Therefore, this method can solve the technical problem of software development relying on hardware devices and being unable to carry out hardware and software development in advance before software development, and achieve the technical effect of shortening the software development cycle by simulating the hardware and software development process. Attached Figure Description

[0008] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 An application environment diagram of a software development method provided in this application embodiment;

[0010] Figure 2 A flowchart illustrating a software development method provided in an embodiment of this application;

[0011] Figure 3 A flowchart illustrating another software development method provided in an embodiment of this application;

[0012] Figure 4 This is a schematic diagram of the structure of a software development apparatus provided in an embodiment of this application;

[0013] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0014] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0015] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0016] It should be noted that the terms "S1," "S2," etc., are used only for descriptive purposes and do not specifically refer to the order or sequence, nor are they intended to limit this application. They are merely for the convenience of describing the method of this application and should not be construed as indicating the sequential order of the steps. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0017] To address the technical problem of software development relying on hardware devices and being unable to perform hardware software development before software development, this application loads a virtual driver in the software development environment. The virtual driver is used to create driver file nodes for simulated hardware devices corresponding to real hardware devices; it also creates access nodes associated with the driver file nodes of the simulated hardware devices, which provide the software with a device interface to access the simulated hardware devices; in response to receiving debugging instructions through the access nodes, it sets the debugging state of the virtual system in the virtual driver, where the debugging state includes a first debugging state and a second debugging state; in response to the first debugging state, it returns the status information of the simulated hardware devices generated based on debugging memory data; in response to the second debugging state, it returns the status information of the simulated hardware devices generated based on preset simulated hardware data. This achieves the technical effect of shortening the software development cycle by simulating the hardware software development process.

[0018] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. The software development method provided in this application can be applied to, for example... Figure 1 , Figure 1This diagram illustrates an application environment for a software development method provided in this application embodiment. Terminal 12 communicates with server 14 via a network. Terminal 12 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. Server 14 can be a standalone server or a server cluster consisting of multiple servers.

[0019] The embodiments of this application provide a software development method, and the method is described in detail in conjunction with the execution flow of the software development method.

[0020] In one embodiment, such as Figure 2 As shown, Figure 2 This is a flowchart illustrating a software development method provided in an embodiment of this application.

[0021] S101: Loads a virtual driver in the software development environment. The virtual driver is used to create driver file nodes for simulated hardware devices that correspond to real hardware devices.

[0022] In this embodiment, a virtual driver is a software module whose function is not to control real physical hardware, but to simulate a software interface and behavior completely identical to that of a real hardware driver in the operating system kernel or user space. In this application, the virtual driver is similar to a hardware simulator, providing a simulated hardware object for upper-layer software when real switch hardware is lacking. A driver file node refers to a special file that a driver typically creates in the file system, such as / dev or / sys, within the operating system. Applications interact with the hardware driver by reading and writing to these files, thereby controlling the hardware.

[0023] Specifically, this embodiment forms the foundation of the entire debugging framework by creating driver file nodes corresponding to real hardware devices. Virtual drivers are installed and loaded in the software development environment, and the software establishes a simulated hardware abstraction layer at the underlying level. The virtual driver creates driver file nodes that correspond one-to-one with the target real hardware, which can be components such as fans, power supplies, sensors, and optical modules of a switch.

[0024] S102: Create an access node associated with the driver file node of the simulated hardware device. The access node is used to provide the software with a device interface to access the simulated hardware device.

[0025] In this embodiment, the access nodes can be nodes created in a specific directory following a specific specification, where the specific directory can be / sys_switch / . This specific specification is used to standardize the platform hardware management interface, build a unified hardware abstraction layer, and shield the differences between different hardware platforms to solve common problems in the integration process of upper-layer software and lower-layer devices of the switch. These access nodes are the standard interfaces that the upper-layer software expects to access, where the upper-layer software can be the platform hardware management interface.

[0026] Specifically, in this embodiment, the driver file nodes associated with the simulated hardware device can be implemented using soft links. This involves linking access nodes conforming to specific specifications to the actual driver file nodes created by the virtual driver, thereby redirecting access to standard interfaces to the underlying simulated driver. This embodiment connects the upper-layer application and the lower-layer simulated driver through standardized interface mapping. Driver file nodes created by the virtual driver, which may have inconsistent locations or names, are mapped into a unified, structured access interface according to industry or project standards. This ensures consistency of the upper-layer software's interface between the simulated and real environments, allowing developers to switch between simulated and real environments without modifying code, reducing development and testing complexity.

[0027] S103: In response to receiving a debugging instruction through the access node, set the debugging state of the virtual system in the virtual driver, wherein the debugging state includes a first debugging state and a second debugging state.

[0028] In this embodiment, a debug command refers to a command issued by a user or test script by writing a string of a specific format, such as "fan10," to a specific debug interface node to simulate dynamic changes in hardware state. A debug state refers to a flag or mode switch within the virtual driver. The first debug state indicates Debug mode, meaning the driver will preferentially use debug memory data to simulate device state; the second debug state indicates non-Debug mode, meaning the driver will use preset, static simulated hardware data to simulate device state.

[0029] Specifically, a dynamically configurable debugging mode mechanism is introduced. Through a controllable switch, the simulation environment can switch between two modes: a configurable dynamic debugging mode for simulating anomalies and boundary conditions, and a static data mode for simulating normal and stable hardware operation. This achieves full coverage of test scenarios, simulating not only normal hardware operation but also abnormal situations, thereby verifying the integrity of the upper-layer software.

[0030] The debugging instructions also include exception simulation instructions for simulating abnormal device states. When a debugging instruction is identified as an exception simulation instruction, the device identifier and target exception type identifier of the target simulated hardware device are parsed and obtained. The exception simulation state corresponding to the target exception type identifier is set in the virtual driver. In response to the exception simulation state being set, the preset error response information corresponding to the target exception type identifier is returned to simulate a scenario in which the target simulated hardware device experiences a hardware exception.

[0031] In this embodiment, debugging commands are no longer limited to simulating normal device "insertion," "removal," or status settings. Instead, they extend to include exception simulation commands. When parsing commands, the virtual driver identifies keywords to determine if they are exception simulation commands and extracts the target exception type identifier. Once the driver determines it to be an exception simulation command, it sets a corresponding exception simulation state. This state can work independently of or in conjunction with the aforementioned debugging states. When upper-layer software accesses the device's status information, the driver prioritizes checking the exception simulation state before generating a response. If a specific exception state is found to be set, normal simulation data is not returned; instead, a preset error response is returned. Exception simulation commands allow developers in the virtual debugging environment to systematically test the behavior of upper-layer software in the face of various hardware exceptions before the hardware is ready, helping to identify and fix potential fault tolerance defects early in development.

[0032] S104: In response to the debug state being the first debug state, return the status information of the simulated hardware device generated based on debug memory data.

[0033] In this embodiment, debug memory data refers to a specific memory region allocated in the driver. Its value can be dynamically modified through debug commands, and is used to overwrite or influence preset hardware data in debug mode to simulate state changes. State information represents the hardware state that the upper-layer software is concerned with, such as fan speed, whether the power supply is in place, sensor temperature value, and the insertion / removal status of the optical module.

[0034] S105: In response to the debugging state being the second debugging state, return the status information of the simulated hardware device generated based on preset simulated hardware data.

[0035] In this embodiment, the preset simulated hardware data represents the static data initialized by the virtual driver according to the configuration parameters when it is loaded, which is used to simulate the baseline state of the hardware under normal conditions.

[0036] Specifically, based on different debug state modes, when the upper-layer software requests device status, the virtual driver will select different data sources to generate a response according to the currently set debug state.

[0037] S106: Complete the development of the software to be developed based on the status information of the simulated hardware device.

[0038] In this embodiment, once the software under development passes all test cases in the simulation environment, the development of the software based on the simulation state information is considered basically complete. Once the real hardware is ready, simply switching the environment to non-debugging mode or directly connecting to the real driver allows for rapid integration testing and deployment, shortening the overall project cycle.

[0039] In this embodiment, by loading a virtual driver in the software development environment, a driver file node that completely corresponds to the real hardware device is created through software simulation. This builds an operable device foundation for upper-layer applications in the absence of physical hardware. Furthermore, by creating a standard access node associated with the driver file node and conforming to industry standards, the upper-layer software is connected to the lower-layer simulation environment. This ensures the migration and interface consistency of the software between the simulation and real environments. A dynamically configurable debug state is introduced. When a debug command is received through the access node, the virtual driver can be set to either a first or second debug state, forming a dual response. In the first debug state, the system returns status information generated based on dynamically modifiable debug memory data, allowing developers to actively simulate various anomalies and boundary conditions. In the second debug state, it returns stable status information generated based on preset simulated hardware data, simulating normal hardware operation scenarios. This state-based response expands the breadth of test coverage, enabling earlier software development and shortening project cycles. It provides a verification platform for early multi-module joint debugging and problem discovery, solving the technical problem of software development relying on hardware devices and being unable to perform hardware-software development before software development. This achieves the technical effect of shortening the software development cycle by simulating the hardware-software development process.

[0040] In one embodiment, such as Figure 3 As shown, Figure 3 This is a flowchart illustrating another software development method provided in an embodiment of this application.

[0041] In one specific embodiment, the driver file node created by the virtual driver is identified; a target file directory structure is created according to a preset file system specification to form an access node framework corresponding to the driver file node; the access nodes in the access node framework are linked to the corresponding driver file node by means of soft links to form a simulated hardware device access path; read and write permissions are set for the access nodes, and the correctness of the read and write permissions is verified so that the software can access the simulated hardware device through the simulated hardware device access path.

[0042] Specifically, after the virtual driver is installed and the underlying driver file node is successfully created, the system automatically identifies the nodes distributed in the system directory through predefined scanning rules. The system directory can be / sys / class / and / dev / . This completes the discovery and registration of the simulated hardware interface. According to the preset file system specification, a standardized target file directory structure is created in user space, such as / sys_switch / fan / or / sys_switch / thermal_sensor / . This constructs an access node framework consistent with the real hardware environment. Through soft links, each standard access node in the framework, such as / sys_switch / fan / fan1_present, is mapped and linked to its corresponding underlying driver file node, forming a complete and unified access path for the simulated hardware device. To ensure the security and reliability of access, the system can set read and write permissions for the access nodes and verify the correctness of the read and write permissions. This ensures that the upper-layer software can access the simulated hardware device through the standardized path, enabling software debugging and functional verification in the virtual environment without any difference from the real environment.

[0043] Specifically, driver file nodes can be divided into the following categories: alias nodes, maximum value nodes, minimum value nodes, register test data nodes and other file read / write nodes, sensor value nodes, optical module erasable programmable read-only memory nodes and low-speed internal integrated circuit signal nodes, fan / power module in-situ status nodes, fan / power module status nodes, fan / power module information nodes, fan / power module running status nodes, etc.

[0044] Among them, file read / write nodes have a single function, possessing only read / write attributes and their corresponding permissions. Read-only nodes such as alias nodes, maximum value nodes, and minimum value nodes are implemented by creating corresponding driver file nodes in user space using structures. Reading and writing driver file nodes allows access to their corresponding memory. Driver file node attributes are implemented through structure assignment and setting permission attributes. The validity of the data written to memory is determined by verifying data legality and checking for memory overflow, thus ensuring the correctness of the code's functionality. This embodiment constructs a directory framework conforming to preset specifications, establishes symbolic link mappings, and sets permissions to build a simulated hardware device access path. This ensures that the way upper-layer software accesses device interfaces in the virtual debugging environment is consistent with the access method in the future real hardware environment, thereby achieving seamless software migration between different environments and eliminating software modification costs caused by interface differences.

[0045] In one specific embodiment, the access node includes a debug interface node with write permissions, and the software development method includes responding to receiving a debug instruction through the debug interface node; parsing the debug instruction to obtain a device identifier of the simulated hardware device and a desired simulated device status value, wherein the device identifier is used to indicate the target simulated hardware device to be debugged; determining the debug memory data address corresponding to the target simulated hardware device based on the device identifier; and writing the device status value to the debug memory data address to update the debug memory data used to generate status information.

[0046] The debug interface node is a special file node with write permissions, serving as a channel for transmitting debug commands between user space and the virtual driver. Users issue debug commands by writing strings of a specific format to this node. Debug commands are string commands written by the user or test script to the debug interface node, following the format of device identifier status values, such as "fan10," and are used to instruct the virtual driver to simulate the state changes of a specific hardware device. The device identifier is a string in the debug command used to uniquely identify the target simulated hardware device, such as "fan1" or "eth1." The virtual driver parses this identifier to determine the specific device to be operated on. The device status value is a numerical value in the debug command used to represent the desired simulated device state, such as "0" indicating the device is unplugged / malfunctioning, and "1" indicating the device is plugged in / normal. This value will be written to debug memory to overwrite or affect the device's preset state. The debug memory data address refers to a specific area address in memory where the virtual driver resides. Each simulated hardware device has a corresponding storage unit in this area, used to store its dynamic state data in debug mode. Debug memory data is dynamic data stored at the above address. Its value can be modified by debug commands. In debug mode, it performs logical operations with preset simulated hardware data to generate status information returned to the upper-level software.

[0047] Specifically, this embodiment provides a standardized interface for dynamically configuring hardware states. After the virtual driver is installed and the access node framework is built, a debug interface node with write permissions is created. When a user or automated test script needs to simulate a specific hardware event through software, a debug instruction conforming to a predetermined format is written to this node. The virtual driver monitors this node in real time. Once it receives the instruction, it immediately starts the parsing process to obtain the key device identifier and the desired simulated device state value from the instruction string, thereby identifying the target simulated hardware device, such as fan number 1, and the target state is "unplugged". Based on this device identifier, the driver searches for and determines the debug memory data address corresponding to the fan in its internally maintained mapping table, that is, the memory pointer pointing to the debugging state of fan number 1. The virtual driver writes the obtained device state value to the debug memory data address, thereby updating the source data used to generate state information.

[0048] This embodiment enables testers to directly modify the state data of specific simulated devices in memory through simple command-line instructions by setting up a debug interface node. This allows them to actively simulate various normal, abnormal, and boundary hardware scenarios without restarting the environment or modifying driver code, thus expanding the breadth of test coverage and improving software development efficiency.

[0049] In one specific embodiment, returning the status information of the simulated hardware device generated based on debug memory data includes: in response to receiving a request to access the status information, calling the status acquisition function corresponding to the target simulated hardware device; determining the current debug status based on the status acquisition function; in response to the debug status being the first debug status, reading the debug memory data corresponding to the target simulated hardware device; performing logical operations on the read debug memory data and preset simulated hardware data to obtain the operation result; and returning the operation result as status information.

[0050] The status information of the simulated hardware device generated based on the preset simulated hardware data is returned. In response to the second debug state, the preset simulated hardware data of the target simulated hardware device is directly read and the preset simulated hardware data is returned as status information.

[0051] The status acquisition function refers to a predefined kernel function in the virtual driver for a specific type of simulated hardware device. When upper-layer software queries the device status, it executes a specific routine after entering kernel mode via a system call, responsible for collecting and returning the device's current status information. The debug state refers to a mode flag maintained internally by the virtual driver, used to control the data source and generation logic of status information. The first debug state, such as Debug mode, instructs the system to prioritize dynamically adjustable debug memory data. The second debug state, such as non-Debug mode, instructs the system to use static preset simulated hardware data. Debug memory data refers to data stored in a specific area of ​​the driver's memory, whose values ​​can be dynamically modified by user instructions through debug interface nodes, used to simulate temporary changes in device status in debug mode. Preset simulated hardware data refers to baseline hardware data generated and stored by the virtual driver based on configuration parameters during initialization, used to simulate the static attributes of the device under normal operating conditions, such as the default fan speed and the baseline values ​​of sensors.

[0052] Specifically, when the upper-layer software initiates an access request for status information through an access node, the process enters kernel mode and calls a pre-registered status acquisition function corresponding to the target simulated hardware device. This function determines the current debug state based on its internal logic. If the debug state is the first debug state, the function reads the debug memory data corresponding to the target simulated hardware device, reads the value at the pointer offset address, performs logical operations on the read debug memory data and preset simulated hardware data, obtains the result, and finally returns this result as status information to the application layer. Conversely, if the debug state is the second debug state, the function logic bypasses the debug memory, directly reads the preset simulated hardware data of the target simulated hardware device, and returns this preset data as status information. By introducing debug state-based judgment logic, the virtual debugging environment can function as a stable and predictable benchmark platform in the second debug state, ensuring the correctness of the software's basic functions. Simultaneously, in the first debug state, it can simulate various extreme, abnormal, or transient hardware scenarios through logical operations on dynamic memory data and static simulated data, thereby enhancing the verification strength of the upper-layer software's fault tolerance capabilities.

[0053] In one specific embodiment, in response to simulating the hardware device as a signal conversion device, the software development method further includes, in response to loading the virtual driver, initializing the port data of the signal conversion device according to configuration parameters; setting the simulated presence signal of the port, and controlling access permissions to the port data according to the status of the presence signal; and creating an access node for the signal conversion device.

[0054] The access nodes include control signal nodes and storage data access nodes, and the signal conversion equipment is debugged based on the access nodes. The signal conversion equipment can be an optical module, which is an optoelectronic device that performs photoelectric and electro-optical conversion.

[0055] Specifically, in response to loading the virtual driver, the system first initializes the port data of the signal conversion device in memory according to the configuration parameters passed in when the driver is loaded. It allocates a data structure for each port and fills it with the simulated data of the default storage data access node. It sets the simulated presence signal of the port, such as initializing the presence status node to 1 to indicate that it is in the presence by default. It controls the access permissions to the port data according to the presence signal status. It creates the access nodes of the signal conversion device according to the preset specifications, including the control signal node and the storage data access node. Users can debug the signal conversion device based on the access nodes. For example, by writing the command echo "lpmode 1"> / sys_switch / transceiver / port1 / lpmode, a low-power mode can be simulated, and the driver will block access to the storage data access node accordingly. Or, by using the command echo "reset 1", a reset operation can be simulated, and the driver will update the port data and remove the access block.

[0056] This embodiment provides full-function simulation of devices such as optical modules, covering normal read and write operations. It can also simulate key behaviors such as low-power modes and reset control, freeing the development and verification of upper-layer software from the availability and specific models of physical optical modules, and enabling early system integration testing. Through dynamically configurable port data and state control mechanisms, it supports the simultaneous simulation of different state combinations of numerous ports, improving the coverage and complexity of test scenarios.

[0057] In one specific embodiment, a control signal node refers to a special file node in the signal conversion device access node used to receive control commands, such as low-power mode control and reset control. Users simulate hardware control signals by writing specific values ​​to these nodes. A debug command to set low-power mode refers to a specific value written by the user to the low-power control node, instructing the virtual driver to set the corresponding optical module to a low-power state. A debug command to set reset mode refers to a specific value written by the user to the reset control node, instructing the virtual driver to perform a reset operation on the optical module. Setting access permissions to a masked state refers to a flag set in memory by the virtual driver. When this flag is set, the driver will reject all read / write access requests to the storage data node on that port. Setting access permissions to an unmasked state is the opposite of the masked state; it means setting the access permission flag to an allowed state, restoring normal access to the storage data node.

[0058] Specifically, when a user needs to debug the signal conversion device through the control signal node, in response to receiving a debugging command to set the low-power mode through the control signal node, the virtual driver sets the access permissions in the port data to a masked state, thereby blocking access to the storage data access node. Any subsequent attempts to read the storage data access node data will be rejected by the driver, simulating the physical characteristic that a real optical module cannot access the configuration memory in low-power mode. Correspondingly, in response to receiving a debugging command to set the reset mode through the control signal node, the virtual driver updates the port data, such as reinitializing the port register state, and sets the access permissions to an unmasked state to perform access to the storage data node, simulating the complete lifecycle behavior of a real device regaining accessibility after a reset.

[0059] This embodiment simulates the hardware's low-power mode and reset operation, enabling upper-layer software to verify its response to device state changes in a virtual environment. Through a dynamic access control mechanism, it simulates the activation of low-power mode, replicating the impact of state changes on data access capabilities and improving the realism and effectiveness of the test. Furthermore, it verifies the fault tolerance and recovery logic under abnormal device conditions, ensuring that when the optical module enters a low-power or reset state, the upper-layer management software can correctly identify and handle access restrictions, avoiding incorrect access timeouts or data verification failures, and enhancing the system's reliability in managing the optical module.

[0060] In one specific embodiment, in response to the simulated hardware device being a sensor, loading a virtual driver in the software development environment includes, in response to loading the virtual driver, receiving a range of numerical parameters of the sensor; determining whether a range of numerical parameters has been received; in response to receiving a range of numerical parameters, generating simulated data of the sensor within the range of numerical parameters; and in response to not receiving a range of numerical parameters, generating simulated data of the sensor within a preset range of numerical parameters, wherein the simulated data is used as preset simulated hardware data.

[0061] The numerical parameter range refers to the range of values ​​generated by the user through module parameters when loading the sensor virtual driver, used to limit the range of values ​​for the sensor's simulated data. The preset numerical parameter range refers to the default numerical range predefined within the virtual driver; this default value is automatically used as the data generation boundary when the user does not specify a parameter range. The sensor's simulated data refers to the simulated sensor readings generated by the virtual driver based on the specified or preset numerical range using an algorithm. This data will be provided to the upper-layer software as preset simulated hardware data.

[0062] Specifically, in response to loading the virtual driver, the driver receives the range of numerical parameters from the sensor, and then determines whether the range of numerical parameters has been received, that is, whether the user provided valid parameters during loading. In response to receiving the range of numerical parameters, the driver generates simulated data of the sensor within the range of numerical parameters; otherwise, in response to not receiving the range of numerical parameters, the driver generates simulated data of the sensor within a preset range of numerical parameters. The simulated data is used as preset simulated hardware data to provide a data source for subsequent status queries.

[0063] This embodiment enables the sensor simulation to be dynamically adjusted according to actual testing needs. When it is necessary to test software behavior under specific conditions, boundary value data can be generated centrally by specifying a narrow parameter range, thereby improving testing efficiency. When performing routine functional verification, a default wide range of parameters can be used to ensure comprehensive test coverage. This allows the virtual driver to meet the testing needs of different stages and purposes, avoids maintaining multiple simulation environments for different test scenarios, and enhances the testing capabilities for boundary conditions and abnormal situations.

[0064] In one specific embodiment, in response to the simulated hardware device being a pluggable device, the debugging instruction is used to simulate the insertion or removal of the pluggable device, and the calculation result is returned as status information, including performing a bitwise AND operation between the read debugging memory data and the preset simulated hardware data; modifying the debugging memory data according to the bitwise AND operation result, and returning the modified debugging memory data to the software, so as to characterize the in-situ status of the target simulated device through the debugging memory data.

[0065] Pluggable devices can be hardware components that support hot-swapping during device operation, such as fan modules, power modules, and optical modules of a switch. Changes in their physical connection status need to be detected by the system in real time. The "in-place" status represents whether the pluggable device is physically connected to the system, typically represented by 1 for "in-place" (inserted) and 0 for "out-of-place" (unplugged).

[0066] Specifically, when responding to a pluggable device, such as a fan module, and when the debugging command is used to simulate the insertion or removal of the pluggable device, the read debugging memory data is bitwise ANDed with the preset simulated hardware data. The debugging memory data is modified according to the bitwise AND operation result, the operation result is written back to the debugging memory area, and the modified debugging memory data is returned to the software. The debugging memory data is used to characterize the in-situ state of the target simulated device.

[0067] This embodiment simulates the state changes of pluggable devices. By controlling the changes of specific bits in the device state, the simulated pluggable state is made consistent with the actual hardware behavior, thereby improving the fidelity of the state simulation.

[0068] In one specific embodiment, the software development method further includes parsing debugging instructions; in response to the debugging instructions instructing the simulated target hardware device to be unplugged, setting the access permission in the port data corresponding to the target hardware device to a masked state, and masking access to the storage data node; in response to the debugging instructions instructing the simulated target hardware device to be plugged in, determining whether the presence state of the target hardware device in the port data has changed; in response to the presence state changing, clearing the simulated historical data in the port data, setting the access permission to an unmasked state, and updating the presence state of the target hardware device in the port data.

[0069] Simulated historical data refers to temporary state data or anomaly markers accumulated in the device port data structure due to multiple simulated operations during the debugging process. A change in in-situ state refers to a transition in the physical connection state of the port from "inserted" to "unplugged" or vice versa, which triggers the need to reset the port data.

[0070] Specifically, the driver parses the debugging instructions to obtain the operation type and device identifier; in response to the debugging instruction instructing the target simulated hardware device to be unplugged, the driver immediately sets the access permission in the port data corresponding to the target simulated hardware device to the masked state, and blocks access to the storage data node. Any read request to the storage data node will return an access error, which is a characteristic that the real simulated device cannot be accessed after it is unplugged; in response to the debugging instruction instructing the target simulated hardware device to be plugged in, the driver determines whether the presence status of the target simulated hardware device in the port data has changed; in response to the presence status changing, the driver clears the simulated historical data in the port data, sets the access permission to the unmasked state, and updates the presence status of the target simulated hardware device in the port data. By determining whether the presence status has changed substantially, the driver decides whether to clean up the historical debugging data to avoid state data pollution caused by multiple debugging operations.

[0071] In one embodiment, such as Figure 4 As shown, Figure 4 This is a schematic diagram of a software development apparatus provided in an embodiment of this application. The software development apparatus may include a loading module 21, a creation module 22, a setting module 23, a first debugging module 24, a second debugging module 25, and an integration module 26.

[0072] Loading module 21 is used to load virtual drivers in the software development environment. Virtual drivers are used to create driver file nodes for simulated hardware devices that correspond to real hardware devices.

[0073] Module 22 is created to create an access node associated with the driver file node of the simulated hardware device. The access node is used to provide the software with a device interface to access the simulated hardware device.

[0074] Setting module 23 is used to set the debugging state of the virtual system in the virtual driver in response to receiving a debugging instruction through the access node, wherein the debugging state includes a first debugging state and a second debugging state.

[0075] The first debugging module 24 is used to return the status information of the simulated hardware device generated based on the debugging memory data in response to the debugging state being the first debugging state.

[0076] The second debugging module 25 is used to return the status information of the simulated hardware device generated based on preset simulated hardware data in response to the debugging state being the second debugging state.

[0077] The integrated module 26 is used to complete the development of the software to be developed based on the status information of the simulated hardware device.

[0078] Each module in the aforementioned software development device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in an electronic device, or stored in the memory of the electronic device as software, so that the processor can call and execute the operations corresponding to each module.

[0079] Embodiments of this application also provide an electronic device, including a memory for storing computer programs.

[0080] A processor, when executing a computer program, can perform at least the following steps:

[0081] A virtual driver is loaded in the software development environment. The virtual driver is used to create a driver file node for a simulated hardware device that corresponds to a real hardware device. An access node is created associated with the driver file node of the simulated hardware device. The access node is used to provide the software with a device interface to access the simulated hardware device. In response to receiving a debugging command through the access node, the debugging state of the virtual system is set in the virtual driver. The debugging state includes a first debugging state and a second debugging state. In response to the first debugging state, the status information of the simulated hardware device generated based on the debugging memory data is returned. In response to the second debugging state, the status information of the simulated hardware device generated based on the preset simulated hardware data is returned.

[0082] In one embodiment, the electronic device may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, this electronic device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores software management data. The network interface is used for communication with external terminals via a network connection.

[0083] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0084] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, can perform at least the following steps:

[0085] A virtual driver is loaded in the software development environment. The virtual driver is used to create a driver file node for a simulated hardware device that corresponds to a real hardware device. An access node is created associated with the driver file node of the simulated hardware device. The access node is used to provide the software with a device interface to access the simulated hardware device. In response to receiving a debugging command through the access node, the debugging state of the virtual system is set in the virtual driver. The debugging state includes a first debugging state and a second debugging state. In response to the first debugging state, the status information of the simulated hardware device generated based on the debugging memory data is returned. In response to the second debugging state, the status information of the simulated hardware device generated based on the preset simulated hardware data is returned.

[0086] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0087] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, can perform at least the following steps:

[0088] A virtual driver is loaded in the software development environment. The virtual driver is used to create a driver file node for a simulated hardware device that corresponds to a real hardware device. An access node is created associated with the driver file node of the simulated hardware device. The access node is used to provide the software with a device interface to access the simulated hardware device. In response to receiving a debugging command through the access node, the debugging state of the virtual system is set in the virtual driver. The debugging state includes a first debugging state and a second debugging state. In response to the first debugging state, the status information of the simulated hardware device generated based on the debugging memory data is returned. In response to the second debugging state, the status information of the simulated hardware device generated based on the preset simulated hardware data is returned.

[0089] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0090] It will also be appreciated that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0091] The software development method, system, device, and computer-readable storage medium provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A software development method characterized by, The software development method includes: A virtual driver is loaded in the software development environment. The virtual driver is used to create driver file nodes for simulated hardware devices that correspond to real hardware devices. Create an access node associated with the driver file node of the simulated hardware device, the access node being used to provide a device interface for the software to be developed to access the simulated hardware device; In response to receiving a debugging instruction through the access node, the debugging state of the virtual system is set in the virtual driver, wherein the debugging state includes a first debugging state and a second debugging state; In response to the debug state being the first debug state, the status information of the simulated hardware device generated based on debug memory data is returned; In response to the debugging state being the second debugging state, the status information of the simulated hardware device generated based on preset simulated hardware data is returned; The development of the software to be developed is completed based on the status information of the simulated hardware device; The creation of the access node associated with the driver file node of the simulated hardware device includes: Identify the driver file node created by the virtual driver; The target file directory structure is created according to the preset file system specification to form an access node framework corresponding to the driver file node; The access nodes in the access node framework are linked to the corresponding driver file nodes using soft links to form a simulated hardware device access path; Set read and write permissions for the access node and verify the correctness of the read and write permissions so that the software can access the simulated hardware device through the simulated hardware device access path; The access node includes a debug interface node with write permissions, and the software development method further includes: In response to receiving the debugging instruction through the debugging interface node; Parse the debugging instructions to obtain the device identifier of the simulated hardware device and the desired simulated device status value, wherein the device identifier is used to indicate the target simulated hardware device to be debugged; Based on the device identifier, determine the debug memory data address corresponding to the target simulated hardware device; The device status value is written to the debug memory data address to update the debug memory data used to generate the status information.

2. The software development method of claim 1, wherein, The returned status information of the simulated hardware device, generated based on debug memory data, includes: In response to receiving a request to access the status information, the status acquisition function corresponding to the target simulated hardware device is invoked; The current debugging state is determined based on the state acquisition function; In response to the debugging state being the first debugging state, the debugging memory data corresponding to the target simulated hardware device is read; The read debug memory data and the preset simulated hardware data are used to perform logical operations to obtain the operation result; The calculation result is returned as the status information; The returned status information of the simulated hardware device, generated based on preset simulated hardware data, includes: In response to the debugging state being the second debugging state, the preset simulation hardware data of the target simulation hardware device is directly read, and the preset simulation hardware data is returned as the status information.

3. The software development method of claim 1, wherein, In response to the analog hardware device being a signal conversion device, the software development method further includes: In response to loading the virtual driver, the port data of the signal conversion device is initialized according to the configuration parameters; Set the simulated presence signal of the port, and control access permissions to the port data according to the status of the presence signal; Create the access node of the signal conversion device, wherein the access node includes a control signal node and a storage data access node; The signal conversion device is debugged based on the access node.

4. The software development method of claim 3, wherein, The method of controlling access permissions to the port data based on the status of the in-situ signal includes: In response to receiving the debug instruction to set a low-power mode via the control signal node, the virtual driver sets the access permissions in the port data to a masked state to block access to the storage data access node; In response to receiving the debug command to set the reset mode via the control signal node, the virtual driver updates the port data and sets the access permission to an unmasked state to perform access to the storage data node.

5. The software development method of claim 2, wherein, In response to the simulated hardware device being a sensor, loading the virtual driver in the software development environment includes: In response to loading the virtual driver, the range of numerical parameters of the sensor is received; Determine whether the received numerical parameter range has been met; In response to receiving the numerical parameter range, analog data of the sensor is generated within the numerical parameter range; In response to the failure to receive the numerical parameter range, analog data of the sensor is generated within a preset numerical parameter range, wherein the analog data is used as the preset analog hardware data.

6. The software development method of claim 2, wherein, In response to the fact that the simulated hardware device is a pluggable device, the debugging command is used to simulate the insertion or removal of the pluggable device, and returning the calculation result as the status information includes: Perform a bitwise AND operation between the read debug memory data and the preset simulated hardware data; The debug memory data is modified based on the bitwise AND operation result, and the modified debug memory data is returned to the software so as to characterize the in-situ state of the target simulation device through the debug memory data.

7. The software development method of claim 6, wherein, The software development method also includes: Parse the debugging instructions; In response to the debugging instruction instructing the target simulated hardware device to be unplugged, the access permissions in the port data corresponding to the target simulated hardware device are set to a blocked state, and access to the storage data node is blocked. In response to the debugging instruction indicating the insertion of the target simulated hardware device, it is determined whether the in-situ state of the target simulated hardware device in the port data has changed; In response to the change in the in-situ status, the simulated historical data in the port data is cleared, the access permission is set to an unblocked state, and the in-situ status of the target simulated hardware device in the port data is updated.

8. An electronic device, comprising: The electronic device includes: a memory for storing a computer program; a processor for implementing the steps of the software development method according to any one of claims 1 to 6 when executing the computer program.

Images