Driver generation device and driver generation program

Abstract

To provide a driver generation device capable of compiling a driver source in a container by using the same compilation command as one on a computer.SOLUTION: According to an embodiment, a driver generation device includes a processor and a storage device. The storage device stores a kernel source and a driver source for a built-in apparatus with an embedded Linux, a container including a compiler of the driver source, and container virtualization software for managing the container. The storage device stores a program for causing the processor to implement a function for creating a directory of the same path as the kernel source on a computer when the container is started, a function for mounting the kernel source on the computer on the directory of the same path in the container, a function for mounting the driver source in the container, and a function for compiling the driver source by using the same command as one on the computer.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] Embodiments of the present invention relate to a driver generation device and a driver generation program.

Background Art

[0002] There is a known technique in which a container is prepared that uses container technology to prepare an environment for compiling a driver source of a device driver, the driver source is mounted in the container, and the driver source is compiled in the container.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] To compile a driver source, a kernel source and path information of the kernel source are required. Therefore, when building a device driver using the kernel source (for POS, MFP, etc.) on a host PC with existing technology, it is necessary to mount the kernel source on the container together with the driver source. Here, the host PC is a physical computer that executes container virtualization software. At this time, the path information of the kernel source changes between the host PC and the container. Therefore, on the container, the compilation command used at the time of compilation on the host PC must be changed.

[0005] The problem to be solved by the present invention is to provide a driver generation device that can compile a driver source in a container using a compilation command used at the time of compilation on a computer.

Means for Solving the Problems

[0006] The driver generation device according to the embodiment includes a computer having a processor and a storage device. The storage device stores kernel source for embedded devices running Linux®, driver source for device drivers for embedded devices, a container including a cross compiler for compiling the driver source, and container virtualization software for managing the container. The storage device provides the processor with a function to reference path information of the kernel source on the computer when the container virtualization software starts a container, and a function to retrieve the directory of the kernel source path on the computer based on the path information. Ri and a directory with the same path Ri The ability to create a directory within the container and to move the kernel source from the computer to a directory with the same path within the container. Ri It stores a driver generation program that implements the functions of mounting to a device, mounting the driver source within the container, and compiling the driver source using the same commands as on a computer to generate a device driver. [Brief explanation of the drawing]

[0007] [Figure 1] Figure 1 shows the hardware configuration of the driver generation device according to the embodiment. [Figure 2] Figure 2 is a schematic diagram showing the functional configuration of the driver generation device according to the embodiment. [Figure 3] Figure 3 is a flowchart showing the processing flow of the driver generation device according to the embodiment. [Figure 4] Figure 4 is a flowchart showing the compilation process flow within the container of the driver generation device according to the embodiment. [Modes for carrying out the invention]

[0008] The driver generation device according to this embodiment will be described below with reference to the drawings.

[0009] (Hardware configuration) First, the hardware configuration of the driver generation device 10 according to the embodiment will be described with reference to Figure 1. Figure 1 is a diagram showing the hardware configuration of the driver generation device 10 according to the embodiment. The driver generation device 10 is composed of a computer.

[0010] As shown in Figure 1, the driver generation device 10 includes a processor 11, ROM (Read Only Memory) 12, RAM (Random Access Memory) 13, storage 14, display 15, keyboard 16, and interface (I / F) 17. In addition to these, the driver generation device 10 may have other peripheral devices.

[0011] The processor 11, ROM 12, RAM 13, storage 14, display 15, keyboard 16, and interface 17 are electrically connected to each other via a bus 18, and transmit and receive data to each other via the bus 18.

[0012] The processor 11 is hardware that executes programs and processes data. The processor 11 consists of a general-purpose hardware processor, such as a CPU (Central Processing Unit) or a GPU (Graphical Processing Unit). The processor 11 controls the entire system, including the ROM 12, RAM 13, storage 14, display 15, keyboard 16, and interface 17.

