From 24e7f01d6e6322e9d98412076dcf3f4d98196bb0 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 11:37:33 +0100 Subject: Integrate auth.html, hurd-paper.html, hurd-talk.html. Move content from devel.html, docs.html. --- hurd/documentation/auth.html | 168 ++++++ hurd/documentation/hurd-paper.html | 760 ++++++++++++++++++++++++++ hurd/documentation/hurd-talk.html | 1061 ++++++++++++++++++++++++++++++++++++ 3 files changed, 1989 insertions(+) create mode 100644 hurd/documentation/auth.html create mode 100644 hurd/documentation/hurd-paper.html create mode 100644 hurd/documentation/hurd-talk.html (limited to 'hurd/documentation') diff --git a/hurd/documentation/auth.html b/hurd/documentation/auth.html new file mode 100644 index 00000000..487fc1fe --- /dev/null +++ b/hurd/documentation/auth.html @@ -0,0 +1,168 @@ +[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] + +[[meta license="Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved."]] + +[[meta title="The Authentication Server, the transcript of a talk about the +details of the authentication mechanisms in the Hurd by Wolfgang Jährling"]] + +

Table of Contents

+ +
+ +

Introduction

+

+In this text, which mostly resembles the talk I gave at Libre Software +Meeting 2002 in Bordeaux, I will describe what the auth server does, +why it is so important and which cool things you can do with it, both +on the programming and the user side. I will also describe related +programs like the password and fakeauth servers. Note that this text +is targeted at programmers who want to understand the auth mechanism +in detail and are already familiar with concepts like Remote Procedure +Calls (RPCs) as well as the way User- and Group-IDs are used in the +POSIX world. + +

+The auth server is a very small server, therefore it gives a useful +example when you want to learn how a server typically looks like. One +reason why it is so small is that the auth interface, which it +implements, consists of only four RPCs. You can find the interface in +hurd/hurd/auth.defs and the server itself in hurd/auth/. + +

How IDs are represented and used

+

+Each process holds (usually) one port to auth (an auth_t in C source, +which actually is a mach_port_t, of course). The purpose of auth is +to manage User-IDs and Group-IDs, which is the reason why users often +will have no choice but to make use of the systems main auth server, +which does not listen on /servers/auth; instead you inherit a port to +auth from your parent process. Each such port is (internally in the +auth server) associated with a set of effective User- and Group-IDs as +well as a set of available User- and Group-IDs. So we have four sets +of IDs in total. The available IDs can be turned into corresponding +effective IDs at any time. + +

+When you send an auth_getids RPC on the port you hold, you will get +information about which IDs are associated with it, so you can figure +out which permissions you have. But how will a server know that you +have these permissions and therefore know which actions (e.g. writing +into file "foo") it is supposed to do on your behalf and which not? +The establishing of a trusted connection to a server works as follows: + +

    +
  1. A user wants a server to know its IDs
  2. +
  3. The user requests a reauthentication from the server
  4. +
  5. In this request the user will include a port
  6. +
  7. Both will hand this port to auth
  8. +
  9. The user uses auth_user_authenticate
  10. +
  11. The server uses auth_server_authenticate
  12. +
  13. The server also passes a new port to auth
  14. +
  15. auth matches these two requests
  16. +
  17. The user gets the new port from auth
  18. +
  19. The server learns about the IDs of the user
  20. +
  21. The user uses the new port for further communication
  22. +
+ +

+We have different RPCs for users and servers because what we pass and +what we get back differs for them: Users get a port, and servers get +the sets of IDs, and have to specify the port which the user will get. + +

+It is interesting to note that auth can match the requests by +comparing two integers, because when you get the same port from two +people, you will have the same mach_port_t (which is nothing but an +integer). + +

+All of this of course only works if they use the same auth server, +which is why I said often you have no choice other than to use the +one main auth server. But this is no serious restriction, as the auth server has +almost no functionality one might want to replace. In fact, there is +one replacement for the default auth implementation, but more on that +later. + +

POSIX and beyond

+

+Before we examine what is possible with this design, let us take a +short look at how the POSIX semantics are implemented on top of this +design. When a program that comes out of POSIX-land asks for its own +effective User- or Group-ID, we will tell it about the first of the +effective IDs. In the same sense, the POSIX real User- or Group-ID is +the first available ID and the POSIX saved User- or Group-ID is the +second available ID, which is why you have the same ID two times in +the available IDs when you log into your GNU/Hurd machine (you can +figure out which IDs you have with the program "ids", that basically +just does an auth_getauth RPC). When you lack one of those IDs (for +example when you have no effective Group-ID), a POSIX program asking +for this particular information will get "-1" as the ID. + +

+But as you can imagine, we can do more than what POSIX specifies. Fox +example, we can modify our permissions. This is always done with the +auth_makeauth RPC. In this RPC, you specify the IDs that should be +associated with the new port. All of these IDs must be associated +with either the port where the RPC is sent to or one of the additional +ports you can specify; an exception is the superuser root, which is +allowed to creat ports that are associated with arbitrary IDs. +Hereby you can convert available into effective IDs. + +

+This opens the door to a bunch of nice features. For example, we have +the addauth program in the Hurd, which makes it possible to add an ID +to either a single process or a group of processes if you hold the ID or know the +appropriate password, and there is a corresponding rmauth program that +removes an ID. So when you are working on your computer with GNU +Emacs and want to edit a system configuration file, you switch to +Emacs' shell-mode, do an "addauth root", enter the password, edit the +file, and when you are done switch back to shell-mode and do "rmauth +root". These programs have some interesting options, and there are +various other programs, for setting the complete list of IDs (setauth) +and so on. + +

Related servers

+

+Finally, I want to explain two servers which are related to auth. The +first is the password server, which listens on /servers/password. If +you pass to it a User- or Group-ID and the correct password for it, it +will return a port to auth to you which is associated with the ID you +passed to it. It can create such a port because it is running as +root. So let us assume you are an FTP server process. You will start +as root, because you want to use port 21 (in this case, "port" does +not refer to a mach_port_t, of course). But then, you can drop all +your permissions so that you run without any ID. This makes it far +less dangerous to communicate with yet unknown users over the +network. But when someone now hands a username and password to you, +you can ask the password server for a new auth port. The password +server will check the data you pass to it, for example by looking into +/etc/shadow, and if it is valid, it will ask the auth server for a new +port. It receives this port from auth and then passes it on to you. +So you have raised your permissions. (And for the very curious: Yes, +we are well aware of the differences between this concept and +capabilities; and we also do have some kinds of capabilities in +various parts of the Hurd.) + +

+My second example is the fakeauth server. It also implements the auth +protocol. It is the part of the fakeroot implementation that gives a +process the impression that it runs as root, even if it doesn't. So +when the process asks fakeauth about its own IDs, fakeauth will tell +the process that it runs as root. But when the process wants to make +use of the authentication protocol described earlier in this text, +fakeauth will forward the request to its own auth server, which will +usually be the systems main auth server, which will then be able to +match the auth_*_authenticate requests. So what fakeauth does is +acting as a proxy auth server that gives someone the impression to run +as root, while not modifying what that one is allowed to do. + +

+At this point, I have said at least most of what can be said about the +auth server and the protocol it implements, so I will finish by saying +that it might be an interesting task (for you) to modify some existing +software to take advantage of the features I described here. diff --git a/hurd/documentation/hurd-paper.html b/hurd/documentation/hurd-paper.html new file mode 100644 index 00000000..15d2daec --- /dev/null +++ b/hurd/documentation/hurd-paper.html @@ -0,0 +1,760 @@ +[[meta copyright="Copyright © 1996, 1997, 1998, 2007, 2008 Free Software +Foundation, Inc."]] + +[[meta license="Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved."]] + +[[meta title="Towards a New Strategy of OS Design, an architectural overview by +Thomas Bushnell, BSG."]] + + +This article explains why FSF is developing a new operating system named the +Hurd, which will be a foundation of the whole GNU system. +The Hurd is built +on top of CMU's Mach 3.0 kernel and uses Mach's virtual memory management and +message-passing facilities. +The GNU C Library will provide the Unix system +call interface, and will call the Hurd for needed services it can't provide +itself. +The design and implementation of the Hurd is being lead by Michael +Bushnell, with assistance from Richard Stallman, Roland McGrath, +Jan Brittenson, and others. + +

Part 1: A More Usable Approach to OS Design

+

+The fundamental purpose of an operating system (OS) is to enable a variety of +programs to share a single computer efficiently and productively. +This +demands memory protection, preemptively scheduled timesharing, coordinated +access to I/O peripherals, and other services. +In addition, an OS can allow +several users to share a computer. +In this case, efficiency demands services +that protect users from harming each other, enable them to share without +prior arrangement, and mediate access to physical devices. +

+On today's computer systems, programmers usually implement these goals +through a large program called the kernel. +Since this program must be +accessible to all user programs, it is the natural place to add functionality +to the system. +Since the only model for process interaction is that of +specific, individual services provided by the kernel, no one creates other +places to add functionality. +As time goes by, more and more is added to the +kernel. +

+A traditional system allows users to add components to a kernel only if they +both understand most of it and have a privileged status within the system. +Testing new components requires a much more painful edit-compile-debug cycle +than testing other programs. +It cannot be done while others are using the +system. +Bugs usually cause fatal system crashes, further disrupting others' +use of the system. +The entire kernel is usually non-pageable. +(There are +systems with pageable kernels, but deciding what can be paged is difficult +and error prone. +Usually the mechanisms are complex, making them difficult +to use even when adding simple extensions.) +

+Because of these restrictions, functionality which properly belongs +behind +the wall of a traditional kernel is usually left out of systems unless it is +absolutely mandatory. +Many good ideas, best done with an open/read/write +interface cannot be implemented because of the problems inherent in the +monolithic nature of a traditional system. +Further, even among those with +the endurance to implement new ideas, only those who are privileged users of +their computers can do so. +The software copyright system darkens the mire by +preventing unlicensed people from even reading the kernel source. +

+Some systems have tried to address these difficulties. +Smalltalk-80 and +the Lisp Machine both represented one method of getting around the problem. +System code is not distinguished from user code; all of the system is +accessible to the user and can be changed as need be. +Both systems were +built around languages that facilitated such easy replacement and extension, +and were moderately successful. +But they both were fairly poor at insulating +users and programs from each other, failing one of the principal goals of OS +design. +

+Most projects that use the Mach 3.0 kernel carry on the hard-to-change +tradition of OS design. +The internal structure is different, but the same +heavy barrier between user and system remains. +The single-servers, while +fairly easy to construct, inherit all the deficiencies of the monolithic +kernels. +

+A multi-server divides the kernel functionality up into logical blocks with +well-defined interfaces. +Properly done, it is easier to make changes and add +functionality. +So most multi-server projects do somewhat better. +Much more +of the system is pageable. +You can debug the system more easily. +You can +test new system components without interfering with other users. +But the +wall between user and system remains; no user can cross it without special +privilege. +

+The GNU Hurd, by contrast, is designed to make the area of +system +code as +limited as possible. +Programs are required to communicate only with a few +essential parts of the kernel; the rest of the system is replaceable +dynamically. +Users can use whatever parts of the remainder of the system +they want, and can easily add components themselves for other users to take +advantage of. +No mutual trust need exist in advance for users to use each +other's services, nor does the system become vulnerable by trusting the +services of arbitrary users. +

+This has been done by identifying those system components which users +must +use in order to communicate with each other. +One of these is responsible for +identifying users' identities and is called the + +authentication server. + +In +order to establish each other's identities, programs must communicate, each +with an authentication server they trust. +Another component establishes +control over system components by the superuser, provides global bookkeeping +operations, and is called the + +process server. + +

+Not all user programs need to communicate with the process server; it is only +necessary for programs which require its services. +Likewise, the +authentication server is only necessary for programs that wish to communicate +their identity to another. +None of the remaining services carry any special +status; not the network implementation, the filesystems, the program +execution mechanism (including setuid), or any others. + +

The Translator Mechanism

+

+The Hurd uses Mach ports primarily as methods for communicating between users +and servers. +(A Mach port is a communication point on a Mach task where +messages are sent and received.) Each port implements a particular set of +protocols, representing operations that can be undertaken on the underlying +object represented by the port. +Some of the protocols specified by the Hurd +are the I/O protocol, used for generic I/O operations; the file protocol, +used for filesystem operations; the socket protocol, used for network +operations; and the process protocol, used for manipulating processes et al. +

+Most servers are accessed by opening files. +Normally, when you open a file, +you create a port associated with that file that is owned by the server +that owns the directory containing the file. +For example, a disk-based +filesystem will normally serve a large number of ports, each of which +represents an open file or directory. +When a file is opened, the server +creates a new port, associates it with the file, and returns the port to the +calling program. +

+However, a file can have a +translator +associated with it. +In this case, +rather than return its own port which refers to the contents of the file, the +server executes a translator program associated with that file. +This +translator is given a port to the actual contents of the file, and is then +asked to return a port to the original user to complete the open operation. +

+This mechanism is used for +mount +by having a translator associated with +each mount point. +When a program opens the mount point, the translator (in +this case, a program which understands the disk format of the mounted +filesystem) is executed and returns a port to the program. +After the +translator is started, it need not be run again unless it dies; the parent +filesystem retains a port to the translator to use in further requests. +

+The owner of a file can associate a translator with it without special +permission. +This means that any program can be specified as a translator. +Obviously the system will not work properly if the translator does not +implement the file protocol correctly. +However, the Hurd is constructed so +that the worst possible consequence is an interruptible hang. +

+One way to use translators is to access hierarchically structured data using +the file protocol. +For example, all the complexity of the user interface to +the +ftp +program is removed. +Users need only know that a particular +directory represents FTP and can use all the standard file manipulation +commands (e.g +ls +or +cp) +to access the remote system, rather than learning +a new set. +Similarly, a simple translator could ease the complexity of +tar +or +gzip. +(Such transparent access would have some added cost, but it would +be convenient.) + +

Generic Services

+

+With translators, the filesystem can act as a rendezvous for interfaces which +are not similar to files. +Consider a service which implements some version +of the X protocol, using Mach messages as an underlying transport. +For each +X display, a file can be created with the appropriate program as its +translator. +X clients would open that file. +At that point, few file +operations would be useful (read and write, for example, would be useless), +but new operations ( +XCreateWindow +or +XDrawText) +might become meaningful. +In this case, the filesystem protocol is used only to manipulate +characteristics of the node used for the rendezvous. +The node need not +support I/O operations, though it should reply to any such messages with a +message_not_understood +return code. +

+This translator technique is used to contact most of the services in the Hurd +that are not structured like hierarchical filesystems. +For example, the +password server, which hands out authorization tags in exchange for +passwords, is contacted this way. +Network protocol servers are also +contacted in this fashion. +Roland McGrath thought up this use of translators. + +

Clever Filesystem Pictures

+

+In the Hurd, translators can also be used to present a filesystem-like view +of another part of the filesystem, with some semantics changed. +For example, +it would be nice to have a filesystem that cannot itself be changed, but +nonetheless records changed versions of its files elsewhere. +(This could be +useful for source code management.) +

+The Hurd will have a translator which creates a directory which is a +conceptual union of other directories, with collision resolution rules of +various sorts. +This can be used to present a single directory to users that +contains all the programs they would want to execute. +There are other useful +variations on this theme. + +

What The User Can Do

+

+No translator gains extra privilege by virtue of being hooked into the +filesystem. +Translators run with the uid of the owner of the file being +translated, and can only be set or changed by that owner. +The I/O and +filesystem protocols are carefully designed to allow their use by mutually +untrusting clients and servers. +Indeed, translators are just ordinary +programs. +The GNU C library has a variety of facilities to make common sorts +of translators easier to write. +

+Some translators may need special privileges, such as the password server or +translators which allow setuid execution. +These translators could be run by +anyone, but only if they are set on a root-owned node would they be able to +provide all their services successfully. +This is analogous to letting any +user call the +reboot +system call, but only honoring it if that user is root. + +

Why This Is So Different

+

+What this design provides is completely novel to the Unix world. +Until now, +OSs have kept huge portions of their functionality in the realm of system +code, thus preventing its modification and extension except in extreme need. +Users cannot replace parts of the system in their programs no matter how much +easier that would make their task, and system managers are loath to install +random tweaks off the net into their kernels. +

+In the Hurd, users can change almost all of the things that are decided for +them in advance by traditional systems. +In combination with the tremendous +control given by the Mach kernel over task address spaces and properties, the +Hurd provides a system in which users will, for the first time, be able to +replace parts of the system they dislike, without disrupting other users. +

+Most Mach-based OSs to date have mostly implemented a wider set of the + +same old + +Unix semantics in a new environment. +In contrast, GNU is extending +those semantics to allow users to improve, bypass, or replace them. + + +

Part 2: A Look at Some of the Hurd's Beasts

+

The Authentication Server

+

+One of the Hurd's more central servers is the authentication server. +Each +port to this server identifies a user and is associated by this server with +an +id block. +Each id block contains sets of user and group ids. +Either +set may be empty. +This server is not the same as the password server +referred to above. +

+The authentication server exports three services. +First, it provides simple +boolean operations on authentication ports: given two authentication ports, +this server will provide a third port representing the union of the two sets +of uids and gids. +Second, this server allows any user with a uid of zero to +create an arbitrary authentication port. +Finally, this server provides RPCs +(Remote Procedure Calls between different programs and possibly different +hosts) which allow mutually untrusting clients and servers to establish their +identities and pass initial information on each other. +This is crucial to +the security of the filesystem and I/O protocols. +

+Any user could write a program which implements the authentication protocol; +this does not violate the system's security. +When a service needs to +authenticate a user, it communicates with its trusted authentication server. +If that user is using a different authentication server, the transaction will +fail and the server can refuse to communicate further. +Because, in effect, +this forces all programs on the system to use the same authentication server, +we have designed its interface to make any safe operation possible, and to +include no extraneous operations. +(This is why there is a separate password +server.) +

The Process Server

+

+The process server acts as an information categorization repository. +There +are four main services supported by this server. +First, the process server +keeps track of generic host-level information not handled by the Mach kernel. +For example, the hostname, the hostid, and the system version are maintained +by the process server. +Second, this server maintains the Posix notions of +sessions and process groups, to help out programs that wish to use Posix +features. +

+Third, the process server maintains a one-to-one mapping between Mach tasks +and Hurd processes. +Every task is assigned a pid. +Processes can register a +message port with this server, which can then be given out to any program +which requests it. +This server makes no attempt to keep these message ports +private, so user programs are expected to implement whatever security they +need themselves. +(The GNU C Library provides convenient functions for all +this.) Processes can tell the process server their current `argv' and `envp' +values; this server will then provide, on request, these vectors of arguments +and environment. +This is useful for writing +ps-like +programs and also +makes it easier to hide or change this information. +None of these features +are mandatory. +Programs are free to disregard all of this and never register +themselves with the process server at all. +They will, however, still have a +pid assigned. +

+Finally, the process server implements +process collections, +which are used +to collect a number of process message ports at the same time. +Also, +facilities are provided for converting between pids, process server ports, +and Mach task ports, while ensuring the security of the ports managed. +

+It is important to stress that the process server is optional. +Because of +restrictions in Mach, programs must run as root in order to identify all the +tasks in the system. +But given that, multiple process servers could +co-exist, each with their own clients, giving their own model of the +universe. +Those process server features which do not require root privileges +to be implemented could be done as per-user servers. +The user's hands are +not tied. +

Transparent FTP

+

+Transparent FTP is an intriguing idea whose time has come. +The popular +ange-ftp +package available for GNU Emacs makes access to FTP files +virtually transparent to all the Emacs file manipulation functions. +Transparent FTP does the same thing, but in a system wide fashion. +This +server is not yet written; the details remain to be fleshed out, and will +doubtless change with experience. +

+In a BSD kernel, a transparent FTP filesystem would be no harder to write +than in the Hurd. +But mention the idea to a BSD kernel hacker, and the +response is that ``such a thing doesn't belong in the kernel''. +In a sense, +this is correct. +It violates all the layering principles of such systems to +place such things in the kernel. +The unfortunate side effect, however, is +that the design methodology (which is based on preventing users from changing +things they don't like) is being used to prevent system designers from making +things better. +(Recent BSD kernels make it possible to write a user program +that provides transparent FTP. +An example is +alex, +but it needs to run +with full root privileges.) +

+In the Hurd, there are no obstacles to doing transparent FTP. +A translator +will be provided for the node +/ftp. +The contents of +/ftp +will probably +not be directly listable, though further subdirectories will be. +There will +be a variety of possible formats. +For example, to access files on uunet, one +could + +cd /ftp/ftp.uu.net:anonymous:mib@gnu. + +Or to access files on a remote +account, one might + +cd /ftp/gnu.org:mib:passwd. + +Parts of this +command could be left out and the transparent FTP program would read them +from a user's +.netrc +file. +In the last case, one might just + +cd /ftp/gnu.org; + +when the rest of the data is already in +.netrc. +

+There is no need to do a +cd +first--use any file command. +To find out about +RFC 1097 (the Telnet Subliminal Message Option), just type + +more /ftp/ftp.uu.net/inet/rfc/rfc1097. + +A copy command to a local disk +could be used if the RFC would be read frequently. +

Filesystems

+

+Ordinary filesystems are also being implemented. +The initial release of the +Hurd will contain a filesystem upwardly compatible with the BSD 4.4 Fast File +System. +In addition to the ordinary semantics, it will provide means to +record translators, offer thirty-two bit user ids and group ids, and supply a +new id per file, called the +author +of the file, which can be set by the +owner arbitrarily. +In addition, because users in the Hurd can have multiple +uids (or even none), there is an additional set of permission bits providing +access control for + +unknown user + +(no uids) as distinct from + +known but arbitrary user + +(some uids: the existing +world +category of file +permissions). +

+The Network File System protocol will be implemented using 4.4 BSD as a +starting point. +A log-structured filesystem will also be implemented using +the same ideas as in Sprite, but probably not the same format. +A GNU network +file protocol may be designed in time, or NFS may be extended to remove its +deficiencies. +There will also be various ``little'' filesystems, such as the +MS-DOS filesystem, to help people move files between GNU and other OSs. + +

Terminals

+

+An I/O server will provide the terminal semantics of Posix. +The GNU C +Library has features for keeping track of the controlling terminal and for +arranging to have proper job control signals sent at the proper times, as +well as features for obeying keyboard and hangup signals. +

+Programs will be able to insert a terminal driver into communications +channels in a variety of ways. +Servers like +rlogind +will be able to insert +the terminal protocol onto their network communication port. +Pseudo-terminals will not be necessary, though they will be provided for +backward compatibility with older programs. +No programs in GNU will depend +on them. +

+Nothing about a terminal driver is forced upon users. +A terminal driver +allows a user to get at the underlying communications channel easily, to +bypass itself on an as-needed basis or altogether, or to substitute a +different terminal driver-like program. +In the last case, provided the +alternate program implements the necessary interfaces, it will be used by the +C Library exactly as if it were the ordinary terminal driver. +

+Because of this flexibility, the original terminal driver will not provide +complex line editing features, restricting itself to the behavior found in +Posix and BSD. +In time, there will be a +readline-based +terminal driver, +which will provide complex line-editing features for those users who want +them. +

+The terminal driver will probably not provide good support for the +high-volume, rapid data transmission required by UUCP or SLIP. +Those +programs do not need any of its features. +Instead they will be using the +underlying Mach device ports for terminals, which support moving large +amounts of data efficiently. + +

Executing Programs

+

+The implementation of the +execve +call is spread across three programs. +The +library marshals the argument and environment vectors. +It then sends a +message to the file server that holds the file to be executed. +The file +server checks execute permissions and makes whatever changes it desires in +the exec call. +For example, if the file is marked setuid and the fileserver +has the ability, it will change the user identification of the new image. +The file server also decides if programs which had access to the old task +should continue to have access to the new task. +If the file server is +augmenting permissions, or executing an unreadable image, then the exec needs +to take place in a new Mach task to maintain security. +

+After deciding the policy associated with the new image, the filesystem calls +the exec server to load the task. +This server, using the BFD (Binary File +Descriptor) library, loads the image. +BFD supports a large number of object +file formats; almost any supported format will be executable. +This server +also handles scripts starting with +#!, +running them through the indicated +program. +

+The standard exec server also looks at the environment of the new image; if +it contains a variable +EXECSERVERS +then it uses the programs specified +there as exec servers instead of the system default. +(This is, of course, +not done for execs that the file server has requested be kept secure.) +

+The new image starts running in the GNU C Library, which sends a message to +the exec server to get the arguments, environment, umask, current directory, +etc. +None of this additional state is special to the file or exec servers; +if programs wish, they can use it in a different manner than the Library. + +

New Processes

+

+The +fork +call is implemented almost entirely in the GNU C Library. +The new +task is created by Mach kernel calls. +The C Library arranges to have its +image inherited properly. +The new task is registered with the process server +(though this is not mandatory). +The C Library provides vectors of functions +to be called at fork time: one vector to be called before the fork, one after +in the parent, and one after in the child. +(These features should not be +used to replace the normal fork-calling sequence; it is intended for +libraries which need to close ports or clean up before a fork occurs.) +The C +library will implement both fork calls specified by the draft Posix.4a (the +proposed standard dealing with the threads extension to the real-time +extension). +

+Nothing forces the user to create new tasks this way. +If a program wants to +use almost the normal fork, but with some special characteristics, then it +can do so. +Hooks will be provided by the C Library, or the function can even +be completely replaced. +None of this is possible in a traditional Unix +system. + +

Asynchronous Messages

+

+As mentioned above, the process server maintains a + +message port + +for each +task registered with it. +These ports are public, and are used to send +asynchronous messages to the task. +Signals, for example, are sent to the +message port. +The signal message also provides a port as an indication that +the sender should be trusted to send the signal. +The GNU C Library lists a +variety of ports in a table, each of which identifies a set of signals that +can be sent by anyone who possesses that port. +For example, if the user +possesses the task's kernel port, it is allowed to send any signal. +If the +user possesses a special + +terminal id + +port, it is allowed to send the +keyboard and hangup signals. +Users can add arbitrary new entries into the C +library's signal permissions table. +

+When a process's process group changes, the process server will send it a +message indicating the new process group. +In this case, the process server +proves its authority by providing the task's kernel port. +

+The C library also has messages to add and delete uids currently used by the +process. +If new uids are sent to the program, the library adds them to its +current set, and then exchanges messages with all the I/O servers it knows +about, proving to them its new authorization. +Similarly, a message can +delete uids. +In the latter case, the caller must provide the process's task +port. +(You can't harm a process by giving it extra permission, but you can +harm it by taking permission away.) The Hurd will provide user programs to +send these messages to processes. +For example, the +su +command will be able +to cause all the programs in your current login session, to gain a new uid, +rather than spawn a subshell. +

+The C library will allow programs to add asynchronous messages they wish to +recognize, as well as prevent recognition of the standard set. +

Making It Look Like Unix

+

+The C Library will implement all of the calls from BSD and Posix as well as +some obvious extensions to them. +This enables users to replace those calls +they dislike or bypass them entirely, whereas in Unix the calls must be used +``as they come'' with no alternatives possible. +

