JP5489437B2 - Device driver creation method, creation apparatus, and program - Google Patents

Description

The present invention relates to a device driver creation method, creation apparatus, and program that can be commonly used in a plurality of systems.

  Conventionally, a device driver is constructed in consideration of hardware characteristics of a system to be mounted. For this reason, it is difficult to switch a device driver created for a piece of hardware on another piece of hardware. On the other hand, for example, in the technology described in Patent Document 1, the device driver requests data reading / writing from a DDI (Device Driver Interface), and the DDI performs endian conversion in consideration of the endian of the bus and the device. Yes. Further, an OS (Operation System) such as UNIX (registered trademark) uses an endian conversion function ntohl (). With these methods, the device driver does not need to consider the endian of the installed system.

JP-A-9-212444

  However, in the technique described in Patent Document 1, since hardware is accessed via DDI, endian determination processing by DDI becomes a redundant load. In a system using a PCI bus or the like, the endian of the PCI bus or the like may be different from the endian of the CPU or OS. Further, ntohl () and the like used in UNIX and the like become complicated when the endian characteristics of the system to be handled become complicated, and it becomes difficult to divert the device driver between systems having different endian characteristics. In addition, a plurality of endian conversion processes may be performed, resulting in a redundant load.

  In view of the above-described problems, the present invention provides a device driver that can be used in common among systems having different endian characteristics and can be optimized by eliminating redundant loads. It is aimed.

The device driver creation method of the present invention is a device driver creation method that switches processing according to the endian of the hardware. In order to use the endian conversion function, a system-dependent endian relating to the endian characteristic of the bus is used as the device driver source. A call step for calling a system-dependent endian conversion function by including a header; a replacement step for replacing the called system-dependent endian conversion function with a basic type endian conversion function based on the endian characteristics of the bus; A selection step for selecting a conversion process corresponding to the replaced basic type endian conversion function based on the endian characteristics of the device, and converting the endian of the device using the selected conversion process And having a conversion step.

  According to the present invention, it is possible to divert a device driver between systems having different endian characteristics. Further, even in a system having complicated endian characteristics, redundant endian conversion processing can be omitted and processing can be optimized.

(First embodiment)
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
FIG. 1 is a diagram showing a typical hierarchical structure of the device driver of this embodiment.
In FIG. 1, the device driver layer 1 includes a device driver header 4 and a device driver source 5. The system-dependent layer 2 includes a system-dependent endian conversion header 7 and a system-dependent endian conversion source 8. Further, the MPU (OS) layer 3 includes a basic type endian conversion header 10 and a basic type endian conversion source 11.

  A system-dependent endian conversion function 6 is used as an interface between the device driver layer 1 and the system-dependent layer 2. Further, a basic type endian conversion function 9 is used as an interface between the system dependent layer 2 and the MPU (OS) layer 3.

  The device driver layer 1 indicates a device driver module that uses an endian conversion function, and uses a system-dependent endian conversion function 6 having a unique module name as a prefix. Here, the internal processing of the system-dependent endian conversion function 6 is not implemented, and the system-dependent endian conversion header 7 is included.

  The system-dependent layer 2 indicates a hierarchy for applying the contents of the system-dependent endian conversion function 6 used by the device driver layer 1 to the construction system. In the system to be built, the system builder uses the basic type endian conversion function 9 provided by the MPU (OS) layer 3 to convert the system dependent endian conversion function 6 into a system dependent endian conversion header 7 and a system dependent endian conversion source 8. To construct. Further, when constructing the system dependence layer 2, the basic type endian conversion header 10 is included.

  The MPU (OS) layer 3 provides a basic type endian conversion function 9 for converting from endian to big endian and little endian adopted by the MPU (OS) of the construction system. The basic type endian conversion function 9 is constructed in a basic type endian conversion header 10 and a basic type endian conversion source 11.

  FIG. 2 is a diagram showing a list of basic type endian conversion functions. In the following description, the interface will be described in terms of expressions corresponding to a plurality of types of bits, but a basic endian conversion function corresponding to each bit width such as 16 bits, 32 bits, 64 bits, etc. is prepared.

  The hostToBe () 21 is a function having a function of converting the value given by the argument from the MPU (OS) representation to the big endian. The hostToLe () 22 is a function having a function of converting the value given by the argument from the MPU (OS) representation into little endian. beToHost () 23 is a function having a function of converting a value given by an argument from a big endian into an MPU (OS) representation. leToHost () 24 is a function having a function of converting a value given by an argument from a little endian into an MPU (OS) expression.

  In this embodiment, a description in C language is used. However, depending on the development system, other development languages such as an assembler and C ++ can be used for the purpose of execution efficiency and development efficiency. The device driver header 4, the system-dependent endian conversion source 8, the basic type endian conversion source 11, and the like can be omitted depending on the development system.

  Next, an example of the hierarchical structure of the device driver of this embodiment is shown in FIG. The system shown in FIG. 3 has the characteristics that the development device is little endian, the system-dependent portion such as a bus is big endian, and the MPU (OS) is big endian.

  In FIG. 3, the device driver layer 31, the system dependent layer 32, and the MPU (OS) layer 33 have a three-layer structure. A device driver source 34, a system-dependent endian conversion function 35, a system-dependent endian conversion header 36, a basic type endian conversion function 37, and a basic type endian conversion header 38 are included.

