cvs diff -u

The past month and some odd have been hectic off-line for RTEMS. The GSoC students were announced. Tornados took out power to RTEMS servers, knocking out the mailing list and CVS repos for a week. Thankfully, everyone known associated with the RTEMS project is fine, though many others are still recovering from the disastrous storm. And, most recently, the founder of OAR, which supports RTEMS commercially, passed away.

Now I'll turn back to the topic of this on-going series, RTEMS development. The month of April (and start of May) featured a few primary themes both of the routine and the novel. Aside from the usual bug fixes, the following items are noteworthy:

• Ralf Corsepius continued improvements with the RTEMS toolchain, notably in preparation of new features in newlib and the upcoming Fedora release cycle. The newlib changes required updating some of the posix support code.
• My red-black tree implementation was committed.
• A flurry of patches were introduced to add SMP support in RTEMS, mainly provided by Jennifer Averett and Joel Sherrill. Patches to add the leon3 and i386 as the first BSPs to support SMP are currently under review. An inelegant but working scheduler has been added to distribute tasks among cores. I will likely highlight this effort in a future post.
• Chris Johns continued to polish the IMFS code base.
• Sebastian Huber continued to improve the ARM BSPs (especially lpc24xx and lpc32xx)
• Joel removed the schedsim project from the main RTEMS tree and placed it in its own CVS repo.
• Kate Feng reworked some of the PowerPC heap initialization and sbrk code, which is primarily used by ppc targets. Till Strauman helped get it into a mergeable state.
• A port for the Blackfin 52x series was submitted but has not yet been committed.

An ongoing debate is on the usefulness of a BSP interface for delays. The SMP code requires some low-level spinning delay, and there has been for some time an rtems_bsp_delay( us ) call that has propagated through the various BSP implementations. Some of the discussion is found on the mailing list and Bugzilla.

The issue of an atomic operations API was raised without much additional chatter. Joel was disinterested in the suggested implementation because it is not SMP-safe. Sebastian is interested in having an API in place. I'm reminded of the concurrency kit work done by a student at GWU, which combines both atomic operations and locking principles in a (portable) framework.

Sebastian suggested that the Mongoose server be updated. Joel generally agreed, but no patches have been forthcoming.

A discussion on how RTEMS development is funded was had on the mailing list. The idea of funding a project like updating the network stack with contributions from multiple interested parties was raised. The idea is nice, although I suspect it is a hard sell to make.