[Soc-coordination] Weekly report (5th week) - Debian GNU/Hurd Debianish initialization

[4winter at informatik.uni-hamburg.de]

.. link: 
.. description: 
.. tags: gsoc, debian, hurd
.. date: 2013/07/19 15:33:31
.. title: A story about virtualization
.. slug: a-story-about-virtualization

I'm sure you all will be a bit disappointed (I know I am) that there
are no ascii screenshots in this weeks report. But let me make it up
to you by telling you a story.

I was at the FOSDEM in the year 2012 and I went to a nice workshop on
sunday afternoon in the Virtualization Devroom. Renzo Davoli was the
host of `this workshop
<https://archive.fosdem.org/2012/schedule/event/tracing_virt_workshop.html>`_
and he started with a little introductory talk to get everyone to
agree on a common terminology first. He began by asking the question,
what *virtualization* meant in the most general way. He defined the
ability to virtualize a resource as the ability to freely and
transparently control how someone (say a process) is interacting with
said resource. So for example if you `LD_PRELOAD` a library to
impersonate `fopen(3)` and friends, you have virtualized the
filesystem (for some small values of virtualized). He then went on to
discuss various methods of virtualization that are commonly available
on Linux, not only full system virtualization solutions, but also all
kinds of methods allowing a more fine-grained control over what
resources are virtualized. Of course every method had its strengths
and its weaknesses.

Having seen `Samuels talk
<http://www.gnu.org/ghm/2011/paris/slides/samuel-thibault-hurd.pdf>`_
about all the awesome things Hurd can do for virtualization I
approached him with a question in the free discussion part of his
workshop. I asked whether he would agree that once a resource is moved
from the kernel to the userspace, the problem of virtualizing that
resource is almost trivially solved, and he agreed. So I said that
this was awesome, because then the trivial and elegant solution for
all his virtualization (and tracing) needs are micro kernel operating
systems, and he also agreed to that but (as far as I can recall) he
mentioned that there is none that would meet his needs (I believe he
is a computer science professor and heavily relies on virtualization
techniques for his lab and for teaching purposes).

And even though a microkernel operating systems has a cost (message
passing instead of function calls for example) it also has its merits
such as scaling better from a development point of view. Also, many
cool features can emerge just from the design. For example think about
the container support in Linux and how painfully long it took to make
all the resources namespace aware (with one of the most critical, the
user namespace being the most difficult one). On Hurd you get the same
functionality for free. If you are curious, read `Samuels awesome
slides
<http://www.gnu.org/ghm/2011/paris/slides/samuel-thibault-hurd.pdf>`_.

So what have I done this week?

* procfs should ignore `--no{dev,exec,suid}`:
  http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00076.html

* libnetfs does not respond properly to `file_get_translator` requests
  on nodes with a passive translator record:
  http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00148.html

* As the mtab translator is a translator of its own, there needs to be
  a way to bind it to `/proc/mounts`. I figured the easiest way would
  be to just serve a node with an appropriate passive translator
  record:
  http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00149.html

* There was no clean way to start the `console-client`. I added
  daemonizing support to the `console-client` and created an
  appropriate initscript:
  http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00165.html

* I also worked a lot on my mtab translator prototype:
  http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00183.html

Next week I'm going to work on the two remaining `sysvinit related
issues </gsoc/#sysvinitrelatedissues>`_. These are the only ones
preventing me to come up with a clean patch series against the
`sysvinit` package and I figured that it would be nice to propose such
a series rather sooner than later so that I will have plenty of time
to discuss any issues with the `sysvinit` maintainers.

See you next week :)