JP5613091B2 - Device driver startup monitoring program, electronic equipment - Google Patents

Description

  The present invention relates to an electronic device including a device driver configured as a bundle on an OSGi platform.

  When an external device is connected to an electronic device such as a computer or an embedded device, a program module called a device driver is required in order for the external device to be recognized by the OS (operating system) of the electronic device. As a method for mounting this device driver in the Java (registered trademark) language, there is one described in Non-Patent Document 1 below.

Further, as a technology for converting a module mounted in Java into a plug-in module, there is an OSGi (registered trademark) platform described in Non-Patent Document 2 below. The OSGi platform is a service platform that allows a Java program to be dynamically added to an application as a Plugin module. The OSGi platform main body is implemented as a stand-alone Java application that is always activated. Java modules that are plug-in modules under OSGi are called bundles.

  A device driver implemented by Java can also be made into a plug-in module as a bundle under OSGi.

JSR80 API Specification, URL: http://javax-usb.org/jsr80.pdf (acquired on February 21, 2011) OSGi Service Platform Release 4, URL: http://www.osgi.org/Release4/HomePage (acquired on February 21, 2011)

  The OSGi bundle is individually activated under OSGi and cannot be used from the outside until the activation is completed. Therefore, when a device driver mounted by Java is converted into a plug-in module as a bundle under OSGi, the device driver mounted by Java cannot be used until all device drivers have been activated.

  In addition, when the device driver is implemented as an OSGi bundle, when an external device is connected to the electronic device and the OS of the electronic device tries to select a device driver suitable for the external device, the device driver is also included. It is impossible for the OS to know whether or not each OSGi bundle has been activated. Therefore, when the OS tries to search for device drivers installed in Java, whether all device drivers have been searched, or whether a device driver suitable for an external device has not been started, but still remains. I can't judge.

  The present invention has been made in order to solve the above-described problems, and provides a technique capable of ensuring that the OS can use all device drivers implemented as OSGi bundles. Objective.

  The device driver activation monitoring program according to the present invention is also configured as an OSGi bundle, and waits until all of the device drivers configured as an OSGi bundle have been activated under OSGi, and when the activation is completed, the electronic device To the OS.

  According to the device driver activation monitoring program according to the present invention, the OS of the electronic device can know that all device drivers configured as OSGi bundles have been activated under OSGi. As a result, the OS can reliably search for all device drivers, so that a situation in which a useful device driver remains unused can be avoided.

1 is a functional block diagram of an electronic device 100 according to Embodiment 1. FIG. It is a figure which shows the process sequence when the electronic device 100 starts. FIG. 6 is a diagram showing an operation procedure when an external device 200 is connected to the electronic apparatus 100.

<Embodiment 1>
FIG. 1 is a functional block diagram of an electronic device 100 according to Embodiment 1 of the present invention. The electronic device 100 is an embedded device that executes embedded software, and includes a CPU (Central Processing Unit) 110, an OS 120, a Java VM (Virtual Machine) 130, and a native device driver 140.

  The CPU 110 is an arithmetic device that executes the OS 120 and the Java VM 130. In the following, for convenience of description, a program such as the OS 120 may be described as an operation subject, but it is added that the CPU 110 actually executes these programs.

  The OS 120 is an OS of the electronic device 100 and includes a device driver selection program 121 as an internal module. The operation of the device driver selection program 121 will be described later. The Java VM 130 is a Java virtual machine that executes software implemented in the Java language. The native device driver 140 is a device driver implemented by binary code.

  The electronic device 100 is set to automatically start the OSGi platform 131 when the OS 120 is started. The Java VM 130 executes the OSGi platform 131 according to the setting. The OSGi platform 131 is implemented as a Java stand-alone application. Thereafter, the Java VM 130 continues to execute the OSGi platform 131 until the OS 120 is shut down.

  Under the OSGi platform 131, a bytecode device driver 132 implemented as an OSGi bundle is arranged. The OSGi platform 131 can arbitrarily load or unload the bytecode device driver 132 in a plug-in format.

  A plurality of types of byte code device drivers 132 and native device drivers 140 may be provided.

  In addition to the bytecode device driver 132, a device driver activation monitoring program 133 is arranged under the OSGi platform 131. The device driver activation monitoring program 133 is also implemented as an OSGi bundle. The operation of the device driver activation monitoring program 133 will be described later.

  FIG. 2 is a diagram illustrating a processing procedure when the electronic device 100 is activated. For convenience of description, the reference numerals of the constituent elements are omitted. Hereinafter, each step of FIG. 2 will be described.