[0013] ROM12 and RAM13 constitute the main memory. ROM12 is non-volatile memory. RAM13 is volatile memory.

[0014] The ROM 12 stores the startup program necessary for the startup of the driver generation device 10. The processor 11 starts up the driver generation device 10 by executing the startup program in the ROM 12. The ROM 12 is composed of, for example, an EPROM (Erasable Programmable Read Only Memory), and stores various settings at startup in addition to the startup program.

[0015] The RAM 13 temporarily stores the programs necessary for the processor 11 to perform various functions and the data necessary for the execution of the programs.

[0016] The storage 14 is an auxiliary storage device that stores data non-temporarily. The storage 14 is composed of a non-volatile memory such as an HDD (Hard Disk Drive) or an SSD (Solid State Drive). The storage 14 stores non-temporarily the programs executed by the processor 11 and the data necessary for the execution of the programs. The processor 11 reads the programs and data in the storage 14 into the RAM 13 and executes various functions by executing the programs.

[0017] The display 15 is an output device that outputs data. The display 15 presents various information to the user.

[0018] The keyboard 16 is an input device that receives data. The keyboard 16 receives commands to be executed by the processor 11, data to be stored in the storage 14, and the like.

[0019] The interface 17 is connected to an external device and enables input and output of data between the external device. The external device may include an input device such as a mouse or a receiving device, an output device such as a transmitting device, and an input / output device such as a disk drive.

[0020] (Functional Configuration) Next, referring to FIG. 2, the functional configuration of the driver generation device 10 will be described. FIG. 2 is a diagram schematically showing the functional configuration of the driver generation device 10.

[0021] As shown in FIG. 2, the driver generation device 10 includes a host PC 20 and a software configuration 21 installed on the host PC 20. The software configuration 21 is stored in the storage 14 and is loaded into the RAM 13 when the driver generation device 10 is started up.

[0022] The software configuration 21 includes an OS 22, container virtualization software 23, a container 24, a driver generation program 27, a kernel source 28, and a driver source 29. The host PC 20 is a physical computer that executes the container virtualization software 23.

[0023] The container virtualization software 23 is a platform that realizes a container-type virtual environment. The container virtualization software 23 provides an execution environment for managing the container 24. The management of the container 24 includes starting the container 24, executing applications in the container 24, stopping and discarding the container 24.

[0024] The container 24 is formed by mounting a container image on the container virtualization software 23. The container 24 provides an application execution environment that is independent of the platform. In the embodiment, the container 24 provides an application execution environment for compiling the driver source 29 for Linux-based embedded devices. Linux-based embedded devices are, for example, MFPs (Multi Function Peripherals), BCPs (Barcode Printers), POSs (Point of Sale), POS peripheral devices, and the like.

[0025] The container 24 includes a cross-compiler 25 and a cross-library 26. The container 24 operates using the kernel of the OS 22. For example, the container virtualization software 23 is a Docker (registered trademark) engine, and the container 24 is a Docker container.

[0026] The driver generation program 27 is a program that controls the container virtualization software 23 to compile the driver source 29 within the container 24 and generate a device driver for Linux-based embedded devices. In other words, the driver generation program 27 is a program that controls the container 24 through the container virtualization software 23.

[0027] Kernel source 28 is the source code for the kernel of a Linux-based embedded device. For example, kernel source 28 is stored in the / src / kernel directory. Driver source 29 is the source code for a device driver for a Linux-based embedded device. Driver source 29 is stored in the current directory.

[0028] (operation) The operation of the driver generation device 10 will be described below with reference to Figures 3 and 4. The driver generation device 10 compiles the driver source 29 using container technology to generate a device driver for Linux-based embedded devices. Figure 3 is a flowchart showing the processing flow of the driver generation device 10. Figure 4 is a flowchart showing the compilation process flow within the container 24.

