= Open Projects = Welcome! Whether you're here because of [wiki:GSoC Summer of Code (SOC)] or just want to scratch an itch to hack, we invite you to peruse our projects and ask about them on the [wiki:TBR/Website/RTEMSMailingLists RTEMS mailing list] or [wiki:Developer/IRC IRC]. If you plan to submit a proposal to do something for the RTEMS Project as part of a SOC, see [wiki:GSoC/GettingStarted Getting Started for SoC Students]. RTEMS projects span kernel hacking, adding support for a new board (BSP), improving the development environment, developing tests, and more. If you want to get your feet wet with RTEMS then check out our [wiki:Developer/SmallProjects 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! 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. Many RTEMS projects are done by student or volunteer coders, so we try to define small projects or subtasks that can be completed and committed individually. Most of the projects are feasible as a [wiki:GSoC Summer of Code] project. Since some projects have multiple steps, students should work with prospective mentors to define the scope of work in their proposal. Similarly, some projects might be a starting point for a class project or graduate thesis. [[TOC(Developer/OpenProjects, depth=2)]] = Overview = 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, solicit feedback from the project's [wiki:TBR/Website/RTEMSMailingLists mailing list] or [wiki:Developer/IRC IRC channel]; many developers sit in IRC and check it (and their email) infrequently throughout the day, so be patient! There may or may not be enough work on a project to constitute an SOC project, and some of these are past SOC projects. If you are interested in one of these, please ask on the mailing list or IRC. Projects in '''Bold text''' are '''higher priority''' simply meaning that users or developers have expressed a lot of interest in such projects. Projects in ''Italic text'' have ''had some work done'' and may need an updated description, might be complete already, and may or may not have sufficient work remaining. If you have a new project add it to the appropriate list below, link to a wiki page that uses the [wiki:PageTemplates/ProjectDescriptionTemplate Open Project Template], and briefly (1-2 sentences) summarize the project and how it will improve RTEMS. If one of the projects sounds interesting, but lacks detail, ask on an RTEMS mailing list for details and we can all help scope the project. = 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: * ''[wiki:Projects/TestingImprovements RTEMS Testing]. Testing for RTEMS, including Unit, Regression operational and building a custom test harness. No prior knowledge of software testing is required. (SOCIS)'' * [wiki:Developer/Testing/Specifications RTEMS Test Specification] - Need a formal test specification. Ideally, inspired by http://softwaretestingstandard.org/ some notes about existing test specifications can be found http://www.rtems.org/wiki/index.php/GoogleCodeInProjects#Test_Documentation_Files_update . * [wiki:RTEMS_Test_Screen_Validation RTEMS Test Screen Validation] - This requires expertise in a unit testing framework, probably DejaGnu, and will probably need to be tied into [http://git.rtems.org/rtems-testing/ rtems-testing] and [http://git.rtems.org/rtems-tools/ rtems-tools]. * '''[wiki:TBR/UserManual/RTEMS_Coverage_Analysis Test Coverage Analysis]''' - In general, there are specific areas that need actual tests written and areas in which the RTEMS Project tools need work to improve our testing ability. Look until Tools and Development Environment for those projects. This section focuses on improvements to coverage by adding more test cases, reworking code to eliminate the need for additional test cases, etc.. Eliminating dead code and reaching 100% coverage helps reduce the likelihood of new and recurrent bugs. * [wiki:Projects/Open/SimulatorUpdates Simulator Updates] - Test BSPs that target simulators to find and fix problems. It is important to ensure that BSPs which run on simulators pass all tests possible. * [wiki:Projects/GNUToolsTesting Testing of the GNU Tools] - Improve Tools Testing on RTEMS targets * [wiki:Projects/POSIXFIFOs POSIX FIFO tests] - Implement tests for FIFOs. * ''[wiki:TBR/Delete/POSIXTimingTests POSIX Timing Tests]'' - Many have been implemented but there should be more cases worth timing. Precise status is stored in a .csv file in the psxtmtests directory in the source tree. * ''[wiki:Projects/POSIXComplianceTestSuite POSIX Compliance Test Suite]'' There are multiple aspects to this project. One aspect is the addition of interface compliance tests for rest of POSIX API. Another part is running third party C Library and POSIX API tests (e.g. from glibc, *BSD, or the older Intel POSIX suite) against RTEMS and newlib. Ultimately, we would like functional coverage test results on newlib as well as RTEMS. Results of third party existing tests would have to be carefully evaluated to ensure appropriateness and results. Related: Improve the POSIX API Compliance test (testsuites/psxtests/psxhdrs). Details described in Ticket #2262. * [wiki:GSoC/Projects/TestTemplate RTEMS Test Template] - Improve by adding functionality * [wiki:TBR/Delete/Fault_injection Fault tolerance]: get a fault injection tool to work with RTEMS and create tutorials and examples. = Tools and Development Environment = 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: * [wiki:Projects/Open/StackAnalysis Static Analysis of Stack Usage] - Develop a tool for static analysis of stack usage. * [wiki:Projects/Open/PythonCoverageReporting Python Coverage Reporting] - Convert coverage reporting to Python and integrate into RTEMS Tools. * '''[wiki:Projects/Open/TesterImprovements RTEMS Test Improvements]''' - Improve RTEMS Tester (rtems-test) by adding simulator recipes for more simulators. * [wiki:Projects/Open/GCovReports GCov Reports] - Use gcov output as generated by covoar to generate useful reports. * [wiki:Projects/Open/GProfReports GProf Reports] - Use gprof output as generated by covoar to generate useful reports. * [wiki:Projects/Open/ImproveRSB Improve RSB] - General improvements to the [wiki:TBR/UserManual/RTEMS_Source_Builder RTEMS Source Builder]. * [wiki:Projects/Open/ImproveEclipsePlugin Improve Eclipse Plugin] - Improvements in the [wiki:Developer/Eclipse/Information RTEMS Eclipse Integration]. * [wiki:Projects/Open/UsingClang Using clang] - Compiling RTEMS with [wiki:Projects/CLANG CLANG]. * ''[wiki:Projects/Open/MergeLEON Merge Leon]'' - Merging Gaisler LEON support code into mainstream RTEMS. * [wiki:Projects/Open/EVisualStudio eVisual Studio] - Integration of RTEMS cross development environment into eVisual Studio. * [wiki:Projects/Open/ArgoUML] - UML for RTEMS. * [wiki:Projects/Open/PyGDB Python GDB Support] - Add Python Script support for debugging RTEMS with GDB. = RTEMS Run-Time Oriented = The projects in this category are more focused on the development of software that runs on RTEMS on target hardware. = Executive (!SuperCore, SuperCoreCPU, libcpu): a.k.a. kernel = * ''[wiki:Developer/SMP Improvements to SMP support]'' - Multiprocessing is of increasing importance. This is a large project and subtasks should be identified before writing any proposal. * '''[wiki:Projects/Condition_Variables Condition Variables]''' for the Classic API and supercore. * Unified Interrupt and PCI APIs -- [wiki:GSoC/2013/UnifiedAPIs UnifiedAPIs] * '''[wiki:Projects/RumpKernels Rump Kernels]''': provide the hypercall interface for [http://rumpkernel.org/ Rump Kernels] in RTEMS. * Nested Mutexes: See Ticket #2124 for a problem description. * [wiki:Projects/SystemEvents kqueue(2) or taskqueue(9)] is a project to port the kqueue(2) or taskqueue(9) API from FreeBSD. * [wiki:Projects/TinyRTEMS 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. * ''[wiki:Projects/Paravirtualization Paravirtualization]'' of RTEMS to make it suitable to be run as a guest OS in a hypervisor. * ''[wiki:Projects/SequencedInitialization 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. * ''[wiki:GSoC/2011/ISO9660_Filesystem ISO9660 file system]'' = Debugging = * '''[wiki:Projects/TraceTool Run-Time Tracing]''' - includes gathering, capturing, and displaying information to the user. We are looking for more trace improvements and visualization. * [wiki:Projects/CPU_Statistics CPU Statistics] - Improvements to CPU Usage Statistics. * [wiki:Projects/Open/StackChecker Stack Checker] - Improvements to Stack Bounds Checker. = Board Support Package (BSP) = * ''[wiki:Projects/GSoC/Beagle Beagle BSP improvements]'' - More peripherals for the Beagleboard / Beaglebone BSP and other improvements * ''[wiki:TBR/BSP/Raspberry_Pi_BSP_Peripherals Raspberry Pi BSP Peripherals]'' Add peripheral support to the Raspberry Pi BSP. We still want more peripherals for Raspberry Pi * VESA x86 BIOS - This is Pavel Pisa's idea. * Port RTEMS to Microblaze (new architecture port, not just BSP) w/BSP for GDB simulator. Also needs BSP for more complete HW on simulator. * RTEMS can always use [wiki:TBR/Delete/MoreBSPsForSimulators more BSPs for Simulators] and readily available boards or open cores. * ''[wiki:Projects/MMU_Support MMU Support]'' Implement MMU low-level support code for more BSPs. * Raspberry Pi2 - on hold due to unavailability of open information * x86 Edison - on hold due to unavailability of open information = API Layers (POSIX, Classic, SAPI) = * Make rename() implementation POSIX conformant * Implement OSEK Support [http://portal.osek-vdx.org/] * Investigate the feasibility of implementing applicable sections of the [http://en.wikipedia.org/wiki/IEC_61131 IEC 61131] standard to enable RTEMS-enabled hardware to act as a [http://en.wikipedia.org/wiki/Programmable_logic_controller 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. * ''ARINC653 API support within RTEMS [wiki:Projects/GSoC/ARINC653API ARINC653API]'' * ''[wiki:Projects/POSIX_Methods_in_NewLib_RTEMS_improvements POSIX Methods in NewLib RTEMS improvements]'' make methods in RTEMS and !NewLib more POSIX compliant (SOCIS) = rtems-libbsd = * ''[wiki:Projects/TCP/IP_update Update the RTEMS TCP/IP stack]'' - The networking stack in the main source tree is old and showing it. This project is 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 may be appropriate for SOC. Given that the stack is working now along with USB, ask about possibilities about Ethernet over USB and Wifi support. * ''[wiki:TBR/UserManual/USBStack port BSD USB stack]'' - This project is complete for some device types. Needs documentation and possible addition of other device types. = Languages = * [wiki:Projects/Mono Mono On RTEMS] * Port the [http://code.google.com/p/v8/ Javascript V8 engine] to RTEMS. V8 is high performance !JavaScript engine written in C++ and embeddable in C++ applications. With V8 it would be easier to build web servers with javascript and even run js framework node.js. = Libraries and Applications = * Port the [http://monkey-project.com/ Monkey HTTP Server] and supporting infrastructure to RTEMS. Beyond simple porting, this includes submitting patches as needed to the Monkey project, providing a recipe for the RSB, an example and any instructions needed. * Identify and implement the functionality currently missing in dup() * Port Transparent IPC (http://tipc.sourceforge.net/index.html) to RTEMS * Implement a [wiki:Projects/Open/LineEditor Simple Line Editor]. Existing code can be refactored for a starting point. * ''[wiki:Dynamic_Object_File_Loading_ Dynamic Object File Loading (RTL)]'' 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. * '''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 toolkits in general. The eventual goal is to have these toolkits buildable by the RTEMS Source Builder. Here are the toolkits areas identified so far: * Define a generic (RTEMS Source Builder based) infrastructure for building and maintaining toolkits. * [wiki:Projects/BenchmarkKit RTEMS BenchKit] - benchmark programs for RTEMS * [wiki:Projects/ApplicationConfigurationKit RTEMS ConfigKit] - configuration file parsing libraries * [wiki:Projects/DatabaseKit RTEMS DBKit] - database packages * [wiki:Projects/GraphicsToolkit RTEMSGraphicsToolkit] - various graphics and video processing. This kit has had some work done on it. * [wiki:Projects/ScienceKit RTEMS SciKit] - libraries of general use to the scientific community RTEMS users * [wiki:Projects/ScriptKit RTEMS ScriptKit] - packages for scripting languages such as Python and Lua * [wiki:Projects/WebKit RTEMS WebKit] - packages for networked devices. * Turn the current port of [wiki:Packages/LWIP LWIP] into a first class citizen that RSB can build. Submit port, make target independent, create maintenance plan. * [wiki:TBR/Delete/IDL_COM IDL/COM] Support for RTEMS. * [wiki:Projects/PortAPackage Make Addon Package] - write a tool to help other developers with ''Libraries, Languages, and Applications'' = Retired Projects = The following projects are complete or pending. * Testing * [wiki:Testing/Filesystem File System Test Suite] * Tools * [wiki:Projects/GSoC/ApplicationConfigurationGUI Application Configuration GUI]. * Runtime * [wiki:Projects/SixtyFourBitTimestamps Sixty-Four Bit Timestamps] * [wiki:Projects/Refactor_the_filesystem_infrastructure Refactor the filesystem infrastructure] * Use [wiki:TBR/Delete/UseHashOrMapInNotepadsAndKeys Maps or Hashes] in the implementation of Classic API Notepads and POSIX API Keys. * [wiki:Projects/GSoC/Bdbuf_improvements Bdbuf improvements]. The current block device buffer implementation can benefit from a number of improvements. * Improve the RTEMS [wiki:Projects/Scheduler SuperCore Scheduler] * Languages * [wiki:Projects/Parrot Parrot On RTEMS] * [wiki:Projects/GCCGoRTEMS GNU GCC Go] * RTEMS port of the [wiki:Projects/GNUJavaCompiler GNU Java Compiler (gjc)] * Lua in RTEMS * [wiki:Projects/GSoC/OpenRISC Porting RTEMS to OpenRISC]. * ''Implement [wiki:Projects/POSIX_Asynchronous_IO POSIX Asynchronous and List IO]'' = 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 [wiki:Projects/Hypervisor hypervisor]. The lack of protected (kernel mode) execution precludes any feasible implementations. * Merge [wiki:Developer/Simulators/SimpleScalar BSP for Simplescalar simulator]. The BSP is heavily bit-rotted and the simulator is a dead project. * [http://code.google.com/p/rosetta-os Rosetta OS] [wiki:Projects/RosettaOSDeviceDriverAPI 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. * More [[TBR/Delete/Libbsd-port| NIC device drivers]]. See instead [wiki:Projects/TCP/IP_update TCP/IP update]. * Integrate [wiki:Projects/CEXP CEXP] into main RTEMS distribution. Possible licensing issues, please apply to the RTL project instead. * Scripts and documentation for creating and installing prebuilt tool packages [wiki:Building/RPM_Packages Building Tool RPM Packages], [[Building/DebianHostedTools| Debian Packages]], [[TBR/Delete/MacOSHostedTools|MacOS tools]], [wiki:TBR/UserManual/MinGW_Tools_for_Windows MinGW Tools for Windows], [wiki:TBR/Delete/Canadian_Cross_Compiler Canadian Cross Compiler]. Please apply to the [[RSB]] project instead.