Description

This implementation contains 10 bundles, and it relies on 2 required bundles, and 2 optional bundles for http service.

Required external packages / bundles

Optional external packages / bundles

Device Access Implentation Bundles

There are 3 family bundles:
-core: bundles representing the device service specification
-tools: some tools and testing bundles
-sample: bundles for devices and driver samples

Core bundles

There are 2 core bundles:
- devicemanager.jar: it provides the main implementation that listens to a registering device and tries to find a corresponding driver.
The device manager controls the device access. It is responsible for initiating all actions in response to the registration and unregistration of Device services and Driver services.
The device manager detects the registration of Device Services and coordinate their attachment with a suitable Driver service. Potential Driver services do not have to be activated in the framework to be eligible. The device manager must use Driver Locator services to find bundles that might be suitable for the detected Device service. Then it decides which of the eligible Driver services is the best match. The device manager must install and start this bundle with the help of a Driver Locator service.
If a Driver service is unregistered due to an uninstallation or update, the device manager must try to reattach a Device service that is IDLE .
(See the specification for details).
- driverlocator.jar: it provides a simple driverlocator Service implementation. It can contact a web server at a specific url defined by the org.osgi.service.device.driverlocator.driverslocation System property (the default url is: http://localhost:8080/drivers/). In this repository it should find a file defining the corresponding match beetween a driver name and its corresponding jar file. This file is defined by the org.osgi.service.device.driverlocator.driverlistfile System Property (Default : drivers.txt).So you need to have an http serveur providing the drivers.txt file at the url defined by the two system properties.

Tools

There are four tool bundles:
- modulemanager : enables to install or remove Linux modules. It makes some system calls to insmod, rmmod and modprobe.
- logger: is a bundle that displays log results
- httpresources: is a bundle that registers the url mapping of the http server (http://localhost:8080/drivers/ -->/opt/drivers/). It is the URL used by the driverlocator service.
- wlandrivertest : is a test bundle that triggers a test method on the wlandriver bundle.

Samples

There are three sample bundles. One device bundle (pcmciadevice.jar) and two driver bundles (pcmciadriver.jar and wlandriver.jar). The device bundle registers the pcmcia device, the standard mecanism, tries to find through the driverlocator service a suitable driver through the internet (http connexion). It downloads the pcmciadriver bundle (which needs to be in the device directory) through the URL http://localhost:8080/drivers/pcmciadriver.jar. When the pcmciadriver is started by the devicemanager, three Linux modules are installed and a daemon is started in order to listen for card insertion events from the pcmcia slots. These modules are provided by the pcmcia_cs package (ds, i82365 or yenta_socket or tcic and pcmcia_core).
- pcmciadevice.jar : It is started by the user through oscar shell.
- pcmciadriver.jar : It is automatically downloaded from http://localhost:8080/drivers/pcmciadriver.jar. It is defined as a based driver in the OSGi terminology. For the moment this base driver defines a refined device, corresponding to the wlan card. When the wlan card is inserted, the wlan driver registers a new wlan device. (package is included into the pcmciadevice bundle). The wlandevice registration triggers the download of the wlandriver.jar from the URL.
- wlandriver.jar : It contains the specific driver of the wlan card. When this driver is attached to the wlandevice, the Linux driver for the card is installed automatically (for example, orinoco_cs).