[0029] The driver generation device 10 operates by the processor 11 executing the driver generation program 27 under the control of the OS 22, and by controlling the container virtualization software 23 according to the driver generation program 27. From another perspective, the driver generation device 10 operates by the driver generation program 27 controlling the container 24 through the container virtualization software 23. For convenience, the following will be described with the driver generation program 27 and the container virtualization software 23 as the main operating entities. It will be assumed that the driver generation program 27 and the container virtualization software 23 are running.

[0030] In ACT11, the driver generation program 27 instructs the container virtualization software 23 to start the container 24.

[0031] In ACT12, the driver generation program 27 refers to the path information of the kernel source 28 on the host PC 20 and passes the path information to the container virtualization software 23. Subsequently, the driver generation program 27 instructs the container virtualization software 23 to create a directory ( / src / kernel) within the container 24 that has the same path as the directory of the kernel source 28 on the host PC 20 ( / src / kernel), based on the path information. If the directory ( / src / kernel) already exists, the container virtualization software 23 omits this step.

[0032] In ACT13, the driver generation program 27 instructs the container virtualization software 23 to mount the kernel source 28 on the host PC 20 to a directory ( / src / kernel) within the container 24. For example, if the container virtualization software 23 is the Docker engine, it refers to environment variables (KERNEL_SRC, etc.) used when building the device driver on the host PC 20 and uses the Docker volume option to mount the kernel source 28 to the Docker engine. This allows the kernel source 28 to be shared between the host PC 20 and the container 24.

[0033] In ACT14, the driver generation program 27 instructs the container virtualization software 23 to mount the driver source 29 on the host PC 20 into the container 24. For example, the driver generation program 27 instructs the container virtualization software 23 to mount the driver source 29 located in the current directory to the / work directory within the container 24. This allows the driver source 29 to be shared between the host PC 20 and the container 24. Therefore, any processing performed on the driver source 29 within the container 24 is also reflected in the driver source 29 on the host PC 20.

[0034] In ACT15, the driver generation program 27 causes the container virtualization software 23 to compile the driver source 29 within the container 24.

[0035] Now, referring to Figure 4, we will explain the compilation process within container 24.

[0036] In ACT21, the container virtualization software 23 reads the path information of the kernel source 28 within the container 24. The path information of the kernel source 28 within the container 24 is the same as the path information of the kernel source 28 on the host PC 20, and both are ( / src / kernel).

[0037] In ACT22, the container virtualization software 23 has the cross-compiler 25 compile the driver source 29 within the container 24. At this time, since the path information of the kernel source 28 within the container 24 is the same as the path information of the kernel source 28 on the host PC 20, the container virtualization software 23 can have the cross-compiler 25 compile the driver source 29 within the container 24 using the same compilation command used during compilation on the host PC 20. As a result, the device driver is built within the container 24. Consequently, the device driver is generated in the / work directory within the container 24 and in the current directory on the host PC 20. This completes the compilation process within the container 24. After the device driver is generated, the container virtualization software 23 returns to the processing of ACT16 outside the container 24.

[0038] In ACT16, the driver generation program 27 instructs the container virtualization software 23 to stop and destroy the container 24.

[0039] After the above processing, the operation of the driver generation device 10, that is, the process of compiling the driver source 29 using the container 24 to generate a device driver for Linux-based embedded devices, is completed.

[0040] (Driver generation program) As can be seen from the above explanation, the driver generation program 27 has the function of referencing the path information of the kernel source 28 on the host PC 20 when the container 24 is started by the container virtualization software 23, and based on the path information, the directory of the path of the kernel source 28 on the host PC 20. Ri and a directory with the same path Ri The function creates a directory within container 24 and the kernel source 28 on host PC 20 in the same path directory within the container. Ri This implements the functionality to mount the source code 29 to the container 24, the functionality to mount the driver source code 29 within the container 24, and the functionality to compile the driver source code 29 using the same commands as on the host PC 20 to generate a device driver.

