Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

DSDP/TML/TmLWhitepaper

< DSDP‎ | TML

A Device Emulator Framework for the Eclipse Platform

A whitepaper for TmL Eclipse Project written by Tml team in July 2007

Introduction

Purpose

The purpose of the device emulator framework is to provide a layer on top of the Eclipse platform that makes it easier to integrate vendor specific emulators into the platform. It is expected to be used by device vendors to provide application development environments with integrated emulators.

Flexibility

The device emulator framework has been designed to be as flexible as possible. This means that any of the provided components can be entirely replaced by custom implementations without affecting the use of the remaining components. This is achieved by using certain design patterns and techniques that reduce component coupling, including heavy use of interfaces.

Moreover, the emulator framework has been conceived to accommodate different types of device emulators or, at least, not to preclude any type of emulator from being used in conjunction with the framework.

Consistency

The device emulator framework provides a consistent set of components that follow the principles and the look-and-feel of the Eclipse platform, allowing emulator end-users to leverage their Eclipse experience.

User Interaction

The device emulator framework assumes that, in order to be useful to an application developer, it must be possible at least to start and stop the emulator, as well as to deploy executable code into it. The device emulator should also have some kind of output, either using an output device such as an emulated display or by performing actions on its environment. In the latter case, adapters must be able to translate those actions into something that can be displayed to the user on the Eclipse UI. Additionally, the emulator may be able to accept user input, and can have properties that the user can configure.

Components

The device emulator framework described in this whitepaper simplifies the implementation of a device emulator as an Eclipse plug-in.

The emulator plug-in supports the creation of emulator instances that can be started and stopped according to user needs.

The framework provides classes that support the implementation of the following plug-in components:

  • A New Emulator Instance Wizard;
  • An Emulator Project Nature;
  • An Emulator Instance View;
  • An emulator instance property management mechanism to handle the properties of each emulator instance, including a Property Editor;
  • An Emulator Perspective;
  • VNC Viewer Views to handle emulator input and output;
  • An Emulator Control Panel to start and stop the emulator instance.

Additional components shall be added in the future to support deployment of executable files to the emulator instances, remote execution of emulator instances and so on.

Emulator Framework Architecture

Background

The basic concepts that must underlie the architecture of the device emulator framework are described below.

  • The Eclipse platform is a portable, Java-based platform that can be extended through plug-ins by implementing extensions which plug into existing extension points;
  • The Eclipse Workbench is the Eclipse UI, a large window that contains the Eclipse menu bar, a central site at the top of the working area that usually contains an editor, and surrounding sites to the left, right and at the bottom that contain views;
  • The Eclipse Workspace is an area where Eclipse projects created using the Eclipse platform and its plug-ins are stored. The contents of the Workspace are displayed in the Navigator View in the Resource Perspective;
  • An Eclipse plug-in is a collection of Java classes and other code that contains one or more extensions that plug into one or more extension points. A plug-in can define actions, views; editors etc. and handle resources in the Workspace. A plug-in can also define new extension points.
  • The Device Emulator Framework is part of the Tools for mobile Linux (TmL) subproject of the Eclipse DSDP (Device Software Development Platform) project. The framework comprises a collection of Java classes organized and distributed as a plug-in and that collectively support the development of emulator plug-ins for the Eclipse platform.
  • An Emulator Plug-in is a plug-in that defines the properties and behavior of a device emulator, allowing the user to create instances of the emulator, customize the properties of each instance, start and stop each instance independently.

The bulk of the device emulator plug-in code will be in the classes or files that define the emulator behavior, while the emulator framework is the “glue” that supports integration with the Eclipse environment.

Framework Architecture

The diagram below shows the architecture of the device emulator framework and the relationships among the Eclipse platform, the emulator framework and the device emulator itself, emphasizing the distinction between the emulator itself and the Eclipse GUI. The diagram is based on a sample emulator that might be based on e.g. QEmu and that has an emulated keyboard, an emulated pointer (e.g. a mouse), standard output and standard error streams, two emulated displays and a set of emulated LEDs. The components shown in yellow are those that belong to the device emulator framework.

Wp001.gif

