A method and apparatus for operating system driver porting

Abstract

The application discloses a kind of operating system driver's transplant method and device, the method includes: according to the I / O mapping mode of target hardware, determine the drive read-write operation function set created using input-output control function;Signal processing mechanism based on target operating system is created drive process number sending function and drive semaphore sending function;Based on drive read-write operation function set, create data unit read-write function function set;Based on drive process number sending function and drive semaphore sending function, create semaphore response connection function;Get the function function program file in the open source demo program of target hardware, replace data unit read-write statement in function function program file using data unit read-write function function set, add semaphore response connection function to function function program file, obtain the function function program file after transplantation.The method is simplified hardware interaction by encapsulating bottom read-write operation and simulating hardware interrupt, improves code reusability.

Description

Technical Field

[0001] This invention relates to a method and apparatus for porting operating system drivers. Background Technology

[0002] In modern computer systems, hardware drivers play a crucial role. Acting as a bridge between the operating system and hardware devices, they manage device resources, handle I / O requests, and provide a stable interface for upper-layer applications. With the increasing prevalence and complexity of embedded systems, hardware manufacturers typically provide demo versions of drivers and sample code for specific devices, enabling users to quickly begin developing applications tailored to their needs. These demo programs often contain two key components: register access I / O functions and general function calls.

[0003] Register access I / O functions are the core of low-level hardware operations. They directly determine how to interact with the hardware, such as reading or writing data to a specific address and configuring hardware parameters. These functions are highly dependent on the specific hardware design, so when ported to a new environment, they must be adjusted accordingly based on the new hardware architecture and operating system characteristics.

[0004] Functional operations focus more on implementing specific business logic or algorithms, such as controlling the state of LED lights or calculating sensor data. This part of the code is usually independent of specific hardware details and can be reused on different platforms, as long as the underlying I / O operations it depends on are correctly implemented. Summary of the Invention

[0005] To simplify the work of porting demo programs to the target operating system driver layer, this invention provides a method and apparatus for porting operating system drivers.

[0006] In a first aspect, embodiments of the present invention provide a method for porting an operating system driver, which may include:

[0007] In the driver layer of the target operating system, based on the I / O mapping method of the target hardware, a set of driver read / write operation functions created using input / output control functions is determined; the set of driver read / write operation functions includes functions for reading data units of the target hardware and functions for writing data to data units of the target hardware.

[0008] Obtain the driver process ID sending function and the driver semaphore sending function created based on the signal processing mechanism of the target operating system;

[0009] At the application layer of the target operating system, a data unit read / write function set is created based on the driver read / write operation function set;

[0010] Based on the driver process ID sending function and the driver semaphore sending function, a semaphore response connection function is created;

[0011] Obtain the function program file from the open-source demo program of the target hardware, replace the data unit read and write statements in the function program file with the data unit read and write function set, and add the semaphore response connection function to the function program file to obtain the ported function program file.

[0012] In one or more optional embodiments of this application, the step of creating a data unit read / write function set based on the driver read / write operation function set includes:

[0013] Call the functions in the driver read / write operation function set used to read the target hardware data unit to create a data unit reading function; the data unit reading function includes assignment statements for the value and address of the data unit;

[0014] Call the functions in the driver read / write operation function set used for writing data to the target hardware data unit to create a data unit write function; the data unit write function includes assignment statements for the data unit address and value.

[0015] In one or more optional embodiments of this application, obtaining the driver process ID sending function and the driver semaphore sending function created based on the signal processing mechanism of the target operating system includes:

[0016] Obtain the driver process ID sending function created using the input / output control function; the driver process ID sending function includes the process ID;

[0017] Based on the signal processing mechanism of the target operating system, an open-source semaphore sending function was determined.

[0018] The driver semaphore sending function is constructed based on the process ID and the open-source semaphore sending function.

[0019] In one or more optional embodiments of this application, after obtaining the function program files from the open-source demo program of the target hardware, the method further includes:

[0020] Add functions to open the driver and functions to close the driver to the function program file;

[0021] The functions for opening and closing the driver are called in the function program file.

[0022] In one or more optional embodiments of this application, after obtaining the function program files from the open-source demo program of the target hardware, the method further includes:

[0023] Based on the target operating system, modify the register base address in the function program file.

[0024] In one or more optional embodiments of this application, the target operating system includes Linux, maxOS, and FreeBSD;

[0025] At the driver layer of the target operating system, based on the I / O mapping method of the target hardware, the set of driver read / write operation functions created using input / output control functions is determined, including:

[0026] At the driver layer of the target operating system, the set of driver read and write operation functions created using the ioctl function is determined based on the I / O mapping method of the target hardware.

[0027] Secondly, embodiments of the present invention provide an operating system driver porting apparatus, which may include:

[0028] The driver read / write module is used to determine, at the driver layer of the target operating system, a set of driver read / write operation functions created using input / output control functions, based on the I / O mapping method of the target hardware; the set of driver read / write operation functions includes functions for reading data units of the target hardware and functions for writing data to data units of the target hardware.

[0029] The driver signal processing module is used to obtain the driver process ID sending function and the driver semaphore sending function created based on the signal processing mechanism of the target operating system.

[0030] The application read / write module is used to create a set of data unit read / write function functions based on the driver read / write operation function set at the application layer of the target operating system.

[0031] The application signal processing module is used to create a semaphore response connection function based on the driver process number sending function and the driver semaphore sending function;

[0032] The program porting module is used to obtain the function program files in the open-source demo program of the target hardware, replace the data unit read and write statements in the function program files with the data unit read and write function set, and add the semaphore response connection function to the function program files to obtain the ported function program files.

[0033] Thirdly, embodiments of the present invention provide a computer-readable storage medium having a computer program / instruction stored thereon, which, when executed by a processor, implements the operating system driver porting method described above.

[0034] Fourthly, embodiments of the present invention provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements the operating system driver porting method described above.

[0035] Fifthly, embodiments of the present invention provide a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the operating system driver porting method described above.

[0036] The beneficial effects of the above-described technical solutions provided in the embodiments of the present invention include at least the following:

[0037] This invention provides a method for porting operating system drivers. The method involves creating a set of driver read / write operation functions at the driver layer of the target operating system, based on the hardware's I / O mapping method. These functions include functions for reading and writing hardware data units. Then, it obtains the driver process ID sending function and driver semaphore sending function, created based on the target operating system's signal processing mechanism. Next, it creates a set of data unit read / write function sets and semaphore response connection functions at the application layer. Finally, it obtains the function program files from the target hardware's open-source demo program, replaces the data unit read / write statements with the data unit read / write function files, and adds the semaphore response connection functions to the function program, thus completing the porting process. This method encapsulates low-level register operations within the driver read / write operation function set and utilizes the signal processing mechanism in the target operating system to simulate hardware interrupt mechanisms. This achieves a high degree of transparency in hardware interaction logic, allowing developers to directly call the function functions in the target hardware's open-source demo program to meet application layer requirements. It fully utilizes the pre-debugged demo programs provided by hardware manufacturers, avoiding the need for redevelopment and deep technical assimilation, thereby significantly shortening the development cycle, reducing costs, and improving code reusability and maintainability.

[0038] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings.

[0039] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0040] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0041] Figure 1 A flowchart illustrating the method for porting an operating system driver provided in an embodiment of the present invention;

[0042] Figure 2 This is a schematic diagram of the structure of the operating system driver porting device provided in an embodiment of this application. Detailed Implementation

[0043] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0044] The inventors discovered that in the actual development of operating system drivers, if the demo program is simply ported directly into the driver program, the function functions, register access I / O functions and the underlying driver will be mixed together, making it impossible to call the function functions and register I / O access functions. At this time, it is necessary to digest the technology and then redevelop it in combination with the hardware itself, which will inevitably affect the development progress.

[0045] Furthermore, for complex hardware configurations such as CAN bus and flash memory access, even with vendor-provided demo programs as a reference, writing a driver from scratch for the target operating system remains a time-consuming and error-prone task. This is especially true in multitasking operating systems like Unix, where there is a distinction between user space and kernel space. Traditional interrupt handling mechanisms are no longer applicable, and developers need to consider cross-layer communication issues to ensure that hardware events are promptly delivered to the application.