[0041] From another perspective, when the container virtualization software 23 starts the container 24, the driver generation program 27 refers to the path information of the kernel source 28 on the host PC 20, and then, based on the path information, instructs the container virtualization software 23 to specify the directory of the kernel source 28 on the host PC 20. Ri and a directory with the same path Ri The container 24 is created, and then the container virtualization software 23 is instructed to move the kernel source 28 from the host PC 20 to the same path directory within the container 24. Ri The device is then mounted, and the container virtualization software 23 is instructed to mount the driver source 29 into the container 24. Next, the container virtualization software 23 is instructed to use the same commands as on the host PC 20 to have the cross-compiler 25 compile the driver source 29 and generate the device driver.

[0042] (effect) As can be seen from the above explanation, according to this embodiment, the kernel source 28 on the host PC 20 is mounted to a directory in the container 24 at the same path as the directory of the kernel source 28 on the host PC 20. Therefore, the driver source 29 can be compiled in the container 24 using the compilation command used during compilation on the host PC 20. In other words, the kernel source 28 can be used in the container 24 without changing the path environment variable required when building the device driver on the host PC 20. Therefore, the build script for the host PC 20 can be reused to compile the driver source 29 in the container 24. As a result, the user can build the device driver without being aware of the directory structure within the container 24.

[0043] While several embodiments of the present invention have been described, these embodiments are presented as examples only and are not intended to limit the scope of the invention. These novel embodiments can be carried out in a variety of other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention, as well as in the claims of the invention and its equivalents. The invention described in the original claims of this application is listed below. [1] Processor and A storage device that stores kernel source code for Linux-based embedded devices, driver source code for device drivers for said embedded devices, a container including a cross-compiler for compiling said driver source code, and container virtualization software for managing said container, A driver generation device including a computer having, The aforementioned storage device is connected to the computer, The container virtualization software has a function to reference the path information of the kernel source on the computer when starting the container, Based on the aforementioned path information, a function is provided to create a directory within the container that has the same path as the directory of the kernel source on the computer. A function to mount the kernel source on the computer to the directory at the same path within the container, A function to mount the aforementioned driver source within the container, A function to compile the driver source using the same commands as on the aforementioned computer and generate the device driver, Store the driver generation program that enables this. Driver generation device. [2] Computers and, The software configuration installed in the aforementioned computer, A driver generation device having, The software configuration includes a kernel source for Linux-based embedded devices, a driver source for device drivers for the embedded devices, a container including a cross-compiler for compiling the driver source, container virtualization software for managing the container, and a driver generation program for controlling the container virtualization software. The aforementioned driver generation program, When the container virtualization software starts the container, it refers to the path information of the kernel source on the computer. Based on the aforementioned path information, the container virtualization software is instructed to create a directory within the container that has the same path as the directory of the kernel source on the computer. The container virtualization software is instructed to mount the kernel source on the computer to the directory at the same path within the container. The container virtualization software is instructed to mount the driver source within the container. The container virtualization software is instructed to use the same commands as on the computer to have the cross-compiler compile the driver source to generate the device driver. Driver generation device. [3] Processor and A storage device that stores kernel source code for Linux-based embedded devices, driver source code for device drivers for said embedded devices, a container including a cross-compiler for compiling said driver source code, and container virtualization software for managing said container, A computer in a driver generation device having, The container virtualization software has a function to reference the path information of the kernel source on the computer when starting the container, Based on the aforementioned path information, a function is provided to create a directory within the container that has the same path as the directory of the kernel source on the computer. A function to mount the kernel source on the computer to the directory at the same path within the container, A function to mount the aforementioned driver source within the container, A function to compile the driver source using the same commands as on the aforementioned computer and generate the device driver, A driver generation program that enables this. [4] A computer for a driver generation device having kernel source for Linux-based embedded devices, driver source for device drivers for said embedded devices, a container including a cross compiler for compiling said driver source, container virtualization software for managing said container, and a driver generation program for controlling said container virtualization software, When the container virtualization software starts the container, it references the path information of the kernel source on the computer. Based on the aforementioned path information, the container virtualization software is instructed to create a directory within the container that has the same path as the directory of the kernel source on the computer. The container virtualization software is instructed to mount the kernel source on the computer to the directory at the same path within the container. The container virtualization software is instructed to mount the driver source within the container. The container virtualization software is instructed to use the same commands as on the computer to have the cross-compiler compile the driver source to generate the device driver. Driver generation program. [Explanation of symbols]