This diagram enables us to identify the main components of the device emulator framework, namely: the property management mechanism (with a properties view that was actually implemented as a property editor to comply with Eclipse standards), the input and output system (with the corresponding views and adapters), and the launching mechanism (with UI elements and the underlying mechanism that actually starts the emulated system).

The next section discusses the design details of the actual components of the emulator framework.

Framework Definitions

This section describes the components of the device emulator framework in high level definitions with the purpose of explain better what is mean of each part of this framework and how them are connected with the other TmL components.

Device Emulator

A device emulator is a binary distribution that contains all files required to run a specific emulator. It provides network connectivity that allows for message exchange using the protocols supported by the emulator framework as well as a framebuffer display protocol.

The first release of TmL supports the RFB (or VNC) protocol versions 3.3, 3.7 and 3.8 to be compatible with a wide array of emulators which export the framebuffer using a VNC server.

Emulator types that can be supported by the framework include:

  • QEmu running ARM Linux
  • QEmu running ReactOS
  • CoLinux running available Linux distributions
  • VMware virtual machine running Linux
  • VMware virtual machine running Windows


Device Emulator Plug-in

The Emulator binaries should be encapsulated into a plug-in project to be distributed over TmL framework. This plug-in contains some configuration files describing the emulator.

Wp002.gif

Figure 1 – Device Emulator Plug-in


Each emulator type might have one description plug-in extending TmL framework and using the extensions points available. The user will be able to create instances for these emulator if they were installed in Eclipse Platform.

Wp003.gif

Figure 2 – Eclipse Platform and TmL plug-ins

Emulator Plug-ins and Instances

An emulator plug-in contains static information required to create and run instances of the corresponding device emulator, but it cannot contain dynamic information associated to each individual instance. Dynamic information must be stored in the Eclipse Workspace and linked to the corresponding emulator instance.

Emulator instances are therefore represented as “projects” in the Eclipse Workspace. These projects are displayed in the Navigator View of the Resource Perspective, just like any other project, but they are identified by an “emulator nature” defined in the framework.

The diagram below clarifies the difference between emulator plug-ins and emulator instances in the Workspace, where the latter contain internal properties that identify them.

Each emulator plug-in provides common features such as a New Emulator Instance Wizard to create a new emulator instance, a start/stop mechanism and property edition.

Wp004.gif

Framework Components

This section describes the components of the device emulator framework in the order that most closely corresponds to the workflow of an emulator developer, so that it can also be used as a tutorial on how to use the framework to develop an Eclipse-integrated device emulator.

The current implementation corresponds to a very first version of the emulator framework and therefore does not contemplate more sophisticated use cases such as managing and running remote device emulators.

New Emulator Instance Wizard

As described before, a device emulator plug-in contains static information regarding the device properties and behavior, while dynamic information pertaining to a specific instance of a device emulator is stored in a “project” in the Eclipse Workspace.

The emulator framework provides a New Emulator Instance Wizard that allows the user to create a new instance of an emulator. The classes provided by the framework can be used directly, requiring only minimal configuration data to be provided by the emulator developer. Alternatively, the emulator developer can customize the wizard pages, provide their own pages, or even create their own wizard altogether.

The New Emulator Instance Wizard is very similar to the standard Eclipse New Project Wizard, where the first page asks the user to specify the project name and location and the remaining pages ask the user for additional information.

Configuring the New Emulator Instance Wizard

TBD

Customizing the New Emulator Instance Wizard Pages

TBD

Creating Your Own New Emulator Instance Wizard

The emulator framework allows the emulator developer to create their own New Emulator Instance Wizard. In this case, the developer must also be careful with the creation of the emulator instance project, for the latter must follow certain constraints and conditions. These are defined in the section about emulator instances. In particular, project natures must be correctly configured and the developer must ensure that the methods return valid values for the properties file and the properties path.

Device Emulator Instances

As previously mentioned an emulator instance is represented as a project in the Eclipse Workspace and corresponds to a specific configuration of an emulator, while the emulator plug-in defines the rules for creation and use of such emulator instances.