FIG. 4 is a diagram showing an excerpt content 41 of the device driver source 34.
In FIG. 4, “sys_endian.h” indicates the system-dependent endian conversion header 36. Further, “usb_leToHost32 ()” is called as the system-dependent endian conversion function 35.

FIG. 5 is a diagram showing the contents 51 of the system-dependent endian conversion header 36.
In FIG. 5, “convert_endian.h” represents a basic type endian conversion header 38. Further, “usb_leToHost32 ()” is constructed using “leToHost32 ()” which is the basic type endian conversion function 37.

FIG. 6 shows the contents 61 of the basic endian conversion header 38.
In FIG. 6, the entity of the basic type endian conversion function 37 is defined. Here, “CPU_BIG_ENDIAN” is a macro defined in the development environment. When the MPU is big endian, a macro of “CPU_BIG_ENDIAN” is defined. In this embodiment, since the MPU is big endian, a macro of “CPU_BIG_ENDIAN” is defined. As a result, byte swap processing occurs from “usb_leToHost32 ()”.

  Next, the flow of function replacement after “usb_leToHost32 ()” of the present embodiment is called will be described with reference to the flowchart of FIG. First, “usb_leToHost32” is replaced with the system-dependent endian conversion header 36 (step S1A). As a result, “leToHost32” is set (step S2A). Next, “leToHost32 ()” is mutually converted by the basic type endian conversion header 38 (step S3A). As a result, “byteSwap32” is set (step S4A). As a result, byte swap processing is performed.

  As described above, according to the present embodiment, the device driver has a three-layer configuration of the device driver layer, the system dependence layer, and the MPU (OS) layer, and the device driver can be used between systems having different endian characteristics. Further, even in a system having complicated endian characteristics, redundant endian conversion processing can be omitted and processing can be optimized.

(Second Embodiment)
Next, as a second embodiment, an example in which the development target device is the same as that in the first embodiment but the development system is different will be described. In this system, a development device has a little endian characteristic, a system dependent part such as a bus has a big endian characteristic, and an MPU (OS) has a little endian characteristic.

FIG. 8 is a diagram showing an example of the hierarchical structure of the device driver of this embodiment.
In FIG. 8, the device driver layer 81, the system dependent layer 82, and the MPU (OS) layer 83 have a three-layer structure. A device driver source 84, a system-dependent endian conversion function 85, a system-dependent endian conversion header 86, a basic type endian conversion function 87, and a basic type endian conversion header 88 are included.

  Here, the device driver source 34 of the first embodiment can be used as it is for the device driver source 84 of the present embodiment. Therefore, the contents extracted from the device driver source 84 will be described with reference to FIG.

  In FIG. 4, “sys_endian.h” indicates a system-dependent endian conversion header 86. Further, “usb_leToHost32” is called as the system-dependent endian conversion function 85.

  Further, the system-dependent endian conversion header 86 of the first embodiment can be used as it is for the system-dependent endian conversion header 86 of the present embodiment. Therefore, the contents of the system-dependent endian conversion header 86 will be described with reference to FIG.

  In FIG. 5, “convert_endian.h” represents a basic type endian conversion header 88. Further, “usb_leToHost32 ()” is constructed using “leToHost32 ()” which is the basic type endian conversion function 87.

  Further, the basic type endian conversion header 38 of the first embodiment can be used as it is for the basic type endian conversion header 88 of the present embodiment. Therefore, the contents of the basic type endian conversion header 88 will be described with reference to FIG.

  In FIG. 6, the entity of the basic type endian conversion function 87 is defined. Here, “CPU_BIG_ENDIAN” is a macro defined in the development environment, and when the MPU is big endian, a macro of “CPU_BIG_ENDIAN” is defined. In this embodiment, since the MPU is little endian, the “CPU_BIG_ENDIAN” macro is not defined. As a result, byte swap processing does not occur from “usb_leToHost32 ()”.

