[[!meta copyright="Copyright © 2008, 2009, 2013, 2014, 2018 Free Software
[[!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
[[!meta title="Server Overriding Mechanism"]]
[[!template id=highlight text="""/!\ Obsolete /!\
This is no longer valid as a Google Summer of Code project."""]]
/!\ [[!tag open_issue_documentation]] Is this completely resolved by
The main idea of the Hurd is that every user can influence almost all system
functionality ([[extensible_system|extensibility]]), by running private Hurd
servers that replace or proxy the global default implementations.
However, running such a customized subenvironment presently is not easy,
because there is no standard mechanism to easily replace an individual standard
server, keeping everything else. (Presently there is only the [[hurd/subhurd]]
method, which creates a completely new system instance with a completely
independent set of servers.)
The goal of this project is to provide a simple method for overriding
individual standard servers, using environment variables, or a special
subshell, or something like that. It is closely related to the
Various approaches for such a mechanism has been discussed before.
Probably the easiest (1) would be to modify the Hurd-specific parts of [[hurd/glibc]],
which are contacting various standard servers to implement certain system
calls, so that instead of always looking for the servers in default locations,
they first check for overrides in environment variables, and use these instead
if present. Take a look at the [socket server overriding
for an example.
A somewhat more generic solution (2) could use some mechanism for arbitrary
client-side namespace overrides. The client-side part of the filename lookup
mechanism would have to check an override table on each lookup, and apply the
desired replacement whenever a match is found.
Another approach would be server-side overrides. Again there are various
variants. The actual servers themselves could provide a mechanism to redirect to
other servers on request. (3) Or we could use some more generic server-side
namespace overrides: Either all filesystem servers could provide a mechanism to
modify the namespace they export to certain clients (4), or proxies could be
used that mirror the default namespace but override certain locations. (5)
Variants (4) and (5) are the most powerful. They are intimately related to
chroots: (4) is like the current chroot implementation works in the Hurd, and
(5) has been proposed as an alternative. The generic overriding mechanism could
be implemented on top of chroot, or chroot could be implemented on top of the
generic overriding mechanism. But this is out of scope for this project...
In practice, probably a mix of the different approaches would prove most useful
for various servers and use cases. It is strongly recommended that the student
starts with (1) as the simplest approach, perhaps augmenting it with (3) for
certain servers that don't work with (1) because of indirect invocation.
Veriant (5) has been discussed and implemented,
This tasks requires some understanding of the Hurd internals, especially a good
understanding of the file name lookup mechanism. It's probably not too heavy on
the coding side.
This is [[!GNU_Savannah_task 6612]]. Also there are quite a bit of emails
discussing this topic, from a previous year's GSoC application -- see
Possible mentors: Olaf Buddenhagen (antrik), Carl Fredrik Hammar (cfhammar)
Exercise: Come up with a glibc patch that allows overriding one specific
standard server using method (1).