A emulator instance is a project and working using the project eclipse rules. To identify one emulator it is used the project nature that is a subset of tags put into .project file and used for the eclipse to identify and associate specific features to specific nature. For instance, when a java project is created , this project has java project nature and eclipse open menus and actions specific designed to work with this kind of project.

An emulator instance has an emulator nature defined in the framework and identified as org.eclipse.tml.emulator.core.emulatornature. It must also have a nature whose name corresponds to the plug-in id itself, which is required in order to associate the instance with the corresponding emulator plug-in and allow the framework to access plug-in-specific features.

If an emulator instance is created by means of a custom creation method, the developer must ensure that the two natures above are both included, and that no other natures are used. This is required by the framework.

Wp005.gif

The framework provides an Emulator Instance view that shows all emulator instances available in the Workspace. In this view one can see the properties and corresponding values for each emulator instance. If the user double clicks on the instance.properties file, the file is opened in the corresponding editor.

Wp006.gif

Properties of a Device Emulator Instance

The properties of a device emulator instance depend on the type of emulator and are defined in the emulator plug-in. In order to use the property management mechanism provided by the emulator framework, the emulator plug-in must include a properties file.

The properties file contains a list of properties for the emulator that the plug-in implements, but it does not contain the property values.

The Emulator Perspective

The emulator framework defines a perspective for viewing emulator instances. It can be opened when a new emulator instance is created, or when the user opens an emulator instance for editing or viewing. The figure below shows all the components of the perspective. Not all components are implemented in the current version of the emulator framework.

Wp007.gif

The current version of the emulator framework includes the Emulator Instance view, the Property editor, the Emulator Instance Control view and the VNC Viewer view.

Running the Emulator

The Emulator Instance view provides a pop-up menu that allows the user to start and stop the emulator instance as well as to display the Emulator Instance Control view.

Wp008.gif

The Emulator Instance Control view provides a graphical representation of the status of the emulator instance, together with buttons to start and stop its execution. The actual implementation of the start and stop operations is done through the Emulator Launcher, which is specific for each emulator plug-in.

Wp009.gif

An emulator launcher is added to an emulator plug-in by means of the extension point org.eclipse.tml.emulator.launch.instance:

Wp010.gif

  • <launcher-class> – this is the name of the launcher class that implements the emulator framework interface IEmulatorLauncher;
  • %Launcher.name – launcher name to be displayed on the Emulator Control Panel;
  • %Launcher.desc – launcher description to be displayed on the Emulator Control Panel.

The launcher is responsible for starting and stopping an emulator instance. In order to do this, it should read the property file and create an instance of a class that implements IEmulatorConnection. The actual class implementation depends on the characteristics of each particular emulator, and it should use the properties for the selected emulator instance. The recommended implementation includes loading the property model from the selected emulator instance project and using the properties to create the connection object.

Emulator Input and Output

There are many ways in which an emulator can display its output and receive its input. The emulator framework uses an independent component that implements an RFB (also known as VNC) client.

The RFB client component is independent from the emulator framework, which means it can be used for totally different purposes. It comprises an SWT viewer that displays the pixels received by the underlying RFB client, which is capable of communicating with any standard RFB server.

The current implementation of the RFB client is based on a subset of version 3.3 of the RFB protocol. The emulator framework provides some pieces to integrate the RFB viewer to an emulator plug-in.


Framework External Interfaces

This section describes the external components of the TmL Project that making some interface with device emulator framework

VNC Viewer

This component implements a RFB protocol in the versions 3.3, 3.7 and 3.8 and allows the emulator redirect the framebuffer output using a VNC connection.

Wp012.gif

Figure 3 - VNC Viewer connected on QEMUReactOS

Wp013.gif

Figure 4 - Interface between instances and viewer

The Figure 4 shows one of the flows possible to display the output of frame buffer using the VNC Viewer component. The first implementation support just RFB protocol and it already has support to send messages related to mouse and keyboard events.

The future releases this component will be extending to support skins and keyboard mapping capabilities. The Figure 5 shows one example of how this viewer could be used in the future implementations.

Wp015.gif

Figure 5 – New viewer composed by VNC, keyboard and Skin (single displays)


File:Wp016.gif

Figure 6 – New viewer composed by VNC, keyboard and Skin (multiple displays)

Back to the top