[0046] Meanwhile, existing porting methods may result in tight coupling between functionalities and underlying hardware operations, requiring redevelopment or significant adjustments to this code every time the hardware platform is changed. Based on this, the inventors, through further research and development, created this invention, providing a method and apparatus for porting operating system drivers.

[0047] Example 1

[0048] Embodiment 1 of this invention provides a method for porting an operating system driver, referring to... Figure 1 As shown, the method may include the following steps S101-S105:

[0049] S101: At the driver layer of the target operating system, based on the I / O mapping method of the target hardware, determine the driver read / write operation function set created using input / output control functions. The driver read / write operation function set includes functions for reading data units from the target hardware and functions for writing data to the target hardware data units.

[0050] S102: Obtain the driver process ID sending function and driver semaphore sending function created based on the signal processing mechanism of the target operating system.

[0051] S103: At the application layer of the target operating system, create a set of data unit read and write function sets based on the driver read and write operation function set.

[0052] S104: Create a semaphore response connection function based on the driver process ID sending function and the driver semaphore sending function.

[0053] S105: Obtain the function program file from the open-source demo program of the target hardware, replace the data unit read and write statements in the function program file with the data unit read and write function set, add the semaphore response connection function to the function program file, and obtain the ported function program file.

[0054] This invention provides a method for porting operating system drivers. The method involves creating a set of driver read / write operation functions at the driver layer of the target operating system, based on the hardware's I / O mapping method. These functions include functions for reading and writing hardware data units. Then, it obtains the driver process ID sending function and driver semaphore sending function, created based on the target operating system's signal processing mechanism. Next, it creates a set of data unit read / write function sets and semaphore response connection functions at the application layer. Finally, it obtains the function program files from the target hardware's open-source demo program, replaces the register read / write statements with data unit read / write function sets, and adds the semaphore response connection functions to the function program, thus completing the porting process. This method encapsulates low-level register operations within the driver read / write operation function set and utilizes the signal processing mechanism in the target operating system to simulate hardware interrupt mechanisms. This achieves a high degree of transparency in hardware interaction logic, allowing developers to directly call the function functions in the target hardware's open-source demo program to meet application layer requirements. It fully utilizes the pre-debugged demo programs provided by hardware manufacturers, avoiding the need for redevelopment and deep technical assimilation, thereby significantly shortening the development cycle, reducing costs, and improving code reusability and maintainability.

[0055] In step S101 above, at the driver layer of the target operating system, a set of driver read / write operation functions created using input / output control functions is determined based on the I / O mapping method of the target hardware. The driver read / write operation function set includes functions for reading data from the target hardware data units and functions for writing data to the target hardware data units. The target operating system includes Unix-like systems, Windows, etc., and Unix-like systems include Linux, macOS, FreeBSD, etc.

[0056] Specifically, this can be achieved by first determining the appropriate input / output control function at the target operating system's driver layer, based on the target hardware's I / O mapping method. This input / output control function will be used to read from and write to the target hardware's data units. These functions will differ between different hardware and operating systems, thus requiring the selection of appropriate input / output control functions. For example, ioctl might be used in Linux, while DeviceIoControl might be used in Windows.

[0057] Then, based on the data units of the target hardware, a set of driver read / write operation functions is obtained. This function set includes functions for reading data from the target hardware and functions for writing data to the target hardware. Taking the target hardware as a CAN bus as an example, there will be specific commands such as CANBUS_IOCGETREG for calling functions to read register values, and CANBUS_IOCSETREG for calling functions to write data to registers.

[0058] To facilitate understanding of this solution by those skilled in the art, the following describes the execution steps of step S101 in detail, using Linux as the target operating system and CAN bus as the target hardware:

[0059] In the Linux kernel space, based on the I / O mapping method of the CAN bus, the set of driver read and write operation functions created using the ioctl function is determined. This set of functions includes two types of functions: functions for reading CAN bus data units and functions for writing data to CAN bus data units.

[0060] Taking registers as the data unit, the following is an example of a function used to read the value of a register in the CAN bus:

[0061]

