[[!meta copyright="Copyright © 2008, 2009, 2013, 2014 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]]."]]"""]] [[!meta title="Server Overriding Mechanism"]] /!\ [[!tag open_issue_documentation]] Is this completely resolved by [[open_issues/virtualization/remap_root_translator]]? 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 [[virtualization]] task. 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 patch](http://www.assembla.com/spaces/VNetHurd/documents/aJidqKp6ur3z-Nab7jnrAJ/download/A%20patch%20of%20glibc) 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, [[open_issues/virtualization/remap_root_translator]]. 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).