Version 285 (modified by Gedare, on 02/06/13 at 21:14:58) (diff) |
---|
Open Projects
Welcome Summer of Code (SOC) Students and hackers. Peruse our projects, and if you have questions ask on the RTEMS mailing list or IRC. If you plan to submit a proposal to do something for the RTEMS Project as part of a SOC, see Getting Started for SoC Students for our SOC getting started guide. RTEMS projects span kernel hacking, adding support for a new board (BSP), improving the development environment, developing tests, and more.
If you are looking to get your feet wet with RTEMS then check out our small projects page? where you can find projects that require little coding skill and are appropriate for those new to RTEMS or open source software projects. If you are interested in one of these projects but are not able to code and test it yourself, consider sponsoring one of the core RTEMS developers to do it for you. Volunteering or sponsoring is how things get done -- users keep RTEMS development alive!
Table of Contents
<!-- Comment out SOCIS material until next SOCIS= ESA SOCIS 2012 =
If you are looking for project ideas for ESA SOCIS, then we would like to highlight some projects which we believe are particularly relevant to the space community.
- Test Coverage Analysis? - Improve coverage by adding more test cases. Eliminating dead code and reaching 100% coverage helps reduce the likelihood of new and recurrent bugs.
- Simulator Updates - This is a new idea for a project and has not been described beyond what is here. Ask on the rtems-devel mailing list for more advice. The RTEMS Project relies heavily on multiple FOSS simulators including qemu and skyeye. We have multiple BSPs which are tested on simulators. Each BSP will need to be tested against the current release and development version of each simulator. If there is a problem, then the issue will have to be identified (possibly using something like git bisect) and the student will have to fix it in the simulator. As an example of this, we believe some ARM BSPs which worked on older versions of Skyeye no longer work on the current version. In some cases, the RTEMS Project is carrying unmerged patches for a simulator (at least qemu m68k and arm) which need to be updated to their development head and submitted. You will try to get the simulator developers to include RTEMS hello world and ticker executables for BSPs their simulator supports in their simulator tests to avoid future breakage. And you will ensure that the scripts in rtems-testing/sim-scripts are working for the latest version of the simulator. We would also like instructions on running the leon BSPs on qemu. Please ask questions. This is a broad project.
There may be other projects on this page which are of interest to the space community. If you are interested in one that is properly sized, email us and ask.
SMP improvements are important to the space community but, to the best of our knowledge, there is no free simulator for the LEON3 which is the primary target for this community. -->
Overview
Most of these projects will take between a few weeks and a few months of effort by a person who is familiar with the general use of GNU/Linux and GNU tools. Some of these projects may consist of multiple steps, and we try to define short steps and subtasks for larger projects. Many RTEMS projects are done as student or volunteer efforts, so projects must be relatively small or divided into steps that can be completed and committed individually. Our mentors have lots of experience in defining useful suitably-sized projects and we try to identify projects that we think are beyond the scope of an SOC.
Most of the projects are feasible as a Summer of Code project. Since some projects have multiple steps, students should work with prospective mentors to determine how many steps to undertake. Similarly, some projects might be a starting point for a class project or graduate thesis.
The order of projects in the list does not reflect their importance, difficulty, or feasibility. Our project list is not exclusive: if you have an idea please ask the RTEMS community if your idea is good. Ask on the project's mailing list or IRC channel; many developers sit in IRC and check it (and their email) infrequently throughout the day, so be patient!
If you have a new project add it to the appropriate list below, link to a wiki page that follows the recommended Open Project Template?, and briefly (1-2 sentences) summarize the project and how it will improve RTEMS.
High Priority Projects
These projects have generated a lot of interest from users and are greatly desired. Most of these are large or ongoing projects that should be broken into manageable subtasks that may constitute reasonable sized projects themselves. Definitely ask before proposing to do any of these projects.
- Improvements to SMP support? - Multiprocessing is of increasing importance in modern systems and we want RTEMS to remain competitive and useful. This is a large project and subtasks should be identified before writing any proposal.
- Implement or integrate Atomic Operations. SMP code requires additional synchronization primitives that are not available currently in RTEMS.
- Test Coverage Analysis? - Improve coverage by adding more test cases. Eliminating dead code and reaching 100% coverage helps reduce the likelihood of new and recurrent bugs.
- Update the RTEMS TCP/IP stack? - The networking stack is old and showing it. This project actively underway. At a high level, this effort requires porting the TCP/IP stack and providing support functional equivalents of multiple BSD kernel constructs. This project has many subprojects many of which are appropriate for SOC. It would be of great usefulness to the community to get as many of these does as an SOC project as possible.
- RTEMS Toolkits - We are defining collections of libraries and support programs which make it easier to get started for certain types of applications. We haven't identified all potential toolkits or components. Each potential component must be evaluated for license and appropriateness for use in an embedded environment like RTEMS. We also should define some guidelines about creating and maintaining these kits. Here are the toolkits areas identified so far:
- RTEMS ConfigKit - configuration file parsing libraries
- RTEMS DBKit - database packages
- RTEMSGraphicsToolkit - various graphics and video processing. This kit has had some work done on it.
- RTEMS SciKit - libraries of general use to the scientific community RTEMS users
- RTEMS ScriptKit - packages for scripting languages such as Python and Lua
- RTEMS WebKit - packages for networked devices.
Testing
Testing a large body of software like RTEMS is in a continual state of improvement. There is always a need for more test cases and easier ways to run them all and decode the results. In addition, we want to be able to run all tests on as many hardware and simulator configurations as possible. Testing doesn't sound exciting to most people but when you combine the breadth of what we need to test with our desire for 100% instruction and branch path coverage, you get some very interesting and challenging work.
Some of the identified activities which would augment our testing capabilities are listed here:
- RTEMS Testing?. Testing for RTEMS, including Unit, Regression operational and building a custom test harness. No prior knowledge of software testing is required.
- Test the POSIX FIFO Implementation?.
- Add support for gprof output to covoar?
- Improve Testing of the GNU Tools? on RTEMS targets
- RTEMS BenchKit - benchmark programs for RTEMS
Development Environment Oriented
RTEMS applications are cross-compiled on a development host to produce executables that are transferred to and executed on target systems. The projects in this section focus on the host side of that equation. This means they will run on a developer's computer and possibly communicate with embedded hardware.
The following areas have been identified for projects related to improving RTEMS development:
- Improvements in the RTEMS Eclipse Integration
- Implement a cross-platform Application Configuration GUI.
- Integration of RTEMS cross development environment into eVisual Studio?
- ArgoUML RTEMS Support?
- GDB Python Script support for RTEMS
- Scripts and documentation for creating and installing prebuilt tool packages:
RTEMS Run-Time Oriented
The projects in this category are more focused on the development of software that runs on RTEMS on target hardware.
Run-Time Projects Not Initiated
The following projects have no work on them.
- Unified Interrupt and PCI APIs -- UnifiedAPIs?
- Use Maps or Hashes? in the implementation of Classic API Notepads and POSIX API Keys.
- RTEMS can always use more BSPs for Simulators?. Being able to test, debug, and perform coverage analysis on simulators is critical to the ongoing success of the project.
- Identify and implement the functionality currently missing in dup()
- Implement a Simple Line Editor. Existing code can be refactored for starting point.
- RTEMS System Events is a project to add a first class object for events. Currently all event sets are tied to a specific thread.
- Implement OSEK Support http://portal.osek-vdx.org/
- Port Transparent IPC (http://tipc.sourceforge.net/index.html) to RTEMS
- Support for new Processor Families - Xtensa, Microblaze
- Add cache manager support for architectures not having it.
- Investigate the feasibility of implementing applicable sections of the IEC 61131 standard to enable RTEMS-enabled hardware to act as a Programmable Logic Controller. More information on the IEC 61131 standard can be found at http://www.plcopen.org/ . http://www.beremiz.org/ is an open source framework for automation that may be a useful starting point.
- Bdbuf improvements. The current block device buffer implementation can benefit from a number of improvements.
- ARINC653 API support within RTEMS ARINC653API?
Run-Time Projects With Some Work
The following projects have had some work on them but are not complete. Ask about the current progress on the mailing list. The remaining activities could be large or small:
- Paravirtualization? of RTEMS to make it suitable to be run as a guest OS in a hypervisor.
- MMU Support? for RTEMS.
- TinyRTEMS is an umbrella term that corresponds to any activities or ideas that could shrink the code and data space requirements for RTEMS. The goal is to progressively lower the minimum CPU requirements.
- Improve the RTEMS SuperCore Scheduler? - near complete
- more NIC device drivers?
Third Party Packages
This is a list of projects related to third party free and open source software and its support for RTEMS. The following project areas have been identified:
- Compiling RTEMS with CLANG.
- Integrate CEXP? into main RTEMS distribution.
- Mono On RTEMS?
- Turn the current port of LWIP into a first class citizen. Submit port, make target independent, etc.
- IDL/COM? Support for RTEMS.
Projects Whose Page Need Updating
The following projects have been worked on and the pages require updating. There may or may not be enough work remaining to constitute an SOC project; many of these are past SOC projects. If you are interested in one of these, please ask on the mailing list or IRC.
- Implement POSIX Asynchronous and List IO?
- Run-Time Tracing? - includes gathering, capturing, and displaying information to the user.
- RTEMS Sequenced Initialization is a project to allow RTEMS initialization to be dynamically constructed based upon user requirements. It would be like C++ global constructors conceptually.
- Dynamic Object File Loading lets a base application with RTEMS dynamically load the rest of the application. The dynamic parts can be optional features and never loaded, or upgraded replacements for parts of the application.
- port BSD USB stack
- Parrot On RTEMS
- RTEMS port of GNU GCC Go?
- File System Test Suite
- POSIX Timing Tests?
- ISO9660 file system
- RTEMS port of the GNU Java Compiler (gjc)
- Add support for gcov output? to covoar so tools like gcov and lcov can be used with RTEMS (another page here)
- POSIX Compliance Test Suite?
- Sixty-Four Bit Timestamps
- Refactor the filesystem infrastructure
Obsolete Projects
Some projects have been proposed that are viewed as being of minor use. This list is meant to provide a way to avoid wasted effort on projects that are not widely desired. However, projects on this list might still be useful to someone, given a motivated individual to work on them.
- Various ideas have been proposed related to using RTEMS as a hypervisor?. The lack of protected (kernel mode) execution precludes any feasible implementations.
- Merge BSP for Simplescalar simulator?. The BSP is heavily bit-rotted and the simulator is a dead project.
- Rosetta OS OS Independent Device Driver API?
- Implement current version of µITRON Interface http://www.www.tron.org/index-e.html. itron support was removed from RTEMS due to lack of interest.