Skip to content

Development History

Jump to bottom
Elliott Hillary edited this page Mar 17, 2015 · 1 revision

The Subversion days

When KBUS was first distributed via Google Code, we used a subversion repository. The contents of this are preserved in the later Mercurial and Git schemes as the legacy repository.

Early history

  • version 0.1 (tagged on 8 Dec 2009) was the "old stable" version. In case you need it, the revision control tag is v0-1 in the legacy repository.

  • version 0.2 (tagged 27 Jan 2010) is the last version with the old KBUS message datastructure. It contains preliminary work for Replier Bind Events. The revision control tag is v0-2, again in the legacy repository.

Version 0.3

Revisions after version 0.2 have:

  • a different KBUS message header (specifically, there are be some extra header fields). The KBUS message header start guard has been changed in the new message headers.
  • a different API for the C library, libkbus
  • preliminary Limpet support, for peer-to-peer messaging (this is alpha code until it has been tested in real applications)

version 0.3 (tagged v0-3 on 22 Feb 2010, in the legacy repository) is the last version to impose a limit on the size of "entire" messages, when writing to KBUS devices. The revision after fixes issue 26, and allows writing "entire" messages of arbitrary size. It also makes a minor change to the C library API, as "short" functions become "entire" functions (again).

Revision 339 (in the Subversion repository) makes message names reference counted (as message data already was), and also rearranges the in-kernel storage of messages. This should be a good thing, may be slightly faster, and may have introduced newer bugs.

Using Mercurial

After version 0.3 the repository was converted to Mercurial, then split up into a handful of sub-repositories. Older tags were removed from the default repository and placeholders v0-1-partial (etc.) left in their place.

The motivation for this was that it was a bit unfriendly to force users to clone a repo containing the bulky talks and slides material.

The project repositories now look like this:

  • [default]: libkbus, cppkbus, jkbus, python, utils, docs source, init.d. Pulls in 'kernel' as an hg subrepo.
  • kernel: Just the kernel module, with a Makefile for building outside of the Linux kernel tree.
  • html: Built HTML docs. Pulls in default as an hg subrepo.
  • presentations: The contents of talks/ and slides/ moved here.

The kernel module was also cloned onto github, in preparation for submission to the Linux kernel maintainers. Specific repositories were:

...unfortunately it looks as if the kernel submission has been abandoned. However, the work required for it, and the advice from the LKML has been invaluable in making the kernel module a better piece of code.

Now in Git

The github work has now been merged back into the mainline KBUS repositories, and this has also been taken as an opportunity to move to using Git as a VCS.

Our repositories are now

  • "default" - a single repository for both userspace and kernel code. This combines the Mercurial "default" and kernel repositories, with the github changes integrated. The repository thus has two "tails" - one representing the "default" (userspace) repository and the other the kernel repository - which join together to form the current HEAD. Note that the github 1- through 5- branches are also preserved. Tags which were previous called something-partial are now called kernel-something or userspace-something.
  • wiki - the wiki, containing this very page
  • presentations - the same content as the Mercurial repository of the same name
  • legacy - the same content as the Mercurial repository of the same name, and thus the same content as the original Subversion repository.

The Mercurial "html" repository is no longer needed, as documentation is now automatically generated by the wonderful ReadTheDocs at http://kbus.readthedocs.org/.

Why did we re-unite the userspace and kernel repositories?

  • Mercurial's subrepo support is much more sophisticated, and simpler to use, then Git's submodule support.
  • In our actual use of the project in-house it is a lot more convenient to have a single repository.
  • Any user of either kernel or userspace KBUS needs at least one common header file, so we'd otherwise have to duplicate that.
  • If we're not actually getting KBUS into the kernel sources, there is less pressure to have the kernel code be separate.

The post-split repositories are likely to be tagged v0-4 once the integration work and tests are complete.

Why did we move to Git?

Mostly personal preference. It's the VCS we're most comfortable with (although note that Mercurial's support for Git repositories seems to be rather good).

Accessing the old repositories

The original Subversion repository is still (directly) accessible, as https://kbus.googlecode.com/svn/.

I'd rather assumed that the Mercurial repositories would still be accessible as well, but this doesn't appear to be the case. However, I've uplodaed copies to obviously named repositories at https://bitbucket.org/tibs in case they're ever needed (well, I didn't bother with the html repository).

Clone this wiki locally