Writing player drivers

Citer from:

http://cgi.cse.unsw.edu.au/~cs4411/wiki/index.php?title=Writing_player_drivers

 

Every driver plugin should define the following functions:

Driver::Driver(ConfigFile *cf, int section, int interface, uint8_t access, size_t datasize, size_t commandsize, size_t reqqueuelen, size_t repqueuelen);

In which you read in general configuration data from the player config file. Interface specifies which interface you are supporting, such as localise or position.

Driver::Setup()

In which you do any device-specific setup, such as opening file buffers or configuring serial ports, and then start the driver thread.

Driver::Shutdown()

In which you do any device-specific cleanup, such as closing file buffers.

Driver::Main()

An infinite loop, which repeatedly updates data and sends for whichever interface you are supporting.

Driver::SendData()

In which we actually put the data in a form that Player can read and send it off.

 

Super Detailed Guide

(I have no idea where we found this, so can't reference it properly. But it is awesome!)

plugin_driver HOWTO: Creating a Plugin Driver

The are two distinct type of drivers in Player:

- Static drivers have their code in the main Player distribution, and are statically linked into the server. Generally speaking, such drivers will be added by the lead developers.

- Plugin drivers are shared objects that are loaded at runtime (like loadable modules in the Linux kernel). They are the recommended method for all new, experimental or third party drivers.

 

Plugin drivers have serveral advantanges over their static counterparts:

- They are easier to build (no mucking about with autotools, or digging about in the server internals).

- They permit rapid development and a much faster code/compile/test cycle (the server does not need to be recompiled/relinked when the driver changes).

- Code can be maintained in a separate source repository. This is particularly useful for users with funky one-off drivers that belong with the rest of their code, data, papers, etc (and not in the Player source tree).

This document describes the process for creating new plugin drivers.

It assumes you are familiar with C++, class inheritance, and thread programming.

 

1. A plugin driver example

 

Sample code for a very basic plugin driver is provided in the examples directory; for a default install, this will be:

/usr/local/src/player/examples/plugins/exampledriver/

Copy the files from this directory and rename Makefile.example to Makefile. Try building the example:

$ make

This produces a plugin driver named exampledriver.so. You can test the model using the included configuration file:

$ player ./example.cfg

The driver block in the config file has an additional field @c plugin specifying the path to the plugin, i.e.,:

driver ( name "exampledriver" plugin "exampledriver.so" provides ["position:0"] ... )

 

2. Writing a simple driver

The first step in creating a new driver is to decide which interface it will support.  The existing interfaces are described in the reference section, and their various message structures and constants are defined in player.h.  Although you can create a new interface, you should try to fit your driver to an existing interface, of which there are many.  By deciding to support an existing interface, you'll have less work to do in the server, and will likely have instant client support for your driver in several languages.
Standard API, part of which the new driver must implement (other parts To create a new driver, you should create a new class for the driver,  which should inherit from the Driver class. 
This base class defines a it may choose to override).  We now describe the salient aspects of the Driver class.

2.1 The constructor
Simple drivers will use the following Driver constructor:
Driver::Driver(ConfigFile *cf, int section, int interface, uint8_t access, size_t datasize, size_t commandsize, size_t reqqueuelen, size_t repqueuelen);

This constructor will establish the buffers and queues that allow the Player server to interface with the driver. 
The preamble for the example driver, for example, looks like this:
ExampleDriver::ExampleDriver(ConfigFile* cf, int section) : Driver(cf, section, PLAYER_POSITION_CODE, PLAYER_ALL_MODE, sizeof(player_position_data_t), sizeof(player_position_cmd_t), 10, 10) { ... }
The preamble indicates that this driver:
 - Supports the position interface (indicated by @c   PLAYER_POSITION_CODE);
 - Allows read/write access from clients (@c PLAYER_ALL_MODE);
 - Has a data buffer large enough to accomodate a  standard position interface data packet (@c sizeof(player_position_data_t));
 - Has a command buffer large enough to accomodate a  standard position interface command packet (@c sizeof(player_position_cmd_t));
 - Can queue up to 10 incoming configuration requests and 10 outgoing configuration replies.
The @c cf and @c section parameters are passed in by the server; these values to access driver-specific options stored in the Player configuration file.  Thus, for example, the driver constructor can read the value of some setting "foo":
this->foop = cf->ReadInt(section, "foo", 0); 
This might be the serial port from which to read data, for example.
See the ConfigFile documentation for the various kinds of options that can be read from the configuration file.

2.2 Setup()
When the first client subscribes to a driver, the driver's Setup() method is called; every driver @b must implement this method. 
The Setup() method generally does two things:
- Do some device-specific initialization (e.g., open a serial port).

- Start the driver thread using Driver::StartThread().
Player is a multi-threaded application, with most drivers running in  their own thread; this makes it particularly easy to write drivers that read/write data from serial ports, network sockets, disk files and so on.
After initialization, Setup() should return either zero to indicate that the device was successfully setup, or non-zero to indicate that setup failed (the latter will cause Player to terminate).

2.3 Shutdown()

When the last client unsubscribes from a device, the driver's Shutdown() method is called; every driver @b must implement this method. 
The Shutdown() method generally does two things:
- Stop the driver thread using Driver::StopThread().
- Do some device-specific finalization (e.g., close a serial port).
 Note that the ordering is important here: we must shut down the driver thread @b before we release the resources it is using; to this end, Driver::StopThread() will tell the driver thread to quit, and wait until it exits before returning.
Shutdown() should return either zero to indicate that device was successfully shutdown, or non-zero to indicate that shutdown failed.

2.4 Main()
The Driver::Startup() method will result in the creation of a new thread of control, which will immediately call Driver::Main().  Every driver must this overload this method.  The overloaded Main() method is generally responsible for translating between some device-specific  API and the standard Player interfaces.  The basic steps are as follows:
- For incoming data:
- Read data from some external device (over a serial port, for example).
- Massage the data into one of the Player interface data structures.
- Write the data to the Player server using Driver::PutData().
- For outgoing data (commands):
- Read commands from the Player server using Driver::GetCommand().
- Massage the command into a device specific format.
- Write the command to the external device.
The Driver::PutData() and Driver::GetCommand() methods manage all of the buffering and locking required to synchronize the driver and server threads.
The overloaded Main() method is also responsible for handling any configuration request sent to the driver; the basic steps are as follows:
- Check for a new request using Driver::GetConfig().
- Do whatever needs to be done for this request.
- Send a response using Driver::PutReply().
Note that your driver must respond, one way or another, to each and every request.  Failing to respond to requests will cause client  programs to "hang" when talking to the driver.
The overloaded Main() must also be capable of graceful termination  (i.e., the function should exit cleanly when the user kills the server).  This can be achieved by calling @c pthread_testcancel() from within the main loop.  This function checks to see if the driver  thread should terminate, and if so, immediately exits Main().  If additional cleanup is required, drivers can also overload Driver::MainQuit(), which is guaranteed to be called on thread termination.

2.5 Instantiation
In order to instantiate a driver, the Player server needs to know two things:
- The driver's name (as it will appear in the configuration file).  
- The driver's @b factory function (used to create a new instance of the driver).  The factory function will generally look something like this:
Driver* ExampleDriver_Init(ConfigFile* cf, int section) { return ((Driver*) (new ExampleDriver(cf, section))); }  
Note that this function may be called multiple times: once for each occurance of the driver name in the configuration file.
Each driver must register itself with the server using the DriverTable::AddDriver(), providing the driver name and factory function.  Drivers must therefore define a registration function as follows:
void ExampleDriver_Register(DriverTable* table) { table->AddDriver("exampledriver", ExampleDriver_Init); }
This function must be called exactly once, on program startup.  For plugin drivers, this can be achieved by defining an initialization function for the shared object:
extern "C" { int player_driver_init(DriverTable* table) { ExampleDriver_Register(table); return 0; } }  
This function will be called when the shared object is loaded, before any drivers are instantiated.  The @c extern @c "C" block is used to prevent C++ name mangling of the intialization function.

2.6 Building the shared library
The example driver includes a Makefile for building shared objects.
To manually build a shared object, try:
$ g++ -Wall -g3 -c exampledriver.cc
$ g++ -shared -nostartfiles -o exampledriver.so exampledriver.o
While the above method will probably work, it is recommended that you use pkg-config to get the compile flags; i.e.,
$ g++ -Wall -g3 `pkg-config --cflags player` -c exampledriver.cc
$ g++ -shared -nostartfiles -o exampledriver.so exampledriver.o

@todo
- Add example of building plugin using libtool.
- Add "theory" from Architecture Chapter of the old manual.

 

3. References:
[1] http://playerstage.sourceforge.net/doc/Player-cvs/player/group__tutorial__plugins.html