Driver generation device and driver generation program

Abstract

To provide a driver generation device and program for compiling even a source code requiring a unique environment in a container in executing compilation.SOLUTION: A driver generation device includes the steps for: determining whether to require a file system patch in executing compilation by a cross compiler when a container is started by container virtualization software; making the container virtualization software mount the file system patch in a container to a determination result of requiring the file system patch; making the container virtualization software mount an application source in the container; and making the container virtualization software compile the application source in the cross compiler to generate a Linux driver.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] An embodiment of the present invention relates to a driver generation device and a driver generation program. [Background technology]

[0002] A known technology uses container virtualization software, such as "Docker (registered trademark)," to mount a directory of a host PC into a container, which is a virtual environment that is independent of the software on the host PC (development machine), thereby placing source code in the container and creating a compilation environment in which the source code is compiled within the container. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2017-76264 Summary of the Invention [Problem to be solved by the invention]

[0004] Depending on the software, it may be necessary to place a unique environment, such as other unique libraries or multiple source codes, in the appropriate path when compiling. For example, a Linux driver that requires the Linux (registered trademark) kernel source is an example of this. In cases where advance preparations are required in the development environment, the source code cannot be compiled simply by placing it in a container.

[0005] The problem to be solved by the present invention is to provide a driver generation device that can compile, within a container, even source code that requires a unique environment during compilation execution. [Means for solving the problem]

[0006] A driver generation device according to an embodiment includes a computer having a processor and a storage device. The storage device stores an application source of a Linux driver, a container including a cross-compiler that compiles the application source, container virtualization software that manages the container, and a file system patch for the cross-compiler. The storage device stores a driver generation program that causes the computer to implement the following functions: when the container virtualization software starts the container, determine whether a file system patch is required when the cross-compiler executes compilation; and, if a file system patch is required, mount the file system patch in the container; mount the application source in the container; and compile the application source to generate a Linux driver. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 is a diagram illustrating a hardware configuration of a driver generating device according to an embodiment. [Figure 2] FIG. 2 is a diagram illustrating a functional configuration of a driver generating device according to the embodiment. [Figure 3] FIG. 3 is a diagram showing an example of the structure of a file system patch. [Figure 4] FIG. 4 is a flowchart showing the flow of processing of the operation of the driver generating device according to the embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0008] Hereinafter, a driver generating device according to an embodiment will be described with reference to the drawings.

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

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

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

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

[0013] The ROM 12 and RAM 13 constitute a main storage device. The ROM 12 is a non-volatile memory. The RAM 13 is a volatile memory.

[0014] The ROM 12 stores a startup program required to start the driver generating device 10. The processor 11 starts the driver generating device 10 by executing the startup program in the ROM 12. The ROM 12 is configured, for example, with 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 programs required for the processor 11 to perform various functions and data required for executing the programs.

[0016] The storage 14 is an auxiliary storage device that non-temporarily stores data. The storage 14 is configured with non-volatile memory such as an HDD (Hard Disk Drive) or an SSD (Solid State Drive). The storage 14 non-temporarily stores programs executed by the processor 11 and data required for executing the programs. The processor 11 loads the programs and data in the storage 14 into the RAM 13 and executes the programs to perform various functions.

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

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

[0019] The interface 17 is connected to an external device and enables input and output of data to and from 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, the functional configuration of the driver generating device 10 will be described with reference to Fig. 2. Fig. 2 is a diagram schematically showing the functional configuration of the driver generating device 10.

[0021] 2, the driver generation device 10 includes a host PC 20 and a software configuration 21 installed in 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 file system patch 28, and an application source 29. The host PC 20 is a physical computer that runs 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 that manages the container 24. The management of the container 24 includes starting the container 24, running applications in the container 24, and stopping and destroying the container 24.

[0024] The container 24 is formed by mounting the container image on the container virtualization software 23. The container 24 provides a platform-independent application execution environment. In an embodiment, the container 24 provides a compilation execution environment for compiling the application source 29.

