Extend and improve infrastructure for KBUS messaging

From eLinux.org
Revision as of 13:15, 31 January 2011 by Wmat (talk | contribs) (Added body of kbus proposal page.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Extend and improve infrastructure for KBUS messaging

Summary
Extend and improve infrastructure for KBUS messaging
Proposer
Tony Ibbs <tibs@tonyibbs.co.uk>

Description

KBUS is a lightweight, simple to use, reliable kernel-mediated messaging system for Linux. It was developed specifically for use on embedded systems. It can be used via low-level file access (open, read, write, ioctl), but also has a C library, and APIs for Python, Java and C++. The unit-tests use the Python API. We have just begun the process of submitting the KBUS kernel module to the Linux kernel.

I would like to propose the following:

Bring all APIs to a consistent level: At the moment, the different language bindings are at different stages. The Java binding does not yet make all KBUS functionality available. The C++ binding includes some ideas which could usefully be incorporated elsewhere. The internal code of the Python API could do with some review, as it is the oldest. Finally, the C++ binding does not use exceptions or RTTI (to allow its use in constrained conditions) and it may be worth providing a "traditional" C++ API (with full use of exceptions) as well.

Provide Poky/OpenEmbedded recipes: The aim is to make it easier for people to incorporate KBUS into their projects.

Provide DEB and RPM packages: If KBUS does get into the kernel, then packaging the associated libraries for the most popular Linux distributions would be very useful. If KBUS does not get into the kernel, packaging the kernel module is more or less essential.

Provide a good set of examples: Specifically, examples of "how to do common tasks". The kmsg example program is useful, but not particularly realistic. We hope one of Kynesim's customers will be releasing its KBUS-using code later in the year, but KBUS is only a small part of the whole. Actual targetted "how-to" examples are needed.

Show/document use with Binder in Android: KBUS has been used within Kynesim to communicate between the Java and Linux levels of Android, in conjunction with Binder. This works rather well. Documentation and decent example code needs to be made available.

Provide a Java Message Services API: At ELCE 2010 several people said it would be useful to do this, and that it would make KBUS more accessible to Java programmers.

Provide a good Limpet exemplar: KBUS deliberately isolates its buses (the "goldfish bowl" metaphor). However, it is sometimes desirable for a program to believe it is talking via KBUS whilst messages are actually being proxied between devices (possibly between machines). KBUS terms such proxies "Limpets". KBUS message headers provide extra fields to help with this, and part of the C library provides helper functions. There are simplified C and Python Limpet examples in the repositories, but they are not suitable for deployment. Ideally, implementations for two of the APIs would be written (C and Python would be simplest).

Design a Javascript API and provide some implementations: One of the obvious uses for KBUS is communicating between a browser and other software. It would be useful to define a "standard" Javascript API. Even more useful would be implementations for some of the commoner Javascript engines.

Investigate use as a reliable low-level driver for DBUS: This was raised as a suggestion at ELCE 2010. The potential should be investigated, and if feasible, a tentative implementation should be attempted.


Related work

and the Kynesim blog has announcements and occasional posts about KBUS

  • The main KBUS documentation can be read

here. An introductory paper prepared for EuroPython2010 is [http://presentations.kbus.googlecode.com/hg/talks/europython2010.html here in HTML], or [http://presentations.kbus.googlecode.com/hg/talks/europython2010.pdf here as PDF]. Other presentations and talks can be found in the presentations repository.

  • I had a showcase table at the ELCE 2010 meeting in Cambridge, giving out this

handout. It has a summary on the front, and some C code on the back.

Scope

Experience shows that I'm not particularly good at estimating, but here goes...

  • Bring all APIs to a consistent level: 4-6 weeks work, depending on the

decision made about the C++ library. This should include updating the KBUS documentation.

  • Provide Poky/OpenEmbedded recipes: For someone with experience of

Poky/OpenEmbedded, presumably a week, including testing and documentation. For someone without such experience, somewhat longer.

  • Provide DEB and RPM packages: I don't have enough experience to quote for

this, but time needs to be allowed for creation of packages for Debian/Ubuntu/MeeGo/Fedora (presumably), possibly at several versions, with adequate testing and provision of a PPA or equivalent, followed by submission upstream. Someone (presumably the candidate) should then provide an ongoing commitment to look after the packages.

  • Provide a good set of examples: This is, by its nature, somewhat unbounded

(so someone should monitor progress!), but I'd suggest an initial 2 weeks for deciding what would be useful, and then at least 2 weeks for coding and documentation.

  • Show/document use with Binder in Android: Start with an allowance of 4

weeks, to produce some solid examples of real use.

  • Provide a Java Message Services API: 2 weeks to produce a good estimate of

feasability and actual requirement, to be followed by a sensible quote for the actual time needed to produce a good implementation.

  • Provide a good Limpet exemplar: I would suggest an initial implementation in

Python, followed by an equivalent using any of the other APIs. Allow 4 weeks for the first implementation, to include good testing and documentation, and 2-4 weeks for the second.

  • Design a Javascript API and provide some implementations: 2 weeks to

document a preferred API. Estimates for particular engines (and choice of which engines are desirable) to be done thereafter.

  • Investigate use as a low-level driver for DBUS: 2-4 weeks for an initial

investigation (depending if the candidate needs to learn how DBUS works), followed by further work if it is deemed a sensible approach.


Contractor Candidates

The obvious candidate for much of this work would be myself (particularly for the first item). Other employees of Kynesim (several of whom have also contributed to or used KBUS) are also obvious candidates. However, if someone else was chosen for some or all of the work, this would be a good thing in spreading knowledge of KBUS, and I would be very happy to give any necessary support.

Comments