Skip to content

Home

Jump to bottom
Daniel Waddington edited this page Nov 9, 2018 · 11 revisions

Comanche

Comanche is a research project that is being maintained by IBM Research, Almaden. As such, the code is not product quality and should only be used for experimentation and further exploration. The code base is active and rapidly evolving; backward compatibility will not be an aim at this stage.

Contributions and collaborations are welcome. Clean up and improvements are always welcome!

Quick Links

Introduction

The advent of high-performance NVMe (e.g., Optane) and the imminent availability of NV-DIMM (e.g., Apache Pass) is driving the need to rethink the Operating System and IO path design. The vision of Comanche is to provide a flexible framework that allows custom storage solutions to be easily composed and aligned to the application's needs.

The basic premises of the project are:

  1. Use of user-level, kernel-bypass approaches enables improves performance through context switch avoidance and improved resource control.
  2. Building IO layers in user-space allows a richer software development capability through extensive library availability and the ability to support other programming languages.
  3. Tailoring lightweight IO stacks to application requirements improves performance and scaling.

Comanche is not aimed at generalized solutions - it assumes some understanding of the application requirements.

Vision

The long term vision of the project is to allow uses to easily compose IO stacks according to their needs. This model could be applied in both a local and distributed sense. Imagine we can deploy 'IO pods' into the cloud that adapt to underlying hardware resources and can be easily composed into powerful peer-to-peer distributed data services. Imagine the Python developer being able to add auditing, logging, encryption, transformation layers to their IO stacks. Imagine integrating and adapting to fast NVMe and NV-DIMM hardware resources.

Contributors

Contributor Guidelines

  • Work on forked branch and make upstream requests through git Pull-Requests.

  • Components everywhere. Comanche components are in-process COM-like components that can be dynamically bound. They provide a standard base interface for interface management and reference counting. Components should not have inter-component source dependencies other than the interface description header and the component UUID (api/components.h).

  • Keep it simple. Strive to keep maintain simplicity whenever possible.

  • Use Google test framework for unit tests. Component unit tests are in the directory unit_test.

  • C++ style guide - https://genode.org/documentation/developer-resources/coding_style

  • Releases are kept on 'master' branch. Pre-releases on the 'unstable' branch.

Clone this wiki locally