[0062] In the example above, the function name is CANBUS_ioctl, which is created with reference to the input / output control function ioctl in Linux. The function prototype of ioctl is ioctl(struct inode*inode,struct file*fp,unsigned long cCmd,unsigned long arg), where cCmd represents the command. When cCmd is equal to "CANBUS_IOCGETREG", it means that the function for reading CAN bus data units is used, and the read / write command is passed by the application. arg is the parameter, which contains the address and data. In the example above, arg contains a register address parameter. The function can flexibly handle the passed address and data by dereferencing the arg pointer.

[0063] In the example above, "ioarg=*(unsigned short*)arg" means that the address of the register is obtained according to the I / O mapping method of the CAN bus chip and stored in the parameter ioarg.

[0064] "addr = ioarg & 0xff" means taking the lower 8 bits of ioarg as the address of the register.

[0065] "*(usCANAddr+0)=addr" means writing the register address to the location usCANAddr+0, where usCANAddr is a pointer to the CAN bus register.

[0066] “value=*(usCANAddr+1)” means reading the value of the register from the position usCANAddr+1.

[0067] "ioarg = value << 8" means shifting the value of the register to the left by 8 bits.

[0068] "*(unsigned short*)arg=ioarg" means storing the value of the register back into the parameter arg, thus completing the reading of the register value.

[0069] Here is an example of a function used to write data to a register in the CAN bus:

[0070]

[0071] In the example above, "ioarg=*(unsigned short*)arg" means that the address and value of the register are obtained according to the I / O mapping method of the CAN bus chip, with the lower 8 bits being the address and the higher 8 bits being the value, and stored in the parameter ioarg.

[0072] "addr = ioarg & 0xff" means taking the lower 8 bits of ioarg as the address of the register.

[0073] "*(usCANAddr+0)=addr" means writing the register address to the location usCANAddr+0, where usCANAddr is a pointer to the CAN bus register.

[0074] “value=ioarg>>8” means taking the high 8 bits as the value of the register.

[0075] "*(usCANAddr+1)=value" means writing data to the usCANAddr+1 location, i.e., the register, completing the data writing to the register.

[0076] In this embodiment, the driver read / write operation function set in step S101 above ensures that the driver program can correctly interact with the hardware by precisely controlling the read / write operations of the target hardware. By using driver functions that adapt to the hardware I / O mapping method, data units can be read and written efficiently, ensuring accurate data transmission.

[0077] In step S102 above, the driver process ID sending function and driver semaphore sending function created based on the signal processing mechanism of the target operating system are obtained. Specifically, this includes the following steps S1021-S1023:

[0078] S1021: Obtain the driver process ID sending function created using the input / output control function. The driver process ID sending function includes the process ID.

[0079] Specifically, the driver process ID sending function allows the application to inform the driver of its process ID via input / output control functions, thus letting the driver know which process to send a signal to. The application's process ID is passed to the driver layer by transmitting commands.

[0080] Taking Linux as the target operating system and ioctl as the input / output control function as an example, the driver process ID sending function is as follows:

[0081]

[0082] In the example above, the passed parameter arg represents the process ID of the application, and "app_pid = arg" means that the process ID is stored in the parameter app_pid. After that, the driver can use the parameter app_pid to determine the target process ID when sending a signal.

[0083] S1022: Based on the signal processing mechanism of the target operating system, determine the open-source semaphore sending function.

[0084] Specifically, this can be achieved by selecting an appropriate semaphore sending function based on the target operating system's signal processing mechanism. In Linux systems, the send_sig function is typically used to send signals to applications.

[0085] S1023: Construct a driver semaphore sending function based on process ID and open-source semaphore sending functions.

[0086] Specifically, this can be achieved by combining the process ID and the semaphore sending function to construct a driver semaphore sending function. When the hardware triggers an interrupt, the driver will trigger the driver semaphore sending function to find the process ID corresponding to the application and send the semaphore via send_sig.

[0087] Taking Linux as the target operating system and send_sig as the semaphore sending function as an example, the driver semaphore sending function example is as follows:

[0088] static irqreturn_t CANBUS_interrupt(int irq,void*dev_id)

[0089] {

[0090] ptask=find_task_by_vpid(app_pid);

[0091] if (ptask != NULL)

[0092] {

[0093] send_sig(CANBUS_SIGNAL,ptask,1);

[0094] }

[0095] return IRQ_RETVAL(IRQ_HANDLED);

[0096] }

