Version 4 (modified by Amar Takhar, on Mar 8, 2016 at 1:32:53 AM) (diff)

Finish for now.

RTEMS Database

Note: The RDB has not been deployed yet but will be soon.

The RTEMS database is a central repository that holds all central project data. With this we will be able to have a fully cross-referenced repository of information that goes backwards to the creation of RTEMS to the present. It can also hold data set in the future for releases that have not happened.

There are a central set of 'key' data points that must be filled in on an ongoing process. They are:

  • Architecture
    • List of RTEMS Architectures
  • BSP
  • Board
    • This is not a complete list but will have the ability for users to submit from the website including photos.
  • ChangeLog
    • Rolling list of changes that users will care about.
  • Component
    • Major components of RTEMS. API, Block Devices, Clients, Kernel, Networking, Servers, Shell...
  • CPU
    • Individual CPUs supported
  • CPU Family
    • CPU Family CPUs fall in.
  • Feature
    • A 'Feature' is a general heading such as UDP, TCP, CORBA, PPD, GDB...
  • Learn
    • Database of resources on where and how to learn using RTEMS.
  • News
    • News entries covering all the various RTEMS sites.
  • Orginisation
    • An orginisation is any org that interacts with RTEMS in some way both commercial, other projects and nonprofit. This is keyed to many other data points within the RDB.
  • Project
    • Toplevel key: What project all the resulting data in the DB relates to. This lets us clone all of this work for any projects under the RTEMS umbrella.
  • Release
    • All release versions, maturity and descriptions for RTEMS.
  • Tool
    • Tools can be Simulators, Compilers, Build tools, Doc tools...
  • Tool Type
    • Compiler, Debugger, Documentation, Memory...
  • Types
    • Availability
      • Open Source, Commercial, Dual, Restricted...
    • Architecture
      • All, 32bit, 64bit, PowerPC, Universal...
    • Platform
      • All, Windows, OS X, Unix, Linux FreeBSD...
    • Distribution
      • Source Code, Binary...
    • Change
      • General, Bugfix, Changed Added, Removed...
    • Maturity
      • Nightly, Alpha, Beta, RC, Stable, EoL...
    • AppType
      • Space, Medical, Aviation...

Uses and Explanations

The RDB is used everywhere:

  • Website
  • Test suite
  • Documentation
  • Releases
  • BuildBot

The purpose of having a database such as this is to avoid replicating data and ensure perfect resolution of our main data points. Historically RTEMS has had issues in keeping data up-to-date and accurate. This type of database removes all possibility of data being outdated as it enforces changing the data before the result can be seen.

For example, if we deprecate a release this can be set in the Release table which will automatically mark the release as deprecated in all other areas of the database. The same goes for future releases. If we set the date in the future it will fall under 'upcoming' releases until we edit the DB to set the version as released. This will make it front-and-center for the website, testing and documentation.


All RDB data will be available via a JSON REST API that is self-documenting. This will allow anyone who wishes to use our results and information for their own uses. API keys will not be enforced however monitoring will be done to avoid abuse

All internal tools will use this API to allow for unhooking software from our internal build farm. This will allow everything to run anywhere it wants without making changes. If someone wishes to run their own clone of our software and point it to a new API data host they can do so without any input from us.


The only way to edit the database is via the default Django admin site. It gets the job done all the focus has been put on the frontend. Eventually a nice, AJAX page will be created to ease adding ChangeLog entries as these will be the most edited item.

The admin site is self explanatory and data input is enforced with validation it is very difficult to input incorrect data.