(Figure 2: Step (1))
When the electronic device 100 is activated, for example, when the electronic device 100 is turned on, the CPU 110 activates the OS 120.

(Figure 2: Step (2))
The OS 120 is set to automatically start the OSGi platform 131 when it is started. The OS 120 activates the OSGi platform 131 via the Java VM 130 according to the setting.

(Figure 2: Step (3))
The OSGi platform 131 sequentially activates subordinate OSGi bundles. Here, the bytecode device driver 132 and the device driver activation monitoring program 133 are activated.

(Figure 2: Step (3): Supplement)
According to the OSGi specification, by registering the service listener of each OSGi bundle, the device driver activation monitoring program 133 can grasp whether each OSGi bundle is activated or terminated. Alternatively, after the device driver activation monitoring program 133 is activated, the device driver activation monitoring program 133 may inquire each byte code device driver 132 as to whether or not activation has been completed.

(Figure 2: Step (4))
The device driver activation monitoring program 133 notifies the OS 120 when all the byte code device drivers 132 have been activated.

(Figure 2: Step (4): Supplement 1)
As one method for implementing the above notification in this step, for example, when the OS 120 starts the OSGi platform 131 via the Java VM 130, the function pointer of the callback function is notified to the OSGi platform 131 as the notification destination in this step. It is possible. When the OSGi platform 131 activates the device driver activation monitoring program 133, the OSGi platform 131 passes the function pointer to the device driver activation monitoring program 133. The device driver activation monitoring program 133 calls the callback function in this step. This callback function may be a function provided in the OS 120 or a function provided in the device driver selection program 121.

(Figure 2: Step (4): Supplement 2)
The device driver activation monitoring program 133 may execute this step when all the bytecode device drivers 132 are activated, and does not need to wait until the OSGi bundle that is not the bytecode device driver 132 is activated.

  FIG. 3 is a diagram illustrating an operation procedure when the external device 200 is connected to the electronic apparatus 100. For convenience of description, the reference numerals of the constituent elements are omitted. Hereinafter, each step of FIG. 3 will be described.

(Figure 3: Step (1))
When the external device 200 is connected to the connection port of the electronic device 100, the CPU 110 detects that fact.

(Figure 3: Step (2))
The CPU 110 instructs the OS 120 to select a device driver suitable for the external device 200. The OS 120 starts the device driver selection program 121 according to the instruction.

(Figure 3: Step (3))
The device driver selection program 121 searches for a device driver suitable for the external device 200 in the native device driver 140. If the corresponding device driver exists, the device driver is provided to the OS 120, and the OS 120 recognizes the external device 200 using the device driver. If no corresponding device driver exists, the process proceeds to step (4).

(Figure 3: Step (4))
The device driver selection program 121 requests the OSGi platform 131 via the Java VM 130 to search the bytecode device driver 132 for a device driver suitable for the external device 200. The OSGi platform 131 (or an appropriate OSGi bundle under the OSGi platform) searches the byte code device driver 132 for a corresponding device driver. If the corresponding device driver exists, the device driver is provided to the OS 120, and the OS 120 recognizes the external device 200 using the device driver. If the corresponding device driver does not exist, the OS 120 is answered that there is no appropriate device driver.