[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 engine, and the container 24 is a Docker container.

[0026] The application source 29 is the source code of an application that requires its own library during compilation. In other words, the application source 29 is the source code of an application that cannot be built simply by placing it in the container 24. For example, the application is a Linux driver that requires the Linux kernel source. The Linux driver is, for example, a driver for an MFP (Multi Function Peripheral), a BCP (Barcode Printer), a POS (Point of Sale), a POS peripheral, or the like.

[0027] The file system patch 28 is a set of directory structures and files required by the cross compiler when compiling the application source 29. An example of the configuration of the file system patch 28 is shown in Figure 3. In Figure 3, the file system patch 28 corresponds to libtest.so under the lib directory under the usr directory, srccode1 under the src directory under the usr directory, srccode2 under the src directory under the root directory, and test.conf under the etc directory.

[0028] libtest.so is a shared object file required by the cross compiler 25 when compiling the application source 29. For example, libtest.so is a library that is linked when compiling the application source 29.

[0029] For example, test.conf is a configuration file for environment variables, options, etc. that the cross compiler 25 needs when compiling the application source 29 .

[0030] For example, srccode1 and srccode2 are header files required when compiling application source 29. Header files are files for declaring functions, constants, structures, etc.

[0031] The file system patch 28 can be packaged in a single file, for example, as a tar.gz.

[0032] (operation) The operation of the driver generation device 10 will be described below with reference to Fig. 4. The operation of the driver generation device 10 is to compile the application source 29 using container technology and generate an application, for example, a Linux driver. Fig. 4 is a flowchart showing the processing flow of the operation of the driver generation device 10.

[0033] 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 in accordance with 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 description will be given with the driver generation program 27 and the container virtualization software 23 acting as the main actors. It is assumed that the driver generation program 27 and the container virtualization software 23 are running.

[0034] In ACT11, the driver generation program 27 causes the container virtualization software 23 to start the container 24. At this time, the driver generation program 27 receives a start-up option for the container 24 designated by the user.

[0035] In ACT12, the driver generation program 27 determines whether a patch file is required for compiling the application source 29 by the cross compiler 25 in the container 24. If the determination result indicates that a patch file is required, the program proceeds to processing in ACT13, and if the determination result indicates that a patch file is not required, the program skips processing in ACT13 and proceeds to processing in ACT 14. Whether a patch file is required is specified by the user as a startup option for the container 24.

[0036] In ACT13, the driver generation program 27 causes the container virtualization software 23 to mount the file system patch 28 in the container 24. At this time, the contents of the file system patch 28 are expanded in the container 24, for example, as shown in FIG.

[0037] In ACT14, the driver generation program 27 causes the container virtualization software 23 to mount the application source 29 in the container 24. This allows the application source 29 to be shared between the host PC 20 and the container 24. Therefore, processing on the application source 29 in the container 24 is also reflected in the application source 29 on the host PC 20.

[0038] In ACT15, the driver generation program 27 causes the container virtualization software 23 to compile the application source 29 with the cross compiler 25 within the container 24. As a result, a Linux driver is generated within the container 24 and on the host PC 20.

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

[0040] Through the above processing, the operation of the driver generation device 10, that is, the process of compiling the application source 29 using the container 24 and generating a Linux driver, is completed.

[0041] (Driver generation program) As can be seen from the above explanation, the driver generation program 27 provides the host PC 20 with the following functions: when the container 24 is started by the container virtualization software 23, determine whether the file system patch 28 is required when the cross compiler 25 performs compilation; and, if the determination result indicates that the file system patch 28 is required, mount the file system patch 28 within the container; mount the application source 29 within the container 24; and compile the application source 29 to generate a Linux driver.

[0042] From another perspective, when the container is started by the container virtualization software 23, the driver generation program 27 determines whether the file system patch 28 is required when the cross compiler 25 performs compilation, and if the determination result indicates that the file system patch 28 is required, the driver generation program 27 causes the container virtualization software 23 to mount the file system patch 28 in the container 24, then mount the application source 29 in the container 24, and then cause the cross compiler 25 to compile the application source to generate a Linux driver.

[0043] (effect) As can be seen from the above description, according to the embodiment, when compiling an application source 29 that requires a special directory structure or unique files for execution at compile time, a file system patch 28 having the special directory structure and unique files is mounted in the container 24 when the container 24 is started. This makes it possible to compile an application source 29 that requires a special directory structure or unique files for execution at compile time. Since the file system patch 28 that was mounted once can be used from the second compilation onwards, it is possible to reduce the effort required to arrange the required directory structure and unique files each time compilation is performed. Combining the file system patch into a single file as tar.gz facilitates source code management.

[0044] Although several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included within the scope and spirit of the invention, and are also included in the scope of the invention and its equivalents as defined in the claims. [Explanation of symbols]

[0045] 10...Driver generation device, 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...File system patch, 29...Application source.

Claims

1. a processor; a storage device that stores an application source of a Linux driver, a container including a cross compiler that compiles the application source, container virtualization software that manages the container, and a file system patch for the cross compiler; A driver generation device including a computer having: The storage device includes: a function of determining whether the file system patch is necessary when the cross compiler executes compilation when the container is started by the container virtualization software; If the file system patch is determined to be necessary, a function of mounting the file system patch in the container; Mounting the application source into the container; A function of compiling the application source to generate a Linux driver; storing a driver generation program for realizing the above; Driver generation device.

2. The file system patch is a set of directories and files that the cross compiler needs when compiling the application source.

2. The driver generating device according to claim 1.

3. A computer, a software configuration installed on the computer; A driver generation device comprising: the software configuration includes: an application source of a Linux driver; a container including a cross compiler that compiles the application source; container virtualization software that manages the container; a file system patch for the cross compiler; and a driver generation program that controls the container virtualization software; The driver generation program When the container is started by the container virtualization software, it is determined whether the file system patch is necessary when the cross-compiler is used to compile the container; If the file system patch is determined to be necessary, the container virtualization software is caused to mount the file system patch within the container; causing the container virtualization software to mount the application source within the container; causing the container virtualization software to use the cross compiler to compile the application source to generate the Linux driver; Driver generation device.

4. a processor; a storage device that stores an application source of a Linux driver, a container including a cross compiler that compiles the application source, container virtualization software that manages the container, and a file system patch for the cross compiler; a driver generation device computer having a function of determining whether the file system patch is necessary when the cross compiler executes compilation when the container is started by the container virtualization software; If the file system patch is determined to be necessary, a function of mounting the file system patch in the container; Mounting the application source into the container; A function of compiling the application source to generate a Linux driver; A driver generation program that makes this possible.

5. A driver generation device computer includes a Linux driver application source, a container including a cross compiler that compiles the application source, container virtualization software that manages the container, a file system patch for the cross compiler, and a driver generation program that controls the container virtualization software. When the container is started by the container virtualization software, it is determined whether the file system patch is necessary when the cross-compiler is used to compile the container; If the file system patch is determined to be necessary, the container virtualization software is caused to mount the file system patch within the container; causing the container virtualization software to mount the application source within the container; causing the container virtualization software to use the cross compiler to compile the application source to generate the Linux driver; Driver generator.

Images