[0097] In the example above, CANBUS_interrupt is the name of the function that drives semaphore transmission, and "ptask = find_task_by_vpid(app_pid)" means finding the corresponding task number ptask based on the process ID app_pid. The function find_task_by_vpid() is a function in the Linux kernel.

[0098] "send_sig(CANBUS_SIGNAL,ptask,1)" means sending the semaphore CANBUS_SIGNAL to the application with task number ptask.

[0099] "return IRQ_RETVAL(IRQ_HANDLED)" is a specific value returned in the Linux kernel to inform the Linux kernel that the driver semaphore sending function has been successfully executed.

[0100] In this embodiment, step S102, by obtaining the process ID of the application and combining it with the signal processing mechanism of the target operating system, enables the driver to send signals to the correct process in a timely and accurate manner, triggering an interrupt response and ensuring efficient cooperation between hardware and software and system stability. This allows hardware events to smoothly influence the behavior of the application, simulating the interrupt function of the hardware device.

[0101] In step S103 above, at the application layer of the target operating system, a data unit read / write function set is created based on the driver read / write operation function set. Specifically, this includes the following steps S1031-S1032:

[0102] S1031: Calls the function in the driver read / write operation function set used to read the target hardware data unit, creating a data unit read function. The data unit read function includes assignment statements for the data unit's value and address.

[0103] Specifically, at the application layer, the address of the target hardware data unit is assigned, and then the function in the driver used to read the target hardware data unit is called to obtain the value of the target hardware data unit, thereby realizing the acquisition of the target hardware data unit.

[0104] Then, the above operations for obtaining target hardware data units are encapsulated at the application layer to obtain the data unit reading function.

[0105] Taking the functions used to read target hardware data units from the driver read / write operation function set obtained in step S101 above as an example, the data unit reading function obtained through step S1031 above is as follows:

[0106] unsigned char ReadSJAReg(unsigned char RegAdr)

[0107] {

[0108] unsigned short arg;

[0109] arg = RegAdr;

[0110] if(ioctl(SJA1000_fd,CANBUS_IOCGETREG,&arg)!=0)

[0111] {

[0112] return -1;

[0113] }

[0114] else

[0115] {

[0116] return arg&0xff;

[0117] }

[0118] }

[0119] In the example above, ReadSJAReg is the name of the data unit reading function, "arg = RegAdr" is the address assignment statement, and RegAdr is the input parameter representing the address of the target hardware data unit.

[0120] The function `ioctl(SJA1000_fd,CANBUS_IOCGETREG,&arg)` calls the function from the driver read / write operation function set obtained in step S101 above, which is used to read the target hardware data unit. It finds the corresponding value based on the address of the target hardware data unit, assigns the value of the data unit to the parameter `arg`, and returns it. Here, the parameter `SJA1000_fd` is a file descriptor used to represent an open device file, such as the device file descriptor of the SJA1000 CAN bus controller.

[0121] "return arg&0xff" means that after "ioctl(SJA1000_fd,CANBUS_IOCGETREG,&arg)" is executed successfully, the lower 8 bits of the parameter arg, which is the value of the target hardware data unit, are returned.

[0122] S1032: Call the function in the driver read / write operation function set used to write data to the target hardware data unit, and create a data unit write function; the data unit write function includes assignment statements for the data unit address and value.

[0123] Specifically, at the application layer, the address of the target hardware data unit is assigned, and then the function in the driver used to write data to the target hardware data unit is called, thereby writing the data to the target hardware data unit.

[0124] Then, the above operation of writing data to the target hardware data unit is encapsulated at the application layer to obtain the data unit writing function.

[0125] Taking the driver read / write operation function set obtained in step S101 above, which is used to write data to the target hardware data unit, as an example, the data unit write function obtained through step S1032 above is as follows:

[0126] char WriteSJAReg(unsigned char RegAdr, unsigned char Value)

[0127] {

[0128] unsigned short arg;

[0129] arg = Value << 8 | RegAdr;

[0130] if(ioctl(SJA1000_fd,CANBUS_IOCSETREG,&arg)!=0)

[0131] {

[0132] return -1;

[0133] }

[0134] else

[0135] {

[0136] return 0;

[0137] }

[0138] }

