It has been quite a while (over a year, in fact) since the last post here. In that time, quite a bit has been done.

FORGE (http://www.quokforge.org/projects/forgeos) has more or less been halted; I need to eventually get back around to implementing HPET support, and to get local APIC timers calibrated to a sensible timing source.

Pedigree (http://www.pedigree-project.org), on the other hand, has moved forward quite rapidly. A general overview, likely with many gaps, is as follows:

  • A new window manager has been implemented, based loosely off the i3 window manager and fully tiling.
  • A port of Mesa has been completed with pure-software rendering.
  • A new userspace dynamic linker has been written, which has also improved support for memory mapped files across Pedigree. Read-only code and data in executables will only be loaded into memory once and shared across every memory mapped file that references it. Writeable regions (eg, .data section) are mapped with copy-on-write. This improves memory usage and also performance, especially when programs are run multiple times.
  • Psuedoterminal support has been added, and the existing text user interface has been updated to use psuedoterminals. A port of the ‘dropbear’ SSH client and server has been successful, and has been demonstrated to be usable.
  • A number of TCP bugs have been resolved, including a bug where TCP segments would be provided to the userspace application out-of-order, and also issues where TCP connection termination would fail. TCP is generally more reliable now.
  • The VFS subsystem has been extended to support the memory mapped file changes above.
  • The cache subsystem has been extended and updated to better-handle out-of-memory conditions, and to also perform writebacks as necessary.
  • A number of bugs have been fixed in the FAT filesystem driver (including one where an off-by-one error would cause long filename entries to be duplicated if the filename was precisely 13 characters long), which now makes it possible for data written to the disk to persist across reboots.
  • Copy on write for address space cloning has been implemented, which has greatly improved efficiency in the typical cases where a clone takes place (a fork followed by running a new program immediately).
  • A new preload daemon has been added, which brings commonly-used files into cache at startup, making initial use of the system faster. For example, ‘bash’ will load significantly faster when it is loaded from disk while the user is typing their username and password. Interestingly, it is rare to type the username and password fast enough to beat the preload daemon to loading the shell at least.
  • The build system has been updated slightly to be more functional when run on Pedigree.

The final point is of particular interest - it is now possible to build Pedigree on Pedigree, or at least the kernel and initrd. This means it will soon be viable to do development work on Pedigree.

A general roadmap before the next release of Pedigree looks much like this (subject to change!):

  • Build kernel and initrd on Pedigree, and reboot into new kernel
  • Provide a way to terminate windows in the window manager, and remove them from the display.
  • Provide a way to restart the window manager (this would be especially useful for making changes to the window manager).
  • Resolve issues labelled with the “Unstable 0.1.3” milestone.

It is expected that publicly available disk images and ISOs for testing Pedigree will be offered with a minimal set of software, that has been well-tested and proven to work reliably. Some software is very exciting (for example, a port of the Netsurf browser), but crashing software reflects badly on the product as a whole.

Pedigree has improved drastically in the past 6-8 months, and it is exciting to see the progress, and to consider where it will go next. Being able to use Pedigree as a development platform for future releases of Pedigree has been a goal for quite some time, and I personally consider the ability to do so a very good indicator of the stability and usability of a system.

Additionally, I have been working on a few other projects, such as a small kernel in the Rust programming language (http://www.github.com/miselin/rustic), and contributions to Rust itself. I have also put up the C unit test framework I put together for FORGE on Github. My profile is at http://www.github.com/miselin.

I’m hoping to keep this blog more up-to-date as more work continues.