Next, the function replacement flow of this embodiment will be described with reference to the flowchart of FIG.
First, “usb_leToHost32 ()” is replaced with the system-dependent endian conversion header 86 (step S1B). As a result, “leToHost32 ()” is set (step S2B). Next, “leToHost32 ()” is replaced with the basic endian conversion header 88 (step S3B). As a result, no processing is performed (step S4B). As a result, byte swap processing is not performed.

  As described above, according to the present embodiment, the device driver has a three-layer configuration of the device driver layer, the system dependence layer, and the MPU (OS) layer, and the device driver can be used between systems having different endian characteristics. Further, even in a system having complicated endian characteristics, redundant endian conversion processing can be omitted and processing can be optimized.

(Third embodiment)
Next, as a third embodiment, another example in which the development target device is the same as that in the first and second embodiments but the development system is different will be described. In this system, the development device has little endian, the system-dependent portion such as a bus has special endian, and the MPU (OS) has big endian characteristics.

FIG. 10 is a diagram showing an example of the hierarchical structure of the device driver of this embodiment.
In FIG. 10, the device driver layer 101, the system dependent layer 102, and the MPU (OS) layer 103 have a three-layer structure. A device driver source 104, a system-dependent endian conversion function 105, a system-dependent endian conversion header 106, and a system-dependent endian conversion source 107 are included. Furthermore, a basic type endian conversion function 108 and a basic type endian conversion header 109 are provided. Here, the special endian means a thing that requires special endian conversion that cannot be converted only by the basic endian conversion function 108.

  FIG. 11 is a diagram showing a special endian byte array 111 before conversion and a byte array 112 after conversion. Here, the device driver source 34 of the first embodiment can be used as it is for the device driver source 104 of the present embodiment. Therefore, the contents extracted from the device driver source 104 will be described with reference to FIG.

  In FIG. 4, “sys_endian.h” indicates the system-dependent endian conversion header 106. In addition, “usb_leToHost32 ()” is called as the system-dependent endian conversion function 105.

FIG. 12 is a diagram showing the contents 121 of the system-dependent endian conversion header 106.
In FIG. 12, “convert_endian.h” is a basic type endian conversion header 109. Also, “usb_leToHost32 ()” is constructed using special endian conversion “specialLeToHost32 ()”. “SpecialLeToHost32 ()” is implemented by the system-dependent endian conversion source 107.

FIG. 13 is a diagram showing an implementation example 131 implemented by the system-dependent endian conversion source 107.
In FIG. 13, after special endian conversion is performed as “xxxSwap ()”, “leToHost32 ()” which is the basic endian conversion function 108 is called to ensure consistency.

  Further, the basic endian conversion header 38 of the first embodiment can be used as it is for the basic endian conversion header 109 of the present embodiment. Therefore, the contents of the basic type endian conversion header 109 will be described with reference to FIG.

  In FIG. 6, the entity of the basic type endian conversion function 108 is defined. Here, “CPU_BIG_ENDIAN” is a macro defined in the development environment. When the MPU is big endian, a macro of “CPU_BIG_ENDIAN” is defined. In this embodiment, since the MPU is big endian, a macro of “CPU_BIG_ENDIAN” is defined. As a result, byte swap processing occurs from “usb_leToHost32 ()”.

Next, the function replacement flow of this embodiment will be described with reference to the flowchart of FIG.
In FIG. 14, “usb_leToHost32 ()” is replaced with the system-dependent endian conversion header 106 (step S1C). As a result, “specialLeToHost32 ()” is set (step S2C). Next, “xxxSwap ()” in “specialLeToHost32 ()” is executed to perform special endian conversion (step S3C).

  Subsequently, “leToHost32 ()” is replaced with the basic endian conversion header 109 (step S4C). As a result, “byteSwap32 ()” is set (step S5C). As a result, byte swap processing is performed.

  As described above, according to the present embodiment, the device driver has a three-layer configuration of the device driver layer, the system dependence layer, and the MPU (OS) layer, and the device driver can be used between systems having different endian characteristics. Further, even in a system having complicated endian characteristics, redundant endian conversion processing can be omitted and processing can be optimized.