[0139] In the example above, WriteSJAReg is the name of the function that writes data units, and "arg = Value << 8 | RegAdr" is an assignment statement for the address and value of the data unit. This statement combines the address and value of the data unit into a 16-bit value, with the high 8 bits representing the value and the low 8 bits representing the address, and then assigns this value to the parameter arg. Value and RegAdr are the input parameters, representing the value and address of the target hardware data unit, respectively.

[0140] "ioctl(SJA1000_fd,CANBUS_IOCGETREG,&arg)" calls the function in the driver read / write operation function set obtained in step S101 above, which is used to read the target hardware data unit. It finds the corresponding value according to the address of the target hardware data unit, assigns the value of the data unit to the parameter arg, and returns it.

[0141] When "ioctl(SJA1000_fd,CANBUS_IOCGETREG,&arg)" is executed successfully, the data unit write function will return 0, indicating that the data has been successfully written to the target hardware data unit.

[0142] In this embodiment, step S103 simplifies hardware access operations and improves code maintainability and reusability by encapsulating driver read / write operation functions at the application layer and creating data unit read / write function functions. This allows the application layer to read and write target hardware data units simply by calling these encapsulated functions, without needing to concern itself with the specific implementation details of the underlying driver. This encapsulation makes hardware control operations more abstract and flexible, helping to reduce code modifications during subsequent function changes and improving the overall stability and scalability of the system.

[0143] In step S104 above, a semaphore response connection function is created based on the driver process number sending function and the driver semaphore sending function.

[0144] Specifically, at the application layer, the driver's process ID is sent to the application's process ID via a semaphore sending function, ensuring the driver can correctly send semaphores to the corresponding process. Then, the semaphore sent by the driver's semaphore sending function to the application is bound to the corresponding signal handler function, enabling the appropriate processing logic to be triggered upon receiving a signal. This step is similar to binding a driver to an interrupt function, allowing the semaphore response function to be automatically called when a signal arrives, thereby achieving response processing for hardware events.

[0145] Taking the driver process ID sending function and driver semaphore sending function obtained in step S102 above as examples, the semaphore response connection function created through step S104 above is an example as follows:

[0146] ioctl(SJA1000_fd,COMMAND_CHANGE_PID,getpid());

[0147] sig_act.sa_handler=SJA1000_signal;

[0148] sig_act.sa_flags = 0;

[0149] sigemptyset(&sig_act.sa_mask);

[0150] ret=sigaction(CANBUS_SIGNAL,&sig_act,NULL);

[0151] In the example above, "ioctl(SJA1000_fd,COMMAND_CHANGE_PID,getpid())" is the driver process ID sending function, and CANBUS_SIGNAL is the semaphore sent to the application by the driver semaphore sending function.

[0152] The setting "sig_act.sa_handler = SJA1000_signal" indicates that the signal handling function is set to the SJA1000_signal function. When the CANBUS_SIGNAL signal is received, the SJA1000_signal function will be called.

[0153] "sig_act.sa_flags=0" means setting the flags of the signal handler function to 0, indicating that no special flags are used, such as not automatically restarting the system call.

[0154] The `sigemptyset(&sig_act.sa_mask)` statement clears the signal mask, ensuring that no other signals are blocked during the execution of the signal handler. This helps avoid deadlocks or other problems during signal handling.

[0155] The statement `ret = sigaction(CANBUS_SIGNAL, &sig_act, NULL)` binds the semaphore `CANBUS_SIGNAL`, which is sent to the application by the semaphore sending function, to the corresponding signal handler function `sig_act`. The `sigaction` function is a system call used for signal handling in Linux.

[0156] In this embodiment, step S104, by creating a semaphore response connection function, ensures that the application can correctly respond to signals sent by the driver, thus binding the semaphore and the signal handling function. This enables automatic processing of driver signals, simulating the interrupt handling mechanism in the driver. This allows the method to implement interrupt handling without modifying the interrupt handling-related demo program. It can promptly trigger the processing logic in the application when hardware events occur, improving the system's response speed and reliability, and avoiding the need for manual intervention.

