summaryrefslogtreecommitdiff
path: root/community/gsoc/2012/virt
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@codesourcery.com>2012-07-12 12:53:11 +0200
committerThomas Schwinge <thomas@codesourcery.com>2012-07-12 12:53:11 +0200
commitaec6d6f6f82c7b566988c26013aa791cad353691 (patch)
tree54bee0be9d043707c2b8b77b1e9fc18949f52279 /community/gsoc/2012/virt
parent3552ec0c40ee2c12f0d8442f7522677588ae2845 (diff)
parentbdb5476b45b43e1753514fe28d1be9436dd572bd (diff)
Merge commit 'bdb5476b45b43e1753514fe28d1be9436dd572bd'
Diffstat (limited to 'community/gsoc/2012/virt')
-rw-r--r--community/gsoc/2012/virt/proposal.mdwn95
1 files changed, 95 insertions, 0 deletions
diff --git a/community/gsoc/2012/virt/proposal.mdwn b/community/gsoc/2012/virt/proposal.mdwn
new file mode 100644
index 00000000..d89f45d5
--- /dev/null
+++ b/community/gsoc/2012/virt/proposal.mdwn
@@ -0,0 +1,95 @@
+[[!meta title="Original proposal"]]
+
+*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.