+In some environments binary compatibility will also be supported. +This works +by building a special version of the library which is then loaded somewhere +in the address space of the process. +(For example, on a VAX, it would be +tucked in above the stack.) A feature of Mach, called system call +redirection, is then used to trap Unix system calls and turn them into jumps +into this special version of the library. +(On almost all machines, the cost +of such a redirection is very small; this is a highly optimized path in Mach. +On a 386 it's about two dozen instructions. +This is little worse than a +simple procedure call.) +

+Many features of Unix, such as signal masks and vectors, are handled +completely by the library. +This makes such features significantly cheaper +than in Unix. +It is now reasonable to use +sigblock +extensively to protect +critical sections, rather than seeking out some other, less expensive method. + +

Network Protocols

+

+The Hurd will have a library that will make it very easy to port 4.4 BSD +protocol stacks into the Hurd. +This will enable operation, virtually for +free, of all the protocols supported by BSD. +Currently, this includes the +CCITT protocols, the TCP/IP protocols, the Xerox NS protocols, and the ISO +protocols. +

+For optimal performance some work would be necessary to take advantage of +Hurd features that provide for very high speed I/O. +For most protocols this +will require some thought, but not too much time. +The Hurd will run the +TCP/IP protocols as efficiently as possible. +

+As an interesting example of the flexibility of the Hurd design, consider the +case of IP trailers, used extensively in BSD for performance. +While the Hurd +will be willing to send and receive trailers, it will gain fairly little +advantage in doing so because there is no requirement that data be copied and +avoiding copies for page-aligned data is irrelevant. diff --git a/hurd/documentation/hurd-talk.html b/hurd/documentation/hurd-talk.html new file mode 100644 index 00000000..d608e12a --- /dev/null +++ b/hurd/documentation/hurd-talk.html @@ -0,0 +1,1061 @@ +[[meta copyright="Copyright © 2001 Marcus Brinkmann"]] + +[[meta license="Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved."]] + +[[meta title="The Hurd, a presentation by Marcus Brinkmann"]] + + +

Table of Contents

+ +
+

Talk about the Hurd

+

+This talk about the Hurd was written by Marcus Brinkmann for +

+ +

Introduction

+

+When we talk about free software, we usually refer to the free +software licenses. We also need relief from software patents, so our +freedom is not restricted by them. But there is a third type of +freedom we need, and that's user freedom. + +

+Expert users don't take a system as it is. They like to change the +configuration, and they want to run the software that works best for +them. That includes window managers as well as your favourite text +editor. But even on a GNU/Linux system consisting only of free +software, you can not easily use the filesystem format, network +protocol or binary format you want without special privileges. In +traditional unix systems, user freedom is severly restricted by the +system administrator. + +

+The Hurd removes these restrictions from the user. It provides an +user extensible system framework without giving up POSIX compatibility +and the unix security model. Throughout this talk, we will see that +this brings further advantages beside freedom. + +

Overview

+
+ +

+The Hurd is a POSIX compatible multi-server +system operating on top of the GNU Mach microkernel. + +

+Topics: +

    +
  • GNU Mach
  • +
  • The Hurd
  • +
  • Development
  • +
  • Debian GNU/Hurd
  • +
+
+ +

+The Hurd is a POSIX compatible multi-server system operating on top of +the GNU Mach Microkernel. + +

+I will have to explain what GNU Mach is, so we start with that. Then +I will talk about the Hurd's architecture. After that, I will give a +short overview on the Hurd libraries. Finally, I will tell you how +the Debian project is related to the Hurd. + +

Historicals

+ +
+
    +
  • 1983: Richard Stallman founds the GNU project.
  • +
  • 1988: Decision is made to use Mach 3.0 as the kernel.
  • +
  • 1991: Mach 3.0 is released under compatible license.
  • +
  • 1991: Thomas Bushnell, BSG, founds the Hurd project.
  • +
  • 1994: The Hurd boots the first time.
  • +
  • 1997: Version 0.2 of the Hurd is released.

  • +
  • 1998: Debian hurd-i386 archive is created.
  • +
  • 2001: Debian GNU/Hurd snapshot fills three CD images.
  • +
+
+ +

+When Richard Stallman founded the GNU project in 1983, he wanted to +write an operating system consisting only of free software. Very +soon, a lot of the essential tools were implemented, and released +under the GPL. However, one critical piece was missing: The kernel. +

+After considering several alternatives, it was decided not to write a +new kernel from scratch, but to start with the Mach microkernel. This +was in 1988, and it was not before 1991 that Mach was released under a +license allowing the GNU project to distribute it as a part of the +system. +

+In 1998, I started the Debian GNU/Hurd project, and in 2001 the number +of available GNU/Hurd packages fills three CD images. + +

Kernel Architectures

+
+

+Microkernel: +

    +
  • Enforces resource management (paging, scheduling)
  • +
  • Manages tasks
  • +
  • Implements message passing for IPC
  • +
  • Provides basic hardware support
  • +
+

+Monolithic kernel: +

    +
  • No message passing necessary
  • +
  • Rich set of features (filesystems, authentication, network + sockets, POSIX interface, ...)
  • +
+
+

+Microkernels were very popular in the scientific world around that +time. They don't implement a full operating system, but only the +infrastructure needed to enable other tasks to implement most +features. In contrast, monolithical kernels like Linux contain +program code of device drivers, network protocols, process management, +authentication, file systems, POSIX compatible interfaces and much +more. +

+So what are the basic facilities a microkernel provides? In general, +this is resource management and message passing. Resource management, +because the kernel task needs to run in a special privileged mode of +the processor, to be able to manipulate the memory management unit and +perform context switches (also to manage interrupts). Message +passing, because without a basic communication facility the other +tasks could not interact to provide the system services. Some +rudimentary hardware device support is often necessary to bootstrap +the system. So the basic jobs of a microkernel are enforcing the +paging policy (the actual paging can be done by an external pager +task), scheduling, message passing and probably basic hardware device +support. +

+Mach was the obvious choice back then, as it provides a rich set of +interfaces to get the job done. Beside a rather brain-dead device +interface, it provides tasks and threads, a messaging system allowing +synchronous and asynchronous operation and a complex interface for +external pagers. It's certainly not one of the sexiest microkernels +that exist today, but more like a big old mama. The GNU project +maintains its own version of Mach, called GNU Mach, which is based on +Mach 4.0. In addition to the features contained in Mach 4.0, the GNU +version contains many of the Linux 2.0 block device and network card +drivers. +

+A complete treatment of the differences between a microkernel and +monolithical kernel design can not be provided here. But a couple of +advantages of a microkernel design are fairly obvious. + +

Micro vs Monolithic

+
+

+Microkernel +

    +
  • Clear cut responsibilities +
  • Flexibility in operating system design, easier debugging
  • +
  • More stability (less code to break)
  • +
  • New features are not added to the kernel
  • +
+

+Monolithic kernel +

    +
  • Intolerance or creeping featuritis
  • +
  • Danger of spaghetti code
  • +
  • Small changes can have far reaching side effects
  • +
+
+

+Because the system is split up into several components, clean +interfaces have to be developed, and the responsibilities of each part +of the system must be clear. +

+Once a microkernel is written, it can be used as the base for several +different operating systems. Those can even run in parallel which +makes debugging easier. When porting, most of the hardware dependant +code is in the kernel. +

+Much of the code that doesn't need to run in the special kernel mode +of the processor is not part of the kernel, so stability increases +because there is simply less code to break. +

+New features are not added to the kernel, so there is no need to hold +the barrier high for new operating system features. +

+Compare this to a monolithical kernel, where you either suffer from +creeping featuritis or you are intolerant of new features (we see both +in the Linux kernel). +

+Because in a monolithical kernel, all parts of the kernel can access +all data structures in other parts, it is more likely that short cuts +are used to avoid the overhead of a clean interface. This leads to a +simple speed up of the kernel, but also makes it less comprehensible +and more error prone. A small change in one part of the kernel can +break remote other parts. + +

Single Server vs Multi Server

+
+

+Single Server +

    +
  • A single task implements the functionality of the operating system.
  • +
+

+Multi Server +

    +
  • Many tasks cooperate to provide the system's functionality.
  • +
  • One server provides only a small but well-defined part of the + whole system.
  • +
  • The responsibilities are distributed logically among the servers.
  • +
+

+A single-server system is comparable to a monolithic kernel system. It +has similar +advantages and disadvantages. +

+

+There exist a couple of operating systems based on Mach, but they all +have the same disadvantages as a monolithical kernel, because those +operating systems are implemented in one single process running on top +of the kernel. This process provides all the services a monolithical +kernel would provide. This doesn't make a whole lot of sense (the +only advantage is that you can probably run several of such isolated +single servers on the same machine). Those systems are also called +single-server systems. The Hurd is the only usable multi-server +system on top of Mach. In the Hurd, there are many server programs, +each one responsible for a unique service provided by the operating +system. These servers run as Mach tasks, and communicate using the +Mach message passing facilities. One of them does only provide a +small part of the functionality of the system, but together they build +up a complete and functional POSIX compatible operating system. + +

Multi Server is superior, ...

+
+

+Any multi-server has advantages over single-server: +

    +
  • Clear cut responsibilities
  • +
  • More stability: If one server dies, all others remain
  • +
  • Easier development cycle: Testing without reboot (or replacing + running servers), debugging with gdb
  • +
  • Easier to make changes and add new features +
+
+

+Using several servers has many advantages, if done right. If a file +system server for a mounted partition crashes, it doesn't take down +the whole system. Instead the partition is "unmounted", and +you can try to start the server again, probably debugging it this time +with gdb. The system is less prone to errors in individual +components, and over-all stability increases. The functionality of +the system can be extended by writing and starting new servers +dynamically. (Developing these new servers is easier for the reasons +just mentioned.) +

+But even in a multi-server system the barrier between the system and +the users remains, and special privileges are needed to cross it. We +have not achieved user freedom yet. + +

The Hurd even more so.

+
+

+The Hurd goes beyond all this, and allows users to write and run their +servers, too! +

    +
  • Users can replace system servers dynamically with their own + implementations.
  • +
  • Users can decide what parts of the remainder of the system they + want to use.
  • +
  • Users can extend the functionality of the system.
  • +
  • No mutual trust necessary to make use of other users + services.
  • +
  • Security of the system is not harmed by trusting users + services.
  • +
+
+

+To quote Thomas Bushnell, BSG, from his paper +[[``Towards_a_New_Strategy_of_OS_design''_(1996)|hurd-paper]]: +

+The GNU Hurd, by contrast, is designed to make the area of system code +as limited as possible. Programs are required to communicate only +with a few essential parts of the kernel; the rest of the system is +replaceable dynamically. Users can use whatever parts of the +remainder of the system they want, and can easily add components +themselves for other users to take advantage of. No mutual trust need +exist in advance for users to use each other's services, nor does the +system become vulnerable by trusting the services of arbitrary users. +
+ +

+So the Hurd is a set of servers running on top of the Mach +micro-kernel, providing a POSIX compatible and extensible operating +system. What servers are there? What functionality do they provide, +and how do they cooperate? + +

Mach Inter Process Communication

+
+

+Ports are message queues which can be used as one-way communication +channels. +

    +
  • Port rights are receive, send or send-once
  • +
  • Exactly one receiver
  • +
  • Potentially many senders
  • +
+

+MIG provides remote procedure calls on top of Mach IPC. RPCs look like +function calls to the user. +

+

+Inter-process communication in Mach is based on the ports concept. A +port is a message queue, used as a one-way communication channel. In +addition to a port, you need a port right, which can be a send right, +receive right, or send-once right. Depending on the port right, you +are allowed to send messages to the server, receive messages from it, +or send just one single message. +

+For every port, there exists exactly one task holding the receive +right, but there can be no or many senders. The send-once right is +useful for clients expecting a response message. They can give a +send-once right to the reply port along with the message. The kernel +guarantees that at some point, a message will be received on the reply +port (this can be a notification that the server destroyed the +send-once right). +

+You don't need to know much about the format a message takes to be +able to use the Mach IPC. The Mach interface generator mig hides the +details of composing and sending a message, as well as receiving the +reply message. To the user, it just looks like a function call, but +in truth the message could be sent over a network to a server running +on a different computer. The set of remote procedure calls a server +provides is the public interface of this server. + + +

How to get a port?

+
+

+Traditional Mach: +

    +
  • Nameserver provides ports to all registered servers.
  • +
  • The nameserver port itself is provided by Mach.
  • +
  • Like a phone book: One list.
  • +
+

+The Hurd: +

    +
  • The filesystem is used as the server namespace.
  • +
  • Root directory port is inserted into each task.
  • +
  • The C library finds other ports with hurd_file_name_lookup, + performing a pathname resolution.
  • +
  • Like a tree of phone books.
  • +
+
+

+So how does one get a port to a server? You need something like a +phone book for server ports, or otherwise you can only talk to +yourself. In the original Mach system, a special nameserver is +dedicated to that job. A task could get a port to the nameserver from +the Mach kernel and ask it for a port (with send right) to a server +that registered itself with the nameserver at some earlier time. +

+In the Hurd, there is no nameserver. Instead, the filesystem is used +as the server namespace. This works because there is always a root +filesystem in the Hurd (remember that the Hurd is a POSIX compatible +system); this is an assumption the people who developed Mach couldn't +make, so they had to choose a different strategy. You can use the +function hurd_file_name_lookup, which is part of the C library, to get +a port to the server belonging to a filename. Then you can start to +send messages to the server in the usual way. + +

Example of hurd_file_name_lookup

+
+mach_port_t identity;
+mach_port_t pwserver;
+kern_return_t err;
+
+pwserver = hurd_file_name_lookup
+                ("/servers/password");
+
+err = password_check_user (pwserver,
+                           0 /* root */, "supass",
+                           &identity);
+
+

+As a concrete example, the special filename +/servers/password can be used to request a port to the +Hurd password server, which is responsible to check user provided +passwords. +

+(explanation of the example) + +

Pathname resolution example

+
+

+Task: Lookup /mnt/readme.txt where /mnt has a mounted filesystem. +

    +
  • The C library asks the root filesystem server about + /mnt/readme.txt.
  • +
  • The root filesystem returns a port to the mnt filesystem server + (matching /mnt) and the retry name + /readme.txt.
  • +
  • The C library asks the mnt filesystem server about + /readme.txt.
  • +
  • The mnt filesystem server returns a port to itself and records + that this port refers to the regular file + /readme.txt.
  • +
+
+

+The C library itself does not have a full list of all available +servers. Instead pathname resolution is used to traverse through a +tree of servers. In fact, filesystems themselves are implemented by +servers (let us ignore the chicken and egg problem here). So all the +C library can do is to ask the root filesystem server about the +filename provided by the user (assuming that the user wants to resolve +an absolute path), using the dir_lookup RPC. If the +filename refers to a regular file or directory on the filesystem, the +root filesystem server just returns a port to itself and records that +this port corresponds to the file or directory in question. But if a +prefix of the full path matches the path of a server the root +filesystem knows about, it returns to the C library a port to this +server and the remaining part of the pathname that couldn't be +resolved. The C library than has to retry and query the other server +about the remaining path component. Eventually, the C library will +either know that the remaining path can't be resolved by the last +server in the list, or get a valid port to the server in question. + +

Mapping the POSIX Interface

+
+ + + + + + + + + + + + + + + + + + + +
FiledescriptorPort to server providing the file
fd = open(name,...)dir_lookup(..,name,..,&port)
+[pathname resolution]
read(fd, ...)io_read(port, ...)
write(fd, ...)io_write(port, ...)
fstat(fd, ...)io_stat(port, ...)
...
+
+

+It should by now be obvious that the port returned by the server can +be used to query the files status, content and other information from +the server, if good remote procedure calls to do that are defined and +implemented by it. This is exactly what happens. Whenever a file is +opened using the C libraries open() call, the C library +uses the above pathname resolution to get a port to a server providing +the file. Then it wraps a file descriptor around it. So in the Hurd, +for every open file descriptor there is a port to a server providing +this file. Many other C library calls like read() and +write() just call a corresponding RPC using the port +associated with the file descriptor. + +

File System Servers

+
+
    +
  • Provide file and directory services for ports (and more).
  • +
  • These ports are returned by a directory lookup.
  • +
  • Translate filesystem accesses through their root path (hence the + name translator).
  • +
  • The C library maps the POSIX file and directory interface (and + more) to RPCs to the filesystem servers ports, but also does work on + its own.
  • +
  • Any user can install file system servers on inodes they own.
  • +
+
+

+So we don't have a single phone book listing all servers, but rather a +tree of servers keeping track of each other. That's really like +calling your friend and asking for the phone number of the blond girl +at the party yesterday. He might refer you to a friend who hopefully +knows more about it. Then you have to retry. +

+This mechanism has huge advantages over a single nameserver. First, +note that standard unix permissions on directories can be used to +restrict access to a server (this requires that the filesystems +providing those directories behave). You just have to set the +permissions of a parent directory accordingly and provide no other way +to get a server port. +

+But there are much deeper implications. Most of all, a pathname never +directly refers to a file, it refers to a port of a server. That +means that providing a regular file with static data is just one of +the many options the server has to service requests on the file port. +A server can also create the data dynamically. For example, a server +associated with /dev/random can provide new random data +on every io_read() on the port to it. A server +associated with /dev/fortune can provide a new fortune +cookie on every open(). +

+While a regular filesystem server will just serve the data as stored +in a filesystem on disk, there are servers providing purely virtual +information, or a mixture of both. It is up to the server to behave +and provide consistent and useful data on each remote procedure call. +If it does not, the results may not match the expectations of the user +and confuse him. +

+A footnote from the Hurd info manual: +

+(1) You are lost in a maze of twisty little filesystems, all +alike.... +
+

+Because a server installed in the filesystem namespace translates all +filesystem operations that go through its root path, such a server is +also called "active translator". You can install translators using +the settrans command with the -a option. + +

Active vs Passive

+
+

+Active Translators: +

    +
  • "settrans -a /cdrom /hurd/isofs /dev/hd2"
  • +
  • Are running filesystem servers.
  • +
  • Are attached to the root node they translate.
  • +
  • Run as a normal process.
  • +
  • Go away with every reboot, or even time out.
  • +
+
+

+Many translator settings remain constant for a long time. It would be +very lame to always repeat the same couple of dozens settrans calls +manually or at boot time. So the Hurd provides a filesystem extension +that allows to store translator settings inside the filesystem and let +the filesystem servers do the work to start those servers on demand. +Such translator settings are called "passive translators". A passive +translator is really just a command line string stored in an inode of +the filesystem. If during a pathname resolution a server encounters +such a passive translator, and no active translator does exist already +(for this node), it will use this string to start up a new translator +for this inode, and then let the C library continue with the path +resolution as described above. Passive translators are installed with +settrans using the -p option (which is already the +default). + +
+

+Passive Translators: +

    +
  • "settrans /mnt /hurd/ext2fs /dev/hd1s1"
  • +
  • Are stored as command strings into an inode.
  • +
  • Are used to start a new active translator if there isn't + one.
  • +
  • Startup is transparent to the user.
  • +
  • Startup happens the first time the server is needed.
  • +
  • Are permanent across reboots (like file data).
  • +
+
+

+So passive translators also serve as a sort of automounting feature, +because no manual interaction is required. The server start up is +deferred until the service is need, and it is transparent to the user. +

+When starting up a passive translator, it will run as a normal process +with the same user and group id as those of the underlying inode. Any +user is allowed to install passive and active translators on inodes +that he owns. This way the user can install new servers into the +global namespace (for example, in his home or tmp directory) and thus +extend the functionality of the system (recall that servers can +implement other remote procedure calls beside those used for files and +directories). A careful design of the trusted system servers makes +sure that no permissions leak out. +

+In addition, users can provide their own implementations of some of +the system servers instead the system default. For example, they can +use their own exec server to start processes. The user specific exec +server could for example start java programs transparently (without +invoking the interpreter manually). This is done by setting the +environment variable EXECSERVERS. The systems default +exec server will evaluate this environment variable and forward the +RPC to each of the servers listed in turn, until some server accepts +it and takes over. The system default exec server will only do this +if there are no security implications. (XXX There are other ways to +start new programs than by using the system exec server. Those are +still available.) +

+Let's take a closer look at some of the Hurd servers. It was already +mentioned that only few system servers are mandatory for users. To +establish your identity within the Hurd system, you have to +communicate with the trusted systems authentication server +auth. To put the system administrator into control over +the system components, the process server does some global +bookkeeping. +

+But even these servers can be ignored. However, registration with the +authentication server is the only way to establish your identity +towards other system servers. Likewise, only tasks registered as +processes with the process server can make use of its services. + +

Authentication

+
+

+A user identity is just a port to an authserver. The auth server +stores four set of ids for it: +

    +
  • effective user ids
  • +
  • effective group ids
  • +
  • available user ids
  • +
  • available group ids
  • +
+

+Basic properties: +

    +
  • Any of these can be empty.
  • +
  • A 0 among the user ids identifies the superuser.
  • +
  • Effective ids are used to check if the user has the + permission.
  • +
  • Available ids can be turned into effective ids on user + request.
  • +
+
+

+The Hurd auth server is used to establish the identity of a user for a +server. Such an identity (which is just a port to the auth server) +consists of a set of effective user ids, a set of effective group ids, +a set of available user ids and a set of available group ids. Any of +these sets can be empty. + +

Operations on authentication ports

+
+

+The auth server provides the following operations on ports: +

    +
  • Merge the ids of two ports into a new one.
  • +
  • Return a new port containing a subset of the ids in a port.
  • +
  • Create a new port with arbitrary ids (superuser only).
  • +
  • Establish a trusted connection between users and servers.
  • +
+
+

+If you have two identities, you can merge them and request an identity +consisting of the unions of the sets from the auth server. You can +also create a new identity consisting only of subsets of an identity +you already have. What you can't do is extending your sets, unless +you are the superuser which is denoted by having the user id 0. + +

Establishing trusted connections

+
+
    +
  • User provides a rendezvous port to the server (with + io_reauthenticate).
  • +
  • User calls auth_user_authenticate on the + authentication port (his identity), passing the rendezvous port.
  • +
  • Server calls auth_server_authenticate on its + authentication port (to a trusted auth server), passing the + rendezvous port and the server port.
  • +
  • If both authentication servers are the same, it can match the + rendezvous ports and return the server port to the user and the user + ids to the server.
  • +
+
+

+Finally, the auth server can establish the identity of a user for a +server. This is done by exchanging a server port and a user identity +if both match the same rendezvous port. The server port will be +returned to the user, while the server is informed about the id sets +of the user. The server can then serve or reject subsequent RPCs by +the user on the server port, based on the identity it received from +the auth server. +

+Anyone can write a server conforming to the auth protocol, but of +course all system servers use a trusted system auth server to +establish the identity of a user. If the user is not using the system +auth server, matching the rendezvous port will fail and no server port +will be returned to the user. Because this practically requires all +programs to use the same auth server, the system auth server is +minimal in every respect, and additional functionality is moved +elsewhere, so user freedom is not unnecessarily restricted. + +

Password Server

+
+

+The password server /servers/password runs as root and +returns a new authentication port in exchange for a unix password. +

+The ids corresponding to the authentication port match the unix user +and group ids. +

+Support for shadow passwords is implemented here. +

+

+The password server sits at /servers/password and runs as +root. It can hand out ports to the auth server in exchange for a unix +password, matching it against the password or shadow file. Several +utilities make use of this server, so they don't need to be setuid +root. + +

Process Server

+
+

+The superuser must remain control over user tasks, so: +

    +
  • All mach tasks are associated with a PID in the system default + proc server.
  • +
+

+Optionally, user tasks can store: +

    +
  • Their environment variables.
  • +
  • Their argument vector.
  • +
  • A port, which others can request based on the PID (like a + nameserver).
  • +
+

+Also implemented in the proc server: +

    +
  • Sessions and process groups.
  • +
  • Global configuration not in Mach, like hostname, hostid, system + version.
  • +
+
+

+The process server is responsible for some global bookkeeping. As +such it has to be trusted and is not replaceable by the user. +However, a user is not required to use any of its service. In that +case the user will not be able to take advantage of the POSIXish +appearance of the Hurd. +

+The Mach Tasks are not as heavy as POSIX processes. For example, +there is no concept of process groups or sessions in Mach. The proc +server fills in the gap. It provides a PID for all Mach tasks, and +also stores the argument line, environment variables and other +information about a process (if the mach tasks provide them, which is +usually the case if you start a process with the default +fork()/exec()). A process can also register +a message port with the proc server, which can then be requested by +anyone. So the proc server also functions as a nameserver using the +process id as the name. +

+The proc server also stores some other miscellaneous information not +provided by Mach, like the hostname, hostid and system version. +Finally, it provides facilities to group processes and their ports +together, as well as to convert between pids, process server ports and +mach task ports. +
+

+User tasks not registering themselve with proc only have a PID assigned. +

+Users can run their own proc server in addition to the system default, +at least for those parts of the interface that don't require superuser +privileges. +

+

+Although the system default proc server can't be avoided (all Mach +tasks spawned by users will get a pid assigned, so the system +administrator can control them), users can run their own additional +process servers if they want, implementing the features not requiring +superuser privileges. + +

Filesystems

+
+

+Store based filesystems +

    +
  • ext2fs
  • +
  • ufs
  • +
  • isofs (iso9660, RockRidge, GNU extensions)
  • +
  • fatfs (under development)
  • +
+

+Network file systems +

    +
  • nfs
  • +
  • ftpfs
  • +
+

+Miscellaneous +

    +
  • hostmux
  • +
  • usermux
  • +
  • tmpfs (under development)
  • +
+
+

+We already talked about translators and the file system service they +provide. Currently, we have translators for the ext2, ufs and iso9660 +filesystems. We also have an nfs client and an ftp filesystem. +Especially the latter is intriguing, as it provides transparent access +to ftp servers in the filesystem. Programs can start to move away +from implementing a plethora of network protocols, as the files are +directly available in the filesystem through the standard POSIX file +interface. + + +

Developing the Hurd

+
+

+Over a dozen libraries support the development of new servers. +

+For special server types highly specialized +libraries require only the implementation of a +number of callback functions. +

    +
  • Use libdiskfs for store based filesystems.
  • +
  • Use libnetfs for network filesystems, also for + virtual filesystems.
  • +
  • Use libtrivfs for simple filesystems providing only + a single file or directory.
  • +
+
+

+The Hurd server protocols are complex enough to allow for the +implementation of a POSIX compatible system with GNU extensions. +However, a lot of code can be shared by all or at least similar +servers. For example, all storage based filesystems need to be able to +read and write to a store medium splitted in blocks. The Hurd comes +with several libraries which make it easy to implement new servers. +Also, there are already a lot of examples of different server types in +the Hurd. This makes writing a new server easier. +

+libdiskfs is a library that supports writing store based +filesystems like ext2fs or ufs. It is not very useful for filesystems +which are purely virtual, like /proc or files in +/dev. +

+libnetfs is intended for filesystems which provide a rich +directory hierarchy, but don't use a backing store (for example ftpfs, +nfs). +

+libtrivfs is intended for filesystems which just provide +a single inode or directory. Most servers which are not intended to +provide a filesystem but other services (like +/servers/password) use it to provide a dummy file, so +that file operations on the servers node will not return errors. But +it can also be used to provide meaningful data in a single file, like +a device store or a character device. + +

Store Abstraction

+
+

+Another very useful library is libstore, which is used by all store +based filesystems. It provides a store media abstraction. A store +consists of a store class and a name (which itself can sometimes +contain stores). +

+Primitive store classes: +

    +
  • device store like device:hd2, device:hd0s1, device:fd0
  • +
  • file store like file:/tmp/disk_image
  • +
  • task store like task:PID
  • +
  • zero store like zero:4m (like /dev/zero, of size 4 MB)
  • +
+
+
+

+Composed store classes: +

    +
  • copy store like copy:zero:4m
  • +
  • gunzip/bunzip2 store like gunzip:device:fd0
  • +
  • concat store like concat:device:hd0s2:device:hd1s5
  • +
  • ileave store (RAID-0(2))
  • +
  • remap store like remap:10+20,50+:file:/tmp/blocks
  • +
  • ...
  • +
+

+Wanted: A similar abstraction for streams (based on channels), which +can be used by network and character device servers. +

+

+libstore provides a store abstraction, which is used by +all store based filesystems. The store is determined by a type and a +name, but some store types modify another store rather than providing +a new store, and thus stores can be stacked. For example, the device +store type expects a Mach device, but the remap store expects a list +of blocks to pick from another store, like remap:1+:device:hd2, which +would pick all blocks from hd2 but the first one, which skipped. +Because this functionality is provided in a library, all libstore +using filesystems support many different store kinds, and adding a new +store type is enough to make all store based filesystems support it. + +

Debian GNU/Hurd

+
+

+Goal: +

    +
  • Provide a binary distribution of the Hurd that is easy to + install.
  • +
+

+Constraints: +

    +
  • Use the same source packages as Debian GNU/Linux.
  • +
  • Use the same infrastructure: +
      +
    • Policy
    • +
    • Archive
    • +
    • Bug tracking system
    • +
    • Release process
    • +
  • +
+

+Side Goal: +

    +
  • Prepare Debian for the future: +
      +
    • More flexibility in the base system
    • +
    • Identify dependencies on the Linux kernel
    • +
  • +
+
+

+The Debian distribution of the GNU Hurd that I started in 1998 is +supposed to become a complete binary distribution of the Hurd that is +easy to install. + +

Status of the Debian GNU/Hurd binary archive

+

+See +http://buildd.debian.org/stats/graph.png +for the most current version of the statistic. + +

Status of the Debian infrastructure

+
+

+Plus: +

    +
  • Source packages can identify build and host OS using + dpkg-architecture.
  • +
+

+Minus: +

    +
  • The binary architecture field is insufficient.
  • +
  • The BTS has no architecture tag.
  • +
  • The policy/FHS need (small) Hurd specific extensions.
  • +
+
+

+While good compatibiity can be achieved at the source level, +the binary packages can not always express their relationship +to the available architectures sufficiently. +

+For example, the Linux version of makedev is binary-all, where +a binary-all-linux relationship would be more appropriate. +

+More work has to be done here to fix the tools. + +

Status of the Debian Source archive

+
+
    +
  • Most packages just work.
  • +
  • Maintainers are usually responsive and cooperative.
  • +
  • Turtle, the autobuilder, crunches through the whole list right + now.
  • +
+

+Common pitfalls are POSIX incompatibilities: +

    +
  • Upstream: +
      +
    • Unconditional use of PATH_MAX + (MAXPATHLEN), MAXHOSTNAMELEN.
    • +
    • Unguarded use of Linux kernel features.
    • +
    • Use of legacy interfaces (sys_errlist, + termio).
    • +
  • +
  • Debian: +
      +
    • Unguarded activation of extensions available with Linux.
    • +
    • Low quality patches.
    • +
    • Assuming GNU/Linux in package scripts.
    • +
  • +
+
+

+Most packages are POSIX compatible and can be compiled without +changes on the Hurd. The maintainers of the Debian source packages +are usually very kind, responsiver and helpful. +

+The Turtle autobuilder software (http://turtle.sourceforge.net) +builds the Debian packages on the Hurd automatically. + +

Debian GNU/Hurd: Good idea, bad idea?

+
+

+Upstream benefits: +

    +
  • Software packages become more portable.
  • +
+

+Debian benefits: +

    +
  • Debian becomes more portable.
  • +
  • Maintainers learn about portability and other systems.
  • +
  • Debian gets a lot of public recognition.
  • +
+

+GNU/Hurd benefits: +

    +
  • Large software base.
  • +
  • Great infrastructure.
  • +
  • Nice community to partner with.
  • +
+
+

+The sheet lists the advantages of all groups involved. + +

End

+
+

+Join us at +

+
+

+List of contacts. -- cgit v1.3.1 From 2213166ab5b58cf89f3b07eded20ab2a03d9c681 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 12:10:57 +0100 Subject: Integrate hurd-and-linux.html. --- hurd-and-linux.html | 104 --------------------------------- hurd/documentation.mdwn | 2 + hurd/documentation/hurd-and-linux.html | 47 +++++++++++++++ 3 files changed, 49 insertions(+), 104 deletions(-) delete mode 100644 hurd-and-linux.html create mode 100644 hurd/documentation/hurd-and-linux.html (limited to 'hurd/documentation') diff --git a/hurd-and-linux.html b/hurd-and-linux.html deleted file mode 100644 index d9181d88..00000000 --- a/hurd-and-linux.html +++ /dev/null @@ -1,104 +0,0 @@ - - - -The Hurd and Linux - GNU Project - Free Software Foundation (FSF) - - - - - -

The Hurd and Linux

-[ - - - Chinese(Simplified) -| Chinese(Traditional) -| Hebrew -| English -| Spanish -] - -

-by Richard Stallman. - -

- -People sometimes ask, ``Why did the FSF develop a new free kernel -instead of using Linux?'' It's a reasonable question. The answer, -briefly, is that that is not the question we faced. - -

-When we started developing the Hurd in 1990, the question facing us -was, ``How can we get a free kernel for the GNU system?'' There was -no free Unix-like kernel then, and we knew of no other plan to write -one. The only way we could expect to have a free kernel was to write -it ourselves. So we started. - -

-We heard about Linux after its release. At that time, the question -facing us was, ``Should we cancel the Hurd project and use Linux -instead?'' - -

-We heard that Linux was not at all portable (this may not be true -today, but that's what we heard then). And we heard that Linux was -architecturally on a par with the Unix kernel; our work was leading to -something much more powerful. - -

-Given the years of work we had already put into the Hurd, we decided -to finish it rather than throw them away. - -

-If we did face the question that people ask---if Linux were already -available, and we were considering whether to start writing another -kernel---we would not do it. Instead we would choose another project, -something to do a job that no existing free software can do. - -

-But we did start the Hurd, back then, and now we have made it work. -We hope its superior architecture will make free operating systems -more powerful. - -


- -[ - - - Chinese(Simplified) -| Chinese(Traditional) -| Hebrew -| English -| Spanish -] - -
- -Return to GNU's home page. -

-FSF & GNU inquiries & questions to -gnu@gnu.org. -Other ways to contact the FSF. -

-Comments on these web pages to -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved. - -

-Updated: - -$Date$ $Author$ - -

- -
- - diff --git a/hurd/documentation.mdwn b/hurd/documentation.mdwn index a8c3a988..a32bc84f 100644 --- a/hurd/documentation.mdwn +++ b/hurd/documentation.mdwn @@ -17,6 +17,8 @@ is included in the section entitled * [[FAQ]] + * [[*The_Hurd_and_Linux*|hurd-and-linux]], a comment by Richard Stallman. + * [[*Towards_a_New_Strategy_of_OS_Design*|hurd-paper]], an architectural overview by Thomas Bushnell, BSG. diff --git a/hurd/documentation/hurd-and-linux.html b/hurd/documentation/hurd-and-linux.html new file mode 100644 index 00000000..8eccd62c --- /dev/null +++ b/hurd/documentation/hurd-and-linux.html @@ -0,0 +1,47 @@ +[[meta copyright="Copyright © 1996, 1997, 1998, 2008 Free Software Foundation, +Inc."]] + +[[meta license="Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved."]] + +[[meta title="The Hurd and Linux"]] + +by Richard Stallman. + +

+People sometimes ask, ``Why did the FSF develop a new free kernel +instead of using Linux?'' It's a reasonable question. The answer, +briefly, is that that is not the question we faced. + +

+When we started developing the Hurd in 1990, the question facing us +was, ``How can we get a free kernel for the GNU system?'' There was +no free Unix-like kernel then, and we knew of no other plan to write +one. The only way we could expect to have a free kernel was to write +it ourselves. So we started. + +

+We heard about Linux after its release. At that time, the question +facing us was, ``Should we cancel the Hurd project and use Linux +instead?'' + +

+We heard that Linux was not at all portable (this may not be true +today, but that's what we heard then). And we heard that Linux was +architecturally on a par with the Unix kernel; our work was leading to +something much more powerful. + +

+Given the years of work we had already put into the Hurd, we decided +to finish it rather than throw them away. + +

+If we did face the question that people ask---if Linux were already +available, and we were considering whether to start writing another +kernel---we would not do it. Instead we would choose another project, +something to do a job that no existing free software can do. + +

+But we did start the Hurd, back then, and now we have made it work. +We hope its superior architecture will make free operating systems +more powerful. -- cgit v1.3.1 From a3bbfa6bc8a3abd8dd3c56fd8fe975028f6fa005 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 12:56:40 +0100 Subject: Integrate whatis/translator.html. --- hurd/documentation.mdwn | 2 + hurd/documentation/translators.html | 236 +++++++++++++++++++++++++++++ hurd/translator.mdwn | 2 + whatis/translator.html | 290 ------------------------------------ 4 files changed, 240 insertions(+), 290 deletions(-) create mode 100644 hurd/documentation/translators.html delete mode 100644 whatis/translator.html (limited to 'hurd/documentation') diff --git a/hurd/documentation.mdwn b/hurd/documentation.mdwn index a32bc84f..be0874e7 100644 --- a/hurd/documentation.mdwn +++ b/hurd/documentation.mdwn @@ -24,6 +24,8 @@ is included in the section entitled * [[*The_Hurd*|hurd-talk]], a presentation by Marcus Brinkmann. + * A document about *[[translators]]* by Marcus Brinkmann. + * [[*A_Critique_of_the_GNU_Hurd_Multi-server_Operating_System*|critique]], an analysis of the GNU Hurd on GNU Mach system, written by Neal Walfield and Marcus Brinkmann. diff --git a/hurd/documentation/translators.html b/hurd/documentation/translators.html new file mode 100644 index 00000000..4e47a9c0 --- /dev/null +++ b/hurd/documentation/translators.html @@ -0,0 +1,236 @@ +[[meta copyright="Copyright © 1998, 1999, 2007, 2008 Free Software Foundation, +Inc."]] + +[[meta license="Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved."]] + +[[meta title="Translators"]] + +By Marcus Brinkmann. + +

+

Concept

+

+Before we take a closer look at translators, let us consider regular +filesystems. A filesystem is store for a hierarchical tree of directories +and files. You access directories and files by a special character string, +the path. Furthermore, there are symbolic links to refer to one file at +several places in the tree, there are hard links to give one and the same +file several names. There are also special device files for communication +with the hardware device drivers of the kernel, and there are mount points +to include other stores in the directory tree. Then there are obscure +objects like fifos and hard links.

+

+Although these objects are very different, they share some common +properties, for example, they have all an owner and a group associated with +them as well as access rights (permissions). This information is written in +inodes. This is a actually a further commonality: Every object has exactly +one inode associated with it (hard links are somewhat special as they share +one and the same inode). Sometimes, the inode has further information +stored in it. For example, the inode can contain the target of a symbolic +link.

+

+However, these commonalities are usually not exploited in the +implementations, despite the common programming interface to them. All +inodes can be accessed through the standard POSIX calls, for example +read() and write(). For example, to add a new +object type (for example a new link type) to a common monolithic unix +kernel, you would need to modify the code for each filesystem +seperately.

+

+In the Hurd, things work differently. Although in the Hurd a special +filesystem server can exploit special properties of standard object types +like links (in the ext2 filesystem with fast links, for example), it has a +general interface to add such features without modifying existing code.

+

+The trick is to allow a program to be inserted between the actual content of +a file and the user accessing this file. Such a program is called a +translator, because it is able to process the incoming requests in many +different ways. In other words, a translator is a Hurd server which provides +the basic filesystem interface.

+

+Translators have very interesting properties. From the kernels point of +view, they are just another user process. This means, translators can be run +by any user. You don't need root priviligies to install or modify a +translator, you only need the access rights for the underlying inode the +translator is attached to. Many translators don't require an actual file to +operate, they can provide information by their own means. This is why +the information about translators is stored in the inode.

+

+Translators are responsible to serve all file system operations that involve +the inode they are attached to. Because they are not restricted to the usual +set of objects (device file, link etc), they are free to return anything +that makes sense to the programmer. One could imagine a translator that +behaves like a directory when accessed by cd or +ls and at the same time behaves like a file when accessed by +cat.

+

Examples

+

Mount Points

+

+A mount point can be seen as an inode that has a special translator attached +to it. Its purpose would be to translate filesystem operations on the mount +point in filesystem operations on another store, let's say, another +partition.

+

+Indeed, this is how filesystems are implemented under the Hurd. A +filesystem is a translator. This translator takes a store as its argument, +and is able to serve all filesystem operations transparently.

+

Device Files

+

+There are many different device files, and in systems with a monolithical +kernel, they are all provided by the kernel itself. In the Hurd, all device +files are provided by translators. One translator can provide support for +many similar device files, for example all hard disk partitions. This way, +the number of actual translators needed is quite small. However, note that +for each device file accessed, a seperate translator task is started. +Because the Hurd is heavily multi threaded, this is very cheap.

+

+When hardware is involved, a translator usually starts to communicate with +the kernel to get the data from the hardware. However, if no hardware access +is necessary, the kernel does not need to be involved. For example, +/dev/zero does not require hardware access, and can therefore +be implemented completely in user space.

+

Symbolic Links

+

+A symbolic link can be seen as a translator. Accesing the symbolic link +would start up the translator, which would forward the request to the +filesystem that contains the file the link points to.

+

+However, for better performance, filesystems that have native support +for symbolic links can take advantage of this feature and implement +symbolic links differently. Internally, accessing a symbolic link would not +start a new translator process. However, to the user, it would still look +as if a passive translator is involved (see below for an explanation what a +passsive translator is).

+

+Because the Hurd ships with a symlink translator, any filesystem server that +provides support for translators automatically has support for symlinks (and +firmlinks, and device files etc)! This means, you can get a working +filesystem very fast, and add native support for symlinks and other features +later.

+

Passive Translators, Active Translators

+

+There are two types of translators, passive and active. They are really +completely different things, so don't mix them up, but they have a close +relation to each other.

+

Active Translators

+

+An active translator is a running translator process, as introduced above. +You can set and remove active translators using the +settrans -a +command. The -a option is necessary to tell +settrans that you want to modify the active translator.

+

+The settrans command takes three kind of arguments. First, you +can set options for the settrans command itself, like +-a to modify the active translator. Then you set the inode you +want to modify. Remember that a translator is always associated with an +inode in the directory hierarchy. You can only modify one inode at a time. +If you do not specify any more arguments, settrans will try to +remove an existing translator. How hard it tries depends on the force +options you specify (if the translator is in use by any process, you will +get "device or resource busy" error message unless you force it to go away).

+

+But if you specify further arguments, it will be interpreted as a command +line to run the translator. This means, the next argument is the filename of +the translator executable. Further arguments are options to the translator, +and not to the settrans command.

+

+For example, to mount an ext2fs partition, you can run +settrans -a -c /mnt /hurd/ext2fs /dev/hd2s5. The +-c option will create the mount point for you if it doesn't +exist already. This does not need to be a directory, by the way. To unmount, +you would try settrans -a /mnt.

+

Passive Translators

+

+A passive translator is set and modified with the same syntax as the active +translator (just leave away the -a, so everything said above is +true for passive translators, too. However, there is a difference: passive +translators are not yet started.

+

+This makes sense, because this is what you usually want. You don't want the +partition mounted unless you really access files on this partition. You +don't want to bring up the network unless there is some traffic and so +on.

+

+Instead, the first time the passive translator is accessed, it is +automatically read out of the inode and an active translator is started on +top of it using the command line that was stored in the inode. This is +similar to the Linux automounter functionality. However, it does not come as +an additional bonus that you have to set up manually, but an integral part of +the system. So, setting passive translators defers starting the translator +task until you really need it. By the way, if the active translator dies for +some reason, the next time the inode is accessed the translator is +restarted.

+

+There is a further difference: active translators can die or get lost. As +soon as the active translator process is killed (for example, because you +reboot the machine) it is lost forever. Passive translators are not transient +and stay in the inode during reboots until you modify them with the +settrans program or delete the inodes they are attached to. +This means, you don't need to maintain a configuration file with your mount +points.

+

+One last point: Even if you have set a passive translator, you can still +set a different active translator. Only if the translator is automatically +started because there was no active translator the time the inode was +accessed the passive translator is considered.

+

Managing Translators

+

+As mentioned above, you can use +settrans +to set and alter passive and active translators. There are a lot of options +to change the behaviour of settrans in case something goes +wrong, and to conditionalize its action. Here are some common usages:

+ +

+You can use the showtrans +command to see if a translator is attached to an inode. This will only show +you the passive translator though.

+

+You can change the options of an active (filesystem) translator with +fsysopts without actually restarting it. This is very +convenient. For example, you can do what is called "remounting a +partition read-only" under Linux simply by running fsysopts +/mntpoint --readonly. The running active translator +will change its behaviour according to your request if possible. +fsysopts /mntpoint without a parameter shows you the current +settings.

+

Examples

+

+I recommend that you start by reading the /bin/mount command, +it is only a small script. Because setting filesystem translators is +similar to mounting partitions, you can easily grasp the concept this way. +Make a file system image with dd if=/dev/zero of=dummy.fs bs=1024k +count=8; mke2fs dummy.fs and "mount" it with settrans -c dummy +/hurd/ext2fs `pwd`/dummy.fs. Note that the translator is not started +yet, no new ext2fs process is running (verify with ps +Aux). Check that everything is correct using showtrans

+

+Now type ls dummy and you will notice the short delay that +occurs while the translator is started. After that, there will be no more +delays accessing dummy. Under Linux, one would say that you automounted a +loop file system. Check with ps Aux that there is an ext2fs +dummy process up and running now. Now put some files into the new +directory. Try to make the filesystem read-only with fsysopts. +Note how further write attempts fail now. Try to kill the active translator +with settrans -g.

+

+You should have some understanding of what is going on now. Now remember +that this was only one special server, the Hurd ext2fs server. +There are many more server in the hurd directory. Some of them +are for filesystems. Some are needed for file system features like links. +Some are needed for device files. Some are useful for networking. Imagine +"mounting" an FTP Server with settrans and downloading files +simply with the standard cp command. Or editing your web sites +with emacs /ftp/homepage.my.server.org/index.html!

diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index 889f02a6..1a987b09 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -40,6 +40,8 @@ Also there is an [[writing/example]] about how to write a simple translator. See some [[examples]] about how to use translators. +Marcus Brinkmann has written a document about [[documentation/translators]]. + # Existing Translators diff --git a/whatis/translator.html b/whatis/translator.html deleted file mode 100644 index 516d5049..00000000 --- a/whatis/translator.html +++ /dev/null @@ -1,290 +0,0 @@ - - - - - GNU Hurd - Free Software Foundation (FSF) - - - - - - - - - - -
-The GNU Hurd
-

-Whatis?
-Howto?
-

- -

- -Acknowledgements
- -

-

GNU Hurd

-

Translators

-

By Marcus Brinkmann

- -

Concept

-

-Before we take a closer look at translators, let us consider regular -filesystems. A filesystem is store for a hierarchical tree of directories -and files. You access directories and files by a special character string, -the path. Furthermore, there are symbolic links to refer to one file at -several places in the tree, there are hard links to give one and the same -file several names. There are also special device files for communication -with the hardware device drivers of the kernel, and there are mount points -to include other stores in the directory tree. Then there are obscure -objects like fifos and hard links.

-

-Although these objects are very different, they share some common -properties, for example, they have all an owner and a group associated with -them as well as access rights (permissions). This information is written in -inodes. This is a actually a further commonality: Every object has exactly -one inode associated with it (hard links are somewhat special as they share -one and the same inode). Sometimes, the inode has further information -stored in it. For example, the inode can contain the target of a symbolic -link.

-

-However, these commonalities are usually not exploited in the -implementations, despite the common programming interface to them. All -inodes can be accessed through the standard POSIX calls, for example -read() and write(). For example, to add a new -object type (for example a new link type) to a common monolithic unix -kernel, you would need to modify the code for each filesystem -seperately.

-

-In the Hurd, things work differently. Although in the Hurd a special -filesystem server can exploit special properties of standard object types -like links (in the ext2 filesystem with fast links, for example), it has a -general interface to add such features without modifying existing code.

-

-The trick is to allow a program to be inserted between the actual content of -a file and the user accessing this file. Such a program is called a -translator, because it is able to process the incoming requests in many -different ways. In other words, a translator is a Hurd server which provides -the basic filesystem interface.

-

-Translators have very interesting properties. From the kernels point of -view, they are just another user process. This means, translators can be run -by any user. You don't need root priviligies to install or modify a -translator, you only need the access rights for the underlying inode the -translator is attached to. Many translators don't require an actual file to -operate, they can provide information by their own means. This is why -the information about translators is stored in the inode.

-

-Translators are responsible to serve all file system operations that involve -the inode they are attached to. Because they are not restricted to the usual -set of objects (device file, link etc), they are free to return anything -that makes sense to the programmer. One could imagine a translator that -behaves like a directory when accessed by cd or -ls and at the same time behaves like a file when accessed by -cat.

-

Examples

-

Mount Points

-

-A mount point can be seen as an inode that has a special translator attached -to it. Its purpose would be to translate filesystem operations on the mount -point in filesystem operations on another store, let's say, another -partition.

-

-Indeed, this is how filesystems are implemented under the Hurd. A -filesystem is a translator. This translator takes a store as its argument, -and is able to serve all filesystem operations transparently.

-

Device Files

-

-There are many different device files, and in systems with a monolithical -kernel, they are all provided by the kernel itself. In the Hurd, all device -files are provided by translators. One translator can provide support for -many similar device files, for example all hard disk partitions. This way, -the number of actual translators needed is quite small. However, note that -for each device file accessed, a seperate translator task is started. -Because the Hurd is heavily multi threaded, this is very cheap.

-

-When hardware is involved, a translator usually starts to communicate with -the kernel to get the data from the hardware. However, if no hardware access -is necessary, the kernel does not need to be involved. For example, -/dev/zero does not require hardware access, and can therefore -be implemented completely in user space.

-

Symbolic Links

-

-A symbolic link can be seen as a translator. Accesing the symbolic link -would start up the translator, which would forward the request to the -filesystem that contains the file the link points to.

-

-However, for better performance, filesystems that have native support -for symbolic links can take advantage of this feature and implement -symbolic links differently. Internally, accessing a symbolic link would not -start a new translator process. However, to the user, it would still look -as if a passive translator is involved (see below for an explanation what a -passsive translator is).

-

-Because the Hurd ships with a symlink translator, any filesystem server that -provides support for translators automatically has support for symlinks (and -firmlinks, and device files etc)! This means, you can get a working -filesystem very fast, and add native support for symlinks and other features -later.

-

Passive Translators, Active Translators

-

-There are two types of translators, passive and active. They are really -completely different things, so don't mix them up, but they have a close -relation to each other.

-

Active Translators

-

-An active translator is a running translator process, as introduced above. -You can set and remove active translators using the -settrans -a -command. The -a option is necessary to tell -settrans that you want to modify the active translator.

-

-The settrans command takes three kind of arguments. First, you -can set options for the settrans command itself, like --a to modify the active translator. Then you set the inode you -want to modify. Remember that a translator is always associated with an -inode in the directory hierarchy. You can only modify one inode at a time. -If you do not specify any more arguments, settrans will try to -remove an existing translator. How hard it tries depends on the force -options you specify (if the translator is in use by any process, you will -get "device or resource busy" error message unless you force it to go away).

-

-But if you specify further arguments, it will be interpreted as a command -line to run the translator. This means, the next argument is the filename of -the translator executable. Further arguments are options to the translator, -and not to the settrans command.

-

-For example, to mount an ext2fs partition, you can run -settrans -a -c /mnt /hurd/ext2fs /dev/hd2s5. The --c option will create the mount point for you if it doesn't -exist already. This does not need to be a directory, by the way. To unmount, -you would try settrans -a /mnt.

-

Passive Translators

-

-A passive translator is set and modified with the same syntax as the active -translator (just leave away the -a, so everything said above is -true for passive translators, too. However, there is a difference: passive -translators are not yet started.

-

-This makes sense, because this is what you usually want. You don't want the -partition mounted unless you really access files on this partition. You -don't want to bring up the network unless there is some traffic and so -on.

-

-Instead, the first time the passive translator is accessed, it is -automatically read out of the inode and an active translator is started on -top of it using the command line that was stored in the inode. This is -similar to the Linux automounter functionality. However, it does not come as -an additional bonus that you have to set up manually, but an integral part of -the system. So, setting passive translators defers starting the translator -task until you really need it. By the way, if the active translator dies for -some reason, the next time the inode is accessed the translator is -restarted.

-

-There is a further difference: active translators can die or get lost. As -soon as the active translator process is killed (for example, because you -reboot the machine) it is lost forever. Passive translators are not transient -and stay in the inode during reboots until you modify them with the -settrans program or delete the inodes they are attached to. -This means, you don't need to maintain a configuration file with your mount -points.

-

-One last point: Even if you have set a passive translator, you can still -set a different active translator. Only if the translator is automatically -started because there was no active translator the time the inode was -accessed the passive translator is considered.

-

Managing Translators

-

-As mentioned above, you can use -settrans -to set and alter passive and active translators. There are a lot of options -to change the behaviour of settrans in case something goes -wrong, and to conditionalize its action. Here are some common usages:

-
  • settrans -c /mnt /hurd/ext2fs /dev/hd2s5 mounts a -partition, the translator will stay across reboots.
  • -
  • settrans -a /mnt /hurd/ext2fs ~/dummy.fs mounts a -filesystem inside a data file, the translator will go away if it dies.
  • -
  • settrans -fg /nfs-data forces a translator to go away.
  • -
-

-You can use the showtrans -command to see if a translator is attached to an inode. This will only show -you the passive translator though.

-

-You can change the options of an active (filesystem) translator with -fsysopts without actually restarting it. This is very -convenient. For example, you can do what is called "remounting a -partition read-only" under Linux simply by running fsysopts -/mntpoint --readonly. The running active translator -will change its behaviour according to your request if possible. -fsysopts /mntpoint without a parameter shows you the current -settings.

-

Examples

-

-I recommend that you start by reading the /bin/mount command, -it is only a small script. Because setting filesystem translators is -similar to mounting partitions, you can easily grasp the concept this way. -Make a file system image with dd if=/dev/zero of=dummy.fs bs=1024k -count=8; mke2fs dummy.fs and "mount" it with settrans -c dummy -/hurd/ext2fs `pwd`/dummy.fs. Note that the translator is not started -yet, no new ext2fs process is running (verify with ps -Aux). Check that everything is correct using showtrans

-

-Now type ls dummy and you will notice the short delay that -occurs while the translator is started. After that, there will be no more -delays accessing dummy. Under Linux, one would say that you automounted a -loop file system. Check with ps Aux that there is an ext2fs -dummy process up and running now. Now put some files into the new -directory. Try to make the filesystem read-only with fsysopts. -Note how further write attempts fail now. Try to kill the active translator -with settrans -g.

-

-You should have some understanding of what is going on now. Now remember -that this was only one special server, the Hurd ext2fs server. -There are many more server in the hurd directory. Some of them -are for filesystems. Some are needed for file system features like links. -Some are needed for device files. Some are useful for networking. Imagine -"mounting" an FTP Server with settrans and downloading files -simply with the standard cp command. Or editing your web sites -with emacs /ftp/homepage.my.server.org/index.html!

- -
- -Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 1998, 1999, 2007 Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved.

-Updated: - -$Date$ $Author$ - -


-
- - - -- cgit v1.3.1 From 88ce1e5f9fddfe35c5f980ce5c6242b74a3d1527 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 18 May 2009 16:17:01 +0200 Subject: Prefix directives. --- abac.mdwn | 4 +- asbestos.mdwn | 4 +- asking_questions.mdwn | 4 +- binutils.mdwn | 4 +- capability.mdwn | 4 +- colophon.mdwn | 4 +- .../about_the_twiki_to_ikiwiki_conversion.mdwn | 6 +- community.mdwn | 4 +- community/communication.mdwn | 4 +- community/facebook.mdwn | 4 +- community/gsoc.mdwn | 6 +- community/gsoc/2008.mdwn | 4 +- community/gsoc/2008/minutes-2008-04-25.mdwn | 4 +- community/gsoc/2008/minutes-2008-05-02.mdwn | 4 +- community/gsoc/2008/minutes-2008-05-16.mdwn | 4 +- community/gsoc/organization_application.mdwn | 4 +- community/gsoc/project_ideas.mdwn | 64 ++++++------- community/gsoc/project_ideas/cdparanoia.mdwn | 6 +- community/gsoc/project_ideas/debian_installer.mdwn | 6 +- .../gsoc/project_ideas/disk_io_performance.mdwn | 6 +- .../gsoc/project_ideas/download_backends.mdwn | 6 +- community/gsoc/project_ideas/driver_glue_code.mdwn | 8 +- community/gsoc/project_ideas/dtrace.mdwn | 6 +- community/gsoc/project_ideas/file_locking.mdwn | 6 +- community/gsoc/project_ideas/gnat.mdwn | 6 +- community/gsoc/project_ideas/gnumach_cleanup.mdwn | 6 +- community/gsoc/project_ideas/hardware_libs.mdwn | 6 +- .../gsoc/project_ideas/language_bindings.mdwn | 6 +- community/gsoc/project_ideas/lexical_dot-dot.mdwn | 8 +- community/gsoc/project_ideas/libcap.mdwn | 6 +- .../gsoc/project_ideas/libdiskfs_locking.mdwn | 6 +- community/gsoc/project_ideas/libgtop.mdwn | 6 +- community/gsoc/project_ideas/maxpath.mdwn | 6 +- community/gsoc/project_ideas/mtab.mdwn | 6 +- .../namespace-based_translator_selection.mdwn | 6 +- community/gsoc/project_ideas/nfs.mdwn | 8 +- community/gsoc/project_ideas/package_manager.mdwn | 6 +- community/gsoc/project_ideas/perl.mdwn | 6 +- community/gsoc/project_ideas/procfs.mdwn | 6 +- community/gsoc/project_ideas/pthreads.mdwn | 8 +- community/gsoc/project_ideas/secure_chroot.mdwn | 6 +- .../gsoc/project_ideas/server_overriding.mdwn | 8 +- community/gsoc/project_ideas/sound.mdwn | 8 +- community/gsoc/project_ideas/tcp_ip_stack.mdwn | 8 +- community/gsoc/project_ideas/tmpfs.mdwn | 6 +- community/gsoc/project_ideas/unionfs_boot.mdwn | 6 +- community/gsoc/project_ideas/unionmount.mdwn | 6 +- community/gsoc/project_ideas/virtualization.mdwn | 6 +- community/gsoc/project_ideas/vm_tuning.mdwn | 8 +- community/gsoc/project_ideas/xattr.mdwn | 8 +- community/gsoc/project_ideas/xmlfs.mdwn | 6 +- community/gsoc/student_application_form.mdwn | 4 +- community/gsoc/xorg_ideas.mdwn | 4 +- community/meetings.mdwn | 6 +- community/meetings/eurosys_2009.mdwn | 8 +- community/meetings/fosdem_2005.mdwn | 6 +- community/meetings/fosdem_2006.mdwn | 6 +- community/meetings/fosdem_2007.mdwn | 10 +- community/meetings/fosdem_2008.mdwn | 12 +-- community/meetings/rmll_2006.mdwn | 6 +- community/meetings/self-organised.mdwn | 6 +- community/meetings/stesie_2007-10-12.mdwn | 4 +- community/weblogs.mdwn | 6 +- community/weblogs/ArneBab.mdwn | 6 +- ...oes-trying-to-get-a-german-keyboard-layout.mdwn | 4 +- config_edittemplate.mdwn | 6 +- config_edittemplate/regular_page.mdwn | 4 +- confused_deputy.mdwn | 4 +- contact_us.mdwn | 4 +- contributing.mdwn | 4 +- contributing/questionnaire.mdwn | 4 +- contributing/web_pages.mdwn | 4 +- designation.mdwn | 4 +- destructive_interference.mdwn | 4 +- documentation.mdwn | 4 +- donate.mdwn | 4 +- emulation.mdwn | 4 +- extensibility.mdwn | 4 +- fdl.texi | 10 +- gcc.mdwn | 4 +- gdb.mdwn | 4 +- gdb/backtrace.mdwn | 4 +- getting_help.mdwn | 6 +- glibc.mdwn | 4 +- hurd.mdwn | 6 +- hurd/advantages.mdwn | 4 +- hurd/authentication.mdwn | 4 +- hurd/binutils.mdwn | 4 +- hurd/building/cross-compiling.mdwn | 4 +- hurd/building/cross-compiling/discussion.mdwn | 4 +- hurd/building/example.mdwn | 4 +- hurd/concepts.mdwn | 4 +- hurd/critique.mdwn | 6 +- hurd/debugging.mdwn | 4 +- hurd/debugging/gdb.mdwn | 4 +- hurd/debugging/gdb/noninvasive_debugging.mdwn | 4 +- hurd/debugging/glibc.mdwn | 4 +- hurd/debugging/rpctrace.mdwn | 4 +- hurd/debugging/translator.mdwn | 6 +- .../translator/capturing_stdout_and_stderr.mdwn | 4 +- hurd/debugging/translator/gdb.mdwn | 4 +- hurd/documentation.mdwn | 4 +- hurd/documentation/auth.html | 6 +- hurd/documentation/hurd-and-linux.html | 6 +- hurd/documentation/hurd-paper.html | 8 +- hurd/documentation/hurd-talk.html | 6 +- hurd/documentation/translators.html | 6 +- hurd/faq.mdwn | 8 +- hurd/faq/old_faq.txt | 4 +- hurd/faq/release.mdwn | 6 +- hurd/faq/slash_usr_symlink.mdwn | 6 +- hurd/gcc.mdwn | 4 +- hurd/glibc.mdwn | 4 +- hurd/glibc/hurd-specific_api.mdwn | 6 +- hurd/history.mdwn | 4 +- hurd/history/port_to_l4.mdwn | 6 +- hurd/hurd_hacking_guide.mdwn | 4 +- hurd/io_path.mdwn | 4 +- hurd/libchannel.mdwn | 4 +- hurd/libhello_example.mdwn | 4 +- hurd/libnetfs.mdwn | 4 +- hurd/libpager.mdwn | 4 +- hurd/libstore.mdwn | 4 +- hurd/logo.mdwn | 8 +- hurd/neighborhurd.mdwn | 4 +- hurd/networking.mdwn | 4 +- hurd/ng/issues_with_mach.mdwn | 4 +- .../limitations_of_the_original_hurd_design.mdwn | 4 +- hurd/ng/position_paper.mdwn | 4 +- hurd/open_issues.mdwn | 8 +- hurd/open_issues/cvs_tasks_file.mdwn | 4 +- hurd/open_issues/cvs_todo_file.mdwn | 4 +- hurd/open_issues/gdb_non-stop_mode.mdwn | 4 +- hurd/open_issues/gdb_pending_execs.mdwn | 4 +- hurd/open_issues/gdb_thread_ids.mdwn | 4 +- hurd/open_issues/libfshelp_in_hurdlibs.mdwn | 4 +- hurd/open_issues/some_todo_list.mdwn | 4 +- hurd/open_issues/wrong_reply_message_id.mdwn | 4 +- hurd/porting.mdwn | 4 +- hurd/porting/guidelines.mdwn | 4 +- hurd/porting/system_api_limitations.mdwn | 4 +- hurd/reference_manual.mdwn | 4 +- hurd/running.mdwn | 4 +- hurd/running/debian.mdwn | 2 +- hurd/running/debian/DebianAptOffline.mdwn | 4 +- hurd/running/debian/after_install.mdwn | 2 +- hurd/running/debian/creating_image_tarball.mdwn | 4 +- hurd/running/debian/faq.mdwn | 8 +- hurd/running/debian/faq/2_gib_partition_limit.mdwn | 6 +- hurd/running/debian/faq/512_mib_ram_limit.mdwn | 6 +- hurd/running/debian/faq/apt_umount.mdwn | 6 +- hurd/running/debian/faq/bad_hypermeta_data.mdwn | 4 +- .../running/debian/faq/debugging_inside_glibc.mdwn | 4 +- hurd/running/debian/faq/debugging_translators.mdwn | 4 +- hurd/running/debian/faq/dev_random.mdwn | 6 +- hurd/running/debian/faq/df.mdwn | 4 +- hurd/running/debian/faq/free_memory.mdwn | 4 +- hurd/running/debian/faq/hurd_console.mdwn | 4 +- hurd/running/debian/faq/kernel_logs.mdwn | 4 +- hurd/running/debian/faq/other_repositories.mdwn | 4 +- hurd/running/debian/faq/ps_hangs.mdwn | 4 +- hurd/running/debian/faq/reporting_bugs.mdwn | 4 +- hurd/running/debian/faq/sata_disk_drives.mdwn | 4 +- .../faq/sshd_only_works_for_root_logins.mdwn | 4 +- hurd/running/debian/faq/xserver-common.mdwn | 4 +- hurd/running/debian/patch_submission.mdwn | 4 +- hurd/running/debian/porting.mdwn | 8 +- hurd/running/debian/porting/adduser.mdwn | 4 +- hurd/running/debian/porting/gcc.mdwn | 4 +- hurd/running/debian/porting/gcc/c++.mdwn | 6 +- hurd/running/debian/porting/gcc/libmudflap.mdwn | 4 +- hurd/running/debian/porting/git-core-2.mdwn | 4 +- hurd/running/debian/porting/git-core.mdwn | 4 +- .../debian/porting/libdbd-sqlite3-perl.mdwn | 4 +- hurd/running/debian/porting/pth.mdwn | 4 +- hurd/running/debian/porting/runit.mdwn | 4 +- hurd/running/debian/porting/socat.mdwn | 4 +- hurd/running/gnu/create_an_image.mdwn | 4 +- hurd/running/gnu/setup.mdwn | 4 +- hurd/running/gnu/universal_package_manager.mdwn | 4 +- hurd/running/qemu.mdwn | 2 +- hurd/running/qemu/microsoft_windows.mdwn | 4 +- hurd/running/qemu/networking.mdwn | 4 +- hurd/running/qemu/networking/sharing_files.mdwn | 4 +- hurd/running/vmware.mdwn | 4 +- hurd/running/vmware/discussion.mdwn | 4 +- hurd/settrans.mdwn | 4 +- hurd/status.mdwn | 4 +- hurd/subhurd.mdwn | 4 +- hurd/subhurd/running_a_subhurd.mdwn | 6 +- hurd/toolchain.mdwn | 4 +- hurd/translator.mdwn | 4 +- hurd/translator/auth.mdwn | 4 +- hurd/translator/cvsfs.mdwn | 4 +- hurd/translator/devfs.mdwn | 4 +- hurd/translator/emailfs.mdwn | 4 +- hurd/translator/examples.mdwn | 4 +- hurd/translator/ext2fs.mdwn | 4 +- hurd/translator/fatfs.mdwn | 6 +- hurd/translator/magic.mdwn | 4 +- hurd/translator/mboxfs.mdwn | 4 +- hurd/translator/pfinet.mdwn | 4 +- hurd/translator/pfinet/implementation.mdwn | 4 +- hurd/translator/pfinet/ipv6.mdwn | 4 +- hurd/translator/pflocal.mdwn | 4 +- hurd/translator/procfs.mdwn | 4 +- hurd/translator/procfs/htop.mdwn | 4 +- hurd/translator/procfs/killall.mdwn | 4 +- hurd/translator/procfs/procps.mdwn | 4 +- hurd/translator/procfs/top.mdwn | 4 +- hurd/translator/storeio.mdwn | 4 +- hurd/translator/stowfs.mdwn | 6 +- hurd/translator/tmpfs.mdwn | 6 +- hurd/translator/tmpfs/notes_bing.mdwn | 4 +- hurd/translator/tmpfs/notes_various.mdwn | 6 +- hurd/translator/unionfs.mdwn | 4 +- hurd/translator/wishlist_1.mdwn | 4 +- hurd/translator/writing/example.mdwn | 4 +- hurd/translator/xmlfs.mdwn | 4 +- hurd/virtual_file_system.mdwn | 4 +- hurd/virtualization.mdwn | 4 +- hurd/what_is_the_gnu_hurd.mdwn | 6 +- .../gramatically_speaking.mdwn | 6 +- hurd/what_is_the_gnu_hurd/origin_of_the_name.mdwn | 6 +- ibac.mdwn | 4 +- idl.mdwn | 4 +- ikiwiki.setup | 2 +- index.mdwn | 10 +- index/discussion.mdwn | 4 +- ipc.mdwn | 4 +- irc.mdwn | 8 +- isolation.mdwn | 4 +- license.mdwn | 2 +- liedtke.mdwn | 4 +- mailing_lists.mdwn | 10 +- mailing_lists/bug-hurd.mdwn | 6 +- mailing_lists/debian-hurd.mdwn | 4 +- mailing_lists/gnu-system-discuss.mdwn | 6 +- mailing_lists/help-hurd.mdwn | 6 +- mailing_lists/hurd-devel-readers.mdwn | 6 +- mailing_lists/hurd-devel.mdwn | 6 +- mailing_lists/l4-hurd.mdwn | 6 +- mailing_lists/unmoderated.mdwn | 4 +- mailing_lists/web-hurd.mdwn | 6 +- mechanism.mdwn | 4 +- microkernel.mdwn | 4 +- microkernel/faq.mdwn | 8 +- microkernel/faq/multiserver_microkernel.mdwn | 6 +- microkernel/for_beginners.mdwn | 4 +- microkernel/fud.mdwn | 5 +- microkernel/mach/documentation.mdwn | 4 +- microkernel/mach/external_pager_mechanism.mdwn | 5 +- microkernel/mach/gnumach.mdwn | 4 +- microkernel/mach/gnumach/boot_trace.mdwn | 4 +- microkernel/mach/gnumach/building/example.mdwn | 4 +- microkernel/mach/gnumach/debugging.mdwn | 4 +- .../mach/gnumach/hardware_compatibility_list.mdwn | 10 +- microkernel/mach/gnumach/open_issues.mdwn | 8 +- .../open_issues/resource_management_problems.mdwn | 4 +- microkernel/mach/gnumach/ports.mdwn | 4 +- microkernel/mach/gnumach/ports/xen.mdwn | 8 +- microkernel/mach/gnumach/ports/xen/internals.mdwn | 4 +- .../ports/xen/networking_configuration.mdwn | 8 +- microkernel/mach/gnumach/projects.mdwn | 6 +- .../mach/gnumach/projects/clean_up_the_code.mdwn | 48 +++++----- microkernel/mach/gnumach/projects/gdb_stubs.mdwn | 4 +- microkernel/mach/gnumach/reference_manual.mdwn | 4 +- microkernel/mach/ipc.mdwn | 4 +- microkernel/mach/ipc/sequence_numbering.mdwn | 4 +- microkernel/mach/mig.mdwn | 4 +- microkernel/mach/mig/documentation.mdwn | 4 +- microkernel/mach/mig/documentation/dealloc.mdwn | 4 +- microkernel/mach/mig/documentation/servercopy.mdwn | 4 +- microkernel/mach/mig/gnu_mig.mdwn | 4 +- microkernel/mach/mig/gnu_mig/open_issues.mdwn | 8 +- .../open_issues/duplicate_inclusion_guards.mdwn | 4 +- microkernel/mach/port.mdwn | 4 +- microkernel/mach/rpc.mdwn | 4 +- microkernel/viengoos.mdwn | 4 +- microkernel/viengoos/building.mdwn | 4 +- microkernel/viengoos/documentation.mdwn | 4 +- microkernel/viengoos/hardware.mdwn | 4 +- microkernel/viengoos/projects.mdwn | 6 +- microkernel/viengoos/serial_port.mdwn | 4 +- naming_context.mdwn | 4 +- news.mdwn | 6 +- news/2002-01-13.mdwn | 4 +- news/2002-01-19.mdwn | 4 +- news/2002-02-18.mdwn | 4 +- news/2002-03-03.mdwn | 4 +- news/2002-03-08.mdwn | 4 +- news/2002-03-23.mdwn | 4 +- news/2002-05-05.mdwn | 4 +- news/2002-05-18.mdwn | 4 +- news/2002-05-24.mdwn | 4 +- news/2002-05-28.mdwn | 4 +- news/2002-06-22.mdwn | 4 +- news/2002-08-16.mdwn | 4 +- news/2002-10-03.mdwn | 4 +- news/2002-10-03_2.mdwn | 4 +- news/2002-10-19.mdwn | 4 +- news/2002-11-18.mdwn | 4 +- news/2003-01-18.mdwn | 4 +- news/2003-02-14.mdwn | 4 +- news/2003-07-02.mdwn | 4 +- news/2003-07-16.mdwn | 4 +- news/2003-08-21.mdwn | 4 +- news/2005-01-28.mdwn | 4 +- news/2005-09-20.mdwn | 4 +- news/2006-04-27.mdwn | 4 +- news/2007-01-07.mdwn | 4 +- news/2007-01-14.mdwn | 4 +- news/2007-03-14.mdwn | 4 +- news/2007-10-01.mdwn | 4 +- news/2007-10-12.mdwn | 4 +- news/2008-02-11.mdwn | 4 +- news/2008-03-19.mdwn | 4 +- news/2008-09-11.mdwn | 4 +- news/2008-11-14.mdwn | 4 +- news/2008-12-12.mdwn | 4 +- news/2009-03-28.mdwn | 4 +- open_issues.mdwn | 10 +- open_issues/blkrrpart_ioctl.mdwn | 8 +- persistency.mdwn | 4 +- policy.mdwn | 4 +- principal.mdwn | 4 +- public_hurd_boxen.mdwn | 6 +- qemu.mdwn | 4 +- recent_changes.mdwn | 8 +- rpc.mdwn | 4 +- rules.mdwn | 4 +- rules/savannah_group.mdwn | 4 +- rules/source_repositories.mdwn | 4 +- security.mdwn | 4 +- sfi.mdwn | 4 +- shortcuts.mdwn | 104 ++++++++++----------- sidebar.mdwn | 12 +-- tcb.mdwn | 4 +- trackers.mdwn | 4 +- trust.mdwn | 4 +- unix.mdwn | 6 +- user/flaviocruz.mdwn | 4 +- user/madhusudancs.mdwn | 6 +- user/scolobb.mdwn | 4 +- user/tschwinge.mdwn | 6 +- user/vincentvikram.mdwn | 4 +- user/zhengda/howto.mdwn | 4 +- virtualization.mdwn | 6 +- 348 files changed, 946 insertions(+), 942 deletions(-) (limited to 'hurd/documentation') diff --git a/abac.mdwn b/abac.mdwn index a260a986..bdf63a32 100644 --- a/abac.mdwn +++ b/abac.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/asbestos.mdwn b/asbestos.mdwn index 65ab391e..fcbd8ecb 100644 --- a/asbestos.mdwn +++ b/asbestos.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/asking_questions.mdwn b/asking_questions.mdwn index d58dee61..bb5c8ffb 100644 --- a/asking_questions.mdwn +++ b/asking_questions.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/binutils.mdwn b/binutils.mdwn index 3e9e5889..85791914 100644 --- a/binutils.mdwn +++ b/binutils.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/capability.mdwn b/capability.mdwn index 2d4d2ce8..c5ef0d1d 100644 --- a/capability.mdwn +++ b/capability.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/colophon.mdwn b/colophon.mdwn index 9146bc15..1afdd51a 100644 --- a/colophon.mdwn +++ b/colophon.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2003, 2004, 2007, 2008, 2009 Free Software +[[!meta copyright="Copyright © 2003, 2004, 2007, 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/colophon/about_the_twiki_to_ikiwiki_conversion.mdwn b/colophon/about_the_twiki_to_ikiwiki_conversion.mdwn index 8c556261..d9443b17 100644 --- a/colophon/about_the_twiki_to_ikiwiki_conversion.mdwn +++ b/colophon/about_the_twiki_to_ikiwiki_conversion.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -38,7 +38,7 @@ also made available by the authors at . The Debian package *libhtml-wikiconverter-perl* is too old at least until -[[debbug 419918]] is closed. +[[!debbug 419918]] is closed. For converting from rcs files (as used by TWiki) to a git repository you'll need to get `git clone git://people.freedesktop.org/~keithp/parsecvs` and build diff --git a/community.mdwn b/community.mdwn index 5d58ae5a..9d8af0ec 100644 --- a/community.mdwn +++ b/community.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009 Free Software +[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/community/communication.mdwn b/community/communication.mdwn index d2eccceb..0e56a77e 100644 --- a/community/communication.mdwn +++ b/community/communication.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/community/facebook.mdwn b/community/facebook.mdwn index b5340224..31a27fec 100644 --- a/community/facebook.mdwn +++ b/community/facebook.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn index ed1f7a52..506516bb 100644 --- a/community/gsoc.mdwn +++ b/community/gsoc.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Google Summer of Code"]] +[[!meta title="Google Summer of Code"]] # 2009 diff --git a/community/gsoc/2008.mdwn b/community/gsoc/2008.mdwn index 5bb5f314..31d45d05 100644 --- a/community/gsoc/2008.mdwn +++ b/community/gsoc/2008.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/community/gsoc/2008/minutes-2008-04-25.mdwn b/community/gsoc/2008/minutes-2008-04-25.mdwn index 3f2c0313..0cb624f2 100644 --- a/community/gsoc/2008/minutes-2008-04-25.mdwn +++ b/community/gsoc/2008/minutes-2008-04-25.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/community/gsoc/2008/minutes-2008-05-02.mdwn b/community/gsoc/2008/minutes-2008-05-02.mdwn index 9c99a8e7..f960ab06 100644 --- a/community/gsoc/2008/minutes-2008-05-02.mdwn +++ b/community/gsoc/2008/minutes-2008-05-02.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/community/gsoc/2008/minutes-2008-05-16.mdwn b/community/gsoc/2008/minutes-2008-05-16.mdwn index 8adb838c..0c848e8a 100644 --- a/community/gsoc/2008/minutes-2008-05-16.mdwn +++ b/community/gsoc/2008/minutes-2008-05-16.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index 53cd85ac..946c225b 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index 78cc7ad3..dede290f 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -75,33 +75,33 @@ will assist you as well as we can. See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/Hurd_Porting). -[[inline pages="community/gsoc/project_ideas/language_bindings" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/virtualization" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/file_locking" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/driver_glue_code" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/server_overriding" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/tcp_ip_stack" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/nfs" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/libdiskfs_locking" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/pthreads" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/sound" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/disk_io_performance" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/vm_tuning" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/mtab" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/gnumach_cleanup" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/xmlfs" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/unionfs_boot" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/tmpfs" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/lexical_dot-dot" show=0 feeds=no actions=yes]] -[[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/debian_installer" 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/hardware_libs" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/cdparanoia" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/perl" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/libcap" show=0 feeds=no actions=yes]] -[[inline pages="community/gsoc/project_ideas/xattr" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/language_bindings" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/virtualization" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/file_locking" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/driver_glue_code" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/server_overriding" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/tcp_ip_stack" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/nfs" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/libdiskfs_locking" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/pthreads" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/sound" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/disk_io_performance" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/vm_tuning" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/mtab" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/gnumach_cleanup" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/xmlfs" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/unionfs_boot" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/tmpfs" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/lexical_dot-dot" show=0 feeds=no actions=yes]] +[[!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/debian_installer" 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/hardware_libs" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/cdparanoia" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/perl" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/libcap" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/xattr" show=0 feeds=no actions=yes]] diff --git a/community/gsoc/project_ideas/cdparanoia.mdwn b/community/gsoc/project_ideas/cdparanoia.mdwn index 117dc56e..f13e19e6 100644 --- a/community/gsoc/project_ideas/cdparanoia.mdwn +++ b/community/gsoc/project_ideas/cdparanoia.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Implement CD Audio Grabbing"]] +[[!meta title="Implement CD Audio Grabbing"]] The Hurd presently has only support for CD-ROMs, but not for audio extraction ("grabbing"). As a result, cdparanoia (and other extraction diff --git a/community/gsoc/project_ideas/debian_installer.mdwn b/community/gsoc/project_ideas/debian_installer.mdwn index cac85df2..183f6708 100644 --- a/community/gsoc/project_ideas/debian_installer.mdwn +++ b/community/gsoc/project_ideas/debian_installer.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Port the Debian Installer to the Hurd"]] +[[!meta title="Port the Debian Installer to the Hurd"]] The primary means of distributing the Hurd is through Debian GNU/Hurd. However, the installation CDs presently use an ancient, non-native installer. diff --git a/community/gsoc/project_ideas/disk_io_performance.mdwn b/community/gsoc/project_ideas/disk_io_performance.mdwn index 8d9b3b7c..9f361de9 100644 --- a/community/gsoc/project_ideas/disk_io_performance.mdwn +++ b/community/gsoc/project_ideas/disk_io_performance.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Disk I/O Performance Tuning"]] +[[!meta title="Disk I/O Performance Tuning"]] The most obvious reason for the Hurd feeling slow compared to mainstream systems like GNU/Linux, is very slow harddisk access. diff --git a/community/gsoc/project_ideas/download_backends.mdwn b/community/gsoc/project_ideas/download_backends.mdwn index a6e090eb..519d1195 100644 --- a/community/gsoc/project_ideas/download_backends.mdwn +++ b/community/gsoc/project_ideas/download_backends.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Use Internet Protocol Translators (ftpfs etc.) as Backends for Other Programs"]] +[[!meta title="Use Internet Protocol Translators (ftpfs etc.) as Backends for Other Programs"]] The Hurd design facilitates splitting up large applications into independent, generic components, which can be easily combined in different contexts, by diff --git a/community/gsoc/project_ideas/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn index 0e193a25..b3c4c129 100644 --- a/community/gsoc/project_ideas/driver_glue_code.mdwn +++ b/community/gsoc/project_ideas/driver_glue_code.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="New Driver Glue Code"]] +[[!meta title="New Driver Glue Code"]] Although a driver framework in userspace would be desirable, presently the Hurd uses kernel drivers in the microkernel, @@ -31,7 +31,7 @@ This is a doable, but pretty involved project. Previous experience with driver programming probably is a must. (No Hurd-specific knowledge is required, though.) -This is [[GNU_Savannah_task 5488]]. +This is [[!GNU_Savannah_task 5488]]. Possible mentors: Samuel Thibault (youpi) diff --git a/community/gsoc/project_ideas/dtrace.mdwn b/community/gsoc/project_ideas/dtrace.mdwn index f0c6f07a..18fbe956 100644 --- a/community/gsoc/project_ideas/dtrace.mdwn +++ b/community/gsoc/project_ideas/dtrace.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="dtrace Support"]] +[[!meta title="dtrace Support"]] One of the main problems of the current Hurd implementation is very poor performance. While we have a bunch of ideas what could cause the performance diff --git a/community/gsoc/project_ideas/file_locking.mdwn b/community/gsoc/project_ideas/file_locking.mdwn index b20b82fd..0c057639 100644 --- a/community/gsoc/project_ideas/file_locking.mdwn +++ b/community/gsoc/project_ideas/file_locking.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Fix File Locking"]] +[[!meta title="Fix File Locking"]] Over the years, [[UNIX]] has aquired a host of different file locking mechanisms. Some of them work on the Hurd, while others are buggy or only partially diff --git a/community/gsoc/project_ideas/gnat.mdwn b/community/gsoc/project_ideas/gnat.mdwn index 135c19aa..b70ab3c6 100644 --- a/community/gsoc/project_ideas/gnat.mdwn +++ b/community/gsoc/project_ideas/gnat.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Porting GNAT"]] +[[!meta title="Porting GNAT"]] The GNU Ada Translator (GNAT) isn't available for the Hurd so far. There are also a number of other Debian packages depending on GNAT, and thus not diff --git a/community/gsoc/project_ideas/gnumach_cleanup.mdwn b/community/gsoc/project_ideas/gnumach_cleanup.mdwn index 0fd6e481..ecbbb200 100644 --- a/community/gsoc/project_ideas/gnumach_cleanup.mdwn +++ b/community/gsoc/project_ideas/gnumach_cleanup.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="GNU Mach Code Cleanup"]] +[[!meta title="GNU Mach Code Cleanup"]] Although there are some attempts to move to a more modern microkernel alltogether, the current Hurd implementation is based on diff --git a/community/gsoc/project_ideas/hardware_libs.mdwn b/community/gsoc/project_ideas/hardware_libs.mdwn index 88b94caa..4a1fe73c 100644 --- a/community/gsoc/project_ideas/hardware_libs.mdwn +++ b/community/gsoc/project_ideas/hardware_libs.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Stub Implementations of Hardware Specific Libraries"]] +[[!meta title="Stub Implementations of Hardware Specific Libraries"]] Many programs use special libraries to access certain hardware devices, like libusb, libbluetooth, libraw1394, libiw-dev (though there already is a diff --git a/community/gsoc/project_ideas/language_bindings.mdwn b/community/gsoc/project_ideas/language_bindings.mdwn index 6dc83463..c247a8f8 100644 --- a/community/gsoc/project_ideas/language_bindings.mdwn +++ b/community/gsoc/project_ideas/language_bindings.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Bindings to Other Programming Languages"]] +[[!meta title="Bindings to Other Programming Languages"]] The main idea of the Hurd design is giving users the ability to easily modify/extend the system's functionality ([[extensible_system|extensibility]]). diff --git a/community/gsoc/project_ideas/lexical_dot-dot.mdwn b/community/gsoc/project_ideas/lexical_dot-dot.mdwn index 55d00337..e37bc71f 100644 --- a/community/gsoc/project_ideas/lexical_dot-dot.mdwn +++ b/community/gsoc/project_ideas/lexical_dot-dot.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Lexical .. Resolution"]] +[[!meta title="Lexical .. Resolution"]] For historical reasons, [[UNIX]] filesystems have a real (hard) `..` link from each directory pointing to its parent. However, this is problematic, because the @@ -29,7 +29,7 @@ to use lexical resolution, and to check that the system is still fully functional afterwards. This task requires understanding the filename resolution mechanism. -See also [[GNU_Savannah_bug 17133]]. +See also [[!GNU_Savannah_bug 17133]]. Possible mentors: ? diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn index 9e722815..2745dc7e 100644 --- a/community/gsoc/project_ideas/libcap.mdwn +++ b/community/gsoc/project_ideas/libcap.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Implementing libcap"]] +[[!meta title="Implementing libcap"]] libcap is a library providing the API to access POSIX capabilities. These allow giving various kinds of specific privileges to individual users, without giving diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn index 434e39ba..d484b40b 100644 --- a/community/gsoc/project_ideas/libdiskfs_locking.mdwn +++ b/community/gsoc/project_ideas/libdiskfs_locking.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Fix libdiskfs Locking Issues"]] +[[!meta title="Fix libdiskfs Locking Issues"]] Nowadays the most often encountered cause of Hurd crashes seems to be lockups in the [[hurd/translator/ext2fs]] server. One of these could be traced diff --git a/community/gsoc/project_ideas/libgtop.mdwn b/community/gsoc/project_ideas/libgtop.mdwn index 4f848820..c0f966c5 100644 --- a/community/gsoc/project_ideas/libgtop.mdwn +++ b/community/gsoc/project_ideas/libgtop.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Porting libgtop"]] +[[!meta title="Porting libgtop"]] libgtop is a library used by many applications (especially GNOME applications) to abstract the system-specific methods for obtaining information about the diff --git a/community/gsoc/project_ideas/maxpath.mdwn b/community/gsoc/project_ideas/maxpath.mdwn index d78297d5..6ece2dbf 100644 --- a/community/gsoc/project_ideas/maxpath.mdwn +++ b/community/gsoc/project_ideas/maxpath.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Fixing Programs Using PATH_MAX et al Unconditionally"]] +[[!meta title="Fixing Programs Using PATH_MAX et al Unconditionally"]] POSIX describes some constants (or rather macros) like PATH_MAX/MAXPATHLEN and similar, which may be defined by the system to indicate certain limits. Many diff --git a/community/gsoc/project_ideas/mtab.mdwn b/community/gsoc/project_ideas/mtab.mdwn index 8e848410..39cde2dd 100644 --- a/community/gsoc/project_ideas/mtab.mdwn +++ b/community/gsoc/project_ideas/mtab.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="mtab"]] +[[!meta title="mtab"]] In traditional monolithic system, the kernel keeps track of all mounts; the information is available through `/proc/mounts` (on Linux at least), and in a diff --git a/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn b/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn index 6bb643fa..79aad7a1 100644 --- a/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn +++ b/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Namspace-based Translator Selection"]] +[[!meta title="Namspace-based Translator Selection"]] The main idea behind the Hurd is to make (almost) all system functionality user-modifiable ([[extensible_system|extensibility]]). This includes a diff --git a/community/gsoc/project_ideas/nfs.mdwn b/community/gsoc/project_ideas/nfs.mdwn index 3874d81a..eeeda6f0 100644 --- a/community/gsoc/project_ideas/nfs.mdwn +++ b/community/gsoc/project_ideas/nfs.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Improved NFS Implementation"]] +[[!meta title="Improved NFS Implementation"]] The Hurd has both NFS server and client implementations, which work, but not very well: File locking doesn't work properly (at least in conjuction with a @@ -31,7 +31,7 @@ has been done for a former GSoC application -- it might give you some pointers. But don't take any of the statements made there for granted -- check the facts yourself! -This task, [[GNU_Savannah_task 5497]], has no special prerequisites besides general programming skills, and +This task, [[!GNU_Savannah_task 5497]], has no special prerequisites besides general programming skills, and an interest in file systems and network protocols. Possible mentors: ? diff --git a/community/gsoc/project_ideas/package_manager.mdwn b/community/gsoc/project_ideas/package_manager.mdwn index c7a33944..4e544ed5 100644 --- a/community/gsoc/project_ideas/package_manager.mdwn +++ b/community/gsoc/project_ideas/package_manager.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Hurdish Package Manager for the GNU System"]] +[[!meta title="Hurdish Package Manager for the GNU System"]] Most GNU/Linux systems use pretty sophisticated package managers, to ease the management of installed software. These keep track of all installed files, and diff --git a/community/gsoc/project_ideas/perl.mdwn b/community/gsoc/project_ideas/perl.mdwn index 803f710e..23420159 100644 --- a/community/gsoc/project_ideas/perl.mdwn +++ b/community/gsoc/project_ideas/perl.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Improving Perl Support"]] +[[!meta title="Improving Perl Support"]] Perl is available on the Hurd, but there are quite a lot of test suite failures. These could be caused by problems in the system-specific diff --git a/community/gsoc/project_ideas/procfs.mdwn b/community/gsoc/project_ideas/procfs.mdwn index 55556b02..8acfa228 100644 --- a/community/gsoc/project_ideas/procfs.mdwn +++ b/community/gsoc/project_ideas/procfs.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="procfs"]] +[[!meta title="procfs"]] Although there is no standard (POSIX or other) for the layout of the `/proc` pseudo-filesystem, it turned out a very useful facility in GNU/Linux and other diff --git a/community/gsoc/project_ideas/pthreads.mdwn b/community/gsoc/project_ideas/pthreads.mdwn index aa532a9a..0e677268 100644 --- a/community/gsoc/project_ideas/pthreads.mdwn +++ b/community/gsoc/project_ideas/pthreads.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Convert Hurd Libraries and Servers to pthreads"]] +[[!meta title="Convert Hurd Libraries and Servers to pthreads"]] The Hurd was originally created at a time when the [pthreads standard](http://www.opengroup.org/onlinepubs/009695399/basedefs/pthread.h.html) @@ -27,7 +27,7 @@ libfuse](http://www.nongnu.org/hurdextras/#libfuse) with any FUSE modules depending on pthreads for example.) Most of the conversion has already been done in previous efforts (see -[[GNU_Savannah_task 5487]]) -- but the tricky parts are still missing. +[[!GNU_Savannah_task 5487]]) -- but the tricky parts are still missing. The goal of this project is to have all the Hurd code use pthreads. Should any limitations in the existing pthreads implementation turn up that hinder this diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn index ba47f78d..e5848a0f 100644 --- a/community/gsoc/project_ideas/secure_chroot.mdwn +++ b/community/gsoc/project_ideas/secure_chroot.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Secure chroot Implementation"]] +[[!meta title="Secure chroot Implementation"]] As the Hurd attempts to be (almost) fully [[UNIX]]-compatible, it also implements a `chroot()` system call. However, the current implementation is not really diff --git a/community/gsoc/project_ideas/server_overriding.mdwn b/community/gsoc/project_ideas/server_overriding.mdwn index 2513df0b..66171313 100644 --- a/community/gsoc/project_ideas/server_overriding.mdwn +++ b/community/gsoc/project_ideas/server_overriding.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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"]] +[[!meta title="Server Overriding Mechanism"]] The main idea of the Hurd is that every user can influence almost all system functionality ([[extensible_system|extensibility]]), by running private Hurd @@ -61,7 +61,7 @@ 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 +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 , , diff --git a/community/gsoc/project_ideas/sound.mdwn b/community/gsoc/project_ideas/sound.mdwn index 26bb91cb..134c5b59 100644 --- a/community/gsoc/project_ideas/sound.mdwn +++ b/community/gsoc/project_ideas/sound.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,9 +8,9 @@ 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="Sound Support"]] +[[!meta title="Sound Support"]] -The Hurd presently has no sound support. Fixing this, [[GNU_Savannah_task +The Hurd presently has no sound support. Fixing this, [[!GNU_Savannah_task 5485]], requires two steps: the first is to port some other kernel's drivers to [[GNU_Mach|microkernel/mach/gnumach]] so we can get access to actual sound hardware. The second is to implement a userspace server ([[hurd/translator]]), diff --git a/community/gsoc/project_ideas/tcp_ip_stack.mdwn b/community/gsoc/project_ideas/tcp_ip_stack.mdwn index 29b1d22d..7ca43152 100644 --- a/community/gsoc/project_ideas/tcp_ip_stack.mdwn +++ b/community/gsoc/project_ideas/tcp_ip_stack.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Hurdish TCP/IP Stack"]] +[[!meta title="Hurdish TCP/IP Stack"]] The Hurd presently uses a [[TCP/IP_stack|hurd/translator/pfinet]] based on code from an old Linux version. This works, but lacks some rather important features (like PPP/PPPoE), and the @@ -32,7 +32,7 @@ individual layers later. The initial implementation, and the choice of a TCP/IP stack, should be done with this in mind -- it needs to be modular enough to make such a split later on feasible. -This is [[GNU_Savannah_task 5469]]. +This is [[!GNU_Savannah_task 5469]]. Possible mentors: ? diff --git a/community/gsoc/project_ideas/tmpfs.mdwn b/community/gsoc/project_ideas/tmpfs.mdwn index a3f474ff..fcf8d96b 100644 --- a/community/gsoc/project_ideas/tmpfs.mdwn +++ b/community/gsoc/project_ideas/tmpfs.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Fix tmpfs"]] +[[!meta title="Fix tmpfs"]] In some situations it is desirable to have a file system that is not backed by actual disk storage, but only by anonymous memory, i.e. lives in the RAM (and diff --git a/community/gsoc/project_ideas/unionfs_boot.mdwn b/community/gsoc/project_ideas/unionfs_boot.mdwn index 21cf168f..3692678f 100644 --- a/community/gsoc/project_ideas/unionfs_boot.mdwn +++ b/community/gsoc/project_ideas/unionfs_boot.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Allow Using unionfs Early at Boot"]] +[[!meta title="Allow Using unionfs Early at Boot"]] In [[UNIX]] systems, traditionally most software is installed in a common directory hierachy, where files from various packages live beside each other, grouped by diff --git a/community/gsoc/project_ideas/unionmount.mdwn b/community/gsoc/project_ideas/unionmount.mdwn index 89b53123..f8fbc283 100644 --- a/community/gsoc/project_ideas/unionmount.mdwn +++ b/community/gsoc/project_ideas/unionmount.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Union Mounts"]] +[[!meta title="Union Mounts"]] When setting a translator on Hurd -- similar to mounting a file system on UNIX -- the new node(s) exported by the translator are obscuring the original node diff --git a/community/gsoc/project_ideas/virtualization.mdwn b/community/gsoc/project_ideas/virtualization.mdwn index 711d3b4c..79c3ab29 100644 --- a/community/gsoc/project_ideas/virtualization.mdwn +++ b/community/gsoc/project_ideas/virtualization.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Virtualization Using Hurd Mechanisms"]] +[[!meta title="Virtualization Using Hurd Mechanisms"]] The main idea behind the Hurd design is to allow users to replace almost any system functionality ([[extensible_system|extensibility]]). Any user can easily diff --git a/community/gsoc/project_ideas/vm_tuning.mdwn b/community/gsoc/project_ideas/vm_tuning.mdwn index d1d75e10..8d6a15c3 100644 --- a/community/gsoc/project_ideas/vm_tuning.mdwn +++ b/community/gsoc/project_ideas/vm_tuning.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="VM Tuning"]] +[[!meta title="VM Tuning"]] Hurd/[[microkernel/Mach]] presently make very bad use of the available physical memory in the system. Some of the problems are inherent to the system design (the kernel @@ -26,7 +26,7 @@ implementation to other systems, implementing any worthwhile improvements, and general optimisation/tuning. It requires very good understanding of the Mach VM, and virtual memory in general. -This project is related to [[GNU_Savannah_task 5489]]. +This project is related to [[!GNU_Savannah_task 5489]]. Possible mentors: Samuel Thibault (youpi) diff --git a/community/gsoc/project_ideas/xattr.mdwn b/community/gsoc/project_ideas/xattr.mdwn index ab16dfbb..b5466091 100644 --- a/community/gsoc/project_ideas/xattr.mdwn +++ b/community/gsoc/project_ideas/xattr.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Implement xattr Support"]] +[[!meta title="Implement xattr Support"]] Extended attributes (xattr) are a standardized, generic method for storing additional metadata along with a file (inode). Most modern UNIX filesystems @@ -38,7 +38,7 @@ Completing this project will require digging into some parts of the Hurd, but it should be quite doable without previous Hurd experience. Some experience with xattrs might help a bit, but shouldn't be really necessary either. -Some previous work on xattr support is available in [[GNU_Savannah_patch +Some previous work on xattr support is available in [[!GNU_Savannah_patch 5126]], and might serve as a starting point. Possible mentors: Samuel Thibault (youpi) diff --git a/community/gsoc/project_ideas/xmlfs.mdwn b/community/gsoc/project_ideas/xmlfs.mdwn index e9c8a5b2..5fd2cbe4 100644 --- a/community/gsoc/project_ideas/xmlfs.mdwn +++ b/community/gsoc/project_ideas/xmlfs.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="xmlfs"]] +[[!meta title="xmlfs"]] Hurd [[translators|hurd/translator]] allow presenting underlying data in a different format. This is a very powerful ability: it allows using standard diff --git a/community/gsoc/student_application_form.mdwn b/community/gsoc/student_application_form.mdwn index 619843f0..e52387b6 100644 --- a/community/gsoc/student_application_form.mdwn +++ b/community/gsoc/student_application_form.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/community/gsoc/xorg_ideas.mdwn b/community/gsoc/xorg_ideas.mdwn index 153b8bf6..c125ee96 100644 --- a/community/gsoc/xorg_ideas.mdwn +++ b/community/gsoc/xorg_ideas.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/community/meetings.mdwn b/community/meetings.mdwn index 1b994e13..9a07e205 100644 --- a/community/meetings.mdwn +++ b/community/meetings.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -9,7 +9,7 @@ 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="Meetings with Hurd developer attendance"]] +[[!meta title="Meetings with Hurd developer attendance"]] # Upcoming diff --git a/community/meetings/eurosys_2009.mdwn b/community/meetings/eurosys_2009.mdwn index 069f6889..cc672f5e 100644 --- a/community/meetings/eurosys_2009.mdwn +++ b/community/meetings/eurosys_2009.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2006, 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2006, 2007, 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -9,7 +9,7 @@ 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="EuroSys 2009"]] +[[!meta title="EuroSys 2009"]] @@ -18,7 +18,7 @@ EuroSys will take place on March 30th to April 3rd in Nuremberg, Germany. # Who and When -[[table class="table_style_1" data=""" +[[!table class="table_style_1" data=""" "Name","Attending","Arrival","Return" "Neal Walfield","yes","Monday evening","Friday" "[[Thomas_Schwinge|tschwinge]]","yes","Monday evening","Friday" diff --git a/community/meetings/fosdem_2005.mdwn b/community/meetings/fosdem_2005.mdwn index c34319fb..e19ff41d 100644 --- a/community/meetings/fosdem_2005.mdwn +++ b/community/meetings/fosdem_2005.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2006, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2006, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="FOSDEM 2005"]] +[[!meta title="FOSDEM 2005"]] diff --git a/community/meetings/fosdem_2006.mdwn b/community/meetings/fosdem_2006.mdwn index 8bf9967f..7f3cdcce 100644 --- a/community/meetings/fosdem_2006.mdwn +++ b/community/meetings/fosdem_2006.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, +[[!meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -9,7 +9,7 @@ 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="FOSDEM 2006"]] +[[!meta title="FOSDEM 2006"]] diff --git a/community/meetings/fosdem_2007.mdwn b/community/meetings/fosdem_2007.mdwn index 55d346fd..e8c37441 100644 --- a/community/meetings/fosdem_2007.mdwn +++ b/community/meetings/fosdem_2007.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, +[[!meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -9,7 +9,7 @@ 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="FOSDEM 2007"]] +[[!meta title="FOSDEM 2007"]] @@ -18,7 +18,7 @@ Bruxelles. # Who And When -[[table class="table_style_1" data=""" +[[!table class="table_style_1" data=""" "Name","Attending","Arrival","Return","Share room with us" "[[AlfredoBeaumont]]","no","n/a","n/a","n/a" "[[AndrewResch]]","no","n/a","n/a","n/a" @@ -88,7 +88,7 @@ Been there in 2006. It was okay. [[SamuelThibault]] booked rooms at ~ 18.60€ there: -[[table class="table_style_1" data=""" +[[!table class="table_style_1" data=""" "Night of...","Persons" "2007-02-22","7**6**" "2007-02-23","10" diff --git a/community/meetings/fosdem_2008.mdwn b/community/meetings/fosdem_2008.mdwn index fb4a3ae9..5d641995 100644 --- a/community/meetings/fosdem_2008.mdwn +++ b/community/meetings/fosdem_2008.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, +[[!meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -9,7 +9,7 @@ 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="FOSDEM 2008"]] +[[!meta title="FOSDEM 2008"]] @@ -19,7 +19,7 @@ Bruxelles. # Who And When -[[table class="table_style_1" data=""" +[[!table class="table_style_1" data=""" "Name","Attending","Arrival","Return","Share room with us" "[[Bas_Wijnen|baswijnen]] and girlfriend","yes","Friday","Monday","yes (two)" "Christian Dietrich","no","n/a","n/a","n/a" @@ -42,7 +42,7 @@ Bruxelles. (Large) evening counts: -[[table class="table_style_1" data=""" +[[!table class="table_style_1" data=""" , Bas, Gianluca, Marcus, Michael, Neal, Olaf, Samuel, Soeren, Thomas, Total Thu 21, , 1? , *1*, , , , 1 , , *1*, *4* 2 Fri 22, 2 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 ,10 @@ -94,7 +94,7 @@ gaah, Full! -[[toggleable id="SATA" text=""" +[[!toggleable id="SATA" text=""" This is how booting a [[GNU/Hurd_system|hurd]] will typically fail if GNU Mach couldn't connect to the hard disk, e.g., in a SATA system without IDE compatibility mode: diff --git a/microkernel/mach/gnumach/open_issues.mdwn b/microkernel/mach/gnumach/open_issues.mdwn index aab854c2..4323ac4b 100644 --- a/microkernel/mach/gnumach/open_issues.mdwn +++ b/microkernel/mach/gnumach/open_issues.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,11 +8,11 @@ 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="Open Issues"]] +[[!meta title="Open Issues"]] This is a dumping ground for open issues for GNU Mach. -[[inline +[[!inline pages="(microkernel/mach/gnumach/open_issues/* or tagged(open_issue_*mach)) and !*/discussion" show=0 diff --git a/microkernel/mach/gnumach/open_issues/resource_management_problems.mdwn b/microkernel/mach/gnumach/open_issues/resource_management_problems.mdwn index e949fa96..07c71568 100644 --- a/microkernel/mach/gnumach/open_issues/resource_management_problems.mdwn +++ b/microkernel/mach/gnumach/open_issues/resource_management_problems.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/mach/gnumach/ports.mdwn b/microkernel/mach/gnumach/ports.mdwn index 00cdee8c..b25fbe60 100644 --- a/microkernel/mach/gnumach/ports.mdwn +++ b/microkernel/mach/gnumach/ports.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn index b9e2fac7..7391ea2e 100644 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ b/microkernel/mach/gnumach/ports/xen.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -9,7 +9,7 @@ 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]]."]]"""]] -[[toc ]] +[[!toc]] ## Xen dom0, hypervisor @@ -79,4 +79,4 @@ The current `hurd-modules` was built from the debian packages `hurd 20070606-2` [[Internals]]. -[[GNU_Savannah_task 5468]], [[GNU_Savannah_task 6584]]. +[[!GNU_Savannah_task 5468]], [[!GNU_Savannah_task 6584]]. diff --git a/microkernel/mach/gnumach/ports/xen/internals.mdwn b/microkernel/mach/gnumach/ports/xen/internals.mdwn index 09e707ea..8e46472d 100644 --- a/microkernel/mach/gnumach/ports/xen/internals.mdwn +++ b/microkernel/mach/gnumach/ports/xen/internals.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/mach/gnumach/ports/xen/networking_configuration.mdwn b/microkernel/mach/gnumach/ports/xen/networking_configuration.mdwn index 71a72bac..f3b0d205 100644 --- a/microkernel/mach/gnumach/ports/xen/networking_configuration.mdwn +++ b/microkernel/mach/gnumach/ports/xen/networking_configuration.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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]]."]]"""]] -[[toc ]] +[[!toc]] The Xen dom0 infrastructure provides for a bridged networking setup using shell scripts to configure the bridging device properly and attach the domUs' virtual @@ -38,7 +38,7 @@ Comment out everything referencing your physical devices. Add this: [...] This needs a version of the `bridge-utils` package more recent than the current -Debian stable one ([[debbug 405215]]). (It's trivial to rebuild the `dpkg` of, +Debian stable one ([[!debbug 405215]]). (It's trivial to rebuild the `dpkg` of, e.g., the Debian testing one on Debian stable.) # */etc/xen/xend-config.sxp* diff --git a/microkernel/mach/gnumach/projects.mdwn b/microkernel/mach/gnumach/projects.mdwn index 9ace6270..8ef71e30 100644 --- a/microkernel/mach/gnumach/projects.mdwn +++ b/microkernel/mach/gnumach/projects.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2005, 2006, 2007, 2008 -Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008 Free Software Foundation, +Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn b/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn index 875bb8cd..0038f00e 100644 --- a/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn +++ b/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2005, 2006, 2007, 2008 - Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008 Free Software Foundation, +Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -39,80 +39,80 @@ So, additionally to the list given below, there may actually be a bunch of further files (also exported ones) that serve no real value, but are being `#include`d through one way or another. -* [[source_gnumach-1-branch ddb/db_expr.h]] +* [[!source_gnumach-1-branch ddb/db_expr.h]] Currently used, but copyright violation? Rewrite? -* [[source_gnumach-1-branch ddb/db_print.h]] +* [[!source_gnumach-1-branch ddb/db_print.h]] Copyright violation? Currently unused, but could be used in principle (or be rewritten, to avoid the copyright oddity). -* [[source_gnumach-1-branch ddb/tr.h]] +* [[!source_gnumach-1-branch ddb/tr.h]] Copyright violation. Unused. Remove. -* [[source_gnumach-1-branch device/dev_master.h]] +* [[!source_gnumach-1-branch device/dev_master.h]] Might be usable for SMP? Remove otherwise. -* [[source_gnumach-1-branch i386/i386/kttd_machdep.h]] +* [[!source_gnumach-1-branch i386/i386/kttd_machdep.h]] -* [[source_gnumach-1-branch i386/i386/sched_param.h]] +* [[!source_gnumach-1-branch i386/i386/sched_param.h]] -* [[source_gnumach-1-branch i386/include/mach/i386/cthreads.h]] +* [[!source_gnumach-1-branch i386/include/mach/i386/cthreads.h]] Was probably once exported, but is no longer. -* [[source_gnumach-1-branch i386/include/mach/i386/ioccom.h]] +* [[!source_gnumach-1-branch i386/include/mach/i386/ioccom.h]] Exported. -* [[source_gnumach-1-branch include/device/audio_status.h]] +* [[!source_gnumach-1-branch include/device/audio_status.h]] Exported. -* [[source_gnumach-1-branch include/device/tape_status.h]] +* [[!source_gnumach-1-branch include/device/tape_status.h]] Exported. -* [[source_gnumach-1-branch include/mach/alert.h]] +* [[!source_gnumach-1-branch include/mach/alert.h]] Exported. -* [[source_gnumach-1-branch include/mach/boot.h]] +* [[!source_gnumach-1-branch include/mach/boot.h]] Exported. -* [[source_gnumach-1-branch include/mach/macro_help.h]] +* [[!source_gnumach-1-branch include/mach/macro_help.h]] Exported. -* [[source_gnumach-1-branch include/mach/multiboot.h]] +* [[!source_gnumach-1-branch include/mach/multiboot.h]] Exported. -* [[source_gnumach-1-branch include/mach/profil.h]] +* [[!source_gnumach-1-branch include/mach/profil.h]] Exported. -* [[source_gnumach-1-branch include/mach/profilparam.h]] +* [[!source_gnumach-1-branch include/mach/profilparam.h]] Exported. -* [[source_gnumach-1-branch include/mach/exec/a.out.h]] +* [[!source_gnumach-1-branch include/mach/exec/a.out.h]] Exported. -* [[source_gnumach-1-branch include/mach_debug/pc_info.h]] +* [[!source_gnumach-1-branch include/mach_debug/pc_info.h]] Currently not exported, but was probably once meant to be. -* [[source_gnumach-1-branch kern/act.h]] +* [[!source_gnumach-1-branch kern/act.h]] -* [[source_gnumach-1-branch kern/refcount.h]] +* [[!source_gnumach-1-branch kern/refcount.h]] -* [[source_gnumach-1-branch kern/shuttle.h]] +* [[!source_gnumach-1-branch kern/shuttle.h]] # Remove dead functions, variables, etc. from source files diff --git a/microkernel/mach/gnumach/projects/gdb_stubs.mdwn b/microkernel/mach/gnumach/projects/gdb_stubs.mdwn index 9a11a82b..43e65a2b 100644 --- a/microkernel/mach/gnumach/projects/gdb_stubs.mdwn +++ b/microkernel/mach/gnumach/projects/gdb_stubs.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/mach/gnumach/reference_manual.mdwn b/microkernel/mach/gnumach/reference_manual.mdwn index 225ab176..dab6423d 100644 --- a/microkernel/mach/gnumach/reference_manual.mdwn +++ b/microkernel/mach/gnumach/reference_manual.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 +[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/mach/ipc.mdwn b/microkernel/mach/ipc.mdwn index 889fac2f..010b51c9 100644 --- a/microkernel/mach/ipc.mdwn +++ b/microkernel/mach/ipc.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/mach/ipc/sequence_numbering.mdwn b/microkernel/mach/ipc/sequence_numbering.mdwn index 7c1f68e4..ea5cf5fe 100644 --- a/microkernel/mach/ipc/sequence_numbering.mdwn +++ b/microkernel/mach/ipc/sequence_numbering.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/mach/mig.mdwn b/microkernel/mach/mig.mdwn index eb1c0906..2bf81d59 100644 --- a/microkernel/mach/mig.mdwn +++ b/microkernel/mach/mig.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2001, 2002, 2003, 2006, 2007, 2008 Free Software +[[!meta copyright="Copyright © 2001, 2002, 2003, 2006, 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/mach/mig/documentation.mdwn b/microkernel/mach/mig/documentation.mdwn index 93bc2769..be0796e8 100644 --- a/microkernel/mach/mig/documentation.mdwn +++ b/microkernel/mach/mig/documentation.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009 Free Software +[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/mach/mig/documentation/dealloc.mdwn b/microkernel/mach/mig/documentation/dealloc.mdwn index 008499f1..42f06613 100644 --- a/microkernel/mach/mig/documentation/dealloc.mdwn +++ b/microkernel/mach/mig/documentation/dealloc.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/mach/mig/documentation/servercopy.mdwn b/microkernel/mach/mig/documentation/servercopy.mdwn index 5ede723b..00edf0f3 100644 --- a/microkernel/mach/mig/documentation/servercopy.mdwn +++ b/microkernel/mach/mig/documentation/servercopy.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/mach/mig/gnu_mig.mdwn b/microkernel/mach/mig/gnu_mig.mdwn index 4f5fb5c8..b2a41bac 100644 --- a/microkernel/mach/mig/gnu_mig.mdwn +++ b/microkernel/mach/mig/gnu_mig.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2001, 2006, 2008 Free Software Foundation, +[[!meta copyright="Copyright © 2001, 2006, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/mach/mig/gnu_mig/open_issues.mdwn b/microkernel/mach/mig/gnu_mig/open_issues.mdwn index 37d27f19..ad440b40 100644 --- a/microkernel/mach/mig/gnu_mig/open_issues.mdwn +++ b/microkernel/mach/mig/gnu_mig/open_issues.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,11 +8,11 @@ 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="Open Issues"]] +[[!meta title="Open Issues"]] This is a dumping ground for open issues for GNU MIG. -[[inline +[[!inline pages="(microkernel/mach/mig/gnu_mig/open_issues/* or tagged(open_issue_*mig)) and !*/discussion" show=0 diff --git a/microkernel/mach/mig/gnu_mig/open_issues/duplicate_inclusion_guards.mdwn b/microkernel/mach/mig/gnu_mig/open_issues/duplicate_inclusion_guards.mdwn index 93347759..27de1015 100644 --- a/microkernel/mach/mig/gnu_mig/open_issues/duplicate_inclusion_guards.mdwn +++ b/microkernel/mach/mig/gnu_mig/open_issues/duplicate_inclusion_guards.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/mach/port.mdwn b/microkernel/mach/port.mdwn index 77b1372f..b3568c29 100644 --- a/microkernel/mach/port.mdwn +++ b/microkernel/mach/port.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/mach/rpc.mdwn b/microkernel/mach/rpc.mdwn index ecef86ee..5508ea3c 100644 --- a/microkernel/mach/rpc.mdwn +++ b/microkernel/mach/rpc.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/viengoos.mdwn b/microkernel/viengoos.mdwn index b4158843..95009142 100644 --- a/microkernel/viengoos.mdwn +++ b/microkernel/viengoos.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/viengoos/building.mdwn b/microkernel/viengoos/building.mdwn index d70ea47d..b34188e2 100644 --- a/microkernel/viengoos/building.mdwn +++ b/microkernel/viengoos/building.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/viengoos/documentation.mdwn b/microkernel/viengoos/documentation.mdwn index 1fe4c937..ccce208b 100644 --- a/microkernel/viengoos/documentation.mdwn +++ b/microkernel/viengoos/documentation.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/viengoos/hardware.mdwn b/microkernel/viengoos/hardware.mdwn index 1b4ce514..e5a2ddf5 100644 --- a/microkernel/viengoos/hardware.mdwn +++ b/microkernel/viengoos/hardware.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/microkernel/viengoos/projects.mdwn b/microkernel/viengoos/projects.mdwn index c61f42bd..cbe39607 100644 --- a/microkernel/viengoos/projects.mdwn +++ b/microkernel/viengoos/projects.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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_viengoos]] +[[!tag open_issue_viengoos]] Some projects: diff --git a/microkernel/viengoos/serial_port.mdwn b/microkernel/viengoos/serial_port.mdwn index 53b988c5..01dd4050 100644 --- a/microkernel/viengoos/serial_port.mdwn +++ b/microkernel/viengoos/serial_port.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/naming_context.mdwn b/naming_context.mdwn index 9c701e71..28b2fabd 100644 --- a/naming_context.mdwn +++ b/naming_context.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news.mdwn b/news.mdwn index 8e5d73da..c5c0a851 100644 --- a/news.mdwn +++ b/news.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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]]."]]"""]] -[[inline +[[!inline pages="news/* and !*/discussion" show=0 feeds=no diff --git a/news/2002-01-13.mdwn b/news/2002-01-13.mdwn index ed56563d..06b62334 100644 --- a/news/2002-01-13.mdwn +++ b/news/2002-01-13.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2002-01-19.mdwn b/news/2002-01-19.mdwn index d221453d..18fe6aab 100644 --- a/news/2002-01-19.mdwn +++ b/news/2002-01-19.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2002-02-18.mdwn b/news/2002-02-18.mdwn index 74c0191d..b34c654a 100644 --- a/news/2002-02-18.mdwn +++ b/news/2002-02-18.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2002-03-03.mdwn b/news/2002-03-03.mdwn index db730238..9a66a2f5 100644 --- a/news/2002-03-03.mdwn +++ b/news/2002-03-03.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2002-03-08.mdwn b/news/2002-03-08.mdwn index 64fa508a..c107dcfc 100644 --- a/news/2002-03-08.mdwn +++ b/news/2002-03-08.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2002-03-23.mdwn b/news/2002-03-23.mdwn index 9820b8c5..1936ca05 100644 --- a/news/2002-03-23.mdwn +++ b/news/2002-03-23.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2002-05-05.mdwn b/news/2002-05-05.mdwn index 81d36280..d5db172b 100644 --- a/news/2002-05-05.mdwn +++ b/news/2002-05-05.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2002-05-18.mdwn b/news/2002-05-18.mdwn index b88db508..e2cb9261 100644 --- a/news/2002-05-18.mdwn +++ b/news/2002-05-18.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2002-05-24.mdwn b/news/2002-05-24.mdwn index cabc3e0d..32469759 100644 --- a/news/2002-05-24.mdwn +++ b/news/2002-05-24.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2002-05-28.mdwn b/news/2002-05-28.mdwn index 60622205..330e8dc0 100644 --- a/news/2002-05-28.mdwn +++ b/news/2002-05-28.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2002-06-22.mdwn b/news/2002-06-22.mdwn index 6ac785a6..439d7ea6 100644 --- a/news/2002-06-22.mdwn +++ b/news/2002-06-22.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2002-08-16.mdwn b/news/2002-08-16.mdwn index 6f6dcb2e..69f42be4 100644 --- a/news/2002-08-16.mdwn +++ b/news/2002-08-16.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2002-10-03.mdwn b/news/2002-10-03.mdwn index 40f4e1b6..28ab527a 100644 --- a/news/2002-10-03.mdwn +++ b/news/2002-10-03.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2002-10-03_2.mdwn b/news/2002-10-03_2.mdwn index 58b44789..0dabd3b6 100644 --- a/news/2002-10-03_2.mdwn +++ b/news/2002-10-03_2.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2002-10-19.mdwn b/news/2002-10-19.mdwn index e856370a..fb3e75b2 100644 --- a/news/2002-10-19.mdwn +++ b/news/2002-10-19.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2002-11-18.mdwn b/news/2002-11-18.mdwn index 44e33200..fec60a89 100644 --- a/news/2002-11-18.mdwn +++ b/news/2002-11-18.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2003-01-18.mdwn b/news/2003-01-18.mdwn index 0719f435..1d89bc68 100644 --- a/news/2003-01-18.mdwn +++ b/news/2003-01-18.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2003-02-14.mdwn b/news/2003-02-14.mdwn index 2509a771..89473575 100644 --- a/news/2003-02-14.mdwn +++ b/news/2003-02-14.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2003-07-02.mdwn b/news/2003-07-02.mdwn index 6e76cc66..b5433eee 100644 --- a/news/2003-07-02.mdwn +++ b/news/2003-07-02.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2003-07-16.mdwn b/news/2003-07-16.mdwn index e4ec468b..af8c8b74 100644 --- a/news/2003-07-16.mdwn +++ b/news/2003-07-16.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2003-08-21.mdwn b/news/2003-08-21.mdwn index 8d060582..602ee2ef 100644 --- a/news/2003-08-21.mdwn +++ b/news/2003-08-21.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2005-01-28.mdwn b/news/2005-01-28.mdwn index 5bd2ac19..92056b38 100644 --- a/news/2005-01-28.mdwn +++ b/news/2005-01-28.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2005, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2005, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2005-09-20.mdwn b/news/2005-09-20.mdwn index 99a20940..16424a8c 100644 --- a/news/2005-09-20.mdwn +++ b/news/2005-09-20.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2005, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2005, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2006-04-27.mdwn b/news/2006-04-27.mdwn index dc52c527..d50fd272 100644 --- a/news/2006-04-27.mdwn +++ b/news/2006-04-27.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2006, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2006, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2007-01-07.mdwn b/news/2007-01-07.mdwn index 75eb7d01..b82ec6e0 100644 --- a/news/2007-01-07.mdwn +++ b/news/2007-01-07.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2007-01-14.mdwn b/news/2007-01-14.mdwn index 8dc3d9f5..16947757 100644 --- a/news/2007-01-14.mdwn +++ b/news/2007-01-14.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2007-03-14.mdwn b/news/2007-03-14.mdwn index 3b1b2ad3..ec3ebcda 100644 --- a/news/2007-03-14.mdwn +++ b/news/2007-03-14.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2007-10-01.mdwn b/news/2007-10-01.mdwn index 768cf42b..a95b2631 100644 --- a/news/2007-10-01.mdwn +++ b/news/2007-10-01.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2007-10-12.mdwn b/news/2007-10-12.mdwn index d262dcd8..8d46a07f 100644 --- a/news/2007-10-12.mdwn +++ b/news/2007-10-12.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2008-02-11.mdwn b/news/2008-02-11.mdwn index a8f00497..7b4346b8 100644 --- a/news/2008-02-11.mdwn +++ b/news/2008-02-11.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2008-03-19.mdwn b/news/2008-03-19.mdwn index fc0388e0..0a2c91e2 100644 --- a/news/2008-03-19.mdwn +++ b/news/2008-03-19.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2008-09-11.mdwn b/news/2008-09-11.mdwn index 1060761c..85f31317 100644 --- a/news/2008-09-11.mdwn +++ b/news/2008-09-11.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2008-11-14.mdwn b/news/2008-11-14.mdwn index 1e2c8802..9cdbdea0 100644 --- a/news/2008-11-14.mdwn +++ b/news/2008-11-14.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2008-12-12.mdwn b/news/2008-12-12.mdwn index 1850cb56..c55b991e 100644 --- a/news/2008-12-12.mdwn +++ b/news/2008-12-12.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/news/2009-03-28.mdwn b/news/2009-03-28.mdwn index 2f67b6ce..72741457 100644 --- a/news/2009-03-28.mdwn +++ b/news/2009-03-28.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/open_issues.mdwn b/open_issues.mdwn index 8aa07c1c..c372abfb 100644 --- a/open_issues.mdwn +++ b/open_issues.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,17 +8,17 @@ 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="Open Issues"]] +[[!meta title="Open Issues"]] This is a dumping ground for open issues. -[[inline +[[!inline pages=none show=-1 feeds=no actions=yes rootpage="open_issues" postformtext="Add a new item titled:"]] -[[map pages="(./open_issues/* or */open_issues/* or +[[!map pages="(./open_issues/* or */open_issues/* or hurd/running/debian/porting/* or tagged(open_issue*)) and !*/discussion" show=title]] diff --git a/open_issues/blkrrpart_ioctl.mdwn b/open_issues/blkrrpart_ioctl.mdwn index 6a4c0378..81e07f3e 100644 --- a/open_issues/blkrrpart_ioctl.mdwn +++ b/open_issues/blkrrpart_ioctl.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,9 +8,9 @@ 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="BLKRRPART IOCTL"]] +[[!meta title="BLKRRPART IOCTL"]] -[[tag open_issue_glibc open_issue_hurd open_issue_gnumach]] +[[!tag open_issue_glibc open_issue_hurd open_issue_gnumach]] Just like in other Unix systems one can, for example, use `fdisk` or `parted` to manage hard disks' partition tables. After doing changes to a disk's diff --git a/persistency.mdwn b/persistency.mdwn index 17176708..16234c9b 100644 --- a/persistency.mdwn +++ b/persistency.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/policy.mdwn b/policy.mdwn index f0a414f2..7412de5f 100644 --- a/policy.mdwn +++ b/policy.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/principal.mdwn b/principal.mdwn index 897c0436..47ec3c7f 100644 --- a/principal.mdwn +++ b/principal.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/public_hurd_boxen.mdwn b/public_hurd_boxen.mdwn index b4ea6169..f504225b 100644 --- a/public_hurd_boxen.mdwn +++ b/public_hurd_boxen.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2006, 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2006, 2007, 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -11,7 +11,7 @@ is included in the section entitled Here are some Hurd boxes that users have made available to the public: -[[table class="table_style_1" data=""" +[[!table class="table_style_1" data=""" "Host Name","Operator","Access","Distro","Machine Specs","Comments" "flubber.bddebian.com","[[Barry_de_Freese|bddebian]]","ssh; port 2250","Debian","Celeron; 2.2 GHz; 333 MiB","domU on zenhost" "clubber.bddebian.com","[[Barry_de_Freese|bddebian]]","ssh; port 2251","Debian","PIII 1 GHz; 384 MiB" diff --git a/qemu.mdwn b/qemu.mdwn index 97ce5693..c0ed12f0 100644 --- a/qemu.mdwn +++ b/qemu.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2005, 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2005, 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/recent_changes.mdwn b/recent_changes.mdwn index 708e4588..e9bd13c4 100644 --- a/recent_changes.mdwn +++ b/recent_changes.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Recent Changes"]] +[[!meta title="Recent Changes"]] -[[inline pages="internal(recent_changes/change_*)" template=recentchanges +[[!inline pages="internal(recent_changes/change_*)" template=recentchanges show=0]] diff --git a/rpc.mdwn b/rpc.mdwn index e60254d1..451dd4d4 100644 --- a/rpc.mdwn +++ b/rpc.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/rules.mdwn b/rules.mdwn index d1a544e0..ccc7363e 100644 --- a/rules.mdwn +++ b/rules.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/rules/savannah_group.mdwn b/rules/savannah_group.mdwn index ab84e75d..7de688be 100644 --- a/rules/savannah_group.mdwn +++ b/rules/savannah_group.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2006, 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2006, 2007, 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/rules/source_repositories.mdwn b/rules/source_repositories.mdwn index 2c54e7cf..f15d0f3a 100644 --- a/rules/source_repositories.mdwn +++ b/rules/source_repositories.mdwn @@ -1,7 +1,7 @@ -[[meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/security.mdwn b/security.mdwn index ae925f74..4c037982 100644 --- a/security.mdwn +++ b/security.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/sfi.mdwn b/sfi.mdwn index 1a987290..67d26105 100644 --- a/sfi.mdwn +++ b/sfi.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/shortcuts.mdwn b/shortcuts.mdwn index 19368aab..47698bb2 100644 --- a/shortcuts.mdwn +++ b/shortcuts.mdwn @@ -1,58 +1,58 @@ -[[if test="enabled(shortcut)" +[[!if test="enabled(shortcut)" then="This wiki has shortcuts **enabled**." else="This wiki has shortcuts **disabled**."]] Some examples of using shortcuts include: - \[[google foo]] - \[[wikipedia War_of_1812]] - \[[debbug 12345]] + \[[!google foo]] + \[[!wikipedia War_of_1812]] + \[[!debbug 12345]] This page controls what shortcut links the wiki supports. -* [[shortcut name=google url="http://www.google.com/search?q=%s"]] -* [[shortcut name=archive url="http://web.archive.org/*/%S"]] -* [[shortcut name=gmap url="http://maps.google.com/maps?q=%s"]] -* [[shortcut name=gmsg url="http://groups.google.com/groups?selm=%s"]] -* [[shortcut name=wikipedia url="http://en.wikipedia.org/wiki/%s"]] -* [[shortcut name=wikitravel url="http://wikitravel.org/en/%s"]] -* [[shortcut name=debbug url="http://bugs.debian.org/%s" desc="bug #%s"]] -* [[shortcut name=deblist url="http://lists.debian.org/debian-%s" desc="debian-%s@lists.debian.org"]] -* [[shortcut name=debpkg url="http://packages.debian.org/%s"]] -* [[shortcut name=debpts url="http://packages.qa.debian.org/%s"]] -* [[shortcut name=debmsg url="http://lists.debian.org/msgid-search/%s"]] -* [[shortcut name=debrt url="https://rt.debian.org/Ticket/Display.html?id=%s"]] -* [[shortcut name=debss url="http://snapshot.debian.net/package/%s"]] - * Usage: `\[[debss package]]`, `\[[debss package#version]]`, or `\[[debss package/version]]`. See http://snapshot.debian.net for details. -* [[shortcut name=fdobug url="https://bugs.freedesktop.org/show_bug.cgi?id=%s" desc="freedesktop.org bug #%s"]] -* [[shortcut name=fdolist url="http://lists.freedesktop.org/mailman/listinfo/%s" desc="%s@lists.freedesktop.org"]] -* [[shortcut name=gnomebug url="http://bugzilla.gnome.org/show_bug.cgi?id=%s" desc="GNOME bug #%s"]] -* [[shortcut name=linuxbug url="http://bugzilla.kernel.org/show_bug.cgi?id=%s" desc="Linux bug #%s"]] -* [[shortcut name=mozbug url="https://bugzilla.mozilla.org/show_bug.cgi?id=%s" desc="Mozilla bug #%s"]] -* [[shortcut name=gnulist url="http://lists.gnu.org/mailman/listinfo/%s" desc="%s@gnu.org"]] -* [[shortcut name=marcmsg url="http://marc.info/?i=%s"]] -* [[shortcut name=marclist url="http://marc.info/?l=%s"]] -* [[shortcut name=gmane url="http://dir.gmane.org/gmane.%s" desc="gmane.%s"]] -* [[shortcut name=gmanemsg url="http://mid.gmane.org/%s"]] -* [[shortcut name=cpan url="http://search.cpan.org/search?mode=dist&query=%s"]] -* [[shortcut name=ctan url="http://tug.ctan.org/cgi-bin/ctanPackageInformation.py?id=%s"]] -* [[shortcut name=hoogle url="http://haskell.org/hoogle/?q=%s"]] -* [[shortcut name=iki url="http://ikiwiki.info/%S/"]] -* [[shortcut name=ljuser url="http://%s.livejournal.com/"]] -* [[shortcut name=rfc url="http://www.ietf.org/rfc/rfc%s.txt" desc="RFC %s"]] -* [[shortcut name=c2 url="http://c2.com/cgi/wiki?%s"]] -* [[shortcut name=meatballwiki url="http://www.usemod.com/cgi-bin/mb.pl?%s"]] -* [[shortcut name=emacswiki url="http://www.emacswiki.org/cgi-bin/wiki/%s"]] -* [[shortcut name=haskellwiki url="http://haskell.org/haskellwiki/%s"]] -* [[shortcut name=dict url="http://www.dict.org/bin/Dict?Form=Dict1&Strategy=*&Database=*&Query=%s"]] -* [[shortcut name=imdb url="http://imdb.com/find?q=%s"]] -* [[shortcut name=gpg url="http://pgpkeys.mit.edu:11371/pks/lookup?op=vindex&exact=on&search=0x%s"]] -* [[shortcut name=perldoc url="http://perldoc.perl.org/search.html?q=%s"]] -* [[shortcut name=whois url="http://reports.internic.net/cgi/whois?whois_nic=%s&type=domain"]] -* [[shortcut name=cve url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=%s"]] -* [[shortcut name=cia url="http://cia.vc/stats/project/%s"]] -* [[shortcut name=ciauser url="http://cia.vc/stats/user/%s"]] -* [[shortcut name=flickr url="http://www.flickr.com/photos/%s"]] +* [[!shortcut name=google url="http://www.google.com/search?q=%s"]] +* [[!shortcut name=archive url="http://web.archive.org/*/%S"]] +* [[!shortcut name=gmap url="http://maps.google.com/maps?q=%s"]] +* [[!shortcut name=gmsg url="http://groups.google.com/groups?selm=%s"]] +* [[!shortcut name=wikipedia url="http://en.wikipedia.org/wiki/%s"]] +* [[!shortcut name=wikitravel url="http://wikitravel.org/en/%s"]] +* [[!shortcut name=debbug url="http://bugs.debian.org/%s" desc="bug #%s"]] +* [[!shortcut name=deblist url="http://lists.debian.org/debian-%s" desc="debian-%s@lists.debian.org"]] +* [[!shortcut name=debpkg url="http://packages.debian.org/%s"]] +* [[!shortcut name=debpts url="http://packages.qa.debian.org/%s"]] +* [[!shortcut name=debmsg url="http://lists.debian.org/msgid-search/%s"]] +* [[!shortcut name=debrt url="https://rt.debian.org/Ticket/Display.html?id=%s"]] +* [[!shortcut name=debss url="http://snapshot.debian.net/package/%s"]] + * Usage: `\[[!debss package]]`, `\[[!debss package#version]]`, or `\[[!debss package/version]]`. See http://snapshot.debian.net for details. +* [[!shortcut name=fdobug url="https://bugs.freedesktop.org/show_bug.cgi?id=%s" desc="freedesktop.org bug #%s"]] +* [[!shortcut name=fdolist url="http://lists.freedesktop.org/mailman/listinfo/%s" desc="%s@lists.freedesktop.org"]] +* [[!shortcut name=gnomebug url="http://bugzilla.gnome.org/show_bug.cgi?id=%s" desc="GNOME bug #%s"]] +* [[!shortcut name=linuxbug url="http://bugzilla.kernel.org/show_bug.cgi?id=%s" desc="Linux bug #%s"]] +* [[!shortcut name=mozbug url="https://bugzilla.mozilla.org/show_bug.cgi?id=%s" desc="Mozilla bug #%s"]] +* [[!shortcut name=gnulist url="http://lists.gnu.org/mailman/listinfo/%s" desc="%s@gnu.org"]] +* [[!shortcut name=marcmsg url="http://marc.info/?i=%s"]] +* [[!shortcut name=marclist url="http://marc.info/?l=%s"]] +* [[!shortcut name=gmane url="http://dir.gmane.org/gmane.%s" desc="gmane.%s"]] +* [[!shortcut name=gmanemsg url="http://mid.gmane.org/%s"]] +* [[!shortcut name=cpan url="http://search.cpan.org/search?mode=dist&query=%s"]] +* [[!shortcut name=ctan url="http://tug.ctan.org/cgi-bin/ctanPackageInformation.py?id=%s"]] +* [[!shortcut name=hoogle url="http://haskell.org/hoogle/?q=%s"]] +* [[!shortcut name=iki url="http://ikiwiki.info/%S/"]] +* [[!shortcut name=ljuser url="http://%s.livejournal.com/"]] +* [[!shortcut name=rfc url="http://www.ietf.org/rfc/rfc%s.txt" desc="RFC %s"]] +* [[!shortcut name=c2 url="http://c2.com/cgi/wiki?%s"]] +* [[!shortcut name=meatballwiki url="http://www.usemod.com/cgi-bin/mb.pl?%s"]] +* [[!shortcut name=emacswiki url="http://www.emacswiki.org/cgi-bin/wiki/%s"]] +* [[!shortcut name=haskellwiki url="http://haskell.org/haskellwiki/%s"]] +* [[!shortcut name=dict url="http://www.dict.org/bin/Dict?Form=Dict1&Strategy=*&Database=*&Query=%s"]] +* [[!shortcut name=imdb url="http://imdb.com/find?q=%s"]] +* [[!shortcut name=gpg url="http://pgpkeys.mit.edu:11371/pks/lookup?op=vindex&exact=on&search=0x%s"]] +* [[!shortcut name=perldoc url="http://perldoc.perl.org/search.html?q=%s"]] +* [[!shortcut name=whois url="http://reports.internic.net/cgi/whois?whois_nic=%s&type=domain"]] +* [[!shortcut name=cve url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=%s"]] +* [[!shortcut name=cia url="http://cia.vc/stats/project/%s"]] +* [[!shortcut name=ciauser url="http://cia.vc/stats/user/%s"]] +* [[!shortcut name=flickr url="http://www.flickr.com/photos/%s"]] To add a new shortcut, use the `shortcut` [[ikiwiki/PreprocessorDirective]]. In the url, "%s" is replaced with the @@ -65,14 +65,14 @@ Remember that the `name` you give the shortcut will become a new with an existing directive. If you come up with a shortcut that you think others might find useful, -consider contributing it to the [[iki shortcuts]] page on the ikiwiki +consider contributing it to the [[!iki shortcuts]] page on the ikiwiki ikiwiki, so that future versions of ikiwiki will include your shortcut in the standard underlay. # Local stuff -* [[shortcut name=source_gnumach-1-branch url="http://cvs.savannah.gnu.org/viewvc/gnumach/%S?view=log&root=hurd&pathrev=gnumach-1-branch"]] -* [[shortcut name=GNU_Savannah_bug url="http://savannah.gnu.org/bugs/?%s" desc="GNU Savannah bug #%s"]] -* [[shortcut name=GNU_Savannah_patch url="http://savannah.gnu.org/patch/?%s" desc="GNU Savannah patch #%s"]] -* [[shortcut name=GNU_Savannah_task url="http://savannah.gnu.org/task/?%s" desc="GNU Savannah task #%s"]] +* [[!shortcut name=source_gnumach-1-branch url="http://cvs.savannah.gnu.org/viewvc/gnumach/%S?view=log&root=hurd&pathrev=gnumach-1-branch"]] +* [[!shortcut name=GNU_Savannah_bug url="http://savannah.gnu.org/bugs/?%s" desc="GNU Savannah bug #%s"]] +* [[!shortcut name=GNU_Savannah_patch url="http://savannah.gnu.org/patch/?%s" desc="GNU Savannah patch #%s"]] +* [[!shortcut name=GNU_Savannah_task url="http://savannah.gnu.org/task/?%s" desc="GNU Savannah task #%s"]] diff --git a/sidebar.mdwn b/sidebar.mdwn index 85596be8..89df4b54 100644 --- a/sidebar.mdwn +++ b/sidebar.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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]]."]]"""]] -Welcome to... [[img hurd/logo/boxes-redrawn.png link=/hurd/logo]] ... the GNU +Welcome to... [[!img hurd/logo/boxes-redrawn.png link=/hurd/logo]] ... the GNU Hurd! * **[[Home|/index]]** @@ -18,13 +18,13 @@ Hurd! --- - * **[[Hurd]]**[[if test="destpage(hurd*)" then=" + * **[[Hurd]]**[[!if test="destpage(hurd*)" then=" * *[[Hurd/Documentation]]* * *[[hurd/Running]]*"]] - * **[[microkernel/Mach]]**[[if test="destpage(microkernel/mach*)" then=" + * **[[microkernel/Mach]]**[[!if test="destpage(microkernel/mach*)" then=" * *[[microkernel/mach/Documentation]]* * *[[GNU_Mach|microkernel/mach/gnumach]]*"]] - * *[[microkernel/mach/MIG]]*[[if test="destpage(microkernel/mach/mig*)" then=" + * *[[microkernel/mach/MIG]]*[[!if test="destpage(microkernel/mach/mig*)" then=" * [[microkernel/mach/mig/GNU_MIG]]"]] --- diff --git a/tcb.mdwn b/tcb.mdwn index d321a954..9b117fae 100644 --- a/tcb.mdwn +++ b/tcb.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/trackers.mdwn b/trackers.mdwn index c47daf9a..028117ef 100644 --- a/trackers.mdwn +++ b/trackers.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/trust.mdwn b/trust.mdwn index f0d29a9c..f0fe0cb7 100644 --- a/trust.mdwn +++ b/trust.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/unix.mdwn b/unix.mdwn index b313010a..96c46caf 100644 --- a/unix.mdwn +++ b/unix.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -10,7 +10,7 @@ is included in the section entitled # External - * Wikipedia page about [[wikipedia UNIX]]. + * Wikipedia page about [[!wikipedia UNIX]]. * [*Standardizing UNIX*](http://www.informit.com/articles/printerfriendly.aspx?p=691503), an diff --git a/user/flaviocruz.mdwn b/user/flaviocruz.mdwn index 9c9af71d..450c2754 100644 --- a/user/flaviocruz.mdwn +++ b/user/flaviocruz.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/user/madhusudancs.mdwn b/user/madhusudancs.mdwn index 1139c718..382f988a 100644 --- a/user/madhusudancs.mdwn +++ b/user/madhusudancs.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -10,7 +10,7 @@ is included in the section entitled [[!meta title="GNU/Linux compatible procfs"]] -[[!toc ]] +[[!toc]] ---- Project Name diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn index 2de8eb4f..8cf47568 100644 --- a/user/scolobb.mdwn +++ b/user/scolobb.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/user/tschwinge.mdwn b/user/tschwinge.mdwn index b72f26f5..5ffa6fd8 100644 --- a/user/tschwinge.mdwn +++ b/user/tschwinge.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -8,7 +8,7 @@ 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="Thomas Schwinge"]] +[[!meta title="Thomas Schwinge"]] diff --git a/user/vincentvikram.mdwn b/user/vincentvikram.mdwn index 847325e2..8927bd4e 100644 --- a/user/vincentvikram.mdwn +++ b/user/vincentvikram.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/user/zhengda/howto.mdwn b/user/zhengda/howto.mdwn index ed13acc2..cea3cf0b 100644 --- a/user/zhengda/howto.mdwn +++ b/user/zhengda/howto.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 diff --git a/virtualization.mdwn b/virtualization.mdwn index 88f95328..325340b0 100644 --- a/virtualization.mdwn +++ b/virtualization.mdwn @@ -1,6 +1,6 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!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 @@ -10,7 +10,7 @@ is included in the section entitled # External - * Wikipedia page about [[wikipedia Virtualization]]. + * Wikipedia page about [[!wikipedia Virtualization]]. # See Also -- cgit v1.3.1 From be6ec0cbbf094924d989d80ddde40d359e7f8ffd Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 18 Jun 2009 15:32:59 +0200 Subject: Move back some pages to their long-year locations, add some redirections, add stable_URL tags. --- history.mdwn | 4 +- hurd-and-linux.html | 49 ++ hurd-l4.mdwn | 2 + hurd-paper.html | 761 ++++++++++++++++ hurd-talk.html | 1062 +++++++++++++++++++++++ hurd.mdwn | 2 +- hurd/documentation.mdwn | 10 +- hurd/documentation/hurd-and-linux.html | 47 - hurd/documentation/hurd-and-linux.mdwn | 11 + hurd/documentation/hurd-paper.html | 760 ---------------- hurd/documentation/hurd-paper.mdwn | 11 + hurd/documentation/hurd-talk.html | 1061 ---------------------- hurd/documentation/hurd-talk.mdwn | 11 + hurd/running/gnu/universal_package_manager.mdwn | 5 +- microkernel/faq/multiserver_microkernel.mdwn | 6 +- 15 files changed, 1922 insertions(+), 1880 deletions(-) create mode 100644 hurd-and-linux.html create mode 100644 hurd-paper.html create mode 100644 hurd-talk.html delete mode 100644 hurd/documentation/hurd-and-linux.html create mode 100644 hurd/documentation/hurd-and-linux.mdwn delete mode 100644 hurd/documentation/hurd-paper.html create mode 100644 hurd/documentation/hurd-paper.mdwn delete mode 100644 hurd/documentation/hurd-talk.html create mode 100644 hurd/documentation/hurd-talk.mdwn (limited to 'hurd/documentation') diff --git a/history.mdwn b/history.mdwn index 927482d9..8f155b54 100644 --- a/history.mdwn +++ b/history.mdwn @@ -9,6 +9,8 @@ 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 stable_URL]] + Richard Stallman (RMS) started GNU in 1983, as a project to create a complete free operating system. In the text of the GNU Manifesto, he mentioned that there is a primitive kernel. In the first GNUsletter, @@ -49,7 +51,7 @@ into multiple processes. [Gnusletter, Jan. 1991]. RMS explains the relationship between [[the Hurd and -Linux|hurd/documentation/hurd-and-linux]], where he mentions +Linux|hurd-and-linux]], where he mentions that the FSF started developing the Hurd in 1990. As of [Gnusletter, Nov. 1991], the Hurd (running on Mach) is GNU's official kernel. diff --git a/hurd-and-linux.html b/hurd-and-linux.html new file mode 100644 index 00000000..01b08aa1 --- /dev/null +++ b/hurd-and-linux.html @@ -0,0 +1,49 @@ +[[!meta copyright="Copyright © 1996, 1997, 1998, 2008, 2009 Free Software +Foundation, Inc."]] + +[[!meta license="Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved."]] + +[[!meta title="The Hurd and Linux"]] + +[[!tag stable_URL]] + +by Richard Stallman. + +

+People sometimes ask, ``Why did the FSF develop a new free kernel +instead of using Linux?'' It's a reasonable question. The answer, +briefly, is that that is not the question we faced. + +

+When we started developing the Hurd in 1990, the question facing us +was, ``How can we get a free kernel for the GNU system?'' There was +no free Unix-like kernel then, and we knew of no other plan to write +one. The only way we could expect to have a free kernel was to write +it ourselves. So we started. + +

+We heard about Linux after its release. At that time, the question +facing us was, ``Should we cancel the Hurd project and use Linux +instead?'' + +

+We heard that Linux was not at all portable (this may not be true +today, but that's what we heard then). And we heard that Linux was +architecturally on a par with the Unix kernel; our work was leading to +something much more powerful. + +

+Given the years of work we had already put into the Hurd, we decided +to finish it rather than throw them away. + +

+If we did face the question that people ask---if Linux were already +available, and we were considering whether to start writing another +kernel---we would not do it. Instead we would choose another project, +something to do a job that no existing free software can do. + +

+But we did start the Hurd, back then, and now we have made it work. +We hope its superior architecture will make free operating systems +more powerful. diff --git a/hurd-l4.mdwn b/hurd-l4.mdwn index 5ad3c3d4..579c1190 100644 --- a/hurd-l4.mdwn +++ b/hurd-l4.mdwn @@ -8,4 +8,6 @@ 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 stable_URL]] + [[!meta redir=history/port_to_l4]] diff --git a/hurd-paper.html b/hurd-paper.html new file mode 100644 index 00000000..880f5fca --- /dev/null +++ b/hurd-paper.html @@ -0,0 +1,761 @@ +[[!meta copyright="Copyright © 1996, 1997, 1998, 2007, 2008, 2009 Free Software +Foundation, Inc."]] + +[[!meta license="Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved."]] + +[[!meta title="Towards a New Strategy of OS Design, an architectural overview +by Thomas Bushnell, BSG."]] + +[[!tag stable_URL]] + +This article explains why FSF is developing a new operating system named the +Hurd, which will be a foundation of the whole GNU system. +The Hurd is built +on top of CMU's Mach 3.0 kernel and uses Mach's virtual memory management and +message-passing facilities. +The GNU C Library will provide the Unix system +call interface, and will call the Hurd for needed services it can't provide +itself. +The design and implementation of the Hurd is being lead by Michael +Bushnell, with assistance from Richard Stallman, Roland McGrath, +Jan Brittenson, and others. + +

Part 1: A More Usable Approach to OS Design

+

+The fundamental purpose of an operating system (OS) is to enable a variety of +programs to share a single computer efficiently and productively. +This +demands memory protection, preemptively scheduled timesharing, coordinated +access to I/O peripherals, and other services. +In addition, an OS can allow +several users to share a computer. +In this case, efficiency demands services +that protect users from harming each other, enable them to share without +prior arrangement, and mediate access to physical devices. +

+On today's computer systems, programmers usually implement these goals +through a large program called the kernel. +Since this program must be +accessible to all user programs, it is the natural place to add functionality +to the system. +Since the only model for process interaction is that of +specific, individual services provided by the kernel, no one creates other +places to add functionality. +As time goes by, more and more is added to the +kernel. +

+A traditional system allows users to add components to a kernel only if they +both understand most of it and have a privileged status within the system. +Testing new components requires a much more painful edit-compile-debug cycle +than testing other programs. +It cannot be done while others are using the +system. +Bugs usually cause fatal system crashes, further disrupting others' +use of the system. +The entire kernel is usually non-pageable. +(There are +systems with pageable kernels, but deciding what can be paged is difficult +and error prone. +Usually the mechanisms are complex, making them difficult +to use even when adding simple extensions.) +

+Because of these restrictions, functionality which properly belongs +behind +the wall of a traditional kernel is usually left out of systems unless it is +absolutely mandatory. +Many good ideas, best done with an open/read/write +interface cannot be implemented because of the problems inherent in the +monolithic nature of a traditional system. +Further, even among those with +the endurance to implement new ideas, only those who are privileged users of +their computers can do so. +The software copyright system darkens the mire by +preventing unlicensed people from even reading the kernel source. +

+Some systems have tried to address these difficulties. +Smalltalk-80 and +the Lisp Machine both represented one method of getting around the problem. +System code is not distinguished from user code; all of the system is +accessible to the user and can be changed as need be. +Both systems were +built around languages that facilitated such easy replacement and extension, +and were moderately successful. +But they both were fairly poor at insulating +users and programs from each other, failing one of the principal goals of OS +design. +

+Most projects that use the Mach 3.0 kernel carry on the hard-to-change +tradition of OS design. +The internal structure is different, but the same +heavy barrier between user and system remains. +The single-servers, while +fairly easy to construct, inherit all the deficiencies of the monolithic +kernels. +

+A multi-server divides the kernel functionality up into logical blocks with +well-defined interfaces. +Properly done, it is easier to make changes and add +functionality. +So most multi-server projects do somewhat better. +Much more +of the system is pageable. +You can debug the system more easily. +You can +test new system components without interfering with other users. +But the +wall between user and system remains; no user can cross it without special +privilege. +

+The GNU Hurd, by contrast, is designed to make the area of +system +code as +limited as possible. +Programs are required to communicate only with a few +essential parts of the kernel; the rest of the system is replaceable +dynamically. +Users can use whatever parts of the remainder of the system +they want, and can easily add components themselves for other users to take +advantage of. +No mutual trust need exist in advance for users to use each +other's services, nor does the system become vulnerable by trusting the +services of arbitrary users. +

+This has been done by identifying those system components which users +must +use in order to communicate with each other. +One of these is responsible for +identifying users' identities and is called the + +authentication server. + +In +order to establish each other's identities, programs must communicate, each +with an authentication server they trust. +Another component establishes +control over system components by the superuser, provides global bookkeeping +operations, and is called the + +process server. + +

+Not all user programs need to communicate with the process server; it is only +necessary for programs which require its services. +Likewise, the +authentication server is only necessary for programs that wish to communicate +their identity to another. +None of the remaining services carry any special +status; not the network implementation, the filesystems, the program +execution mechanism (including setuid), or any others. + +

The Translator Mechanism

+

+The Hurd uses Mach ports primarily as methods for communicating between users +and servers. +(A Mach port is a communication point on a Mach task where +messages are sent and received.) Each port implements a particular set of +protocols, representing operations that can be undertaken on the underlying +object represented by the port. +Some of the protocols specified by the Hurd +are the I/O protocol, used for generic I/O operations; the file protocol, +used for filesystem operations; the socket protocol, used for network +operations; and the process protocol, used for manipulating processes et al. +

+Most servers are accessed by opening files. +Normally, when you open a file, +you create a port associated with that file that is owned by the server +that owns the directory containing the file. +For example, a disk-based +filesystem will normally serve a large number of ports, each of which +represents an open file or directory. +When a file is opened, the server +creates a new port, associates it with the file, and returns the port to the +calling program. +

+However, a file can have a +translator +associated with it. +In this case, +rather than return its own port which refers to the contents of the file, the +server executes a translator program associated with that file. +This +translator is given a port to the actual contents of the file, and is then +asked to return a port to the original user to complete the open operation. +

+This mechanism is used for +mount +by having a translator associated with +each mount point. +When a program opens the mount point, the translator (in +this case, a program which understands the disk format of the mounted +filesystem) is executed and returns a port to the program. +After the +translator is started, it need not be run again unless it dies; the parent +filesystem retains a port to the translator to use in further requests. +

+The owner of a file can associate a translator with it without special +permission. +This means that any program can be specified as a translator. +Obviously the system will not work properly if the translator does not +implement the file protocol correctly. +However, the Hurd is constructed so +that the worst possible consequence is an interruptible hang. +

+One way to use translators is to access hierarchically structured data using +the file protocol. +For example, all the complexity of the user interface to +the +ftp +program is removed. +Users need only know that a particular +directory represents FTP and can use all the standard file manipulation +commands (e.g +ls +or +cp) +to access the remote system, rather than learning +a new set. +Similarly, a simple translator could ease the complexity of +tar +or +gzip. +(Such transparent access would have some added cost, but it would +be convenient.) + +

Generic Services

+

+With translators, the filesystem can act as a rendezvous for interfaces which +are not similar to files. +Consider a service which implements some version +of the X protocol, using Mach messages as an underlying transport. +For each +X display, a file can be created with the appropriate program as its +translator. +X clients would open that file. +At that point, few file +operations would be useful (read and write, for example, would be useless), +but new operations ( +XCreateWindow +or +XDrawText) +might become meaningful. +In this case, the filesystem protocol is used only to manipulate +characteristics of the node used for the rendezvous. +The node need not +support I/O operations, though it should reply to any such messages with a +message_not_understood +return code. +

+This translator technique is used to contact most of the services in the Hurd +that are not structured like hierarchical filesystems. +For example, the +password server, which hands out authorization tags in exchange for +passwords, is contacted this way. +Network protocol servers are also +contacted in this fashion. +Roland McGrath thought up this use of translators. + +

Clever Filesystem Pictures

+

+In the Hurd, translators can also be used to present a filesystem-like view +of another part of the filesystem, with some semantics changed. +For example, +it would be nice to have a filesystem that cannot itself be changed, but +nonetheless records changed versions of its files elsewhere. +(This could be +useful for source code management.) +

+The Hurd will have a translator which creates a directory which is a +conceptual union of other directories, with collision resolution rules of +various sorts. +This can be used to present a single directory to users that +contains all the programs they would want to execute. +There are other useful +variations on this theme. + +

What The User Can Do

+

+No translator gains extra privilege by virtue of being hooked into the +filesystem. +Translators run with the uid of the owner of the file being +translated, and can only be set or changed by that owner. +The I/O and +filesystem protocols are carefully designed to allow their use by mutually +untrusting clients and servers. +Indeed, translators are just ordinary +programs. +The GNU C library has a variety of facilities to make common sorts +of translators easier to write. +

+Some translators may need special privileges, such as the password server or +translators which allow setuid execution. +These translators could be run by +anyone, but only if they are set on a root-owned node would they be able to +provide all their services successfully. +This is analogous to letting any +user call the +reboot +system call, but only honoring it if that user is root. + +

Why This Is So Different

+

+What this design provides is completely novel to the Unix world. +Until now, +OSs have kept huge portions of their functionality in the realm of system +code, thus preventing its modification and extension except in extreme need. +Users cannot replace parts of the system in their programs no matter how much +easier that would make their task, and system managers are loath to install +random tweaks off the net into their kernels. +

+In the Hurd, users can change almost all of the things that are decided for +them in advance by traditional systems. +In combination with the tremendous +control given by the Mach kernel over task address spaces and properties, the +Hurd provides a system in which users will, for the first time, be able to +replace parts of the system they dislike, without disrupting other users. +

+Most Mach-based OSs to date have mostly implemented a wider set of the + +same old + +Unix semantics in a new environment. +In contrast, GNU is extending +those semantics to allow users to improve, bypass, or replace them. + + +

Part 2: A Look at Some of the Hurd's Beasts

+

The Authentication Server

+

+One of the Hurd's more central servers is the authentication server. +Each +port to this server identifies a user and is associated by this server with +an +id block. +Each id block contains sets of user and group ids. +Either +set may be empty. +This server is not the same as the password server +referred to above. +

+The authentication server exports three services. +First, it provides simple +boolean operations on authentication ports: given two authentication ports, +this server will provide a third port representing the union of the two sets +of uids and gids. +Second, this server allows any user with a uid of zero to +create an arbitrary authentication port. +Finally, this server provides RPCs +(Remote Procedure Calls between different programs and possibly different +hosts) which allow mutually untrusting clients and servers to establish their +identities and pass initial information on each other. +This is crucial to +the security of the filesystem and I/O protocols. +

+Any user could write a program which implements the authentication protocol; +this does not violate the system's security. +When a service needs to +authenticate a user, it communicates with its trusted authentication server. +If that user is using a different authentication server, the transaction will +fail and the server can refuse to communicate further. +Because, in effect, +this forces all programs on the system to use the same authentication server, +we have designed its interface to make any safe operation possible, and to +include no extraneous operations. +(This is why there is a separate password +server.) +

The Process Server

+

+The process server acts as an information categorization repository. +There +are four main services supported by this server. +First, the process server +keeps track of generic host-level information not handled by the Mach kernel. +For example, the hostname, the hostid, and the system version are maintained +by the process server. +Second, this server maintains the Posix notions of +sessions and process groups, to help out programs that wish to use Posix +features. +

+Third, the process server maintains a one-to-one mapping between Mach tasks +and Hurd processes. +Every task is assigned a pid. +Processes can register a +message port with this server, which can then be given out to any program +which requests it. +This server makes no attempt to keep these message ports +private, so user programs are expected to implement whatever security they +need themselves. +(The GNU C Library provides convenient functions for all +this.) Processes can tell the process server their current `argv' and `envp' +values; this server will then provide, on request, these vectors of arguments +and environment. +This is useful for writing +ps-like +programs and also +makes it easier to hide or change this information. +None of these features +are mandatory. +Programs are free to disregard all of this and never register +themselves with the process server at all. +They will, however, still have a +pid assigned. +

+Finally, the process server implements +process collections, +which are used +to collect a number of process message ports at the same time. +Also, +facilities are provided for converting between pids, process server ports, +and Mach task ports, while ensuring the security of the ports managed. +

+It is important to stress that the process server is optional. +Because of +restrictions in Mach, programs must run as root in order to identify all the +tasks in the system. +But given that, multiple process servers could +co-exist, each with their own clients, giving their own model of the +universe. +Those process server features which do not require root privileges +to be implemented could be done as per-user servers. +The user's hands are +not tied. +

Transparent FTP

+

+Transparent FTP is an intriguing idea whose time has come. +The popular +ange-ftp +package available for GNU Emacs makes access to FTP files +virtually transparent to all the Emacs file manipulation functions. +Transparent FTP does the same thing, but in a system wide fashion. +This +server is not yet written; the details remain to be fleshed out, and will +doubtless change with experience. +

+In a BSD kernel, a transparent FTP filesystem would be no harder to write +than in the Hurd. +But mention the idea to a BSD kernel hacker, and the +response is that ``such a thing doesn't belong in the kernel''. +In a sense, +this is correct. +It violates all the layering principles of such systems to +place such things in the kernel. +The unfortunate side effect, however, is +that the design methodology (which is based on preventing users from changing +things they don't like) is being used to prevent system designers from making +things better. +(Recent BSD kernels make it possible to write a user program +that provides transparent FTP. +An example is +alex, +but it needs to run +with full root privileges.) +

+In the Hurd, there are no obstacles to doing transparent FTP. +A translator +will be provided for the node +/ftp. +The contents of +/ftp +will probably +not be directly listable, though further subdirectories will be. +There will +be a variety of possible formats. +For example, to access files on uunet, one +could + +cd /ftp/ftp.uu.net:anonymous:mib@gnu. + +Or to access files on a remote +account, one might + +cd /ftp/gnu.org:mib:passwd. + +Parts of this +command could be left out and the transparent FTP program would read them +from a user's +.netrc +file. +In the last case, one might just + +cd /ftp/gnu.org; + +when the rest of the data is already in +.netrc. +

+There is no need to do a +cd +first--use any file command. +To find out about +RFC 1097 (the Telnet Subliminal Message Option), just type + +more /ftp/ftp.uu.net/inet/rfc/rfc1097. + +A copy command to a local disk +could be used if the RFC would be read frequently. +

Filesystems

+

+Ordinary filesystems are also being implemented. +The initial release of the +Hurd will contain a filesystem upwardly compatible with the BSD 4.4 Fast File +System. +In addition to the ordinary semantics, it will provide means to +record translators, offer thirty-two bit user ids and group ids, and supply a +new id per file, called the +author +of the file, which can be set by the +owner arbitrarily. +In addition, because users in the Hurd can have multiple +uids (or even none), there is an additional set of permission bits providing +access control for + +unknown user + +(no uids) as distinct from + +known but arbitrary user + +(some uids: the existing +world +category of file +permissions). +

+The Network File System protocol will be implemented using 4.4 BSD as a +starting point. +A log-structured filesystem will also be implemented using +the same ideas as in Sprite, but probably not the same format. +A GNU network +file protocol may be designed in time, or NFS may be extended to remove its +deficiencies. +There will also be various ``little'' filesystems, such as the +MS-DOS filesystem, to help people move files between GNU and other OSs. + +

Terminals

+

+An I/O server will provide the terminal semantics of Posix. +The GNU C +Library has features for keeping track of the controlling terminal and for +arranging to have proper job control signals sent at the proper times, as +well as features for obeying keyboard and hangup signals. +

+Programs will be able to insert a terminal driver into communications +channels in a variety of ways. +Servers like +rlogind +will be able to insert +the terminal protocol onto their network communication port. +Pseudo-terminals will not be necessary, though they will be provided for +backward compatibility with older programs. +No programs in GNU will depend +on them. +

+Nothing about a terminal driver is forced upon users. +A terminal driver +allows a user to get at the underlying communications channel easily, to +bypass itself on an as-needed basis or altogether, or to substitute a +different terminal driver-like program. +In the last case, provided the +alternate program implements the necessary interfaces, it will be used by the +C Library exactly as if it were the ordinary terminal driver. +

+Because of this flexibility, the original terminal driver will not provide +complex line editing features, restricting itself to the behavior found in +Posix and BSD. +In time, there will be a +readline-based +terminal driver, +which will provide complex line-editing features for those users who want +them. +

+The terminal driver will probably not provide good support for the +high-volume, rapid data transmission required by UUCP or SLIP. +Those +programs do not need any of its features. +Instead they will be using the +underlying Mach device ports for terminals, which support moving large +amounts of data efficiently. + +

Executing Programs

+

+The implementation of the +execve +call is spread across three programs. +The +library marshals the argument and environment vectors. +It then sends a +message to the file server that holds the file to be executed. +The file +server checks execute permissions and makes whatever changes it desires in +the exec call. +For example, if the file is marked setuid and the fileserver +has the ability, it will change the user identification of the new image. +The file server also decides if programs which had access to the old task +should continue to have access to the new task. +If the file server is +augmenting permissions, or executing an unreadable image, then the exec needs +to take place in a new Mach task to maintain security. +

+After deciding the policy associated with the new image, the filesystem calls +the exec server to load the task. +This server, using the BFD (Binary File +Descriptor) library, loads the image. +BFD supports a large number of object +file formats; almost any supported format will be executable. +This server +also handles scripts starting with +#!, +running them through the indicated +program. +

+The standard exec server also looks at the environment of the new image; if +it contains a variable +EXECSERVERS +then it uses the programs specified +there as exec servers instead of the system default. +(This is, of course, +not done for execs that the file server has requested be kept secure.) +

+The new image starts running in the GNU C Library, which sends a message to +the exec server to get the arguments, environment, umask, current directory, +etc. +None of this additional state is special to the file or exec servers; +if programs wish, they can use it in a different manner than the Library. + +

New Processes

+

+The +fork +call is implemented almost entirely in the GNU C Library. +The new +task is created by Mach kernel calls. +The C Library arranges to have its +image inherited properly. +The new task is registered with the process server +(though this is not mandatory). +The C Library provides vectors of functions +to be called at fork time: one vector to be called before the fork, one after +in the parent, and one after in the child. +(These features should not be +used to replace the normal fork-calling sequence; it is intended for +libraries which need to close ports or clean up before a fork occurs.) +The C +library will implement both fork calls specified by the draft Posix.4a (the +proposed standard dealing with the threads extension to the real-time +extension). +

+Nothing forces the user to create new tasks this way. +If a program wants to +use almost the normal fork, but with some special characteristics, then it +can do so. +Hooks will be provided by the C Library, or the function can even +be completely replaced. +None of this is possible in a traditional Unix +system. + +

Asynchronous Messages

+

+As mentioned above, the process server maintains a + +message port + +for each +task registered with it. +These ports are public, and are used to send +asynchronous messages to the task. +Signals, for example, are sent to the +message port. +The signal message also provides a port as an indication that +the sender should be trusted to send the signal. +The GNU C Library lists a +variety of ports in a table, each of which identifies a set of signals that +can be sent by anyone who possesses that port. +For example, if the user +possesses the task's kernel port, it is allowed to send any signal. +If the +user possesses a special + +terminal id + +port, it is allowed to send the +keyboard and hangup signals. +Users can add arbitrary new entries into the C +library's signal permissions table. +

+When a process's process group changes, the process server will send it a +message indicating the new process group. +In this case, the process server +proves its authority by providing the task's kernel port. +

+The C library also has messages to add and delete uids currently used by the +process. +If new uids are sent to the program, the library adds them to its +current set, and then exchanges messages with all the I/O servers it knows +about, proving to them its new authorization. +Similarly, a message can +delete uids. +In the latter case, the caller must provide the process's task +port. +(You can't harm a process by giving it extra permission, but you can +harm it by taking permission away.) The Hurd will provide user programs to +send these messages to processes. +For example, the +su +command will be able +to cause all the programs in your current login session, to gain a new uid, +rather than spawn a subshell. +

+The C library will allow programs to add asynchronous messages they wish to +recognize, as well as prevent recognition of the standard set. +

Making It Look Like Unix

+

+The C Library will implement all of the calls from BSD and Posix as well as +some obvious extensions to them. +This enables users to replace those calls +they dislike or bypass them entirely, whereas in Unix the calls must be used +``as they come'' with no alternatives possible. +

+In some environments binary compatibility will also be supported. +This works +by building a special version of the library which is then loaded somewhere +in the address space of the process. +(For example, on a VAX, it would be +tucked in above the stack.) A feature of Mach, called system call +redirection, is then used to trap Unix system calls and turn them into jumps +into this special version of the library. +(On almost all machines, the cost +of such a redirection is very small; this is a highly optimized path in Mach. +On a 386 it's about two dozen instructions. +This is little worse than a +simple procedure call.) +

+Many features of Unix, such as signal masks and vectors, are handled +completely by the library. +This makes such features significantly cheaper +than in Unix. +It is now reasonable to use +sigblock +extensively to protect +critical sections, rather than seeking out some other, less expensive method. + +

Network Protocols

+

+The Hurd will have a library that will make it very easy to port 4.4 BSD +protocol stacks into the Hurd. +This will enable operation, virtually for +free, of all the protocols supported by BSD. +Currently, this includes the +CCITT protocols, the TCP/IP protocols, the Xerox NS protocols, and the ISO +protocols. +

+For optimal performance some work would be necessary to take advantage of +Hurd features that provide for very high speed I/O. +For most protocols this +will require some thought, but not too much time. +The Hurd will run the +TCP/IP protocols as efficiently as possible. +

+As an interesting example of the flexibility of the Hurd design, consider the +case of IP trailers, used extensively in BSD for performance. +While the Hurd +will be willing to send and receive trailers, it will gain fairly little +advantage in doing so because there is no requirement that data be copied and +avoiding copies for page-aligned data is irrelevant. diff --git a/hurd-talk.html b/hurd-talk.html new file mode 100644 index 00000000..ec9eb777 --- /dev/null +++ b/hurd-talk.html @@ -0,0 +1,1062 @@ +[[!meta copyright="Copyright © 2001 Marcus Brinkmann"]] + +[[!meta license="Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved."]] + +[[!meta title="The Hurd, a presentation by Marcus Brinkmann"]] + +[[!tag stable_URL]] + +

Table of Contents

+ +
+

Talk about the Hurd

+

+This talk about the Hurd was written by Marcus Brinkmann for +

    +
  • OSDEM, Brussels, 4. Feb 2001, +
  • Frühjahrsfachgespräche, Cologne, 2. Mar 2001 and +
  • Libre Software Meeting, Bordeaux, 4. Jul 2001. +
+ +

Introduction

+

+When we talk about free software, we usually refer to the free +software licenses. We also need relief from software patents, so our +freedom is not restricted by them. But there is a third type of +freedom we need, and that's user freedom. + +

+Expert users don't take a system as it is. They like to change the +configuration, and they want to run the software that works best for +them. That includes window managers as well as your favourite text +editor. But even on a GNU/Linux system consisting only of free +software, you can not easily use the filesystem format, network +protocol or binary format you want without special privileges. In +traditional unix systems, user freedom is severly restricted by the +system administrator. + +

+The Hurd removes these restrictions from the user. It provides an +user extensible system framework without giving up POSIX compatibility +and the unix security model. Throughout this talk, we will see that +this brings further advantages beside freedom. + +

Overview

+
+ +

+The Hurd is a POSIX compatible multi-server +system operating on top of the GNU Mach microkernel. + +

+Topics: +

    +
  • GNU Mach
  • +
  • The Hurd
  • +
  • Development
  • +
  • Debian GNU/Hurd
  • +
+
+ +

+The Hurd is a POSIX compatible multi-server system operating on top of +the GNU Mach Microkernel. + +

+I will have to explain what GNU Mach is, so we start with that. Then +I will talk about the Hurd's architecture. After that, I will give a +short overview on the Hurd libraries. Finally, I will tell you how +the Debian project is related to the Hurd. + +

Historicals

+ +
+
    +
  • 1983: Richard Stallman founds the GNU project.
  • +
  • 1988: Decision is made to use Mach 3.0 as the kernel.
  • +
  • 1991: Mach 3.0 is released under compatible license.
  • +
  • 1991: Thomas Bushnell, BSG, founds the Hurd project.
  • +
  • 1994: The Hurd boots the first time.
  • +
  • 1997: Version 0.2 of the Hurd is released.

  • +
  • 1998: Debian hurd-i386 archive is created.
  • +
  • 2001: Debian GNU/Hurd snapshot fills three CD images.
  • +
+
+ +

+When Richard Stallman founded the GNU project in 1983, he wanted to +write an operating system consisting only of free software. Very +soon, a lot of the essential tools were implemented, and released +under the GPL. However, one critical piece was missing: The kernel. +

+After considering several alternatives, it was decided not to write a +new kernel from scratch, but to start with the Mach microkernel. This +was in 1988, and it was not before 1991 that Mach was released under a +license allowing the GNU project to distribute it as a part of the +system. +

+In 1998, I started the Debian GNU/Hurd project, and in 2001 the number +of available GNU/Hurd packages fills three CD images. + +

Kernel Architectures

+
+

+Microkernel: +

    +
  • Enforces resource management (paging, scheduling)
  • +
  • Manages tasks
  • +
  • Implements message passing for IPC
  • +
  • Provides basic hardware support
  • +
+

+Monolithic kernel: +

    +
  • No message passing necessary
  • +
  • Rich set of features (filesystems, authentication, network + sockets, POSIX interface, ...)
  • +
+
+

+Microkernels were very popular in the scientific world around that +time. They don't implement a full operating system, but only the +infrastructure needed to enable other tasks to implement most +features. In contrast, monolithical kernels like Linux contain +program code of device drivers, network protocols, process management, +authentication, file systems, POSIX compatible interfaces and much +more. +

+So what are the basic facilities a microkernel provides? In general, +this is resource management and message passing. Resource management, +because the kernel task needs to run in a special privileged mode of +the processor, to be able to manipulate the memory management unit and +perform context switches (also to manage interrupts). Message +passing, because without a basic communication facility the other +tasks could not interact to provide the system services. Some +rudimentary hardware device support is often necessary to bootstrap +the system. So the basic jobs of a microkernel are enforcing the +paging policy (the actual paging can be done by an external pager +task), scheduling, message passing and probably basic hardware device +support. +

+Mach was the obvious choice back then, as it provides a rich set of +interfaces to get the job done. Beside a rather brain-dead device +interface, it provides tasks and threads, a messaging system allowing +synchronous and asynchronous operation and a complex interface for +external pagers. It's certainly not one of the sexiest microkernels +that exist today, but more like a big old mama. The GNU project +maintains its own version of Mach, called GNU Mach, which is based on +Mach 4.0. In addition to the features contained in Mach 4.0, the GNU +version contains many of the Linux 2.0 block device and network card +drivers. +

+A complete treatment of the differences between a microkernel and +monolithical kernel design can not be provided here. But a couple of +advantages of a microkernel design are fairly obvious. + +

Micro vs Monolithic

+
+

+Microkernel +

    +
  • Clear cut responsibilities +
  • Flexibility in operating system design, easier debugging
  • +
  • More stability (less code to break)
  • +
  • New features are not added to the kernel
  • +
+

+Monolithic kernel +

    +
  • Intolerance or creeping featuritis
  • +
  • Danger of spaghetti code
  • +
  • Small changes can have far reaching side effects
  • +
+
+

+Because the system is split up into several components, clean +interfaces have to be developed, and the responsibilities of each part +of the system must be clear. +

+Once a microkernel is written, it can be used as the base for several +different operating systems. Those can even run in parallel which +makes debugging easier. When porting, most of the hardware dependant +code is in the kernel. +

+Much of the code that doesn't need to run in the special kernel mode +of the processor is not part of the kernel, so stability increases +because there is simply less code to break. +

+New features are not added to the kernel, so there is no need to hold +the barrier high for new operating system features. +

+Compare this to a monolithical kernel, where you either suffer from +creeping featuritis or you are intolerant of new features (we see both +in the Linux kernel). +

+Because in a monolithical kernel, all parts of the kernel can access +all data structures in other parts, it is more likely that short cuts +are used to avoid the overhead of a clean interface. This leads to a +simple speed up of the kernel, but also makes it less comprehensible +and more error prone. A small change in one part of the kernel can +break remote other parts. + +

Single Server vs Multi Server

+
+

+Single Server +

    +
  • A single task implements the functionality of the operating system.
  • +
+

+Multi Server +

    +
  • Many tasks cooperate to provide the system's functionality.
  • +
  • One server provides only a small but well-defined part of the + whole system.
  • +
  • The responsibilities are distributed logically among the servers.
  • +
+

+A single-server system is comparable to a monolithic kernel system. It +has similar +advantages and disadvantages. +

+

+There exist a couple of operating systems based on Mach, but they all +have the same disadvantages as a monolithical kernel, because those +operating systems are implemented in one single process running on top +of the kernel. This process provides all the services a monolithical +kernel would provide. This doesn't make a whole lot of sense (the +only advantage is that you can probably run several of such isolated +single servers on the same machine). Those systems are also called +single-server systems. The Hurd is the only usable multi-server +system on top of Mach. In the Hurd, there are many server programs, +each one responsible for a unique service provided by the operating +system. These servers run as Mach tasks, and communicate using the +Mach message passing facilities. One of them does only provide a +small part of the functionality of the system, but together they build +up a complete and functional POSIX compatible operating system. + +

Multi Server is superior, ...

+
+

+Any multi-server has advantages over single-server: +

    +
  • Clear cut responsibilities
  • +
  • More stability: If one server dies, all others remain
  • +
  • Easier development cycle: Testing without reboot (or replacing + running servers), debugging with gdb
  • +
  • Easier to make changes and add new features +
+
+

+Using several servers has many advantages, if done right. If a file +system server for a mounted partition crashes, it doesn't take down +the whole system. Instead the partition is "unmounted", and +you can try to start the server again, probably debugging it this time +with gdb. The system is less prone to errors in individual +components, and over-all stability increases. The functionality of +the system can be extended by writing and starting new servers +dynamically. (Developing these new servers is easier for the reasons +just mentioned.) +

+But even in a multi-server system the barrier between the system and +the users remains, and special privileges are needed to cross it. We +have not achieved user freedom yet. + +

The Hurd even more so.

+
+

+The Hurd goes beyond all this, and allows users to write and run their +servers, too! +

    +
  • Users can replace system servers dynamically with their own + implementations.
  • +
  • Users can decide what parts of the remainder of the system they + want to use.
  • +
  • Users can extend the functionality of the system.
  • +
  • No mutual trust necessary to make use of other users + services.
  • +
  • Security of the system is not harmed by trusting users + services.
  • +
+
+

+To quote Thomas Bushnell, BSG, from his paper +[[``Towards_a_New_Strategy_of_OS_design''_(1996)|hurd-paper]]: +

+The GNU Hurd, by contrast, is designed to make the area of system code +as limited as possible. Programs are required to communicate only +with a few essential parts of the kernel; the rest of the system is +replaceable dynamically. Users can use whatever parts of the +remainder of the system they want, and can easily add components +themselves for other users to take advantage of. No mutual trust need +exist in advance for users to use each other's services, nor does the +system become vulnerable by trusting the services of arbitrary users. +
+ +

+So the Hurd is a set of servers running on top of the Mach +micro-kernel, providing a POSIX compatible and extensible operating +system. What servers are there? What functionality do they provide, +and how do they cooperate? + +

Mach Inter Process Communication

+
+

+Ports are message queues which can be used as one-way communication +channels. +

    +
  • Port rights are receive, send or send-once
  • +
  • Exactly one receiver
  • +
  • Potentially many senders
  • +
+

+MIG provides remote procedure calls on top of Mach IPC. RPCs look like +function calls to the user. +

+

+Inter-process communication in Mach is based on the ports concept. A +port is a message queue, used as a one-way communication channel. In +addition to a port, you need a port right, which can be a send right, +receive right, or send-once right. Depending on the port right, you +are allowed to send messages to the server, receive messages from it, +or send just one single message. +

+For every port, there exists exactly one task holding the receive +right, but there can be no or many senders. The send-once right is +useful for clients expecting a response message. They can give a +send-once right to the reply port along with the message. The kernel +guarantees that at some point, a message will be received on the reply +port (this can be a notification that the server destroyed the +send-once right). +

+You don't need to know much about the format a message takes to be +able to use the Mach IPC. The Mach interface generator mig hides the +details of composing and sending a message, as well as receiving the +reply message. To the user, it just looks like a function call, but +in truth the message could be sent over a network to a server running +on a different computer. The set of remote procedure calls a server +provides is the public interface of this server. + + +

How to get a port?

+
+

+Traditional Mach: +

    +
  • Nameserver provides ports to all registered servers.
  • +
  • The nameserver port itself is provided by Mach.
  • +
  • Like a phone book: One list.
  • +
+

+The Hurd: +

    +
  • The filesystem is used as the server namespace.
  • +
  • Root directory port is inserted into each task.
  • +
  • The C library finds other ports with hurd_file_name_lookup, + performing a pathname resolution.
  • +
  • Like a tree of phone books.
  • +
+
+

+So how does one get a port to a server? You need something like a +phone book for server ports, or otherwise you can only talk to +yourself. In the original Mach system, a special nameserver is +dedicated to that job. A task could get a port to the nameserver from +the Mach kernel and ask it for a port (with send right) to a server +that registered itself with the nameserver at some earlier time. +

+In the Hurd, there is no nameserver. Instead, the filesystem is used +as the server namespace. This works because there is always a root +filesystem in the Hurd (remember that the Hurd is a POSIX compatible +system); this is an assumption the people who developed Mach couldn't +make, so they had to choose a different strategy. You can use the +function hurd_file_name_lookup, which is part of the C library, to get +a port to the server belonging to a filename. Then you can start to +send messages to the server in the usual way. + +

Example of hurd_file_name_lookup

+
+mach_port_t identity;
+mach_port_t pwserver;
+kern_return_t err;
+
+pwserver = hurd_file_name_lookup
+                ("/servers/password");
+
+err = password_check_user (pwserver,
+                           0 /* root */, "supass",
+                           &identity);
+
+

+As a concrete example, the special filename +/servers/password can be used to request a port to the +Hurd password server, which is responsible to check user provided +passwords. +

+(explanation of the example) + +

Pathname resolution example

+
+

+Task: Lookup /mnt/readme.txt where /mnt has a mounted filesystem. +

    +
  • The C library asks the root filesystem server about + /mnt/readme.txt.
  • +
  • The root filesystem returns a port to the mnt filesystem server + (matching /mnt) and the retry name + /readme.txt.
  • +
  • The C library asks the mnt filesystem server about + /readme.txt.
  • +
  • The mnt filesystem server returns a port to itself and records + that this port refers to the regular file + /readme.txt.
  • +
+
+

+The C library itself does not have a full list of all available +servers. Instead pathname resolution is used to traverse through a +tree of servers. In fact, filesystems themselves are implemented by +servers (let us ignore the chicken and egg problem here). So all the +C library can do is to ask the root filesystem server about the +filename provided by the user (assuming that the user wants to resolve +an absolute path), using the dir_lookup RPC. If the +filename refers to a regular file or directory on the filesystem, the +root filesystem server just returns a port to itself and records that +this port corresponds to the file or directory in question. But if a +prefix of the full path matches the path of a server the root +filesystem knows about, it returns to the C library a port to this +server and the remaining part of the pathname that couldn't be +resolved. The C library than has to retry and query the other server +about the remaining path component. Eventually, the C library will +either know that the remaining path can't be resolved by the last +server in the list, or get a valid port to the server in question. + +

Mapping the POSIX Interface

+
+ + + + + + + + + + + + + + + + + + + +
FiledescriptorPort to server providing the file
fd = open(name,...)dir_lookup(..,name,..,&port)
+[pathname resolution]
read(fd, ...)io_read(port, ...)
write(fd, ...)io_write(port, ...)
fstat(fd, ...)io_stat(port, ...)
...
+
+

+It should by now be obvious that the port returned by the server can +be used to query the files status, content and other information from +the server, if good remote procedure calls to do that are defined and +implemented by it. This is exactly what happens. Whenever a file is +opened using the C libraries open() call, the C library +uses the above pathname resolution to get a port to a server providing +the file. Then it wraps a file descriptor around it. So in the Hurd, +for every open file descriptor there is a port to a server providing +this file. Many other C library calls like read() and +write() just call a corresponding RPC using the port +associated with the file descriptor. + +

File System Servers

+
+
    +
  • Provide file and directory services for ports (and more).
  • +
  • These ports are returned by a directory lookup.
  • +
  • Translate filesystem accesses through their root path (hence the + name translator).
  • +
  • The C library maps the POSIX file and directory interface (and + more) to RPCs to the filesystem servers ports, but also does work on + its own.
  • +
  • Any user can install file system servers on inodes they own.
  • +
+
+

+So we don't have a single phone book listing all servers, but rather a +tree of servers keeping track of each other. That's really like +calling your friend and asking for the phone number of the blond girl +at the party yesterday. He might refer you to a friend who hopefully +knows more about it. Then you have to retry. +

+This mechanism has huge advantages over a single nameserver. First, +note that standard unix permissions on directories can be used to +restrict access to a server (this requires that the filesystems +providing those directories behave). You just have to set the +permissions of a parent directory accordingly and provide no other way +to get a server port. +

+But there are much deeper implications. Most of all, a pathname never +directly refers to a file, it refers to a port of a server. That +means that providing a regular file with static data is just one of +the many options the server has to service requests on the file port. +A server can also create the data dynamically. For example, a server +associated with /dev/random can provide new random data +on every io_read() on the port to it. A server +associated with /dev/fortune can provide a new fortune +cookie on every open(). +

+While a regular filesystem server will just serve the data as stored +in a filesystem on disk, there are servers providing purely virtual +information, or a mixture of both. It is up to the server to behave +and provide consistent and useful data on each remote procedure call. +If it does not, the results may not match the expectations of the user +and confuse him. +

+A footnote from the Hurd info manual: +

+(1) You are lost in a maze of twisty little filesystems, all +alike.... +
+

+Because a server installed in the filesystem namespace translates all +filesystem operations that go through its root path, such a server is +also called "active translator". You can install translators using +the settrans command with the -a option. + +

Active vs Passive

+
+

+Active Translators: +

    +
  • "settrans -a /cdrom /hurd/isofs /dev/hd2"
  • +
  • Are running filesystem servers.
  • +
  • Are attached to the root node they translate.
  • +
  • Run as a normal process.
  • +
  • Go away with every reboot, or even time out.
  • +
+
+

+Many translator settings remain constant for a long time. It would be +very lame to always repeat the same couple of dozens settrans calls +manually or at boot time. So the Hurd provides a filesystem extension +that allows to store translator settings inside the filesystem and let +the filesystem servers do the work to start those servers on demand. +Such translator settings are called "passive translators". A passive +translator is really just a command line string stored in an inode of +the filesystem. If during a pathname resolution a server encounters +such a passive translator, and no active translator does exist already +(for this node), it will use this string to start up a new translator +for this inode, and then let the C library continue with the path +resolution as described above. Passive translators are installed with +settrans using the -p option (which is already the +default). + +
+

+Passive Translators: +

    +
  • "settrans /mnt /hurd/ext2fs /dev/hd1s1"
  • +
  • Are stored as command strings into an inode.
  • +
  • Are used to start a new active translator if there isn't + one.
  • +
  • Startup is transparent to the user.
  • +
  • Startup happens the first time the server is needed.
  • +
  • Are permanent across reboots (like file data).
  • +
+
+

+So passive translators also serve as a sort of automounting feature, +because no manual interaction is required. The server start up is +deferred until the service is need, and it is transparent to the user. +

+When starting up a passive translator, it will run as a normal process +with the same user and group id as those of the underlying inode. Any +user is allowed to install passive and active translators on inodes +that he owns. This way the user can install new servers into the +global namespace (for example, in his home or tmp directory) and thus +extend the functionality of the system (recall that servers can +implement other remote procedure calls beside those used for files and +directories). A careful design of the trusted system servers makes +sure that no permissions leak out. +

+In addition, users can provide their own implementations of some of +the system servers instead the system default. For example, they can +use their own exec server to start processes. The user specific exec +server could for example start java programs transparently (without +invoking the interpreter manually). This is done by setting the +environment variable EXECSERVERS. The systems default +exec server will evaluate this environment variable and forward the +RPC to each of the servers listed in turn, until some server accepts +it and takes over. The system default exec server will only do this +if there are no security implications. (XXX There are other ways to +start new programs than by using the system exec server. Those are +still available.) +

+Let's take a closer look at some of the Hurd servers. It was already +mentioned that only few system servers are mandatory for users. To +establish your identity within the Hurd system, you have to +communicate with the trusted systems authentication server +auth. To put the system administrator into control over +the system components, the process server does some global +bookkeeping. +

+But even these servers can be ignored. However, registration with the +authentication server is the only way to establish your identity +towards other system servers. Likewise, only tasks registered as +processes with the process server can make use of its services. + +

Authentication

+
+

+A user identity is just a port to an authserver. The auth server +stores four set of ids for it: +

    +
  • effective user ids
  • +
  • effective group ids
  • +
  • available user ids
  • +
  • available group ids
  • +
+

+Basic properties: +

    +
  • Any of these can be empty.
  • +
  • A 0 among the user ids identifies the superuser.
  • +
  • Effective ids are used to check if the user has the + permission.
  • +
  • Available ids can be turned into effective ids on user + request.
  • +
+
+

+The Hurd auth server is used to establish the identity of a user for a +server. Such an identity (which is just a port to the auth server) +consists of a set of effective user ids, a set of effective group ids, +a set of available user ids and a set of available group ids. Any of +these sets can be empty. + +

Operations on authentication ports

+
+

+The auth server provides the following operations on ports: +

    +
  • Merge the ids of two ports into a new one.
  • +
  • Return a new port containing a subset of the ids in a port.
  • +
  • Create a new port with arbitrary ids (superuser only).
  • +
  • Establish a trusted connection between users and servers.
  • +
+
+

+If you have two identities, you can merge them and request an identity +consisting of the unions of the sets from the auth server. You can +also create a new identity consisting only of subsets of an identity +you already have. What you can't do is extending your sets, unless +you are the superuser which is denoted by having the user id 0. + +

Establishing trusted connections

+
+
    +
  • User provides a rendezvous port to the server (with + io_reauthenticate).
  • +
  • User calls auth_user_authenticate on the + authentication port (his identity), passing the rendezvous port.
  • +
  • Server calls auth_server_authenticate on its + authentication port (to a trusted auth server), passing the + rendezvous port and the server port.
  • +
  • If both authentication servers are the same, it can match the + rendezvous ports and return the server port to the user and the user + ids to the server.
  • +
+
+

+Finally, the auth server can establish the identity of a user for a +server. This is done by exchanging a server port and a user identity +if both match the same rendezvous port. The server port will be +returned to the user, while the server is informed about the id sets +of the user. The server can then serve or reject subsequent RPCs by +the user on the server port, based on the identity it received from +the auth server. +

+Anyone can write a server conforming to the auth protocol, but of +course all system servers use a trusted system auth server to +establish the identity of a user. If the user is not using the system +auth server, matching the rendezvous port will fail and no server port +will be returned to the user. Because this practically requires all +programs to use the same auth server, the system auth server is +minimal in every respect, and additional functionality is moved +elsewhere, so user freedom is not unnecessarily restricted. + +

Password Server

+
+

+The password server /servers/password runs as root and +returns a new authentication port in exchange for a unix password. +

+The ids corresponding to the authentication port match the unix user +and group ids. +

+Support for shadow passwords is implemented here. +

+

+The password server sits at /servers/password and runs as +root. It can hand out ports to the auth server in exchange for a unix +password, matching it against the password or shadow file. Several +utilities make use of this server, so they don't need to be setuid +root. + +

Process Server

+
+

+The superuser must remain control over user tasks, so: +

    +
  • All mach tasks are associated with a PID in the system default + proc server.
  • +
+

+Optionally, user tasks can store: +

    +
  • Their environment variables.
  • +
  • Their argument vector.
  • +
  • A port, which others can request based on the PID (like a + nameserver).
  • +
+

+Also implemented in the proc server: +

    +
  • Sessions and process groups.
  • +
  • Global configuration not in Mach, like hostname, hostid, system + version.
  • +
+
+

+The process server is responsible for some global bookkeeping. As +such it has to be trusted and is not replaceable by the user. +However, a user is not required to use any of its service. In that +case the user will not be able to take advantage of the POSIXish +appearance of the Hurd. +

+The Mach Tasks are not as heavy as POSIX processes. For example, +there is no concept of process groups or sessions in Mach. The proc +server fills in the gap. It provides a PID for all Mach tasks, and +also stores the argument line, environment variables and other +information about a process (if the mach tasks provide them, which is +usually the case if you start a process with the default +fork()/exec()). A process can also register +a message port with the proc server, which can then be requested by +anyone. So the proc server also functions as a nameserver using the +process id as the name. +

+The proc server also stores some other miscellaneous information not +provided by Mach, like the hostname, hostid and system version. +Finally, it provides facilities to group processes and their ports +together, as well as to convert between pids, process server ports and +mach task ports. +
+

+User tasks not registering themselve with proc only have a PID assigned. +

+Users can run their own proc server in addition to the system default, +at least for those parts of the interface that don't require superuser +privileges. +

+

+Although the system default proc server can't be avoided (all Mach +tasks spawned by users will get a pid assigned, so the system +administrator can control them), users can run their own additional +process servers if they want, implementing the features not requiring +superuser privileges. + +

Filesystems

+
+

+Store based filesystems +

    +
  • ext2fs
  • +
  • ufs
  • +
  • isofs (iso9660, RockRidge, GNU extensions)
  • +
  • fatfs (under development)
  • +
+

+Network file systems +

    +
  • nfs
  • +
  • ftpfs
  • +
+

+Miscellaneous +

    +
  • hostmux
  • +
  • usermux
  • +
  • tmpfs (under development)
  • +
+
+

+We already talked about translators and the file system service they +provide. Currently, we have translators for the ext2, ufs and iso9660 +filesystems. We also have an nfs client and an ftp filesystem. +Especially the latter is intriguing, as it provides transparent access +to ftp servers in the filesystem. Programs can start to move away +from implementing a plethora of network protocols, as the files are +directly available in the filesystem through the standard POSIX file +interface. + + +

Developing the Hurd

+
+

+Over a dozen libraries support the development of new servers. +

+For special server types highly specialized +libraries require only the implementation of a +number of callback functions. +

    +
  • Use libdiskfs for store based filesystems.
  • +
  • Use libnetfs for network filesystems, also for + virtual filesystems.
  • +
  • Use libtrivfs for simple filesystems providing only + a single file or directory.
  • +
+
+

+The Hurd server protocols are complex enough to allow for the +implementation of a POSIX compatible system with GNU extensions. +However, a lot of code can be shared by all or at least similar +servers. For example, all storage based filesystems need to be able to +read and write to a store medium splitted in blocks. The Hurd comes +with several libraries which make it easy to implement new servers. +Also, there are already a lot of examples of different server types in +the Hurd. This makes writing a new server easier. +

+libdiskfs is a library that supports writing store based +filesystems like ext2fs or ufs. It is not very useful for filesystems +which are purely virtual, like /proc or files in +/dev. +

+libnetfs is intended for filesystems which provide a rich +directory hierarchy, but don't use a backing store (for example ftpfs, +nfs). +

+libtrivfs is intended for filesystems which just provide +a single inode or directory. Most servers which are not intended to +provide a filesystem but other services (like +/servers/password) use it to provide a dummy file, so +that file operations on the servers node will not return errors. But +it can also be used to provide meaningful data in a single file, like +a device store or a character device. + +

Store Abstraction

+
+

+Another very useful library is libstore, which is used by all store +based filesystems. It provides a store media abstraction. A store +consists of a store class and a name (which itself can sometimes +contain stores). +

+Primitive store classes: +

    +
  • device store like device:hd2, device:hd0s1, device:fd0
  • +
  • file store like file:/tmp/disk_image
  • +
  • task store like task:PID
  • +
  • zero store like zero:4m (like /dev/zero, of size 4 MB)
  • +
+
+
+

+Composed store classes: +

    +
  • copy store like copy:zero:4m
  • +
  • gunzip/bunzip2 store like gunzip:device:fd0
  • +
  • concat store like concat:device:hd0s2:device:hd1s5
  • +
  • ileave store (RAID-0(2))
  • +
  • remap store like remap:10+20,50+:file:/tmp/blocks
  • +
  • ...
  • +
+

+Wanted: A similar abstraction for streams (based on channels), which +can be used by network and character device servers. +

+

+libstore provides a store abstraction, which is used by +all store based filesystems. The store is determined by a type and a +name, but some store types modify another store rather than providing +a new store, and thus stores can be stacked. For example, the device +store type expects a Mach device, but the remap store expects a list +of blocks to pick from another store, like remap:1+:device:hd2, which +would pick all blocks from hd2 but the first one, which skipped. +Because this functionality is provided in a library, all libstore +using filesystems support many different store kinds, and adding a new +store type is enough to make all store based filesystems support it. + +

Debian GNU/Hurd

+
+

+Goal: +

    +
  • Provide a binary distribution of the Hurd that is easy to + install.
  • +
+

+Constraints: +

    +
  • Use the same source packages as Debian GNU/Linux.
  • +
  • Use the same infrastructure: +
      +
    • Policy
    • +
    • Archive
    • +
    • Bug tracking system
    • +
    • Release process
    • +
  • +
+

+Side Goal: +

    +
  • Prepare Debian for the future: +
      +
    • More flexibility in the base system
    • +
    • Identify dependencies on the Linux kernel
    • +
  • +
+
+

+The Debian distribution of the GNU Hurd that I started in 1998 is +supposed to become a complete binary distribution of the Hurd that is +easy to install. + +

Status of the Debian GNU/Hurd binary archive

+

+See +http://buildd.debian.org/stats/graph.png +for the most current version of the statistic. + +

Status of the Debian infrastructure

+
+

+Plus: +

    +
  • Source packages can identify build and host OS using + dpkg-architecture.
  • +
+

+Minus: +

    +
  • The binary architecture field is insufficient.
  • +
  • The BTS has no architecture tag.
  • +
  • The policy/FHS need (small) Hurd specific extensions.
  • +
+
+

+While good compatibiity can be achieved at the source level, +the binary packages can not always express their relationship +to the available architectures sufficiently. +

+For example, the Linux version of makedev is binary-all, where +a binary-all-linux relationship would be more appropriate. +

+More work has to be done here to fix the tools. + +

Status of the Debian Source archive

+
+
    +
  • Most packages just work.
  • +
  • Maintainers are usually responsive and cooperative.
  • +
  • Turtle, the autobuilder, crunches through the whole list right + now.
  • +
+

+Common pitfalls are POSIX incompatibilities: +

    +
  • Upstream: +
      +
    • Unconditional use of PATH_MAX + (MAXPATHLEN), MAXHOSTNAMELEN.
    • +
    • Unguarded use of Linux kernel features.
    • +
    • Use of legacy interfaces (sys_errlist, + termio).
    • +
  • +
  • Debian: +
      +
    • Unguarded activation of extensions available with Linux.
    • +
    • Low quality patches.
    • +
    • Assuming GNU/Linux in package scripts.
    • +
  • +
+
+

+Most packages are POSIX compatible and can be compiled without +changes on the Hurd. The maintainers of the Debian source packages +are usually very kind, responsiver and helpful. +

+The Turtle autobuilder software (http://turtle.sourceforge.net) +builds the Debian packages on the Hurd automatically. + +

Debian GNU/Hurd: Good idea, bad idea?

+
+

+Upstream benefits: +

    +
  • Software packages become more portable.
  • +
+

+Debian benefits: +

    +
  • Debian becomes more portable.
  • +
  • Maintainers learn about portability and other systems.
  • +
  • Debian gets a lot of public recognition.
  • +
+

+GNU/Hurd benefits: +

    +
  • Large software base.
  • +
  • Great infrastructure.
  • +
  • Nice community to partner with.
  • +
+
+

+The sheet lists the advantages of all groups involved. + +

End

+
+

+Join us at +

+
+

+List of contacts. diff --git a/hurd.mdwn b/hurd.mdwn index 6c56b619..67ad46e9 100644 --- a/hurd.mdwn +++ b/hurd.mdwn @@ -48,7 +48,7 @@ in the *unstable* branch of the Debian archive. * [[Documentation]] * [Gaël Le Mignot](http://kilobug.free.fr/hurd/pres-en/slides/slides.html) * Architecture - * [[Towards_a_New_Strategy_of_OS_Design|documentation/hurd-paper]] by Thomas Bushnell, BSG. + * [[Towards_a_New_Strategy_of_OS_Design|hurd-paper]] by Thomas Bushnell, BSG. * Marcus Brinkmann's [revisit](http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00651.html) * Jonathan S. Shapiro [comments](http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00654.html) * [[Critique]] - Analysis diff --git a/hurd/documentation.mdwn b/hurd/documentation.mdwn index 0d311758..589246bd 100644 --- a/hurd/documentation.mdwn +++ b/hurd/documentation.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 -Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, +2009 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 @@ -17,12 +17,12 @@ is included in the section entitled * [[FAQ]] - * [[*The_Hurd_and_Linux*|hurd-and-linux]], a comment by Richard Stallman. + * [[*The_Hurd_and_Linux*|/hurd-and-linux]], a comment by Richard Stallman. - * [[*Towards_a_New_Strategy_of_OS_Design*|hurd-paper]], an architectural + * [[*Towards_a_New_Strategy_of_OS_Design*|/hurd-paper]], an architectural overview by Thomas Bushnell, BSG. - * [[*The_Hurd*|hurd-talk]], a presentation by Marcus Brinkmann. + * [[*The_Hurd*|/hurd-talk]], a presentation by Marcus Brinkmann. * A document about *[[translators]]* by Marcus Brinkmann. diff --git a/hurd/documentation/hurd-and-linux.html b/hurd/documentation/hurd-and-linux.html deleted file mode 100644 index 1fc75f75..00000000 --- a/hurd/documentation/hurd-and-linux.html +++ /dev/null @@ -1,47 +0,0 @@ -[[!meta copyright="Copyright © 1996, 1997, 1998, 2008 Free Software Foundation, -Inc."]] - -[[!meta license="Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved."]] - -[[!meta title="The Hurd and Linux"]] - -by Richard Stallman. - -

-People sometimes ask, ``Why did the FSF develop a new free kernel -instead of using Linux?'' It's a reasonable question. The answer, -briefly, is that that is not the question we faced. - -

-When we started developing the Hurd in 1990, the question facing us -was, ``How can we get a free kernel for the GNU system?'' There was -no free Unix-like kernel then, and we knew of no other plan to write -one. The only way we could expect to have a free kernel was to write -it ourselves. So we started. - -

-We heard about Linux after its release. At that time, the question -facing us was, ``Should we cancel the Hurd project and use Linux -instead?'' - -

-We heard that Linux was not at all portable (this may not be true -today, but that's what we heard then). And we heard that Linux was -architecturally on a par with the Unix kernel; our work was leading to -something much more powerful. - -

-Given the years of work we had already put into the Hurd, we decided -to finish it rather than throw them away. - -

-If we did face the question that people ask---if Linux were already -available, and we were considering whether to start writing another -kernel---we would not do it. Instead we would choose another project, -something to do a job that no existing free software can do. - -

-But we did start the Hurd, back then, and now we have made it work. -We hope its superior architecture will make free operating systems -more powerful. diff --git a/hurd/documentation/hurd-and-linux.mdwn b/hurd/documentation/hurd-and-linux.mdwn new file mode 100644 index 00000000..678ea8da --- /dev/null +++ b/hurd/documentation/hurd-and-linux.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=/hurd-and-linux]] diff --git a/hurd/documentation/hurd-paper.html b/hurd/documentation/hurd-paper.html deleted file mode 100644 index 86375d46..00000000 --- a/hurd/documentation/hurd-paper.html +++ /dev/null @@ -1,760 +0,0 @@ -[[!meta copyright="Copyright © 1996, 1997, 1998, 2007, 2008 Free Software -Foundation, Inc."]] - -[[!meta license="Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved."]] - -[[!meta title="Towards a New Strategy of OS Design, an architectural overview -by Thomas Bushnell, BSG."]] - - -This article explains why FSF is developing a new operating system named the -Hurd, which will be a foundation of the whole GNU system. -The Hurd is built -on top of CMU's Mach 3.0 kernel and uses Mach's virtual memory management and -message-passing facilities. -The GNU C Library will provide the Unix system -call interface, and will call the Hurd for needed services it can't provide -itself. -The design and implementation of the Hurd is being lead by Michael -Bushnell, with assistance from Richard Stallman, Roland McGrath, -Jan Brittenson, and others. - -

Part 1: A More Usable Approach to OS Design

-

-The fundamental purpose of an operating system (OS) is to enable a variety of -programs to share a single computer efficiently and productively. -This -demands memory protection, preemptively scheduled timesharing, coordinated -access to I/O peripherals, and other services. -In addition, an OS can allow -several users to share a computer. -In this case, efficiency demands services -that protect users from harming each other, enable them to share without -prior arrangement, and mediate access to physical devices. -

-On today's computer systems, programmers usually implement these goals -through a large program called the kernel. -Since this program must be -accessible to all user programs, it is the natural place to add functionality -to the system. -Since the only model for process interaction is that of -specific, individual services provided by the kernel, no one creates other -places to add functionality. -As time goes by, more and more is added to the -kernel. -

-A traditional system allows users to add components to a kernel only if they -both understand most of it and have a privileged status within the system. -Testing new components requires a much more painful edit-compile-debug cycle -than testing other programs. -It cannot be done while others are using the -system. -Bugs usually cause fatal system crashes, further disrupting others' -use of the system. -The entire kernel is usually non-pageable. -(There are -systems with pageable kernels, but deciding what can be paged is difficult -and error prone. -Usually the mechanisms are complex, making them difficult -to use even when adding simple extensions.) -

-Because of these restrictions, functionality which properly belongs -behind -the wall of a traditional kernel is usually left out of systems unless it is -absolutely mandatory. -Many good ideas, best done with an open/read/write -interface cannot be implemented because of the problems inherent in the -monolithic nature of a traditional system. -Further, even among those with -the endurance to implement new ideas, only those who are privileged users of -their computers can do so. -The software copyright system darkens the mire by -preventing unlicensed people from even reading the kernel source. -

-Some systems have tried to address these difficulties. -Smalltalk-80 and -the Lisp Machine both represented one method of getting around the problem. -System code is not distinguished from user code; all of the system is -accessible to the user and can be changed as need be. -Both systems were -built around languages that facilitated such easy replacement and extension, -and were moderately successful. -But they both were fairly poor at insulating -users and programs from each other, failing one of the principal goals of OS -design. -

-Most projects that use the Mach 3.0 kernel carry on the hard-to-change -tradition of OS design. -The internal structure is different, but the same -heavy barrier between user and system remains. -The single-servers, while -fairly easy to construct, inherit all the deficiencies of the monolithic -kernels. -

-A multi-server divides the kernel functionality up into logical blocks with -well-defined interfaces. -Properly done, it is easier to make changes and add -functionality. -So most multi-server projects do somewhat better. -Much more -of the system is pageable. -You can debug the system more easily. -You can -test new system components without interfering with other users. -But the -wall between user and system remains; no user can cross it without special -privilege. -

-The GNU Hurd, by contrast, is designed to make the area of -system -code as -limited as possible. -Programs are required to communicate only with a few -essential parts of the kernel; the rest of the system is replaceable -dynamically. -Users can use whatever parts of the remainder of the system -they want, and can easily add components themselves for other users to take -advantage of. -No mutual trust need exist in advance for users to use each -other's services, nor does the system become vulnerable by trusting the -services of arbitrary users. -

-This has been done by identifying those system components which users -must -use in order to communicate with each other. -One of these is responsible for -identifying users' identities and is called the - -authentication server. - -In -order to establish each other's identities, programs must communicate, each -with an authentication server they trust. -Another component establishes -control over system components by the superuser, provides global bookkeeping -operations, and is called the - -process server. - -

-Not all user programs need to communicate with the process server; it is only -necessary for programs which require its services. -Likewise, the -authentication server is only necessary for programs that wish to communicate -their identity to another. -None of the remaining services carry any special -status; not the network implementation, the filesystems, the program -execution mechanism (including setuid), or any others. - -

The Translator Mechanism

-

-The Hurd uses Mach ports primarily as methods for communicating between users -and servers. -(A Mach port is a communication point on a Mach task where -messages are sent and received.) Each port implements a particular set of -protocols, representing operations that can be undertaken on the underlying -object represented by the port. -Some of the protocols specified by the Hurd -are the I/O protocol, used for generic I/O operations; the file protocol, -used for filesystem operations; the socket protocol, used for network -operations; and the process protocol, used for manipulating processes et al. -

-Most servers are accessed by opening files. -Normally, when you open a file, -you create a port associated with that file that is owned by the server -that owns the directory containing the file. -For example, a disk-based -filesystem will normally serve a large number of ports, each of which -represents an open file or directory. -When a file is opened, the server -creates a new port, associates it with the file, and returns the port to the -calling program. -

-However, a file can have a -translator -associated with it. -In this case, -rather than return its own port which refers to the contents of the file, the -server executes a translator program associated with that file. -This -translator is given a port to the actual contents of the file, and is then -asked to return a port to the original user to complete the open operation. -

-This mechanism is used for -mount -by having a translator associated with -each mount point. -When a program opens the mount point, the translator (in -this case, a program which understands the disk format of the mounted -filesystem) is executed and returns a port to the program. -After the -translator is started, it need not be run again unless it dies; the parent -filesystem retains a port to the translator to use in further requests. -

-The owner of a file can associate a translator with it without special -permission. -This means that any program can be specified as a translator. -Obviously the system will not work properly if the translator does not -implement the file protocol correctly. -However, the Hurd is constructed so -that the worst possible consequence is an interruptible hang. -

-One way to use translators is to access hierarchically structured data using -the file protocol. -For example, all the complexity of the user interface to -the -ftp -program is removed. -Users need only know that a particular -directory represents FTP and can use all the standard file manipulation -commands (e.g -ls -or -cp) -to access the remote system, rather than learning -a new set. -Similarly, a simple translator could ease the complexity of -tar -or -gzip. -(Such transparent access would have some added cost, but it would -be convenient.) - -

Generic Services

-

-With translators, the filesystem can act as a rendezvous for interfaces which -are not similar to files. -Consider a service which implements some version -of the X protocol, using Mach messages as an underlying transport. -For each -X display, a file can be created with the appropriate program as its -translator. -X clients would open that file. -At that point, few file -operations would be useful (read and write, for example, would be useless), -but new operations ( -XCreateWindow -or -XDrawText) -might become meaningful. -In this case, the filesystem protocol is used only to manipulate -characteristics of the node used for the rendezvous. -The node need not -support I/O operations, though it should reply to any such messages with a -message_not_understood -return code. -

-This translator technique is used to contact most of the services in the Hurd -that are not structured like hierarchical filesystems. -For example, the -password server, which hands out authorization tags in exchange for -passwords, is contacted this way. -Network protocol servers are also -contacted in this fashion. -Roland McGrath thought up this use of translators. - -

Clever Filesystem Pictures

-

-In the Hurd, translators can also be used to present a filesystem-like view -of another part of the filesystem, with some semantics changed. -For example, -it would be nice to have a filesystem that cannot itself be changed, but -nonetheless records changed versions of its files elsewhere. -(This could be -useful for source code management.) -

-The Hurd will have a translator which creates a directory which is a -conceptual union of other directories, with collision resolution rules of -various sorts. -This can be used to present a single directory to users that -contains all the programs they would want to execute. -There are other useful -variations on this theme. - -

What The User Can Do

-

-No translator gains extra privilege by virtue of being hooked into the -filesystem. -Translators run with the uid of the owner of the file being -translated, and can only be set or changed by that owner. -The I/O and -filesystem protocols are carefully designed to allow their use by mutually -untrusting clients and servers. -Indeed, translators are just ordinary -programs. -The GNU C library has a variety of facilities to make common sorts -of translators easier to write. -

-Some translators may need special privileges, such as the password server or -translators which allow setuid execution. -These translators could be run by -anyone, but only if they are set on a root-owned node would they be able to -provide all their services successfully. -This is analogous to letting any -user call the -reboot -system call, but only honoring it if that user is root. - -

Why This Is So Different

-

-What this design provides is completely novel to the Unix world. -Until now, -OSs have kept huge portions of their functionality in the realm of system -code, thus preventing its modification and extension except in extreme need. -Users cannot replace parts of the system in their programs no matter how much -easier that would make their task, and system managers are loath to install -random tweaks off the net into their kernels. -

-In the Hurd, users can change almost all of the things that are decided for -them in advance by traditional systems. -In combination with the tremendous -control given by the Mach kernel over task address spaces and properties, the -Hurd provides a system in which users will, for the first time, be able to -replace parts of the system they dislike, without disrupting other users. -

-Most Mach-based OSs to date have mostly implemented a wider set of the - -same old - -Unix semantics in a new environment. -In contrast, GNU is extending -those semantics to allow users to improve, bypass, or replace them. - - -

Part 2: A Look at Some of the Hurd's Beasts

-

The Authentication Server

-

-One of the Hurd's more central servers is the authentication server. -Each -port to this server identifies a user and is associated by this server with -an -id block. -Each id block contains sets of user and group ids. -Either -set may be empty. -This server is not the same as the password server -referred to above. -

-The authentication server exports three services. -First, it provides simple -boolean operations on authentication ports: given two authentication ports, -this server will provide a third port representing the union of the two sets -of uids and gids. -Second, this server allows any user with a uid of zero to -create an arbitrary authentication port. -Finally, this server provides RPCs -(Remote Procedure Calls between different programs and possibly different -hosts) which allow mutually untrusting clients and servers to establish their -identities and pass initial information on each other. -This is crucial to -the security of the filesystem and I/O protocols. -

-Any user could write a program which implements the authentication protocol; -this does not violate the system's security. -When a service needs to -authenticate a user, it communicates with its trusted authentication server. -If that user is using a different authentication server, the transaction will -fail and the server can refuse to communicate further. -Because, in effect, -this forces all programs on the system to use the same authentication server, -we have designed its interface to make any safe operation possible, and to -include no extraneous operations. -(This is why there is a separate password -server.) -

The Process Server

-

-The process server acts as an information categorization repository. -There -are four main services supported by this server. -First, the process server -keeps track of generic host-level information not handled by the Mach kernel. -For example, the hostname, the hostid, and the system version are maintained -by the process server. -Second, this server maintains the Posix notions of -sessions and process groups, to help out programs that wish to use Posix -features. -

-Third, the process server maintains a one-to-one mapping between Mach tasks -and Hurd processes. -Every task is assigned a pid. -Processes can register a -message port with this server, which can then be given out to any program -which requests it. -This server makes no attempt to keep these message ports -private, so user programs are expected to implement whatever security they -need themselves. -(The GNU C Library provides convenient functions for all -this.) Processes can tell the process server their current `argv' and `envp' -values; this server will then provide, on request, these vectors of arguments -and environment. -This is useful for writing -ps-like -programs and also -makes it easier to hide or change this information. -None of these features -are mandatory. -Programs are free to disregard all of this and never register -themselves with the process server at all. -They will, however, still have a -pid assigned. -

-Finally, the process server implements -process collections, -which are used -to collect a number of process message ports at the same time. -Also, -facilities are provided for converting between pids, process server ports, -and Mach task ports, while ensuring the security of the ports managed. -

-It is important to stress that the process server is optional. -Because of -restrictions in Mach, programs must run as root in order to identify all the -tasks in the system. -But given that, multiple process servers could -co-exist, each with their own clients, giving their own model of the -universe. -Those process server features which do not require root privileges -to be implemented could be done as per-user servers. -The user's hands are -not tied. -

Transparent FTP

-

-Transparent FTP is an intriguing idea whose time has come. -The popular -ange-ftp -package available for GNU Emacs makes access to FTP files -virtually transparent to all the Emacs file manipulation functions. -Transparent FTP does the same thing, but in a system wide fashion. -This -server is not yet written; the details remain to be fleshed out, and will -doubtless change with experience. -

-In a BSD kernel, a transparent FTP filesystem would be no harder to write -than in the Hurd. -But mention the idea to a BSD kernel hacker, and the -response is that ``such a thing doesn't belong in the kernel''. -In a sense, -this is correct. -It violates all the layering principles of such systems to -place such things in the kernel. -The unfortunate side effect, however, is -that the design methodology (which is based on preventing users from changing -things they don't like) is being used to prevent system designers from making -things better. -(Recent BSD kernels make it possible to write a user program -that provides transparent FTP. -An example is -alex, -but it needs to run -with full root privileges.) -

-In the Hurd, there are no obstacles to doing transparent FTP. -A translator -will be provided for the node -/ftp. -The contents of -/ftp -will probably -not be directly listable, though further subdirectories will be. -There will -be a variety of possible formats. -For example, to access files on uunet, one -could - -cd /ftp/ftp.uu.net:anonymous:mib@gnu. - -Or to access files on a remote -account, one might - -cd /ftp/gnu.org:mib:passwd. - -Parts of this -command could be left out and the transparent FTP program would read them -from a user's -.netrc -file. -In the last case, one might just - -cd /ftp/gnu.org; - -when the rest of the data is already in -.netrc. -

-There is no need to do a -cd -first--use any file command. -To find out about -RFC 1097 (the Telnet Subliminal Message Option), just type - -more /ftp/ftp.uu.net/inet/rfc/rfc1097. - -A copy command to a local disk -could be used if the RFC would be read frequently. -

Filesystems

-

-Ordinary filesystems are also being implemented. -The initial release of the -Hurd will contain a filesystem upwardly compatible with the BSD 4.4 Fast File -System. -In addition to the ordinary semantics, it will provide means to -record translators, offer thirty-two bit user ids and group ids, and supply a -new id per file, called the -author -of the file, which can be set by the -owner arbitrarily. -In addition, because users in the Hurd can have multiple -uids (or even none), there is an additional set of permission bits providing -access control for - -unknown user - -(no uids) as distinct from - -known but arbitrary user - -(some uids: the existing -world -category of file -permissions). -

-The Network File System protocol will be implemented using 4.4 BSD as a -starting point. -A log-structured filesystem will also be implemented using -the same ideas as in Sprite, but probably not the same format. -A GNU network -file protocol may be designed in time, or NFS may be extended to remove its -deficiencies. -There will also be various ``little'' filesystems, such as the -MS-DOS filesystem, to help people move files between GNU and other OSs. - -

Terminals

-

-An I/O server will provide the terminal semantics of Posix. -The GNU C -Library has features for keeping track of the controlling terminal and for -arranging to have proper job control signals sent at the proper times, as -well as features for obeying keyboard and hangup signals. -

-Programs will be able to insert a terminal driver into communications -channels in a variety of ways. -Servers like -rlogind -will be able to insert -the terminal protocol onto their network communication port. -Pseudo-terminals will not be necessary, though they will be provided for -backward compatibility with older programs. -No programs in GNU will depend -on them. -

-Nothing about a terminal driver is forced upon users. -A terminal driver -allows a user to get at the underlying communications channel easily, to -bypass itself on an as-needed basis or altogether, or to substitute a -different terminal driver-like program. -In the last case, provided the -alternate program implements the necessary interfaces, it will be used by the -C Library exactly as if it were the ordinary terminal driver. -

-Because of this flexibility, the original terminal driver will not provide -complex line editing features, restricting itself to the behavior found in -Posix and BSD. -In time, there will be a -readline-based -terminal driver, -which will provide complex line-editing features for those users who want -them. -

-The terminal driver will probably not provide good support for the -high-volume, rapid data transmission required by UUCP or SLIP. -Those -programs do not need any of its features. -Instead they will be using the -underlying Mach device ports for terminals, which support moving large -amounts of data efficiently. - -

Executing Programs

-

-The implementation of the -execve -call is spread across three programs. -The -library marshals the argument and environment vectors. -It then sends a -message to the file server that holds the file to be executed. -The file -server checks execute permissions and makes whatever changes it desires in -the exec call. -For example, if the file is marked setuid and the fileserver -has the ability, it will change the user identification of the new image. -The file server also decides if programs which had access to the old task -should continue to have access to the new task. -If the file server is -augmenting permissions, or executing an unreadable image, then the exec needs -to take place in a new Mach task to maintain security. -

-After deciding the policy associated with the new image, the filesystem calls -the exec server to load the task. -This server, using the BFD (Binary File -Descriptor) library, loads the image. -BFD supports a large number of object -file formats; almost any supported format will be executable. -This server -also handles scripts starting with -#!, -running them through the indicated -program. -

-The standard exec server also looks at the environment of the new image; if -it contains a variable -EXECSERVERS -then it uses the programs specified -there as exec servers instead of the system default. -(This is, of course, -not done for execs that the file server has requested be kept secure.) -

-The new image starts running in the GNU C Library, which sends a message to -the exec server to get the arguments, environment, umask, current directory, -etc. -None of this additional state is special to the file or exec servers; -if programs wish, they can use it in a different manner than the Library. - -

New Processes

-

-The -fork -call is implemented almost entirely in the GNU C Library. -The new -task is created by Mach kernel calls. -The C Library arranges to have its -image inherited properly. -The new task is registered with the process server -(though this is not mandatory). -The C Library provides vectors of functions -to be called at fork time: one vector to be called before the fork, one after -in the parent, and one after in the child. -(These features should not be -used to replace the normal fork-calling sequence; it is intended for -libraries which need to close ports or clean up before a fork occurs.) -The C -library will implement both fork calls specified by the draft Posix.4a (the -proposed standard dealing with the threads extension to the real-time -extension). -

-Nothing forces the user to create new tasks this way. -If a program wants to -use almost the normal fork, but with some special characteristics, then it -can do so. -Hooks will be provided by the C Library, or the function can even -be completely replaced. -None of this is possible in a traditional Unix -system. - -

Asynchronous Messages

-

-As mentioned above, the process server maintains a - -message port - -for each -task registered with it. -These ports are public, and are used to send -asynchronous messages to the task. -Signals, for example, are sent to the -message port. -The signal message also provides a port as an indication that -the sender should be trusted to send the signal. -The GNU C Library lists a -variety of ports in a table, each of which identifies a set of signals that -can be sent by anyone who possesses that port. -For example, if the user -possesses the task's kernel port, it is allowed to send any signal. -If the -user possesses a special - -terminal id - -port, it is allowed to send the -keyboard and hangup signals. -Users can add arbitrary new entries into the C -library's signal permissions table. -

-When a process's process group changes, the process server will send it a -message indicating the new process group. -In this case, the process server -proves its authority by providing the task's kernel port. -

-The C library also has messages to add and delete uids currently used by the -process. -If new uids are sent to the program, the library adds them to its -current set, and then exchanges messages with all the I/O servers it knows -about, proving to them its new authorization. -Similarly, a message can -delete uids. -In the latter case, the caller must provide the process's task -port. -(You can't harm a process by giving it extra permission, but you can -harm it by taking permission away.) The Hurd will provide user programs to -send these messages to processes. -For example, the -su -command will be able -to cause all the programs in your current login session, to gain a new uid, -rather than spawn a subshell. -

-The C library will allow programs to add asynchronous messages they wish to -recognize, as well as prevent recognition of the standard set. -

Making It Look Like Unix

-

-The C Library will implement all of the calls from BSD and Posix as well as -some obvious extensions to them. -This enables users to replace those calls -they dislike or bypass them entirely, whereas in Unix the calls must be used -``as they come'' with no alternatives possible. -

-In some environments binary compatibility will also be supported. -This works -by building a special version of the library which is then loaded somewhere -in the address space of the process. -(For example, on a VAX, it would be -tucked in above the stack.) A feature of Mach, called system call -redirection, is then used to trap Unix system calls and turn them into jumps -into this special version of the library. -(On almost all machines, the cost -of such a redirection is very small; this is a highly optimized path in Mach. -On a 386 it's about two dozen instructions. -This is little worse than a -simple procedure call.) -

-Many features of Unix, such as signal masks and vectors, are handled -completely by the library. -This makes such features significantly cheaper -than in Unix. -It is now reasonable to use -sigblock -extensively to protect -critical sections, rather than seeking out some other, less expensive method. - -

Network Protocols

-

-The Hurd will have a library that will make it very easy to port 4.4 BSD -protocol stacks into the Hurd. -This will enable operation, virtually for -free, of all the protocols supported by BSD. -Currently, this includes the -CCITT protocols, the TCP/IP protocols, the Xerox NS protocols, and the ISO -protocols. -

-For optimal performance some work would be necessary to take advantage of -Hurd features that provide for very high speed I/O. -For most protocols this -will require some thought, but not too much time. -The Hurd will run the -TCP/IP protocols as efficiently as possible. -

-As an interesting example of the flexibility of the Hurd design, consider the -case of IP trailers, used extensively in BSD for performance. -While the Hurd -will be willing to send and receive trailers, it will gain fairly little -advantage in doing so because there is no requirement that data be copied and -avoiding copies for page-aligned data is irrelevant. diff --git a/hurd/documentation/hurd-paper.mdwn b/hurd/documentation/hurd-paper.mdwn new file mode 100644 index 00000000..06c23662 --- /dev/null +++ b/hurd/documentation/hurd-paper.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=/hurd-paper]] diff --git a/hurd/documentation/hurd-talk.html b/hurd/documentation/hurd-talk.html deleted file mode 100644 index 29518dd6..00000000 --- a/hurd/documentation/hurd-talk.html +++ /dev/null @@ -1,1061 +0,0 @@ -[[!meta copyright="Copyright © 2001 Marcus Brinkmann"]] - -[[!meta license="Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved."]] - -[[!meta title="The Hurd, a presentation by Marcus Brinkmann"]] - - -

Table of Contents

- -
-

Talk about the Hurd

-

-This talk about the Hurd was written by Marcus Brinkmann for -

    -
  • OSDEM, Brussels, 4. Feb 2001, -
  • Frühjahrsfachgespräche, Cologne, 2. Mar 2001 and -
  • Libre Software Meeting, Bordeaux, 4. Jul 2001. -
- -

Introduction

-

-When we talk about free software, we usually refer to the free -software licenses. We also need relief from software patents, so our -freedom is not restricted by them. But there is a third type of -freedom we need, and that's user freedom. - -

-Expert users don't take a system as it is. They like to change the -configuration, and they want to run the software that works best for -them. That includes window managers as well as your favourite text -editor. But even on a GNU/Linux system consisting only of free -software, you can not easily use the filesystem format, network -protocol or binary format you want without special privileges. In -traditional unix systems, user freedom is severly restricted by the -system administrator. - -

-The Hurd removes these restrictions from the user. It provides an -user extensible system framework without giving up POSIX compatibility -and the unix security model. Throughout this talk, we will see that -this brings further advantages beside freedom. - -

Overview

-
- -

-The Hurd is a POSIX compatible multi-server -system operating on top of the GNU Mach microkernel. - -

-Topics: -

    -
  • GNU Mach
  • -
  • The Hurd
  • -
  • Development
  • -
  • Debian GNU/Hurd
  • -
-
- -

-The Hurd is a POSIX compatible multi-server system operating on top of -the GNU Mach Microkernel. - -

-I will have to explain what GNU Mach is, so we start with that. Then -I will talk about the Hurd's architecture. After that, I will give a -short overview on the Hurd libraries. Finally, I will tell you how -the Debian project is related to the Hurd. - -

Historicals

- -
-
    -
  • 1983: Richard Stallman founds the GNU project.
  • -
  • 1988: Decision is made to use Mach 3.0 as the kernel.
  • -
  • 1991: Mach 3.0 is released under compatible license.
  • -
  • 1991: Thomas Bushnell, BSG, founds the Hurd project.
  • -
  • 1994: The Hurd boots the first time.
  • -
  • 1997: Version 0.2 of the Hurd is released.

  • -
  • 1998: Debian hurd-i386 archive is created.
  • -
  • 2001: Debian GNU/Hurd snapshot fills three CD images.
  • -
-
- -

-When Richard Stallman founded the GNU project in 1983, he wanted to -write an operating system consisting only of free software. Very -soon, a lot of the essential tools were implemented, and released -under the GPL. However, one critical piece was missing: The kernel. -

-After considering several alternatives, it was decided not to write a -new kernel from scratch, but to start with the Mach microkernel. This -was in 1988, and it was not before 1991 that Mach was released under a -license allowing the GNU project to distribute it as a part of the -system. -

-In 1998, I started the Debian GNU/Hurd project, and in 2001 the number -of available GNU/Hurd packages fills three CD images. - -

Kernel Architectures

-
-

-Microkernel: -

    -
  • Enforces resource management (paging, scheduling)
  • -
  • Manages tasks
  • -
  • Implements message passing for IPC
  • -
  • Provides basic hardware support
  • -
-

-Monolithic kernel: -

    -
  • No message passing necessary
  • -
  • Rich set of features (filesystems, authentication, network - sockets, POSIX interface, ...)
  • -
-
-

-Microkernels were very popular in the scientific world around that -time. They don't implement a full operating system, but only the -infrastructure needed to enable other tasks to implement most -features. In contrast, monolithical kernels like Linux contain -program code of device drivers, network protocols, process management, -authentication, file systems, POSIX compatible interfaces and much -more. -

-So what are the basic facilities a microkernel provides? In general, -this is resource management and message passing. Resource management, -because the kernel task needs to run in a special privileged mode of -the processor, to be able to manipulate the memory management unit and -perform context switches (also to manage interrupts). Message -passing, because without a basic communication facility the other -tasks could not interact to provide the system services. Some -rudimentary hardware device support is often necessary to bootstrap -the system. So the basic jobs of a microkernel are enforcing the -paging policy (the actual paging can be done by an external pager -task), scheduling, message passing and probably basic hardware device -support. -

-Mach was the obvious choice back then, as it provides a rich set of -interfaces to get the job done. Beside a rather brain-dead device -interface, it provides tasks and threads, a messaging system allowing -synchronous and asynchronous operation and a complex interface for -external pagers. It's certainly not one of the sexiest microkernels -that exist today, but more like a big old mama. The GNU project -maintains its own version of Mach, called GNU Mach, which is based on -Mach 4.0. In addition to the features contained in Mach 4.0, the GNU -version contains many of the Linux 2.0 block device and network card -drivers. -

-A complete treatment of the differences between a microkernel and -monolithical kernel design can not be provided here. But a couple of -advantages of a microkernel design are fairly obvious. - -

Micro vs Monolithic

-
-

-Microkernel -

    -
  • Clear cut responsibilities -
  • Flexibility in operating system design, easier debugging
  • -
  • More stability (less code to break)
  • -
  • New features are not added to the kernel
  • -
-

-Monolithic kernel -

    -
  • Intolerance or creeping featuritis
  • -
  • Danger of spaghetti code
  • -
  • Small changes can have far reaching side effects
  • -
-
-

-Because the system is split up into several components, clean -interfaces have to be developed, and the responsibilities of each part -of the system must be clear. -

-Once a microkernel is written, it can be used as the base for several -different operating systems. Those can even run in parallel which -makes debugging easier. When porting, most of the hardware dependant -code is in the kernel. -

-Much of the code that doesn't need to run in the special kernel mode -of the processor is not part of the kernel, so stability increases -because there is simply less code to break. -

-New features are not added to the kernel, so there is no need to hold -the barrier high for new operating system features. -

-Compare this to a monolithical kernel, where you either suffer from -creeping featuritis or you are intolerant of new features (we see both -in the Linux kernel). -

-Because in a monolithical kernel, all parts of the kernel can access -all data structures in other parts, it is more likely that short cuts -are used to avoid the overhead of a clean interface. This leads to a -simple speed up of the kernel, but also makes it less comprehensible -and more error prone. A small change in one part of the kernel can -break remote other parts. - -

Single Server vs Multi Server

-
-

-Single Server -

    -
  • A single task implements the functionality of the operating system.
  • -
-

-Multi Server -

    -
  • Many tasks cooperate to provide the system's functionality.
  • -
  • One server provides only a small but well-defined part of the - whole system.
  • -
  • The responsibilities are distributed logically among the servers.
  • -
-

-A single-server system is comparable to a monolithic kernel system. It -has similar -advantages and disadvantages. -

-

-There exist a couple of operating systems based on Mach, but they all -have the same disadvantages as a monolithical kernel, because those -operating systems are implemented in one single process running on top -of the kernel. This process provides all the services a monolithical -kernel would provide. This doesn't make a whole lot of sense (the -only advantage is that you can probably run several of such isolated -single servers on the same machine). Those systems are also called -single-server systems. The Hurd is the only usable multi-server -system on top of Mach. In the Hurd, there are many server programs, -each one responsible for a unique service provided by the operating -system. These servers run as Mach tasks, and communicate using the -Mach message passing facilities. One of them does only provide a -small part of the functionality of the system, but together they build -up a complete and functional POSIX compatible operating system. - -

Multi Server is superior, ...

-
-

-Any multi-server has advantages over single-server: -

    -
  • Clear cut responsibilities
  • -
  • More stability: If one server dies, all others remain
  • -
  • Easier development cycle: Testing without reboot (or replacing - running servers), debugging with gdb
  • -
  • Easier to make changes and add new features -
-
-

-Using several servers has many advantages, if done right. If a file -system server for a mounted partition crashes, it doesn't take down -the whole system. Instead the partition is "unmounted", and -you can try to start the server again, probably debugging it this time -with gdb. The system is less prone to errors in individual -components, and over-all stability increases. The functionality of -the system can be extended by writing and starting new servers -dynamically. (Developing these new servers is easier for the reasons -just mentioned.) -

-But even in a multi-server system the barrier between the system and -the users remains, and special privileges are needed to cross it. We -have not achieved user freedom yet. - -

The Hurd even more so.

-
-

-The Hurd goes beyond all this, and allows users to write and run their -servers, too! -

    -
  • Users can replace system servers dynamically with their own - implementations.
  • -
  • Users can decide what parts of the remainder of the system they - want to use.
  • -
  • Users can extend the functionality of the system.
  • -
  • No mutual trust necessary to make use of other users - services.
  • -
  • Security of the system is not harmed by trusting users - services.
  • -
-
-

-To quote Thomas Bushnell, BSG, from his paper -[[``Towards_a_New_Strategy_of_OS_design''_(1996)|hurd-paper]]: -

-The GNU Hurd, by contrast, is designed to make the area of system code -as limited as possible. Programs are required to communicate only -with a few essential parts of the kernel; the rest of the system is -replaceable dynamically. Users can use whatever parts of the -remainder of the system they want, and can easily add components -themselves for other users to take advantage of. No mutual trust need -exist in advance for users to use each other's services, nor does the -system become vulnerable by trusting the services of arbitrary users. -
- -

-So the Hurd is a set of servers running on top of the Mach -micro-kernel, providing a POSIX compatible and extensible operating -system. What servers are there? What functionality do they provide, -and how do they cooperate? - -

Mach Inter Process Communication

-
-

-Ports are message queues which can be used as one-way communication -channels. -

    -
  • Port rights are receive, send or send-once
  • -
  • Exactly one receiver
  • -
  • Potentially many senders
  • -
-

-MIG provides remote procedure calls on top of Mach IPC. RPCs look like -function calls to the user. -

-

-Inter-process communication in Mach is based on the ports concept. A -port is a message queue, used as a one-way communication channel. In -addition to a port, you need a port right, which can be a send right, -receive right, or send-once right. Depending on the port right, you -are allowed to send messages to the server, receive messages from it, -or send just one single message. -

-For every port, there exists exactly one task holding the receive -right, but there can be no or many senders. The send-once right is -useful for clients expecting a response message. They can give a -send-once right to the reply port along with the message. The kernel -guarantees that at some point, a message will be received on the reply -port (this can be a notification that the server destroyed the -send-once right). -

-You don't need to know much about the format a message takes to be -able to use the Mach IPC. The Mach interface generator mig hides the -details of composing and sending a message, as well as receiving the -reply message. To the user, it just looks like a function call, but -in truth the message could be sent over a network to a server running -on a different computer. The set of remote procedure calls a server -provides is the public interface of this server. - - -

How to get a port?

-
-

-Traditional Mach: -

    -
  • Nameserver provides ports to all registered servers.
  • -
  • The nameserver port itself is provided by Mach.
  • -
  • Like a phone book: One list.
  • -
-

-The Hurd: -

    -
  • The filesystem is used as the server namespace.
  • -
  • Root directory port is inserted into each task.
  • -
  • The C library finds other ports with hurd_file_name_lookup, - performing a pathname resolution.
  • -
  • Like a tree of phone books.
  • -
-
-

-So how does one get a port to a server? You need something like a -phone book for server ports, or otherwise you can only talk to -yourself. In the original Mach system, a special nameserver is -dedicated to that job. A task could get a port to the nameserver from -the Mach kernel and ask it for a port (with send right) to a server -that registered itself with the nameserver at some earlier time. -

-In the Hurd, there is no nameserver. Instead, the filesystem is used -as the server namespace. This works because there is always a root -filesystem in the Hurd (remember that the Hurd is a POSIX compatible -system); this is an assumption the people who developed Mach couldn't -make, so they had to choose a different strategy. You can use the -function hurd_file_name_lookup, which is part of the C library, to get -a port to the server belonging to a filename. Then you can start to -send messages to the server in the usual way. - -

Example of hurd_file_name_lookup

-
-mach_port_t identity;
-mach_port_t pwserver;
-kern_return_t err;
-
-pwserver = hurd_file_name_lookup
-                ("/servers/password");
-
-err = password_check_user (pwserver,
-                           0 /* root */, "supass",
-                           &identity);
-
-

-As a concrete example, the special filename -/servers/password can be used to request a port to the -Hurd password server, which is responsible to check user provided -passwords. -

-(explanation of the example) - -

Pathname resolution example

-
-

-Task: Lookup /mnt/readme.txt where /mnt has a mounted filesystem. -

    -
  • The C library asks the root filesystem server about - /mnt/readme.txt.
  • -
  • The root filesystem returns a port to the mnt filesystem server - (matching /mnt) and the retry name - /readme.txt.
  • -
  • The C library asks the mnt filesystem server about - /readme.txt.
  • -
  • The mnt filesystem server returns a port to itself and records - that this port refers to the regular file - /readme.txt.
  • -
-
-

-The C library itself does not have a full list of all available -servers. Instead pathname resolution is used to traverse through a -tree of servers. In fact, filesystems themselves are implemented by -servers (let us ignore the chicken and egg problem here). So all the -C library can do is to ask the root filesystem server about the -filename provided by the user (assuming that the user wants to resolve -an absolute path), using the dir_lookup RPC. If the -filename refers to a regular file or directory on the filesystem, the -root filesystem server just returns a port to itself and records that -this port corresponds to the file or directory in question. But if a -prefix of the full path matches the path of a server the root -filesystem knows about, it returns to the C library a port to this -server and the remaining part of the pathname that couldn't be -resolved. The C library than has to retry and query the other server -about the remaining path component. Eventually, the C library will -either know that the remaining path can't be resolved by the last -server in the list, or get a valid port to the server in question. - -

Mapping the POSIX Interface

-
- - - - - - - - - - - - - - - - - - - -
FiledescriptorPort to server providing the file
fd = open(name,...)dir_lookup(..,name,..,&port)
-[pathname resolution]
read(fd, ...)io_read(port, ...)
write(fd, ...)io_write(port, ...)
fstat(fd, ...)io_stat(port, ...)
...
-
-

-It should by now be obvious that the port returned by the server can -be used to query the files status, content and other information from -the server, if good remote procedure calls to do that are defined and -implemented by it. This is exactly what happens. Whenever a file is -opened using the C libraries open() call, the C library -uses the above pathname resolution to get a port to a server providing -the file. Then it wraps a file descriptor around it. So in the Hurd, -for every open file descriptor there is a port to a server providing -this file. Many other C library calls like read() and -write() just call a corresponding RPC using the port -associated with the file descriptor. - -

File System Servers

-
-
    -
  • Provide file and directory services for ports (and more).
  • -
  • These ports are returned by a directory lookup.
  • -
  • Translate filesystem accesses through their root path (hence the - name translator).
  • -
  • The C library maps the POSIX file and directory interface (and - more) to RPCs to the filesystem servers ports, but also does work on - its own.
  • -
  • Any user can install file system servers on inodes they own.
  • -
-
-

-So we don't have a single phone book listing all servers, but rather a -tree of servers keeping track of each other. That's really like -calling your friend and asking for the phone number of the blond girl -at the party yesterday. He might refer you to a friend who hopefully -knows more about it. Then you have to retry. -

-This mechanism has huge advantages over a single nameserver. First, -note that standard unix permissions on directories can be used to -restrict access to a server (this requires that the filesystems -providing those directories behave). You just have to set the -permissions of a parent directory accordingly and provide no other way -to get a server port. -

-But there are much deeper implications. Most of all, a pathname never -directly refers to a file, it refers to a port of a server. That -means that providing a regular file with static data is just one of -the many options the server has to service requests on the file port. -A server can also create the data dynamically. For example, a server -associated with /dev/random can provide new random data -on every io_read() on the port to it. A server -associated with /dev/fortune can provide a new fortune -cookie on every open(). -

-While a regular filesystem server will just serve the data as stored -in a filesystem on disk, there are servers providing purely virtual -information, or a mixture of both. It is up to the server to behave -and provide consistent and useful data on each remote procedure call. -If it does not, the results may not match the expectations of the user -and confuse him. -

-A footnote from the Hurd info manual: -

-(1) You are lost in a maze of twisty little filesystems, all -alike.... -
-

-Because a server installed in the filesystem namespace translates all -filesystem operations that go through its root path, such a server is -also called "active translator". You can install translators using -the settrans command with the -a option. - -

Active vs Passive

-
-

-Active Translators: -

    -
  • "settrans -a /cdrom /hurd/isofs /dev/hd2"
  • -
  • Are running filesystem servers.
  • -
  • Are attached to the root node they translate.
  • -
  • Run as a normal process.
  • -
  • Go away with every reboot, or even time out.
  • -
-
-

-Many translator settings remain constant for a long time. It would be -very lame to always repeat the same couple of dozens settrans calls -manually or at boot time. So the Hurd provides a filesystem extension -that allows to store translator settings inside the filesystem and let -the filesystem servers do the work to start those servers on demand. -Such translator settings are called "passive translators". A passive -translator is really just a command line string stored in an inode of -the filesystem. If during a pathname resolution a server encounters -such a passive translator, and no active translator does exist already -(for this node), it will use this string to start up a new translator -for this inode, and then let the C library continue with the path -resolution as described above. Passive translators are installed with -settrans using the -p option (which is already the -default). - -
-

-Passive Translators: -

    -
  • "settrans /mnt /hurd/ext2fs /dev/hd1s1"
  • -
  • Are stored as command strings into an inode.
  • -
  • Are used to start a new active translator if there isn't - one.
  • -
  • Startup is transparent to the user.
  • -
  • Startup happens the first time the server is needed.
  • -
  • Are permanent across reboots (like file data).
  • -
-
-

-So passive translators also serve as a sort of automounting feature, -because no manual interaction is required. The server start up is -deferred until the service is need, and it is transparent to the user. -

-When starting up a passive translator, it will run as a normal process -with the same user and group id as those of the underlying inode. Any -user is allowed to install passive and active translators on inodes -that he owns. This way the user can install new servers into the -global namespace (for example, in his home or tmp directory) and thus -extend the functionality of the system (recall that servers can -implement other remote procedure calls beside those used for files and -directories). A careful design of the trusted system servers makes -sure that no permissions leak out. -

-In addition, users can provide their own implementations of some of -the system servers instead the system default. For example, they can -use their own exec server to start processes. The user specific exec -server could for example start java programs transparently (without -invoking the interpreter manually). This is done by setting the -environment variable EXECSERVERS. The systems default -exec server will evaluate this environment variable and forward the -RPC to each of the servers listed in turn, until some server accepts -it and takes over. The system default exec server will only do this -if there are no security implications. (XXX There are other ways to -start new programs than by using the system exec server. Those are -still available.) -

-Let's take a closer look at some of the Hurd servers. It was already -mentioned that only few system servers are mandatory for users. To -establish your identity within the Hurd system, you have to -communicate with the trusted systems authentication server -auth. To put the system administrator into control over -the system components, the process server does some global -bookkeeping. -

-But even these servers can be ignored. However, registration with the -authentication server is the only way to establish your identity -towards other system servers. Likewise, only tasks registered as -processes with the process server can make use of its services. - -

Authentication

-
-

-A user identity is just a port to an authserver. The auth server -stores four set of ids for it: -

    -
  • effective user ids
  • -
  • effective group ids
  • -
  • available user ids
  • -
  • available group ids
  • -
-

-Basic properties: -

    -
  • Any of these can be empty.
  • -
  • A 0 among the user ids identifies the superuser.
  • -
  • Effective ids are used to check if the user has the - permission.
  • -
  • Available ids can be turned into effective ids on user - request.
  • -
-
-

-The Hurd auth server is used to establish the identity of a user for a -server. Such an identity (which is just a port to the auth server) -consists of a set of effective user ids, a set of effective group ids, -a set of available user ids and a set of available group ids. Any of -these sets can be empty. - -

Operations on authentication ports

-
-

-The auth server provides the following operations on ports: -

    -
  • Merge the ids of two ports into a new one.
  • -
  • Return a new port containing a subset of the ids in a port.
  • -
  • Create a new port with arbitrary ids (superuser only).
  • -
  • Establish a trusted connection between users and servers.
  • -
-
-

-If you have two identities, you can merge them and request an identity -consisting of the unions of the sets from the auth server. You can -also create a new identity consisting only of subsets of an identity -you already have. What you can't do is extending your sets, unless -you are the superuser which is denoted by having the user id 0. - -

Establishing trusted connections

-
-
    -
  • User provides a rendezvous port to the server (with - io_reauthenticate).
  • -
  • User calls auth_user_authenticate on the - authentication port (his identity), passing the rendezvous port.
  • -
  • Server calls auth_server_authenticate on its - authentication port (to a trusted auth server), passing the - rendezvous port and the server port.
  • -
  • If both authentication servers are the same, it can match the - rendezvous ports and return the server port to the user and the user - ids to the server.
  • -
-
-

-Finally, the auth server can establish the identity of a user for a -server. This is done by exchanging a server port and a user identity -if both match the same rendezvous port. The server port will be -returned to the user, while the server is informed about the id sets -of the user. The server can then serve or reject subsequent RPCs by -the user on the server port, based on the identity it received from -the auth server. -

-Anyone can write a server conforming to the auth protocol, but of -course all system servers use a trusted system auth server to -establish the identity of a user. If the user is not using the system -auth server, matching the rendezvous port will fail and no server port -will be returned to the user. Because this practically requires all -programs to use the same auth server, the system auth server is -minimal in every respect, and additional functionality is moved -elsewhere, so user freedom is not unnecessarily restricted. - -

Password Server

-
-

-The password server /servers/password runs as root and -returns a new authentication port in exchange for a unix password. -

-The ids corresponding to the authentication port match the unix user -and group ids. -

-Support for shadow passwords is implemented here. -

-

-The password server sits at /servers/password and runs as -root. It can hand out ports to the auth server in exchange for a unix -password, matching it against the password or shadow file. Several -utilities make use of this server, so they don't need to be setuid -root. - -

Process Server

-
-

-The superuser must remain control over user tasks, so: -

    -
  • All mach tasks are associated with a PID in the system default - proc server.
  • -
-

-Optionally, user tasks can store: -

    -
  • Their environment variables.
  • -
  • Their argument vector.
  • -
  • A port, which others can request based on the PID (like a - nameserver).
  • -
-

-Also implemented in the proc server: -

    -
  • Sessions and process groups.
  • -
  • Global configuration not in Mach, like hostname, hostid, system - version.
  • -
-
-

-The process server is responsible for some global bookkeeping. As -such it has to be trusted and is not replaceable by the user. -However, a user is not required to use any of its service. In that -case the user will not be able to take advantage of the POSIXish -appearance of the Hurd. -

-The Mach Tasks are not as heavy as POSIX processes. For example, -there is no concept of process groups or sessions in Mach. The proc -server fills in the gap. It provides a PID for all Mach tasks, and -also stores the argument line, environment variables and other -information about a process (if the mach tasks provide them, which is -usually the case if you start a process with the default -fork()/exec()). A process can also register -a message port with the proc server, which can then be requested by -anyone. So the proc server also functions as a nameserver using the -process id as the name. -

-The proc server also stores some other miscellaneous information not -provided by Mach, like the hostname, hostid and system version. -Finally, it provides facilities to group processes and their ports -together, as well as to convert between pids, process server ports and -mach task ports. -
-

-User tasks not registering themselve with proc only have a PID assigned. -

-Users can run their own proc server in addition to the system default, -at least for those parts of the interface that don't require superuser -privileges. -

-

-Although the system default proc server can't be avoided (all Mach -tasks spawned by users will get a pid assigned, so the system -administrator can control them), users can run their own additional -process servers if they want, implementing the features not requiring -superuser privileges. - -

Filesystems

-
-

-Store based filesystems -

    -
  • ext2fs
  • -
  • ufs
  • -
  • isofs (iso9660, RockRidge, GNU extensions)
  • -
  • fatfs (under development)
  • -
-

-Network file systems -

    -
  • nfs
  • -
  • ftpfs
  • -
-

-Miscellaneous -

    -
  • hostmux
  • -
  • usermux
  • -
  • tmpfs (under development)
  • -
-
-

-We already talked about translators and the file system service they -provide. Currently, we have translators for the ext2, ufs and iso9660 -filesystems. We also have an nfs client and an ftp filesystem. -Especially the latter is intriguing, as it provides transparent access -to ftp servers in the filesystem. Programs can start to move away -from implementing a plethora of network protocols, as the files are -directly available in the filesystem through the standard POSIX file -interface. - - -

Developing the Hurd

-
-

-Over a dozen libraries support the development of new servers. -

-For special server types highly specialized -libraries require only the implementation of a -number of callback functions. -

    -
  • Use libdiskfs for store based filesystems.
  • -
  • Use libnetfs for network filesystems, also for - virtual filesystems.
  • -
  • Use libtrivfs for simple filesystems providing only - a single file or directory.
  • -
-
-

-The Hurd server protocols are complex enough to allow for the -implementation of a POSIX compatible system with GNU extensions. -However, a lot of code can be shared by all or at least similar -servers. For example, all storage based filesystems need to be able to -read and write to a store medium splitted in blocks. The Hurd comes -with several libraries which make it easy to implement new servers. -Also, there are already a lot of examples of different server types in -the Hurd. This makes writing a new server easier. -

-libdiskfs is a library that supports writing store based -filesystems like ext2fs or ufs. It is not very useful for filesystems -which are purely virtual, like /proc or files in -/dev. -

-libnetfs is intended for filesystems which provide a rich -directory hierarchy, but don't use a backing store (for example ftpfs, -nfs). -

-libtrivfs is intended for filesystems which just provide -a single inode or directory. Most servers which are not intended to -provide a filesystem but other services (like -/servers/password) use it to provide a dummy file, so -that file operations on the servers node will not return errors. But -it can also be used to provide meaningful data in a single file, like -a device store or a character device. - -

Store Abstraction

-
-

-Another very useful library is libstore, which is used by all store -based filesystems. It provides a store media abstraction. A store -consists of a store class and a name (which itself can sometimes -contain stores). -

-Primitive store classes: -

    -
  • device store like device:hd2, device:hd0s1, device:fd0
  • -
  • file store like file:/tmp/disk_image
  • -
  • task store like task:PID
  • -
  • zero store like zero:4m (like /dev/zero, of size 4 MB)
  • -
-
-
-

-Composed store classes: -

    -
  • copy store like copy:zero:4m
  • -
  • gunzip/bunzip2 store like gunzip:device:fd0
  • -
  • concat store like concat:device:hd0s2:device:hd1s5
  • -
  • ileave store (RAID-0(2))
  • -
  • remap store like remap:10+20,50+:file:/tmp/blocks
  • -
  • ...
  • -
-

-Wanted: A similar abstraction for streams (based on channels), which -can be used by network and character device servers. -

-

-libstore provides a store abstraction, which is used by -all store based filesystems. The store is determined by a type and a -name, but some store types modify another store rather than providing -a new store, and thus stores can be stacked. For example, the device -store type expects a Mach device, but the remap store expects a list -of blocks to pick from another store, like remap:1+:device:hd2, which -would pick all blocks from hd2 but the first one, which skipped. -Because this functionality is provided in a library, all libstore -using filesystems support many different store kinds, and adding a new -store type is enough to make all store based filesystems support it. - -

Debian GNU/Hurd

-
-

-Goal: -

    -
  • Provide a binary distribution of the Hurd that is easy to - install.
  • -
-

-Constraints: -

    -
  • Use the same source packages as Debian GNU/Linux.
  • -
  • Use the same infrastructure: -
      -
    • Policy
    • -
    • Archive
    • -
    • Bug tracking system
    • -
    • Release process
    • -
  • -
-

-Side Goal: -

    -
  • Prepare Debian for the future: -
      -
    • More flexibility in the base system
    • -
    • Identify dependencies on the Linux kernel
    • -
  • -
-
-

-The Debian distribution of the GNU Hurd that I started in 1998 is -supposed to become a complete binary distribution of the Hurd that is -easy to install. - -

Status of the Debian GNU/Hurd binary archive

-

-See -http://buildd.debian.org/stats/graph.png -for the most current version of the statistic. - -

Status of the Debian infrastructure

-
-

-Plus: -

    -
  • Source packages can identify build and host OS using - dpkg-architecture.
  • -
-

-Minus: -

    -
  • The binary architecture field is insufficient.
  • -
  • The BTS has no architecture tag.
  • -
  • The policy/FHS need (small) Hurd specific extensions.
  • -
-
-

-While good compatibiity can be achieved at the source level, -the binary packages can not always express their relationship -to the available architectures sufficiently. -

-For example, the Linux version of makedev is binary-all, where -a binary-all-linux relationship would be more appropriate. -

-More work has to be done here to fix the tools. - -

Status of the Debian Source archive

-
-
    -
  • Most packages just work.
  • -
  • Maintainers are usually responsive and cooperative.
  • -
  • Turtle, the autobuilder, crunches through the whole list right - now.
  • -
-

-Common pitfalls are POSIX incompatibilities: -

    -
  • Upstream: -
      -
    • Unconditional use of PATH_MAX - (MAXPATHLEN), MAXHOSTNAMELEN.
    • -
    • Unguarded use of Linux kernel features.
    • -
    • Use of legacy interfaces (sys_errlist, - termio).
    • -
  • -
  • Debian: -
      -
    • Unguarded activation of extensions available with Linux.
    • -
    • Low quality patches.
    • -
    • Assuming GNU/Linux in package scripts.
    • -
  • -
-
-

-Most packages are POSIX compatible and can be compiled without -changes on the Hurd. The maintainers of the Debian source packages -are usually very kind, responsiver and helpful. -

-The Turtle autobuilder software (http://turtle.sourceforge.net) -builds the Debian packages on the Hurd automatically. - -

Debian GNU/Hurd: Good idea, bad idea?

-
-

-Upstream benefits: -

    -
  • Software packages become more portable.
  • -
-

-Debian benefits: -

    -
  • Debian becomes more portable.
  • -
  • Maintainers learn about portability and other systems.
  • -
  • Debian gets a lot of public recognition.
  • -
-

-GNU/Hurd benefits: -

    -
  • Large software base.
  • -
  • Great infrastructure.
  • -
  • Nice community to partner with.
  • -
-
-

-The sheet lists the advantages of all groups involved. - -

End

-
-

-Join us at -

-
-

-List of contacts. diff --git a/hurd/documentation/hurd-talk.mdwn b/hurd/documentation/hurd-talk.mdwn new file mode 100644 index 00000000..83dcaf74 --- /dev/null +++ b/hurd/documentation/hurd-talk.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=/hurd-talk]] diff --git a/hurd/running/gnu/universal_package_manager.mdwn b/hurd/running/gnu/universal_package_manager.mdwn index bb8ff693..ecac8e21 100644 --- a/hurd/running/gnu/universal_package_manager.mdwn +++ b/hurd/running/gnu/universal_package_manager.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009 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 @@ -127,7 +128,7 @@ OK. I will give you steps. i. Install a GNU System by folowing [[these_instructions|setup]] -ii. Read about GNU Design: [[Towards_a_New_Strategy_of_OS_Design|documentation/hurd-paper]] +ii. Read about GNU Design: [[Towards_a_New_Strategy_of_OS_Design|hurd-paper]] iii. Read about translators diff --git a/microkernel/faq/multiserver_microkernel.mdwn b/microkernel/faq/multiserver_microkernel.mdwn index b16faa92..ca9b2179 100644 --- a/microkernel/faq/multiserver_microkernel.mdwn +++ b/microkernel/faq/multiserver_microkernel.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2008 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2008, 2009 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 @@ -23,4 +23,4 @@ it, they may, for instance, mount an FTP filesystem in their home directory. For more information about the design of the Hurd, read the paper by Thomas Bushnell, BSG: -[[Towards_a_New_Strategy_of_OS_Design|hurd/documentation/hurd-paper]]. +[[Towards_a_New_Strategy_of_OS_Design|hurd-paper]]. -- cgit v1.3.1