[0157] In step S105 above, the function program file in the open-source demo program of the target hardware is obtained, the data unit read / write statements in the function program file are replaced with the data unit read / write function set, and the semaphore response connection function is added to the function program file to obtain the ported function program file. Specifically, this includes the following steps S1051-S1054:

[0158] S1051: Obtain the function files from the open-source demo program of the target hardware.

[0159] Specifically, this could involve downloading or extracting function files from open-source demo programs that have already been tested and approved by the hardware manufacturer. These files typically contain direct operational logic for the hardware, such as raw programs for microcontrollers or DSPs, rather than operating systems. These files may be based on bare-metal development or applications developed in an embedded development environment.

[0160] S1052: Add and call a function to open the driver and a function to close the driver in the function program file.

[0161] Specifically, this can involve adding and calling control functions for the driver in the function program file to control the driver's lifecycle. This is the basic process of driver development, which includes a function to open the driver and a function to close the driver.

[0162] The `open()` function, which opens a driver, performs device initialization, resource allocation, and returns a file descriptor. Opening a driver is the first step in the interaction between the user program and the driver.

[0163] The close() function for closing a driver releases resources and performs cleanup work, ensuring that the hardware device can be safely shut down when it is no longer in use.

[0164] When porting a program, these two operations need to be encapsulated and called in the function program file to ensure normal communication with the target hardware. This is a basic operation for driver-application interaction, ensuring that the device driver can be correctly opened, used, and closed when using the driver.

[0165] S1053: Based on the target operating system, modify the register base address in the function program file.

[0166] Specifically, this could involve consulting hardware documentation, identifying the register addresses of the target hardware, and modifying the original register base addresses in the function program file to ensure they are consistent with the hardware configuration under the current operating system environment.

[0167] S1054: Replace the data unit read / write statements in the function program file with the data unit read / write function set, add the semaphore response connection function to the function program file, and obtain the ported function program file.

[0168] Specifically, this can be achieved by replacing the original hardware read / write operations in the function program file with the register read / write function set obtained in step 103 above.

[0169] At the same time, the semaphore response connection function obtained in step S104 is added to the function program file to ensure that the application can respond to the signal normally when a hardware event is triggered.

[0170] This method significantly improves the porting efficiency from single-threaded drivers to target operating system drivers by creating a dedicated set of driver read / write operation functions at the target operating system's driver layer based on the hardware's I / O mapping, and by constructing process ID sending and semaphore sending functions based on the operating system's signal processing mechanism. Simultaneously, at the application layer, data unit read / write function functions are created using the aforementioned set of read / write operation functions. These functions are then combined with the function functions in the open-source demo program, replacing the original register read / write statements and adding semaphore response connection functions. This reduces code coupling and enhances cross-platform reusability. This not only ensures the stability and compatibility of the ported function functions in the target operating system environment and simplifies the porting process for complex hardware configurations, greatly improving development efficiency and reducing porting difficulty, but also provides a standardized development process for team collaboration, ensuring rapid project progress and ease of long-term maintenance.

[0171] Example 2

[0172] Based on the same inventive concept, embodiments of the present invention also provide an operating system driver porting device, referring to... Figure 2 As shown, the device includes:

[0173] The driver read / write module 101 is used to determine, at the driver layer of the target operating system, a set of driver read / write operation functions created using input / output control functions, based on the I / O mapping method of the target hardware; the set of driver read / write operation functions includes functions for reading data units of the target hardware and functions for writing data to data units of the target hardware.

[0174] The driver signal processing module 102 is used to obtain the driver process ID sending function and the driver semaphore sending function created based on the signal processing mechanism of the target operating system;

[0175] The application read / write module 103 is used to create a data unit read / write function set based on the driver read / write operation function set at the application layer of the target operating system.

[0176] The application signal processing module 104 is used to create a semaphore response connection function based on the driver process number sending function and the driver semaphore sending function;

[0177] The program porting module 105 is used to obtain the function program file in the open-source demo program of the target hardware, replace the data unit read and write statements in the function program file with the data unit read and write function set, and add the semaphore response connection function to the function program file to obtain the ported function program file.

[0178] Example 3

