Latest Automatically Built Documentation: http://www.rtems.org/onlinedocs/doc-current/share/rtems/html/
This page is a rough development plan for RTEMS 4.10. The goal of this page is to capture ideas for enhancements and let people commit to implementing them for 4.10. We succeeded in getting from 4.8 to 4.9 in much less time than from 4.6 to 4.7 or from 4.7 to 4.8. As I write this (10 Aug 2008), it looks like we are within a week of branching 4.9. Ideally 4.10 will happen 6 to 9 months after the release of 4.9.0 which should have us aiming for in the first part of 2009. This obviously depends on the RTEMS Community and the submission levels. We want to set specific goals and find a branch point once a minimum set is implemented and stable.
The proposals are divided into sections for likely and candidate ideas.
- Likely means that someone has expressed a commitment to implementing it.
- Possible indicates suggested but no firm commitment.
- WishList? indicates an idea that is believed to take enough effort that it is unlikely to be in a 4.8 branch.. But if someone comes through, it is welcomed. :)
If you are willing to implement something and have a reasonable chance of doint it before the end of the calendar year, move that item from Possible to Likely and add yourself as committed to implementing it.
If you suggest something or commit to implementing it, please put your name with it.
The toolset will be an updated version of what is used with RTEMS 4.8 now.
- autoconf - CVS HEAD currently requires Autoconf 2.61
- automake - CVS HEAD currently requires Automake 1.10
- binutils - releases are relatively infrequent so it may be the same base version as 4.9
- gdb - releases are relatively infrequent so it may be the same base version as 4.9
- gcc - releases are frequent enough so we can expect to be at least 4.4. I (Joel) have been testing multilibbed Ada on the pre-4.4 SVN trunk with good results so we may finally be looking at having Ada RPMs again.
newlib - Proposed RTEMS changes (e.g. newlib thread exit cleanup modifications and file locking) will require modifications in newlib. newlib traditionally has a release in December or January so we want our changes done in time for that. RTEMS 4.10 will likely use a patched newlib 1.17.
- Tool build upgrade: As of 2 October 2007, the distributed RPMs are built by Ralf using this scheme but it is not documented for use by others.
- Add POSIX pthread mutex missing attributes. Chris Johns posted this list a while ago and I would have to reconfirm it. Again this requires newlib changes for prototypes. No developer committed yet but JoelSherrill is willing.
- Promote more of libmisc to "first class citizens". This means renaming to being "rtems_XXX", provide example programs, and document in User's Manual. The stack usage, cpu usage, and period usage portions were addressed between 4.7 and 4.8. Suggested and to be implemented by JoelSherrill with help from the community. This includes at least the following components:
- Capture Engine
- Drop initialization of managers which have 0 objects configured. I prototyped this a while back and liked the potential size savings. Suggested by JoelSherrill. ChrisJohns? has a pending patch for FreeBSD style config file for build kernel. There is currently a PR filed with a preliminary patch.
- Clean up the BSD headers (sys/cdefs.h, sys/queue.h). Suggested by RalfCorsepius?.
- Document printk() as a first class citizen.
- Splitting out cpukit into a separate package and make multilibs mandatory. Suggested by RalfCorsepius?. This appears to be important to support Ada RPMs.
- Drop the Makefile fragments. Suggested by RalfCorsepius?.
- Rework all clock drivers to use shell. Then eliminate MP hooks and modify shm driver to use an RTEMS timer. This opens the door for clock tick drivers to support a "nanoseconds since last tick" function. Suggested and initiated by JoelSherrill. This was partially accomplished between 4.7 and 4.8 and work continues. This will take a while to implement and I will not hold up a 4.10 branch because this is missing.
- Blocking object addition to SuperCore?. This is a minor rework so API objects with Thread Queues have more commonality and it will lead to debug improvement. Suggested by JoelSherrill.
- AVR port.
We can only plan to include what we know someone is working on. There is an actively maintained list of Open Projects? that you can look for to see if something strikes your fancy.