This is the proposal as it has been submitted to Google Summer of Code.

The name of the project

Virtualization Using Hurd Mechanisms

Summary

The goal is to create tools that let a user create a set of servers that implement a Hurd environment and the necessary resources, with the possibility of relying on existing servers in the parent Hurd for some of them, instead of creating them.

Benefits

This project will permit to create isolated systems but with far more flexibility than traditional virtualization tools, because the degree of isolation can be changed and possibly not only at creation time, and communication and sharing of subsystems can be arranged between isolated systems.

Deliverables

D1 — User stories for the toolset, that will later serve as examples for the documentation

D2 — Exhaustive but concise documentation of the set of needed servers making a working Hurd system (as much for me as for future users of the tool, building and linking to existing Hurd documentation)

D3 — Low-level tool to create a working Hurd environment (possibly with strong limitations on the shape of the resources used by the environment, most probably on the underlying filesystem)

D4 — Fake or noop servers for the documented set of needed servers, to be provided instead of working ones, where a feature is to be denied to a Hurd environnement

D5 — Proxy servers, where desirable, to provide access to servers outside the environment (in ocaps terminology, caretakers)

D6 — Extension of the low-level tool from D3 to remove its unreasonable limitations

D7 — High-level tools to easily create environments and run programs in them (akin respectively to debootstrap and schroot)

D8 — If possible, extensions to the D5 and D7 tools to enable dynamic modifications of the features and authority granted to environments and creation of multiple interconnected environments

Plan

I intend to develop using the Scrum method, with sprints of two weeks, which mean that each two weeks, I will present at least one new working feature, working incrementally towards the full deliverable. I will also push my code at least once a day to a public Git hosting, including topic branches, so my progress can be followed easily.

I intend to start from crosshurd and see how I can hook in its process of creation to allow being provided alternatives. Depending on how crosshurd is malleable to those changes, a modified crosshurd will either be a learning-stage prototype or the base of the implementation.

To reuse Git terminology, once plumbing tools (i.e. tools that take detailed invocation information for each server) are working fine, I'll move on to porcelain tools, the final UI (i.e. tools that provide sensible default options, aliases mechanisms, etc.).

Communication

I'm usually easy to reach through both email and jabber, so those and IRC will be my main way to inform my mentor and ask questions. I'll setup an ikiwiki to have a summary of the exchanges and the temporary documentation of the project (i.e. documentation that doesn't fit with the code yet).

Qualification

Thansk to or because of my participation to the Hurd mailing lists, I've been utterly contaminated by the concept of POLA a few years ago. Since then, I've been longing, almost in a painful way, for a object-capability flavour of Debian. Having to deal in my previous day jobs with virtualization tools like Xen and VMWare when I knew there would be no need for paravirtualization or emulation to isolate systems in an object-capability OS only made it worst.

Now most of the code I produce naturally becomes capability oriented, even if my underlying platform, programming language or OS, doesn't provide true capabilities. And creating true POLA systems and making it possible for others to benefit from POLA is now one of my dreams.