[0179] Based on the same inventive concept, embodiments of the present invention also provide a computer-readable storage medium storing a computer program / instruction thereon, which, when executed by a processor, implements the operating system driver porting method described in Embodiment 1 above.

[0180] Example 4

[0181] Based on the same inventive concept, embodiments of the present invention also provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements the operating system driver porting method described in Embodiment 1 above.

[0182] Example 5

[0183] Based on the same inventive concept, embodiments of the present invention also provide a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the operating system driver porting method described in Embodiment 1 above.

[0184] 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 and optical storage) containing computer-usable program code.

[0185] 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 processor, 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 and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1A device that provides the functions specified in one or more boxes.

[0186] 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.

[0187] 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.

[0188] 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 porting an operating system driver, characterized in that, include: In the driver layer of the target operating system, the set of driver read and write operation functions created using input / output control functions is determined based on the I / O mapping method of the target hardware; The driver read / write operation function set includes functions for reading target hardware data units and functions for writing data to target hardware data units; Obtain the driver process ID sending function and the driver semaphore sending function created based on the signal processing mechanism of the target operating system; At the application layer of the target operating system, a data unit read / write function set is created based on the driver read / write operation function set; Based on the driver process ID sending function and the driver semaphore sending function, a semaphore response connection function is created; Obtain the function program file from the open-source demo program of the target hardware, replace the data unit read and write statements in the function program file with the data unit read and write function set, and add the semaphore response connection function to the function program file to obtain the ported function program file.

2. The method according to claim 1, characterized in that, The creation of a data unit read / write function set based on the driver read / write operation function set includes: Call the functions in the driver read / write operation function set used to read the target hardware data unit to create a data unit reading function; the data unit reading function includes assignment statements for the value and address of the data unit; Call the functions in the driver read / write operation function set used for writing data to the target hardware data unit to create a data unit write function; the data unit write function includes assignment statements for the data unit address and value.

3. The method according to claim 1, characterized in that, The step of obtaining the driver process ID sending function and the driver semaphore sending function created based on the signal processing mechanism of the target operating system includes: Obtain the driver process ID sending function created using the input / output control function; the driver process ID sending function includes the process ID; Based on the signal processing mechanism of the target operating system, an open-source semaphore sending function was determined. The driver semaphore sending function is constructed based on the process ID and the open-source semaphore sending function.

4. The method according to claim 1, characterized in that, After obtaining the function program files from the open-source demo program of the target hardware, the following is also included: Add functions to open the driver and functions to close the driver to the function program file; The functions for opening and closing the driver are called in the function program file.

5. The method according to claim 1, characterized in that, After obtaining the function program files from the open-source demo program of the target hardware, the following is also included: Based on the target operating system, modify the register base address in the function program file.

6. The method according to claim 1, characterized in that, The target operating systems include Linux, MAXOS, and FreeBSD; At the driver layer of the target operating system, based on the I / O mapping method of the target hardware, the set of driver read / write operation functions created using input / output control functions is determined, including: At the driver layer of the target operating system, the set of driver read and write operation functions created using the ioctl function is determined based on the I / O mapping method of the target hardware.

7. A porting device for an operating system driver, characterized in that, include: The driver read / write module is used to determine, at the driver layer of the target operating system, a set of driver read / write operation functions created using input / output control functions, based on the I / O mapping method of the target hardware; the set of driver read / write operation functions includes functions for reading data units of the target hardware and functions for writing data to data units of the target hardware. The driver signal processing module is used to obtain the driver process ID sending function and the driver semaphore sending function created based on the signal processing mechanism of the target operating system. The application read / write module is used to create a set of data unit read / write function functions based on the driver read / write operation function set at the application layer of the target operating system. The application signal processing module is used to create a semaphore response connection function based on the driver process number sending function and the driver semaphore sending function; The program porting module is used to obtain the function program files in the open-source demo program of the target hardware, replace the data unit read and write statements in the function program files with the data unit read and write function set, and add the semaphore response connection function to the function program files to obtain the ported function program files.

8. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instruction is executed by the processor, it implements the porting method of the operating system driver as described in any one of claims 1-6.

9. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the porting method of the operating system driver as described in any one of claims 1-6.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the operating system driver porting method according to any one of claims 1-6.

Images