diff options
Diffstat (limited to 'community/gsoc')
| -rw-r--r-- | community/gsoc/2012/virt/proposal.mdwn | 95 | ||||
| -rw-r--r-- | community/gsoc/project_ideas.mdwn | 1 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn | 64 |
3 files changed, 159 insertions, 1 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. diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index 5d42b5c6..8ce10ffa 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -98,7 +98,6 @@ other: language_bindings, gnat, gccgo, perl_python. --> [[!inline pages="community/gsoc/project_ideas/secure_chroot" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/package_manager" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/download_backends" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/libgtop" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/maxpath" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/gnat" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/gccgo" show=0 feeds=no actions=yes]] diff --git a/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn b/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn new file mode 100644 index 00000000..befd680a --- /dev/null +++ b/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn @@ -0,0 +1,64 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + + +# IRC, freenode, #hurd, 2012-04-22 + + <youpi> btw, I was wondering, when working on namespace mangling, did they + think about automatitioning ? + <youpi> autopartitioning, I meant + <youpi> i.e. with a foo.img file, open foo.img,,part1 + <braunr> what are you referring to with namespace mangling + <youpi> and voila + <youpi> I don't remember the exact term they used + <braunr> you mean there is a hurd library that parses names and can direct + to different services depending on part of the name ? + <youpi> namespace-based_translator_selection + <youpi> yes + <braunr> i thought it only handled directories + <braunr> well, the classical path representation + * civodul finds it ugly + <youpi> civodul: because of potential conflict, and the not-too-nice ",," + part? + <youpi> actually I wonder whether using directory access would be nicer + <youpi> i.e. you have a foo.gz, just open foo.gz/gunzip to get the unzipped + content + <youpi> and for foo.img.gz, open foo.img.gz/gunzip/part/1 + <civodul> youpi: because of the interpretation of special chars in file + names + <civodul> users should be free to use any character they like in file names + <civodul> foo.gz/gunzip looks nicer to me + <youpi> ok, so we agree + <youpi> that said, the user could choose the separator + <youpi> the namespace can be not run by root for everybody, but just for + your shell, run by yourself + <antrik> civodul: the user can't use any character anyways... '/' and '\0' + are reserved :-P + <civodul> antrik: '/' isn't quite reserved on the Hurd :-) + <civodul> you could implement dir_lookup such that it does something + special about it + <civodul> (server-side) + <antrik> civodul: as for overloading '/', although I haven't thought it + through entirely, I guess that would work for nodes that present as files + normally. however, it would *not* work for directory nodes + <antrik> which would be quite a serious limitation IMHO + <antrik> I can think of various kinds of useful directory translators + <antrik> what's more, one of the main use cases I originally had in mind is + a policy filter + <antrik> you could pass a directory name with a appropriate filter applied + to tar for example, so it wouldn't try to follow any translators + <antrik> I don't see why taking an obscure prefix like ,, would be much of + a problem in practice anyways + <antrik> (also, it doesn't strictly prevent the user from having such file + names... you just need to escape it if accessing such files through the + namespace multiplexer. though admittedly that would need some special + handling in *some* programs to work properly) |