[0044] 10...Driver generator, 11...Processor, 12...ROM, 13...RAM, 14...Storage, 15...Display, 16...Keyboard, 17...Interface, 18...Bus, 20...Host PC, 21...Software configuration, 23...Container virtualization software, 24...Container, 25...Cross compiler, 26...Cross library, 27...Driver generation program, 28...Kernel source, 29...Driver source.

Claims

1. Processor and A storage device that stores kernel source code for Linux-based embedded devices, driver source code for device drivers for the said embedded devices, a container including a cross-compiler for compiling the said driver source code, and container virtualization software for managing the said container. A driver generation device including a computer having, The aforementioned storage device is connected to the computer, The container virtualization software has a function to reference the path information of the kernel source on the computer when starting the container, Based on the aforementioned path information, a function is provided to create a directory within the container that has the same path as the directory of the kernel source on the computer, A function to mount the kernel source on the computer to the directory at the same path within the container, A function to mount the aforementioned driver source within the container, A function to compile the driver source using the same commands as on the aforementioned computer and generate the device driver, Store the driver generation program that enables this. Driver generation device.

2. Computers and, The software configuration installed in the aforementioned computer, A driver generation device having, The software configuration includes a kernel source for Linux-based embedded devices, a driver source for device drivers for the embedded devices, a container including a cross-compiler for compiling the driver source, container virtualization software for managing the container, and a driver generation program for controlling the container virtualization software. The aforementioned driver generation program, When the container virtualization software starts the container, it refers to the path information of the kernel source on the computer. Based on the aforementioned path information, the container virtualization software is instructed to create a directory within the container with the same path as the directory containing the kernel source on the computer. The container virtualization software is instructed to mount the kernel source on the computer to the directory at the same path within the container. The container virtualization software is instructed to mount the driver source within the container. The container virtualization software is instructed to use the same commands as on the computer to have the cross-compiler compile the driver source to generate the device driver. Driver generation device.

3. Processor and A storage device that stores kernel source code for Linux-based embedded devices, driver source code for device drivers for the said embedded devices, a container including a cross-compiler for compiling the said driver source code, and container virtualization software for managing the said container. A computer in a driver generation device having, The container virtualization software has a function to reference the path information of the kernel source on the computer when starting the container, Based on the aforementioned path information, a function is provided to create a directory within the container that has the same path as the directory of the kernel source on the computer, A function to mount the kernel source on the computer to the directory at the same path within the container, A function to mount the aforementioned driver source within the container, A function to compile the driver source using the same commands as on the aforementioned computer and generate the device driver, A driver generation program that enables this.

4. A computer for a driver generation device having kernel source for Linux-based embedded devices, driver source for device drivers for said embedded devices, a container including a cross compiler for compiling said driver source, container virtualization software for managing said container, and a driver generation program for controlling said container virtualization software, When the container virtualization software starts the container, it references the path information of the kernel source on the computer. Based on the aforementioned path information, the container virtualization software is instructed to create a directory within the container with the same path as the directory containing the kernel source on the computer. The container virtualization software is instructed to mount the kernel source on the computer to the directory at the same path within the container. The container virtualization software is instructed to mount the driver source within the container. The container virtualization software is instructed to use the same commands as on the computer to have the cross-compiler compile the driver source to generate the device driver. Driver generation program.

Images