(Other embodiments according to the present invention)
Each step of the device driver creation method in the above-described embodiment of the present invention can be realized by operating a program stored in a RAM or ROM of a computer. This program and a computer-readable recording medium recording the program are included in the present invention.

  Further, the present invention can be implemented as, for example, a system, apparatus, method, program, or recording medium. Specifically, the present invention may be applied to a system including a plurality of devices. The present invention may be applied to an apparatus composed of a single device.

  In the present invention, a software program (in the embodiment, a program corresponding to the flowcharts shown in FIGS. 7, 9, and 14) for realizing the functions of the above-described embodiments is supplied directly or remotely to a system or apparatus. Including. This includes the case where the system or the computer of the apparatus is also achieved by reading and executing the supplied program code.

  Accordingly, since the functions of the present invention are implemented by computer, the program code installed in the computer also implements the present invention. In other words, the present invention includes a computer program itself for realizing the functional processing of the present invention.

  In that case, as long as it has the function of a program, it may be in the form of object code, a program executed by an interpreter, script data supplied to the OS, and the like.

  Examples of the recording medium for supplying the program include a flexible disk, a hard disk, an optical disk, and a magneto-optical disk. Further, there are MO, CD-ROM, CD-R, CD-RW, magnetic tape, nonvolatile memory card, ROM, DVD (DVD-ROM, DVD-R) and the like.

  As another program supply method, there is a method of connecting to a homepage on the Internet using a browser of a client computer. The computer program itself of the present invention or a compressed file including an automatic installation function can be downloaded from the homepage by downloading it to a recording medium such as a hard disk.

  It can also be realized by dividing the program code constituting the program of the present invention into a plurality of files and downloading each file from a different homepage. That is, a WWW server that allows a plurality of users to download a program file for realizing the functional processing of the present invention on a computer is also included in the present invention.

  As another method, the program of the present invention is encrypted, stored in a recording medium such as a CD-ROM, distributed to users, and encrypted from a homepage via the Internet to users who have cleared predetermined conditions. Download the key information to be solved. It is also possible to execute the encrypted program by using the key information and install the program on a computer.

  Further, the functions of the above-described embodiments are realized by the computer executing the read program. Furthermore, based on the instructions of the program, an OS or the like running on the computer performs part or all of the actual processing, and the functions of the above-described embodiments can be realized by the processing.

  As another method, the program read from the recording medium is first written in a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer. Then, based on the instructions of the program, the CPU or the like provided in the function expansion board or function expansion unit performs part or all of the actual processing, and the functions of the above-described embodiments are also realized by the processing.

It is a figure which shows the typical hierarchical structure of the device driver of the 1st Embodiment of this invention. It is a figure which shows the list of a basic form endian conversion function. It is a figure which shows an example of the hierarchical structure of the device driver of the 1st Embodiment of this invention. It is a figure which shows the content of the source code (extract) of the device driver layer of the 1st Embodiment of this invention. It is a figure which shows the content of the system dependence endian conversion header of the 1st Embodiment of this invention. It is a figure which shows the content of the basic form endian conversion header of the 1st Embodiment of this invention. It is a flowchart which shows an example of the process sequence of the function substitution of the 1st Embodiment of this invention. It is a figure which shows an example of the hierarchical structure of the device driver of the 2nd Embodiment of this invention. It is a flowchart which shows an example of the process procedure of the function substitution of the 2nd Embodiment of this invention. It is a figure which shows an example of the hierarchical structure of the device driver of the 3rd Embodiment of this invention. It is a figure for demonstrating the special endian of the 3rd Embodiment of this invention. It is a figure which shows the content of the system dependence endian conversion header of the 3rd Embodiment of this invention. It is a figure which shows the content of the system dependence endian conversion source (extract) of the 3rd Embodiment of this invention. It is a flowchart which shows an example of the process sequence of the function substitution of the 3rd Embodiment of this invention.

Explanation of symbols

1 Device Driver Layer 2 System Dependent Layer 3 MPU (OS) Layer 4 Device Driver Header 5 Device Driver Source 6 System Dependent Endian Conversion Function 7 System Dependent Endian Conversion Header 8 System Dependent Endian Conversion Source 9 Basic Endian Conversion Function 10 Basic Endian Conversion Header 11 Basic endian conversion source

Claims (5)

A method of creating a device driver that switches processing according to the endian of the hardware,
Invoking the system-dependent endian conversion function by including a system-dependent endian header related to the endian characteristics of the bus in the device driver source to use the endian conversion function;
A replacement step of replacing the called system-dependent endian conversion function with a basic endian conversion function based on the endian characteristics of the bus;
A selection step of selecting a conversion process corresponding to the replaced basic type endian conversion function based on an endian characteristic of the MPU;
And a conversion step of converting the endian of the device using the selected conversion process . 2. The device driver creation method according to claim 1, wherein the basic endian conversion function has a function of converting a value given by an argument into an MPU expression. The device driver has at least a device driver layer, a system-dependent layer, and an MPU layer,
The calling step is performed in the device driver layer,
The replacing step is performed in the system dependent layer;
The device driver creation method according to claim 1, wherein the selection step is performed in the MPU layer.   A program for causing a computer to execute the steps of the device driver creation method according to claim 1. A device driver creation device that switches processing according to hardware endian,
In order to use the endian conversion function, by including a system dependent endian header related to the endian characteristics of the bus in the device driver source, a calling means for calling a system dependent endian conversion function,
Replacement means for replacing the called system-dependent endian conversion function with a basic endian conversion function based on the endian characteristics of the bus;
Selection means for selecting a conversion process corresponding to the replaced basic type endian conversion function based on an endian characteristic of the MPU;
A device driver creation apparatus, comprising: conversion means for converting the endian of the device using the selected conversion process.

Images