Version 25 (modified by C Rempel, on Apr 9, 2013 at 6:27:25 AM) (diff)

/* Basic Requirements */




Joel Sherrill, Cynthia Rempel


Help Wanted


The chapter has been rewritten to be easier to parse. The decision to go with python has been made.


The GUI attempts to solve the problem of how to make configuring RTEMS in a user-friendly way. Having the GUI automatically generated from either # a Makefile (or Makefiles) and or, # Waf solves the problem of keeping the GUI up-to-date with limited maintainer-hours.

Below is a list of requirements for the application GUI # Written in Python # Allows the user to edit values # Recognize when one of the values is not set # Save its own version of user configuration, and # Generate a .c file which would be used in an application # Must not use "hot dog stand" colors; i.e. look professional # Automatically generated by running a command that uses textual substitution/parsing of


The goal is to have a graphical tool to configure RTEMS for a certain Application e.g. max number of tasks, semaphores etc. It could generate a userconf.h which includes confdefs.h. The complete list of RTEMS configuration parameters for version 4.9.1 of RTEMS are documented in the Configuring a System chapter in the User's Guide.== Project Deliverables (code, docs, testing) ==

= Basic Requirements =

# describing the parameters # saving user selections # generating appconfig.c (arbitrary name) # UI implementation(s) # needs to be shareable in a computer manner between the users guide and the Configuration Tool.

All user dialogs need to be generated based on descriptions of the parameters. There can be no hard-coding of menu options. If we add or delete a parameter, this should just fall out naturally from the descriptions.

There needs to be a file format to save user selections. This file format needs to be the same independent of UI. The user should be able to generate a configuration, come back later, load it, edit it, and regenerate C code.

The UI must be portable between all major platforms including Linux, *BSD, MacOS, and Windows.

And any transformation between Users Guide and UI configuration parameter must likely be command line.

The UI (4.) could be a command line tools to transform (2.) which is in ASCII into a C file to be compiled. But the UI could also be a TUI (Text User Interface) using ncurses or true GUI using Python.

Ultimately the definition of (1.)-(3.) make it possible to implement multiple UIs. But we need a simple portable one first that assumes little. I assume that means a TUI and next a GUI.

If you are clever, you can do all of this with some transformation and magic of reading files and generating various dialogs in TUI and GUI form.


# A script to generate the GUI # A Makefile/Makefiles? to run the script # A generated GUI # Header files showing: the default, slightly modified default, and major configuration changes # A modified that's trivial to parse, but still generates informative HTML, each configuration item should clearly describe:

  • The Constant Name
  • Type: integer, defined, address, etc.
  • Default Values:
  • Range:
  • Description:
  • Notes


# A tutorial for adding additional functionality is provided, and the code is commented enough to enable additional functionality # A tutorial for using the GUI is provided # is commented so that developers will keep conf.t easy to parse== Testing ==

# Generate the files in the Code section

Required / Suggested Methodology

# (Suggested) Start with an existing open source project that generates configurations, for example: dialog, xpresser, system config printer, or wbarconf. Note: these are just examples that illustrate there are already projects out there, but if another project has a preferred configuration GUI written in Python it can be used as a starting point as well. # (Suggested) Identify patterns in the open source project for how it writes configurations # (Required) Rewrite so it's trivial to use textual substitution to generate parts of the configuration GUI from them, and thus the trivial textual substitution will be easier to maintain # (Suggested) Use a template approach, automatically generate from, and have a file (or files) for the top, and a file (or files) for the bottom. # (Required) Generate configuration support from

Standards of Quality

# The GUI generating script runs on Fedora (this is the Linux distribution RTEMS provides support on) # The GUI generating script can be run from a Makefile. # The GUI generating script is open source and resulting GUI is written in a Python version that runs on 32-bit Debian 6.0.6 (stability oriented distribution), 64-bit Fedora (cutting edge distribution), MacOS, Windows cmd.exe (probably should be geared towards Windows 7, but might be tested on Vista, Server 2008, or 8)... # The GUI only generates headers with documented configuration constants from the C user's guide. # is modified to be easy to parse (i.e. the parser is trivial to write). # The GUI generates headers for all documented configuration constants in the C user's guide. # The GUI runs on 32-bit Debian 6.0.6 (stability oriented distribution), 64-bit Fedora (cutting edge distribution), MacOS, Windows cmd.exe.

Possible Goal Extensions beyond the Main Objective

# Add to the Makefile a check for whether the required libraries/headers were on a system, and if not, install them. # Copy the script and modify the copy to use another approach, for example: if an Eclipse Wizard was generated, re implement to generate the a Linux kernel config infrastructure. # Work on the RTEMS ConfigKit?. # Hook the Application Configuration GUI into the RTEMS source tree, by putting into # Package the GUI so that it includes the libraries it depends on, for example, if the GUI uses GTK+, the GUI would ship with GTK+

Skills Required

The level of expertise required by the developer tackling this project will have to have: # Prior experience with bash/Makefile scripting, C preprocessor, texinfo, and textual substitution is not required, but moderate skill level will be acquired while completing this task # The ability to read an open source programming language is highly desired # No mathematical/algorithmic background is required # An interest in finding and modifying code from existing open-source projects to meet this need is a big plus

There are a variety of ways to approach this project.

  • One solution is to write a GUI in Python. This should be cross-platform.
  • Another solution could be a Wizard/Editor? for Eclipse.
  • Another solution is to use the config infrastructure used by the GNU/Linux kernel.
  • Another approach would be to use the configuration GUI from eCos and NutOS:

There is NO consensus on how best to approach this project and you must convince the community that your approach will be the right one.

JoelSherrill has used the GNU/Linux kernel config infrastructure for similar projects in the past and things it is likely the best alternative as a baseline. This would certainly provide multiple interfaces on GNU/Linux hosts (e.g. X11, menu, command line). But we would like a solution that also addresses MS-Windows users.

A better possibility is to write a GUI program in Python which reads an XML format file describing the RTEMS configuration parameters. As the user set values, the program would store this information in another XML format file. When it was time to write the C code to use with the RTEMS application, the GUI application would write that. So we would have:

  • XML file describing RTEMS configuration parameters
  • XML save file with user settings
  • C/H file output for use with RTEMS application= References =

# Some Design work # Python Config Parser Examples : The python config parser can read and write config files.