(Figure 3: Step (4): Supplement)
If the OS 120 has not yet received the notification of step (4) in FIG. 2 at the time of this step, since the bytecode device driver 132 has not been started, the device driver selection program 121 waits until receiving this notification. You may make it do. As a result, the device driver selection program 121 waits until all the bytecode device drivers 132 under the OSGi platform 131 become available, so that all the bytecode device drivers 132 are surely searched. can do. If there is not much need to search for the bytecode device driver 132, this step may be terminated without waiting.

  The operation procedure when the external device 200 is connected to the electronic apparatus 100 has been described above. Note that the device driver selection program 121 may be implemented as a program module under the OS 120 or as a part of the OS 120.

<Embodiment 1: Summary>
As described above, the device driver activation monitoring program 133 according to the first embodiment informs the OS 120 when all the bytecode device drivers 132 implemented as the OSGi bundle have been activated under the OSGi platform 131. Notice. As a result, the OS 120 can reliably use all the bytecode device drivers 132.

  In the electronic device 100 according to the first embodiment, when the device driver selection program 121 searches for a device driver suitable for the external device 200, all the bytecode device drivers 132 have been started up under the OSGi platform 131. If no notification has been received, the system waits until the notification is received. Thereby, the said effect can be exhibited reliably.

<Embodiment 2>
The device driver implemented by the Java bytecode is usually delegated to a lower-layer device driver for physical layer control. Therefore, in the first embodiment, the bytecode device driver 132 is preferably mounted as a device driver higher than the layer that controls the physical signals of the electronic device 100 and the external device 200. Since the native device driver 140 is a device driver in the same layer as the bytecode device driver 132, the same applies.

  For example, a device conforming to the USB standard is assumed as the external device 200. In the USB standard, a bus driver, a core driver, and a device driver (in a narrow sense) are defined as layers of a device driver (in a broad sense). The bytecode device driver 132 and the native device driver 140 are preferably implemented as (narrowly defined) device drivers in the USB standard.

  100: Electronic device, 110: CPU, 120: OS, 121: Device driver selection program, 130: JavaVM, 131: OSGi platform, 132: Byte code device driver, 133: Device driver activation monitoring program, 140: Native device driver, 200: External device.

Claims (6)

A device driver activation monitoring program for causing an arithmetic unit included in the electronic device to execute processing for notifying the OS of the electronic device that a device driver of the electronic device configured as an OSGi bundle has been activated under the OSGi In the arithmetic unit,
Waiting until all the device drivers configured as OSGi bundles are started under the OSGi;
When all the device drivers are started under the control of the OSGi, notifying the OS of the electronic device to that effect;
And execute
The device driver activation monitoring program is configured as a bundle of the OSGi other than the device driver. A device driver activation monitoring program according to claim 1;
JavaVM running the OSGi platform;
An OS having the device driver activation monitoring program and the JavaVM under control;
An arithmetic device that executes the device driver activation monitoring program, the JavaVM, and the OS;
An electronic device characterized by comprising: A native device driver implemented in binary code,
A device driver selection program for causing the arithmetic unit to execute a process of selecting a device driver for causing the OS of the electronic device to recognize the external device when an external device is connected to the electronic device;
With
The device driver selection program is stored in the arithmetic device.
A native search step of searching for the native device driver that matches the external device;
If a device driver that matches the external device is not found in the native search step and the notification has already arrived from the device driver activation monitoring program to the OS, a device driver configured as a bundle of the OSGi Searching for a device driver suitable for the external device,
A step of waiting for the notification when a device driver suitable for the external device is not found in the native search step and the notification is not received from the device driver activation monitoring program to the OS;
The electronic device according to claim 2, wherein the electronic device is executed. The OS is connected to the arithmetic unit.
When the Java VM activates the device driver activation monitoring program under the OSGi platform, a process of registering a function pointer of a function included in the OS or the device driver selection program as a callback destination is executed. The electronic device according to claim 3. The native device driver and the device driver configured as the OSGi bundles, claim 3, characterized in that it is described as a device driver for the upper layer than the layer for controlling the physical signals on the electronic device or 4. The electronic device according to 4 . The electronic device according to any one of claims 3 to 5, wherein the device driver configured as a bundle of the native device driver and the OSGi is described as a device driver of a device driver layer in the USB standard. .

Images