From 81582b07623a0a999898325140e8f1539d1ca5dd Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 16 Dec 2007 01:26:05 +0100 Subject: Hurd/HurdSpecificGlibcApi -> hurd/glibc/hurd-specific_api. --- hurd/running/distrib.mdwn | 1 - 1 file changed, 1 deletion(-) (limited to 'hurd/running/distrib.mdwn') diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index a373062c..fc42e862 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -96,7 +96,6 @@ about getting applications to work (if possible). * [[TestSuites]] - Posix, Perl, results feedback, etc. * [docs and papers](http://www.gnu.org/software/hurd/docs.html) * [[SystemAPILimits]] -* [[Hurd/HurdSpecificGlibcApi]] * [[CodeAnnouncements]] - Recent coding projects related to the Hurd
-- cgit v1.2.3 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. --- auth.html | 248 ----- contributing.mdwn | 10 +- devel.html | 159 ---- docs.html | 302 ------ documentation.mdwn | 16 +- hurd-paper.html | 812 ---------------- hurd-talk.html | 1151 ----------------------- hurd.mdwn | 2 - hurd/authentication.mdwn | 2 +- hurd/critique.mdwn | 4 +- hurd/documentation.mdwn | 48 +- hurd/documentation/auth.html | 168 ++++ hurd/documentation/hurd-paper.html | 760 +++++++++++++++ hurd/documentation/hurd-talk.html | 1061 +++++++++++++++++++++ hurd/hurd_hacking_guide.mdwn | 16 +- hurd/ng/position_paper.mdwn | 9 +- hurd/reference_manual.mdwn | 18 + hurd/running/distrib.mdwn | 2 +- hurd/running/gnu/universal_package_manager.mdwn | 2 +- hurd/translator.mdwn | 1 + hurd/translator/auth.mdwn | 13 + microkernel/faq/multiserver_microkernel.mdwn | 4 +- microkernel/mach/documentation.mdwn | 18 +- microkernel/mach/gnu_mach.mdwn | 1 + microkernel/mach/gnu_mach/reference_manual.mdwn | 26 + microkernel/mach/mig/documentation.mdwn | 3 +- 26 files changed, 2146 insertions(+), 2710 deletions(-) delete mode 100644 auth.html delete mode 100644 devel.html delete mode 100644 docs.html delete mode 100644 hurd-paper.html delete mode 100644 hurd-talk.html create mode 100644 hurd/documentation/auth.html create mode 100644 hurd/documentation/hurd-paper.html create mode 100644 hurd/documentation/hurd-talk.html create mode 100644 hurd/reference_manual.mdwn create mode 100644 hurd/translator/auth.mdwn create mode 100644 microkernel/mach/gnu_mach/reference_manual.mdwn (limited to 'hurd/running/distrib.mdwn') diff --git a/auth.html b/auth.html deleted file mode 100644 index 676442ee..00000000 --- a/auth.html +++ /dev/null @@ -1,248 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - English -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
-

 -
-

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. -
  2. The user requests a reauthentication from the server
    3. -
  3. In this request the user will include a port
    4. -
  4. Both will hand this port to auth
    5. -
  5. The user uses auth_user_authenticate
    6. -
  6. The server uses auth_server_authenticate
    7. -
  7. The server also passes a new port to auth
    8. -
  8. auth matches these two requests
    9. -
  9. The user gets the new port from auth
    10. -
  10. The server learns about the IDs of the user
    11. -
  11. The user uses the new port for further communication
    12. -
- -

-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. - -

- -
- -[ - English -] - -
- -

-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) 2002 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/contributing.mdwn b/contributing.mdwn index 698d03b3..f1003389 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -52,7 +52,7 @@ is another possibility, see the page about [[running_a_Hurd_system|hurd/running]] for the full story. Then you can either play around and eventually strive to do something -useful or -- if you want -- ask us to assign something to you, depending +useful or -- if you want -- [[ask_us|contact_us]] to assign something to you, depending on the skills you have and the resources you intend to invest. Please spend some time with thinking about the items in this [[questionnaire]]. @@ -62,10 +62,10 @@ system, e.g., [[microkernels_for_beginners|microkernel/for_beginners]]. Until you can do the basic exercises listed there, you won't be able to significantly contribute to the Hurd. -For more reading resources, please see these web pages, and also -, - for links to a bunch of documents, -and in general. +For more reading resources, please see these web pages, for example, +[[Hurd_documentation|hurd/documentation]] and +[[Mach_documentation|microkernel/mach/documentation]] for links to a bunch of +documents. ### Porting Packages diff --git a/devel.html b/devel.html deleted file mode 100644 index 2a31f959..00000000 --- a/devel.html +++ /dev/null @@ -1,159 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - en -| eo -| es -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

Table of Contents

- -
- -

Contributing

-

-If you want to contribute to the Hurd, you should first install and -use it for a while, to become familiar with its features and design. -To join the development team, subscribe to the -Bug-Hurd -<bug-hurd@gnu.org> -mailing list, which is also the place where you can announce your -intentions, make your proposals and send in your patches. -(You can also send mail there without being subscribed to the list.) -

-There is also the -Hurd-devel-readers -mailing list. It is the read-only version of Hurd-devel, an internal -low-volume list restricted to the core developers of the Hurd. If you -want to follow up on the discussion of the Hurd experts, please reply -to the Bug-hurd mailing list. You can also follow the Hurd-devel -mailing list by browsing the web-based archive of -Hurd-devel. - -

Machinery: getting access to a -system

-

-There are essentially two possibilities: either you install the GNU/Hurd on a -system (see here) or if you don't -have a system to install it on, you can be provided with a shell account. See -this wiki page -for details. - -

Tasks

-

-Developing an operating system is a huge job, with a lot of different -things to do. To be able to keep track of issues, we use a -

-There is also an older (but still valid) list of specific items in the -task file -and in the -TODO file -of the Hurd source repository. - -
- -
- -[ - - - en -| eo -| es -] - -
- -

-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) 2001, 2002, 2006, 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$ - -

- - diff --git a/docs.html b/docs.html deleted file mode 100644 index 9c3a43f1..00000000 --- a/docs.html +++ /dev/null @@ -1,302 +0,0 @@ - - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - English -| Esperanto -| Spanish -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

Table of Contents

- -
- -

Introductory material, papers and other -informational documents

-

-

- -

Frequently asked questions

-

-Please check out the -Frequently -Asked Questions about the GNU Hurd (33k characters) and their -answers, which cover most issues a new user will be confronted with. -

-This document is available in several languages: -

- -

Wiki

-

A wiki is available for -collecting ideas and reciepes. Fell free -to contribute! - -

Some topics: - -

- - -

Reference manuals

- -
    - -
  • -

    -The GNU Mach Reference Manual documents the architecture, the usage and -the programming of the GNU Mach microkernel. At the moment, the manual -documents the interface completely, but is not very useful as a tutorial or -introduction into the Mach architecture. -

    -Available Formats: -

    -

    -If you want to work on the manual, you're advised to make a checkout of the source tree. Be sure to get the -GNU Mach 1 branch when you intend to work on the manual. You -can then find the manual's sources in the doc/ directory. Please -submit any modifications to <bug-hurd@gnu.org> (if possible in -unidiff format, as produced by diff -u). - -

    • - -
  • -

    -The GNU Hurd Reference Manual documents the architecture, the usage -and the programming of the GNU Hurd. At the moment, the manual is -quite incomplete. -

    -Available Formats: -

    -

    -If you want to work on the manual, you're advised to make a checkout of the source tree. You can then find the manual's -sources in the doc/ directory. Please submit any modifications to -<bug-hurd@gnu.org> (if possible in -unidiff format, as produced by diff -u). - -

    • - -
- -
- -
- -[ - - - English -| Esperanto -| Spanish -] - -
- -

-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) 2001, 2002, 2003, 2004, 2005, 2006, 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$ - -

- - diff --git a/documentation.mdwn b/documentation.mdwn index 45bb5ffc..4e4b4b23 100644 --- a/documentation.mdwn +++ b/documentation.mdwn @@ -8,21 +8,13 @@ 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]]."]]"""]] -# General +Documentation for... - * [GNU Hurd Documentation](http://www.gnu.org/software/hurd/docs.html) + * [[GNU_Hurd|hurd/documentation]] + * [[Mach|microkernel/mach/documentation]] -# Introductory Material - -## External - - * [*Examining the Legendary HURD - Kernel*](http://www.informit.com/articles/printerfriendly.aspx?p=1180992), - an article by David Chisnall. - - Also covers a bit of GNU's and the Hurd's history, fundamental techniques - applied, comparisions to other systems. + * [[MIG|microkernel/mach/mig/documentation]] # [[Unix]] Programming diff --git a/hurd-paper.html b/hurd-paper.html deleted file mode 100644 index bb49829c..00000000 --- a/hurd-paper.html +++ /dev/null @@ -1,812 +0,0 @@ - - - -Towards a New Strategy of OS Design - - - -

Towards a New Strategy of OS Design

- [image of a Hurd Metafont Logo] (jpeg 10k) -(jpeg 20k) -no gifs due to patent problems -
-
-[ - - - English -| Hebrew -| Turkish -] - -

-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. - -

- -[ - - - English -| Hebrew -| Turkish -] - -
- -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 Trent Fisher -
-Copyright (C) 1996, 1997, 1998, 2007 Free Software Foundation, Inc., -51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. -

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

-Updated: - -19 Dec 1998 jonas - -

- - diff --git a/hurd-talk.html b/hurd-talk.html deleted file mode 100644 index 630bbc7d..00000000 --- a/hurd-talk.html +++ /dev/null @@ -1,1151 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - English -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

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 -``A new strategy towards OS -design'' (1996): -

-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. - -

-Some of these links are at other web sites not maintained by the -FSF. The FSF is not responsible for the content of these other web sites. - -

- -
- -[ - - - English -] - -
- -

-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) 2001 Marcus Brinkmann <marcus@gnu.org> -

-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.mdwn b/hurd.mdwn index 61e83d21..3c65bb4e 100644 --- a/hurd.mdwn +++ b/hurd.mdwn @@ -53,8 +53,6 @@ in the *unstable* branch of the Debian archive. * [[Critique]] - Analysis * [[Hurd_Hacking_Guide]] * [[Concepts]] -* Other resources - * [Docs at gnu.org](http://www.gnu.org/software/hurd/docs.html) # Using diff --git a/hurd/authentication.mdwn b/hurd/authentication.mdwn index cbb164c8..14144d8e 100644 --- a/hurd/authentication.mdwn +++ b/hurd/authentication.mdwn @@ -10,7 +10,7 @@ is included in the section entitled UIDs on the Hurd are separate from processes. A process has [[capabilities|capability]] designating so-called UID vectors that -are implemented by an [[auth]] server. This +are implemented by an [[translator/auth]] server. This makes them easily [[virtualizable|virtualization]]. When a process wishes to gain access to a resource provided by a third diff --git a/hurd/critique.mdwn b/hurd/critique.mdwn index 9770138e..dacd7bb8 100644 --- a/hurd/critique.mdwn +++ b/hurd/critique.mdwn @@ -8,8 +8,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]]."]]"""]] -[[NealWalfield]] and [[MarcusBrinkmann]] wrote a paper titled [*A Critique of -the GNU Hurd Multi-Server Operating +Neal Walfield and Marcus Brinkmann wrote a paper titled [*A Critique of +the GNU Hurd Multi-server Operating System*](http://walfield.org/papers/200707-walfield-critique-of-the-GNU-Hurd.pdf). This was published in ACM SIGOPS Operating Systems Review in July 2007. This is sometimes referred to as *the critique*. diff --git a/hurd/documentation.mdwn b/hurd/documentation.mdwn index bb37a8be..a8c3a988 100644 --- a/hurd/documentation.mdwn +++ b/hurd/documentation.mdwn @@ -1,4 +1,5 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[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 id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,10 +9,53 @@ 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]]."]]"""]] +# Introductory Material + * [[What_Is_the_GNU_Hurd]] * [[Advantages]] * [[FAQ]] - * + * [[*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. + + * [[*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. + +## External + + * [*Examining the Legendary HURD + Kernel*](http://www.informit.com/articles/printerfriendly.aspx?p=1180992), + an article by David Chisnall. + + Also covers a bit of GNU's and the Hurd's history, fundamental techniques + applied, comparisions to other systems. + + +# Development + + * *[[The_GNU_Hurd_Reference_Manual|reference_manual]]*. + + * The *[[Hurd_Hacking_Guide]]*, an introduction to GNU Hurd and Mach + programming by Wolfgang Jährling. + + * [*Manually Bootstrapping a + Translator*](http://walfield.org/pub/people/neal/papers/hurd-misc/manual-bootstrap.txt), + a text by Neal Walfield about how to *manually connect the translator to + the filesystem*. + + * [[*The_Authentication_Server*|auth]], the transcript of a talk about the + details of the authentication mechanisms in the Hurd by Wolfgang Jährling. + + * [*The Mach Paging Interface as Used by the + Hurd*](http://lists.gnu.org/archive/html/l4-hurd/2002-06/msg00001.html), a + text by Neal Walfield. + + * In the + [[Position_paper_*Improving_Usability_via_Access_Decomposition_and_Policy*|ng/position_paper]] + Neal Walfield and Marcus Brinkmann give an overview about how a future, + subsequent system may be architected. 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. +
  2. The user requests a reauthentication from the server
    3. +
  3. In this request the user will include a port
    4. +
  4. Both will hand this port to auth
    5. +
  5. The user uses auth_user_authenticate
    6. +
  6. The server uses auth_server_authenticate
    7. +
  7. The server also passes a new port to auth
    8. +
  8. auth matches these two requests
    9. +
  9. The user gets the new port from auth
    10. +
  10. The server learns about the IDs of the user
    11. +
  11. The user uses the new port for further communication
    12. +
+ +

+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 +

    +
  • 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/hurd_hacking_guide.mdwn b/hurd/hurd_hacking_guide.mdwn index 0cb96f32..2ef08f8a 100644 --- a/hurd/hurd_hacking_guide.mdwn +++ b/hurd/hurd_hacking_guide.mdwn @@ -8,6 +8,16 @@ 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]]."]]"""]] -Originally written by Wolfgang Jährling, the [Hurd Hacking Guide](http://www.gnu.org/software/hurd/hacking-guide/hhg.html) -contains an overview of some of the Hurd's features. -Also contains a tutorial on writing your own [[translator]]. +Originally written by Wolfgang Jährling, the *Hurd Hacking Guide* contains an +introduction to GNU Hurd and GNU Mach programming, an overview of some of the +Hurd's features. It also contains a tutorial on writing your own +[[translator]]. + + * [HTML version](http://www.gnu.org/software/hurd/hacking-guide/hhg.html) for + browsing online, + * [PostScript version](http://www.gnu.org/software/hurd/hacking-guide/hhg.ps) + [187kB, 37 pages], + * [ASCII text + version](http://www.gnu.org/software/hurd/hacking-guide/hhg.txt) [59kB], + * [Texinfo source](http://www.gnu.org/software/hurd/hacking-guide/hhg.texi) + [60kB]. diff --git a/hurd/ng/position_paper.mdwn b/hurd/ng/position_paper.mdwn index 3240a41d..e0f4bf60 100644 --- a/hurd/ng/position_paper.mdwn +++ b/hurd/ng/position_paper.mdwn @@ -8,7 +8,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]]."]]"""]] -[[NealWalfield]] and [[MarcusBrinkmann]] wrote a paper titled [*Improving -Usability via Access Decomposition and Policy -Refinement*](http://walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf). -This is sometimes referred to as *the position paper*. +Neal Walfield and Marcus Brinkmann wrote a paper titled [*Improving Usability +via Access Decomposition and Policy +Refinement*](http://walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf) +where they give an overview about how a future, subsequent system may be +architected. This is sometimes referred to as *the position paper*. diff --git a/hurd/reference_manual.mdwn b/hurd/reference_manual.mdwn new file mode 100644 index 00000000..5b5bff2d --- /dev/null +++ b/hurd/reference_manual.mdwn @@ -0,0 +1,18 @@ +[[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 +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]]."]]"""]] + +*The GNU Hurd Reference Manual* documents the architecture, the usage and the +programming of the GNU Hurd. At the moment, the manual is quite incomplete. + + * [HTML version](http://www.gnu.org/software/hurd/doc/hurd_toc.html) for + browsing online, + * [PostScript version](http://www.gnu.org/software/hurd/doc/hurd.ps) + [1020KiB, 91 pages]. diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index fc42e862..b0a6badd 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -94,7 +94,7 @@ about getting applications to work (if possible). * GNU [Coding Standards](http://www.gnu.org/prep/standards.html) * [[TestSuites]] - Posix, Perl, results feedback, etc. -* [docs and papers](http://www.gnu.org/software/hurd/docs.html) +* [[Documentation]] * [[SystemAPILimits]] * [[CodeAnnouncements]] - Recent coding projects related to the Hurd diff --git a/hurd/running/gnu/universal_package_manager.mdwn b/hurd/running/gnu/universal_package_manager.mdwn index 009b26bf..440f1122 100644 --- a/hurd/running/gnu/universal_package_manager.mdwn +++ b/hurd/running/gnu/universal_package_manager.mdwn @@ -127,7 +127,7 @@ OK. I will give you steps. i. Install a GNU System by folowing [[these_instructions|setup]] -ii. Read about GNU Design +ii. Read about GNU Design: [[Towards_a_New_Strategy_of_OS_Design|documentation/hurd-paper]] iii. Read about translators diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index b9952931..889f02a6 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -43,6 +43,7 @@ See some [[examples]] about how to use translators. # Existing Translators +* [[auth]] * [[pfinet]] * [[pflocal]] * [[hostmux]] diff --git a/hurd/translator/auth.mdwn b/hurd/translator/auth.mdwn new file mode 100644 index 00000000..73e7e025 --- /dev/null +++ b/hurd/translator/auth.mdwn @@ -0,0 +1,13 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +[[*The_Authentication_Server*|documentation/auth]], the transcript of a talk +about the details of the authentication mechanisms in the Hurd by Wolfgang +Jährling. diff --git a/microkernel/faq/multiserver_microkernel.mdwn b/microkernel/faq/multiserver_microkernel.mdwn index da690425..68ed332c 100644 --- a/microkernel/faq/multiserver_microkernel.mdwn +++ b/microkernel/faq/multiserver_microkernel.mdwn @@ -22,5 +22,5 @@ use, but now, because the server runs in user space as the user that started 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 on OS -design](http://www.gnu.org/software/hurd/hurd-paper.html). +Bushnell, BSG: +[[Towards_a_New_Strategy_of_OS_Design|hurd/documentation/hurd-paper]]. diff --git a/microkernel/mach/documentation.mdwn b/microkernel/mach/documentation.mdwn index fe870386..f6f2eb79 100644 --- a/microkernel/mach/documentation.mdwn +++ b/microkernel/mach/documentation.mdwn @@ -1,4 +1,5 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[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 id="license" text="Permission is granted to copy, distribute and/or modify this @@ -11,12 +12,27 @@ is included in the section entitled - [Meet Mach](http://www.stepwise.com/Articles/Technical/MeetMach.html), a summary of Mach's history and main concepts. + * *[[The_GNU_Mach_Reference_Manual|gnu_mach/reference_manual]]*. + - OSF's [Kernel Interface (ps)](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_interface.ps) [Kernel Interface (pdf)](http://shakthimaan.com/downloads/hurd/kernel_interface.pdf) - OSF's [Kernel Principles (ps)](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_principles.ps) [Kernel Principles (pdf)](http://shakthimaan.com/downloads/hurd/kernel_principles.pdf) + * [*The Unofficial GNU Mach IPC beginner's + guide*](http://hurdextras.nongnu.org/ipc_guide/), an easy introduction to + Inter Process Comunication in the Mach microkernel by Manuel Pavón + Valderrama. + + * [*Mach IPC without + MIG*](http://walfield.org/pub/people/neal/papers/hurd-misc/mach-ipc-without-mig.txt), + an exercise by Neal Walfield *to understand Mach IPC at one of its lowest + application levels*. + + * [*ipc-hello.c*](http://walfield.org/pub/people/neal/papers/hurd-misc/ipc-hello.c): + *Hello world à la mach ipc*. + - [Porting and Modifying the Mach 3.0 Microkernel](http://shakthimaan.com/downloads/hurd/Porting%20and%20Modifying%20the%20Mach%203.0%20Microkernel.pdf) - [An IO System for Mach](http://shakthimaan.com/downloads/hurd/An%20IO%20System%20for%20Mach.pdf) diff --git a/microkernel/mach/gnu_mach.mdwn b/microkernel/mach/gnu_mach.mdwn index cdb43a6f..19e1ea53 100644 --- a/microkernel/mach/gnu_mach.mdwn +++ b/microkernel/mach/gnu_mach.mdwn @@ -71,6 +71,7 @@ GNU/Hurd. # Development + * [[Reference_Manual]] * [[Building]] * [[Debugging]] * [[Boot_Trace]] diff --git a/microkernel/mach/gnu_mach/reference_manual.mdwn b/microkernel/mach/gnu_mach/reference_manual.mdwn new file mode 100644 index 00000000..225ab176 --- /dev/null +++ b/microkernel/mach/gnu_mach/reference_manual.mdwn @@ -0,0 +1,26 @@ +[[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 +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]]."]]"""]] + +*The GNU Mach Reference Manual* documents the architecture, the usage and the +programming of the GNU Mach microkernel. At the moment, the manual documents +the interface completely, but is not very useful as a tutorial or introduction +into the Mach architecture. + + * [HTML version](http://www.gnu.org/software/hurd/gnumach-doc/index.html) + for browsing online, + * [PostScript + version](http://www.gnu.org/software/hurd/gnumach-doc/mach.ps) [around + 900KiB], + * [gzipped PostScript + version](http://www.gnu.org/software/hurd/gnumach-doc/mach.ps.gz) + [around 300KiB], + * [PDF version](http://www.gnu.org/software/hurd/gnumach-doc/mach.pdf) + [around 700KiB]. diff --git a/microkernel/mach/mig/documentation.mdwn b/microkernel/mach/mig/documentation.mdwn index 8c977e55..a0bbbe14 100644 --- a/microkernel/mach/mig/documentation.mdwn +++ b/microkernel/mach/mig/documentation.mdwn @@ -66,8 +66,7 @@ pp. 67--77." # Further Relevant Documentation - * The [GNU Mach Reference - Manual](http://www.gnu.org/software/hurd/docs.html#manuals), espacially + * The [[GNU_Mach_Reference_Manual|gnu_mach/reference_manual]], espacially [Chapter 4, Inter Process Communication](http://www.gnu.org/software/hurd/gnumach-doc/Inter-Process-Communication.html), which, for example, explains how the `dealloc` flag -- cgit v1.2.3 From 27d13175ccd378e4d3531176276475dd84af5fed Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 19 Jan 2009 13:09:16 +0100 Subject: Move some pages, remove others that are either out of date or whose content is duplicated somewhere else. --- grub.mdwn | 72 ++++++++++++ grub/tftp_boot.mdwn | 42 +++++++ hurd/libstore.mdwn | 6 +- hurd/running/debian/CrossInstall.mdwn | 2 +- hurd/running/debian/after_install.mdwn | 2 +- hurd/running/distrib.mdwn | 4 +- hurd/running/qemu.mdwn | 2 +- hurd/translator.mdwn | 124 +-------------------- hurd/translator/wishlist_1.mdwn | 129 ++++++++++++++++++++++ hurd/translator/wishlist_2.mdwn | 189 ++++++++++++++++++++++++++++++++ unsorted/ABITransitionStatus.mdwn | 9 -- unsorted/AdvancedGrubUsage.mdwn | 42 ------- unsorted/AptConfOffline.mdwn | 28 ----- unsorted/BootProcess.mdwn | 36 ------ unsorted/GNOME.mdwn | 11 -- unsorted/GrubNotes.mdwn | 70 ------------ unsorted/InstallNotes.mdwn | 2 +- unsorted/InstallTips.mdwn | 2 +- unsorted/LuisBustamanteHurdPage.mdwn | 11 -- unsorted/NewMachHistory.mdwn | 27 ----- unsorted/OskitMach.mdwn | 2 +- unsorted/PppDaemon.mdwn | 6 - unsorted/TranslatorExamples.mdwn | 61 ----------- unsorted/TranslatorPages.mdwn | 51 --------- unsorted/TranslatorWishList.mdwn | 193 --------------------------------- 25 files changed, 449 insertions(+), 674 deletions(-) create mode 100644 grub.mdwn create mode 100644 grub/tftp_boot.mdwn create mode 100644 hurd/translator/wishlist_1.mdwn create mode 100644 hurd/translator/wishlist_2.mdwn delete mode 100644 unsorted/ABITransitionStatus.mdwn delete mode 100644 unsorted/AdvancedGrubUsage.mdwn delete mode 100644 unsorted/AptConfOffline.mdwn delete mode 100644 unsorted/BootProcess.mdwn delete mode 100644 unsorted/GNOME.mdwn delete mode 100644 unsorted/GrubNotes.mdwn delete mode 100644 unsorted/LuisBustamanteHurdPage.mdwn delete mode 100644 unsorted/NewMachHistory.mdwn delete mode 100644 unsorted/PppDaemon.mdwn delete mode 100644 unsorted/TranslatorExamples.mdwn delete mode 100644 unsorted/TranslatorPages.mdwn delete mode 100644 unsorted/TranslatorWishList.mdwn (limited to 'hurd/running/distrib.mdwn') diff --git a/grub.mdwn b/grub.mdwn new file mode 100644 index 00000000..a63ad181 --- /dev/null +++ b/grub.mdwn @@ -0,0 +1,72 @@ +# [GRUB](http://www.gnu.org/software/grub/) + +This section complements the [[InstallNotes]] with complete information regarding the GRUB boot loader. The syntax is different from Lilo's and so to scratch my own itch I'm creating this quick reference. The [Grub manual](http://www.gnu.org/software/grub/manual/grub.html) is another good reference. + +* update-grub is **Debian specific** and very nice. It will automatically create a /boot/grub/menu.lst file for the kernels in /boot/. It will also append a manually configured set for other partitions like the GNU/Hurd. +* grub-floppy is a **Debian specific** boot floppy creation script. +* mkbimage is a **Debian specific** boot disk image creation script. +* contains a Debian packaged makefile for creating CD & floppy images. Looks like it doesn't work properly. If you fix it, please send patches to the maintainer. +* essential GRUB commands & disk syntax + * root + * kernel + * module + * boot +* sample file + + title GNU/Linux + root (hd0,11) + kernel /boot/vmlinuz-2.4.18 root=/dev/hda12 ro + initrd /boot/initrd.img-2.4.18 + savedefault + + title GNU + root (hd0,15) + kernel /boot/oskit-mach root=device:hd0s16 -- + module /hurd/ext2fs.static \ + --multiboot-command-line=${kernel-command-line} \ + --host-priv-port=${host-port} \ + --device-master-port=${device-port} \ + --exec-server-task=${exec-task} \ + -T typed ${root} $(task-create) $(task-resume) + module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) + savedefault + + title DOS + rootnoverify (hd0,0) + chainloader +1 + +-- [[Main/GrantBow]] - 01 Oct 2002
-- [[Main/GrantBow]] - 22 Dec 2002 + +Another example, just as good, but a lot easier to read. The backslash at the end of each line is to "escape" the enter-key. So make sure there are no spaces following the backslashes! + + title GNU/Linux (Linux 2.4.18) + root (hd0,11) + kernel /boot/vmlinuz-2.4.18 root=/dev/hda12 ro + initrd /boot/initrd.img-2.4.18 + savedefault + + title GNUmach 1.3 + root (hd0,1) + kernel /boot/gnumach.gz root=device:hd0s2 + module /hurd/ext2fs.static --readonly \ + --multiboot-command-line=${kernel-command-line} \ + --host-priv-port=${host-port} \ + --device-master-port=${device-port} \ + --exec-server-task=${exec-task} \ + -T typed ${root} $(task-create) $(task-resume) + module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) + + title GNUmach 1.90 (CVS) + root (hd0,1) + kernel /boot/oskit-mach.gz root=device:hd0s2 -- + module /hurd/ext2fs.static --readonly \ + --multiboot-command-line=${kernel-command-line} \ + --host-priv-port=${host-port} \ + --device-master-port=${device-port} \ + --exec-server-task=${exec-task} \ + -T typed ${root} $(task-create) $(task-resume) + module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) + +Note the differences between GNUmach and OSKit-Mach. The latter **needs** the two dashes after the root specification! + +-- [[Main/JoachimNilsson]] - 09 Nov 2002 diff --git a/grub/tftp_boot.mdwn b/grub/tftp_boot.mdwn new file mode 100644 index 00000000..8e307b4f --- /dev/null +++ b/grub/tftp_boot.mdwn @@ -0,0 +1,42 @@ +## Advanced Grub + +[Grub](http://www.gnu.org/software/grub/) is a capable boot loader. This document is intended to capture some of its most interesting features and try to explain them a bit better than the texinfo documentation. + +### Debian Grub + +The Debian grub packages do not have networking enabled, so you have to apt-get the source, modify the debian/rules file to include --enable-network-card and dpkg-buildpackage to get a .deb of grub that supports TFTP. + +1. cd /usr/src/debian +2. apt-get source grub +3. cd grub-\_VERSION\_ +4. Add `--enable-tulip` or similar for your NIC to the `./configure` line of the `configure-stamp` target in the `debian/rules` file. +5. `dpkg-buildpackage` (as `root`) +6. `cd ..` +7. `dpkg -i grub*.deb` +8. cp /lib/grub/\_ARCH\_/\* /boot/grub/, e.g., _ARCH_ is `i386-pc` +9. Edit your `/boot/grub/menu.lst` (see below) +10. If your boot disk is `/dev/hda` ==> `grub-install (hd0)` + +### TFTP Boot + +Using trivial ftp to load a kernel is one of the best features of Grub. Here is how it is done. + +The `menu.lst` can look something like this: + + ifconfig --address=192.168.1.2 --server=192.168.1.1 + root (nd) + kernel /gnu/boot/oskit-mach.gz root=device:hd0s2 -- + root (hd0,1) + module /hurd/ext2fs.static \ + --multiboot-command-line=${kernel-command-line} \ + --host-priv-port=${host-port} \ + --device-master-port=${device-port} \ + --exec-server-task=${exec-task} \ + -T typed ${root} $(task-create) $(task-resume) + module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) + +**Note: Make sure there are NO spaces after the trailing backslases (\\)!!** + +For more information on GNUmach modules lines and installation setup, see [[Hurd/InstallNotes]] + +-- [[Main/JoachimNilsson]] - 13 Apr 2005 diff --git a/hurd/libstore.mdwn b/hurd/libstore.mdwn index ab649ebc..6b81691b 100644 --- a/hurd/libstore.mdwn +++ b/hurd/libstore.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 @@ -31,3 +32,6 @@ device node below `/dev`... At you can find some effort to make some crypto store. + +At , another package +can be found. diff --git a/hurd/running/debian/CrossInstall.mdwn b/hurd/running/debian/CrossInstall.mdwn index 9a07424e..1cde150c 100644 --- a/hurd/running/debian/CrossInstall.mdwn +++ b/hurd/running/debian/CrossInstall.mdwn @@ -34,7 +34,7 @@ Now the program starts retrieving all the necessary base packages. ### Preparing to reboot -When all packages have been extracted we must prepare [[GrubNotes]] for the Hurd when we reboot. Add the below entry to your `/boot/grub/menu.lst` file to boot the Hurd in single user mode (-s). Single user mode is needed only for the two reboots when running the Native Install. +When all packages have been extracted we must prepare [[GRUB]] for the Hurd when we reboot. Add the below entry to your `/boot/grub/menu.lst` file to boot the Hurd in single user mode (-s). Single user mode is needed only for the two reboots when running the Native Install. title GNU (kernel GNUmach 1.3) root (hd0,2) diff --git a/hurd/running/debian/after_install.mdwn b/hurd/running/debian/after_install.mdwn index b795fd2b..4cdcaea9 100644 --- a/hurd/running/debian/after_install.mdwn +++ b/hurd/running/debian/after_install.mdwn @@ -35,7 +35,7 @@ In order to use DHCP, you need to install the `dhcp-client` package and run `dhc You surely want grub to have a nice menu entry able to boot GNU, instead of typing a boring arcane. There are Debian-specific scripts that may help -you. See the [[GrubNotes]] for this. +you. See [[GRUB]]'s page for this. # Setup `apt-get` diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index b0a6badd..935c0c2d 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -30,8 +30,8 @@

-
[[GrubNotes]]
-
A quick reference and explanation. There's also a topic for the new [[GrubConf]].
+
[[GRUB]]
+
A quick reference and explanation.
diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index 7e4816f5..f13ef5c8 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -23,7 +23,7 @@ volunteers and may not have been tested extensively. # What is Needed to create a QEMU image 1. First thing is to install [[/QEMU]]. -2. A [grub](http://www.gnu.org/software/grub/) boot disk for the floppy disk image needed for booting. The [0\.97 version](ftp://alpha.gnu.org/gnu/grub/grub-0.97-i386-pc.ext2fs) works fine. I downloaded it an renamed to `floppy.img`. Alternatively, the Debian grub-disk package (up till version 0.97-28) is fine as well. +2. A [[grub]] boot disk for the floppy disk image needed for booting. The [0\.97 version](ftp://alpha.gnu.org/gnu/grub/grub-0.97-i386-pc.ext2fs) works fine. I downloaded it an renamed to `floppy.img`. Alternatively, the Debian grub-disk package (up till version 0.97-28) is fine as well. 3. You will need a [Debian/Hurd installation CD](http://www.debian.org/ports/hurd/hurd-cd). K16 works fine. diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index 0823f0db..0cfcc5fa 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -73,123 +73,7 @@ available. * ... -# Translator wishlist - -* [[devfs]] - -* FUSE(fuse.sourceforge.net/) compatilbility library. : just modify FUSE apps a and compile little to work as translator :-) - -* File Finder. (uses find, grep, a combination or a custom command (htdig, mp3 info) - * Files found will be available under one directory and then can be used like a normal directory - * usefull to generate Albums, Share only resulting files over the et, etc.. - * The filefinder can be scheduled or can be connected over some ipc like dbus to the VFS system if any to keep a watch for new files. - -* GNOKII, BitPim and openobex as translators - * grep through your SMSs! - * share your addressbook! - * "Attach" that funny SMS/MMS to your email. - * "svn commit" your joke collection :-D - -* Real Language Translator [[br]] - * cat /usr/translator/de-en/usr/share/doc/something.txt should take /usr/share/doc/something.txt , submit it to google's website and bring back results. - -* Mozilla Bookmarks = del.ici.ous - * Need more explanation ? ;-) - -* - * having a directory structure for a file can allow to "svn commit" the hnb document in a more "node-safe" manner, thus allowing multiple people to work on the same hnb document. - * This must be fairly easy as HNB can already export to XML and XMLfs already exists. - -* DavFS - * Just setup a 'WebDav share' as a directory. The implimentation of the protocol is already available in nautilus and konqueror. - -* Compiled form of your project - * you have your project in /somedir/project with source in /somedir/project/src .. /somedir/project/bin should always have the compiled version.. is it possible? - * The source has to have a MakeFile. - * creating /somedir/project/bin-somearch should aotomatically crosscompile - * Seems feasible for a small project. - -* Report generation FrameWork - an idea to be hugged by app developers..not kernel developers. - * You have financial data in some Spreadsheet like format in /yourFinance directory - * You add report templates to /yourFinance/repTemplates - * Once you save data in /yourFinance the next cat /yourFinance/reports/areportname will give you an uptodate report. - * This will be usefull for any purpose including serving by static page web servers, sharing over samba/nfs/ftp etc.! - * The advantage is any save to the spreadsheet will update the report.. not just from one software. - -* SVN (Subversion suite) - * like [[cvsfs]]. /svndir/version/version-no should automatically have subversion - * I think it is nice to write a generalised version control system framework library which will help in writing version control translators and other tools easily. - -* Flexi-acls - * First of all - Can this be done? : A translator bound to a directory must be able to access the contents of the directory which would have been accessible in the absence of the translator.. - * This will enable to wirte translators that can implement custom "Access Control Lists". Just imagine having advanced ACLs even if underlying FileSystem is dumb! Imagine changing the type of ACLs implemented with Just two commands - one to unattach previous translator and the next to attach a different ACL translator! The ACLs themselves may be stored in a different directory - -* The translator manager! - * Some translators will need to be inserted automatically - like for eg: hardware drivers .. - * Each hardware translator will pubish its capabilities. - * The "top" translator will query the capabilities of different hardware and match capabilities with the "slave" translators. That is it's only Job. - * The control is then handed over to the slave translator. - * The ranking not only looks who can handle the "most" capabilites of the hardware. If it finds that multiple translators can handle the same hardware, It will use other parameters to choose between them.. like may be the size in memory? The revision date? Stability (inferred from version number)? And to go to the extreme, the profiling data of the driver ;-P - * Advantage : The best driver wins! - -* An eg. Skip it if you understood the above :-): - * You have a driver that can handle VGA + SVGA + Super3d acceleration + Particle graphics + Works for nvidea card. - * You have a driver that can handle SVGA + VGA . - * You have a driver that can handle VGA. - * Case 1: Your card: A VGA card with some extra fonts.. - * First the VGA driver will be quireied .. ok can handle essential capability. - * Next SVGA driver: can handle but has extra module.. unnecassary weight . - * The Nvidia driver: can handle , but again unnecassary weight : ruled out. - * Winner : VGA driver: - * Case 2: Your card An SVGA card: - * First the VGA driver will be quireied .. ok can handle one essential capability. - * Next SVGA driver: can handle essential and one extra capability no extra weight.. - * The Nvidia driver: can handle , but unnecassary weight : ruled out. - * Winner : SVGA driver.. - * Case 3 : You have an VGA .. but no VGA driver .. then the SVGA driver would win. - -* Sound Server - * /ahsa - stands for Advanced HURD sound architecture :-) Just a temporary name .. for fun. - * /ahsa/out - directory wich will hold "plug"s where apllications come and join the server .. see below. - * /ahsa/out/mixer - main mixer - * /ahsa/out/nextfree - the file when "cat"ed gives the number of the next free plug - * /ahsa/plugins/ - info about available plugins - * /ahsa/out/[1..n]/ - dynamically generated directories for applications to plug on.. - * /ahsa/out/[1..n]/data this is where you should do a "cat somerawsoundfile>/ahsa/out/`cat /ahsa/nextfree`/data" - * /ahsa/out/[1..n]/plugins - the plugin stack .. volume is also a plugin.. - * /ahsa/out/[1..n]/plugins/[1..m]/ - echo "plugin param1 param2 param3" > /ahsa/out/[1..n]/plugins/`cat /ahsa/out/[1..n]/plugins/nextfree`/add - * /ahsa/out/[1..n]/plugins/[1..m]/params/{param1.. paramn} - * /ahsa/out/[1..n]/data.out - can be catted to get data processed through the server - * /ahsa/in - similar to /ahsa/out .. with except for an extra file to choose input devices. - * /ahsa/devs/{1..n} - devices detected .. can be dynamic .. there are usb soundcards and and midi devices. - * /ahsa/out/[1..n]/plugins/[1..m]/0/params/dev - * Dont get tempted for :/ahsa/out/[1..n]/params/{rate, channels, and other stuff} - * that goes into /ahsa/out/[1..n]/plugins/0/params if /ahsa/out/[1..n]/plugins/0/detected == "headerless audio" - * There are a lot more things I can continue about the "sound server" .. The Ideas simply dont seem to exhaust.. - * Some features/advantages - * set output's translator plugin as ordinary text -- have text to speech conversion done by sound server! - * Create and apply plugin presets by simply copying directories! - * Me getting dizzy thinking of the zillion more advantages. - * If you are really doing some ordinary output , all you need to do is "cat" data into next free "plug" and everything will be autodetected including the format of the data and sent to the final sound "merge"r - * Dizzy ... - -* /usr/share/menu !!!! extension for package management idea .. - * cat mymenuitem.menu >> /usr/share/menu/menu - * cat /usr/share/menu/debian/kde ... :-) - -* Spam/Malware Control - * /usr/antimalware/ - put your mail here.. it will automatically be scanned. when finished it will vanish from here .. - * /usr/antimalware/clean - ... and pop out from here - * /usr/antimalware/malware - or here. - -* NetDevice - * !JustImagine(tm)... settrans -ac /netdevices /hurd/netdevfs - [ host | net ] - * One can access device files remotely - * This could be acheived by allowing translators talk to one another over a network - * This will need translators to catch and handle ioctls (if there is such a thing in HURD). - * The device server which will listen to requests from the translators can be run even on a Linux machine!!! - * !JustImagine(tm)... accessing the crwriter/webcam on that GNU/Linux machine on the network using cdrecord of your local hurd machine! - * !JustImagine(tm)... running GNU/HURD on a minimalistic GNU/Linux(but with all the drivers) through a specially modified and optimised Qemu. The device server runs on the host machine, and the client translators access over the virtual network created by Qemu. You got most of the drivers for free! - -* Emacs File VFS - * I came to know from my Emacs loving friend that there are lots of VFS handlers in Emacs.. I was wondering if there can be translator which can tap into these Emacs VFS handlers. +# Translator Wishlists + + * [[wishlist_1]] + * [[wishlist_2]] diff --git a/hurd/translator/wishlist_1.mdwn b/hurd/translator/wishlist_1.mdwn new file mode 100644 index 00000000..6a4d591a --- /dev/null +++ b/hurd/translator/wishlist_1.mdwn @@ -0,0 +1,129 @@ +[[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 +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]]."]]"""]] + +* [[devfs]] + +* FUSE(fuse.sourceforge.net/) compatilbility library. : just modify FUSE apps a and compile little to work as translator :-) + +* File Finder. (uses find, grep, a combination or a custom command (htdig, mp3 info) + * Files found will be available under one directory and then can be used like a normal directory + * usefull to generate Albums, Share only resulting files over the et, etc.. + * The filefinder can be scheduled or can be connected over some ipc like dbus to the VFS system if any to keep a watch for new files. + +* GNOKII, BitPim and openobex as translators + * grep through your SMSs! + * share your addressbook! + * "Attach" that funny SMS/MMS to your email. + * "svn commit" your joke collection :-D + +* Real Language Translator [[br]] + * cat /usr/translator/de-en/usr/share/doc/something.txt should take /usr/share/doc/something.txt , submit it to google's website and bring back results. + +* Mozilla Bookmarks = del.ici.ous + * Need more explanation ? ;-) + +* + * having a directory structure for a file can allow to "svn commit" the hnb document in a more "node-safe" manner, thus allowing multiple people to work on the same hnb document. + * This must be fairly easy as HNB can already export to XML and XMLfs already exists. + +* DavFS + * Just setup a 'WebDav share' as a directory. The implimentation of the protocol is already available in nautilus and konqueror. + +* Compiled form of your project + * you have your project in /somedir/project with source in /somedir/project/src .. /somedir/project/bin should always have the compiled version.. is it possible? + * The source has to have a MakeFile. + * creating /somedir/project/bin-somearch should aotomatically crosscompile + * Seems feasible for a small project. + +* Report generation FrameWork - an idea to be hugged by app developers..not kernel developers. + * You have financial data in some Spreadsheet like format in /yourFinance directory + * You add report templates to /yourFinance/repTemplates + * Once you save data in /yourFinance the next cat /yourFinance/reports/areportname will give you an uptodate report. + * This will be usefull for any purpose including serving by static page web servers, sharing over samba/nfs/ftp etc.! + * The advantage is any save to the spreadsheet will update the report.. not just from one software. + +* SVN (Subversion suite) + * like [[cvsfs]]. /svndir/version/version-no should automatically have subversion + * I think it is nice to write a generalised version control system framework library which will help in writing version control translators and other tools easily. + +* Flexi-acls + * First of all - Can this be done? : A translator bound to a directory must be able to access the contents of the directory which would have been accessible in the absence of the translator.. + * This will enable to wirte translators that can implement custom "Access Control Lists". Just imagine having advanced ACLs even if underlying FileSystem is dumb! Imagine changing the type of ACLs implemented with Just two commands - one to unattach previous translator and the next to attach a different ACL translator! The ACLs themselves may be stored in a different directory + +* The translator manager! + * Some translators will need to be inserted automatically - like for eg: hardware drivers .. + * Each hardware translator will pubish its capabilities. + * The "top" translator will query the capabilities of different hardware and match capabilities with the "slave" translators. That is it's only Job. + * The control is then handed over to the slave translator. + * The ranking not only looks who can handle the "most" capabilites of the hardware. If it finds that multiple translators can handle the same hardware, It will use other parameters to choose between them.. like may be the size in memory? The revision date? Stability (inferred from version number)? And to go to the extreme, the profiling data of the driver ;-P + * Advantage : The best driver wins! + +* An eg. Skip it if you understood the above :-): + * You have a driver that can handle VGA + SVGA + Super3d acceleration + Particle graphics + Works for nvidea card. + * You have a driver that can handle SVGA + VGA . + * You have a driver that can handle VGA. + * Case 1: Your card: A VGA card with some extra fonts.. + * First the VGA driver will be quireied .. ok can handle essential capability. + * Next SVGA driver: can handle but has extra module.. unnecassary weight . + * The Nvidia driver: can handle , but again unnecassary weight : ruled out. + * Winner : VGA driver: + * Case 2: Your card An SVGA card: + * First the VGA driver will be quireied .. ok can handle one essential capability. + * Next SVGA driver: can handle essential and one extra capability no extra weight.. + * The Nvidia driver: can handle , but unnecassary weight : ruled out. + * Winner : SVGA driver.. + * Case 3 : You have an VGA .. but no VGA driver .. then the SVGA driver would win. + +* Sound Server + * /ahsa - stands for Advanced HURD sound architecture :-) Just a temporary name .. for fun. + * /ahsa/out - directory wich will hold "plug"s where apllications come and join the server .. see below. + * /ahsa/out/mixer - main mixer + * /ahsa/out/nextfree - the file when "cat"ed gives the number of the next free plug + * /ahsa/plugins/ - info about available plugins + * /ahsa/out/[1..n]/ - dynamically generated directories for applications to plug on.. + * /ahsa/out/[1..n]/data this is where you should do a "cat somerawsoundfile>/ahsa/out/`cat /ahsa/nextfree`/data" + * /ahsa/out/[1..n]/plugins - the plugin stack .. volume is also a plugin.. + * /ahsa/out/[1..n]/plugins/[1..m]/ - echo "plugin param1 param2 param3" > /ahsa/out/[1..n]/plugins/`cat /ahsa/out/[1..n]/plugins/nextfree`/add + * /ahsa/out/[1..n]/plugins/[1..m]/params/{param1.. paramn} + * /ahsa/out/[1..n]/data.out - can be catted to get data processed through the server + * /ahsa/in - similar to /ahsa/out .. with except for an extra file to choose input devices. + * /ahsa/devs/{1..n} - devices detected .. can be dynamic .. there are usb soundcards and and midi devices. + * /ahsa/out/[1..n]/plugins/[1..m]/0/params/dev + * Dont get tempted for :/ahsa/out/[1..n]/params/{rate, channels, and other stuff} + * that goes into /ahsa/out/[1..n]/plugins/0/params if /ahsa/out/[1..n]/plugins/0/detected == "headerless audio" + * There are a lot more things I can continue about the "sound server" .. The Ideas simply dont seem to exhaust.. + * Some features/advantages + * set output's translator plugin as ordinary text -- have text to speech conversion done by sound server! + * Create and apply plugin presets by simply copying directories! + * Me getting dizzy thinking of the zillion more advantages. + * If you are really doing some ordinary output , all you need to do is "cat" data into next free "plug" and everything will be autodetected including the format of the data and sent to the final sound "merge"r + * Dizzy ... + +* /usr/share/menu !!!! extension for package management idea .. + * cat mymenuitem.menu >> /usr/share/menu/menu + * cat /usr/share/menu/debian/kde ... :-) + +* Spam/Malware Control + * /usr/antimalware/ - put your mail here.. it will automatically be scanned. when finished it will vanish from here .. + * /usr/antimalware/clean - ... and pop out from here + * /usr/antimalware/malware - or here. + +* NetDevice + * !JustImagine(tm)... settrans -ac /netdevices /hurd/netdevfs - [ host | net ] + * One can access device files remotely + * This could be acheived by allowing translators talk to one another over a network + * This will need translators to catch and handle ioctls (if there is such a thing in HURD). + * The device server which will listen to requests from the translators can be run even on a Linux machine!!! + * !JustImagine(tm)... accessing the crwriter/webcam on that GNU/Linux machine on the network using cdrecord of your local hurd machine! + * !JustImagine(tm)... running GNU/HURD on a minimalistic GNU/Linux(but with all the drivers) through a specially modified and optimised Qemu. The device server runs on the host machine, and the client translators access over the virtual network created by Qemu. You got most of the drivers for free! + +* Emacs File VFS + * I came to know from my Emacs loving friend that there are lots of VFS handlers in Emacs.. I was wondering if there can be translator which can tap into these Emacs VFS handlers. diff --git a/hurd/translator/wishlist_2.mdwn b/hurd/translator/wishlist_2.mdwn new file mode 100644 index 00000000..3ea68999 --- /dev/null +++ b/hurd/translator/wishlist_2.mdwn @@ -0,0 +1,189 @@ +## Introduction + +The idea behind file system translators is a powerful concept which hasn't recieved much attention in the mainstream computing world. So here is a list of interesting translators I've been able to dream up. I'm sure there are many more ideas floating around out there, so add them to the list! + +The [ferris project](http://witme.sourceforge.net/libferris.web/features.html) has some great ideas and code in the area of userspace dynamic filesystems, as has the [FUSE project](http://fuse.sourceforge.net/). + +## Audio\_cdfs + +A translator which produces a directory of \*.wav files when you have an audio CD in the drive. + +## Ogg + +This translator could be a sub-directory of the Audio\_cdfs translator and it would translate the \*.wav files into Ogg Vorbis/MP3 format. + +## CDDB + +Of course it would be a lot nicer if the above two translators didn't name their files something worthless like track001.ogg. So we would want a translator which would hook up with a database on the web and produce meaningful file names. + +## Crypto + +A cryptographic/steganographic seem like a nice match with the concept of user-land file systems. I like the idea of something like `settrans -a /secure stegfs --mpeg file001.mpg` + +## Revision control + +All of the empty space on your drive is now being wasted. Why not have a revision control translator which tracks changes to your documents? See also [this guy](http://www.linuxjournal.com/article.php?sid=5976). And then you'd do something like `cd /time-machine/2003/sept/14/` to see what your system looked like on the 14th of septempber 2003. + +## CVSFS + +See [cvsFS for Linux](http://cvsfs.sourceforge.net/). This provides a package which presents the CVS contents as mountable file system. It allows to view the versioned files as like they were ordinary files on a disk. There is also a possibility to check in/out some files for editing. A read-only version has been written by Stefan Siegl and is available at [Berlios](http://cvs.berlios.de/cgi-bin/viewcvs.cgi/cvsfs4hurd/cvsfs/). + +## tar and gzip + +Rumor has it that they are on the way. Actually, a tar + gzip/bzip2 translator does exist (although it hasn't been used much...) : see [the Hurdextras project](http://savannah.nongnu.org/projects/hurdextras/) on Savannah. + +## ROM + +How about a translator which makes it look like you can write to read only media (like CDs), or change files which I don't have permission to change. This translator would make it seem like you could copy files to places where you normally couldn't. Think about combining this translator with the ftp translator and the tar and gzip translators. (cd /ftp/gnu.org/gnome.tar.gz/writes\_allowed; make install). It could be that unionfs does this very thing. + +## Super\_FIFO + +It's like a named pipe which is smart enough to start a process everytime something new tries to read from it. For example, let's say I have a script that reads in a JPEG image and spits out a smaller thumbnail \*.jpg to STDOUT. With a standard fifo (`mknod -p fifo`) this would almost works (`script big.jpg > fifo`). But what if there are two processes trying to read the fifo at once? Ick. And of course the standard way only works once without rerunning the command. I'm not quite sure what the syntax should look like, but I'm sure someone out there has a great idea waiting to happen. + +## Perl + +Perl is a wonderful language for hacking together something useful in a short amount of time. No concept is complete without being able to use it in a perl one-liner. And that goes for Hurd translators too. Right? + + #!/usr/bin/perl + use Hurd::translator; + + #file named "two" can produce an endless supply of twos, etc. (a la /dev/zero) + my $i=0; + for $filename ([zero one two three four]) + { + $libtrivfsread_codehash{$filename}= + sub{ $num_bytes=shift; my $data=$i; return chr($data) x $num_bytes; }; + #that's a hash of references to closures + $i++; + } + translator_startup(); + +A Perl translator has been started by [John Edwin Tobey](http://john-edwin-tobey.org/Hurd/) (pith). + +## Source code + +Here's a crazy thought. How about a translator for source code. You have a C source file like `hello.c` which is your normal everyday file. But there's a translator sitting underneath, so when you `cd hello.c` you get a directory with files like `main()` which represent the subroutines in `hello.c`. And of course you should be able to edit/remove those and have it modify the original source. + +## Libraries + +Here's an [idea](http://www.circlemud.org/~jelson/software/fusd/docs/node13.html) from the people making [userspace drivers in Linux](http://www.circlemud.org/~jelson/software/fusd/): + +* "One particularly interesting application of FUSD that we've found very useful is as a way to let regular user-space libraries export device file APIs. For example, imagine you had a library which factored large composite numbers. Typically, it might have a C interface--say, a function called `int *factorize(int bignum)`. With FUSD, it's possible to create a device file interface--say, a device called `/dev/factorize` to which clients can `write(2)` a big number, then `read(2)` back its factors. + +* This may sound strange, but device file APIs have at least three advantages over a typical library API. First, it becomes much more language independent--any language that can make system calls can access the factorization library. Second, the factorization code is running in a different address space; if it crashes, it won't crash or corrupt the caller. Third, and most interestingly, it is possible to use `select(2)` to wait for the factorization to complete. `select(2)` would make it easy for a client to factor a large number while remaining responsive to other events that might happen in the meantime. In other words, FUSD allows normal user-space libraries to integrate seamlessly with UNIX's existing, POSIX-standard event notification interface: `select(2)`." + +## Mail + +Am I off my rocker, or does an IMAP/POP translator sound like a good idea? It would make your remote mail servers look like local ones. Or what about a translator that makes a mbox format mail spool look like a directory. Can anyone think of a good use for an SMTP translator? + +## UUEncode + +How about a UUEncode translator for those places you can only store ASCII. Combine this with a NNTP translator and store your data in someone's Usenet archive. Or since, (as far as I know), there are no size limitations on file names in the Hurd, why not have a filesystem translator whose underlying store is a file name. (Now ls becomes cat). + +## Computation + +This is from the revenge of the command-line department. Make a directory translator whose contents are a result of the computation specified in the directory name. Here's an example... + + $ settrans -a /comp /hurd/computationfs + $ cd "/comp/3+4" + $ ls -l + total 0 + -rw-r--r-- 1 nobody users 0 Oct 16 11:41 7 + $ + $ cd "/comp/sqrt(2)" + $ ls -l + total 0 + -rw-r--r-- 1 nobody users 0 Oct 16 11:42 1.4142135623731 + $ + +...etc. Now think about your favorite GUI HTML editor and using File->Open on the following directory name, ``"/comp/for i in $( find / -name *.html ); do ln -s $i `basename $i`;done"`` Which would produce a directory listing with soft links to all of the \*.html files on your system. You could have all of the comforts of the shell from within that little File->Open dialog box. + +## Other + +Just found Wolfgang J�hrling's translator [wishlist](http://www.8ung.at/shell/trans.html). + +## Bochs + +A translator which works with [Bochs](http://bochs.sourceforge.net/) disk images would be nice. + +## Rollover + +A translator that uses a circular buffer to store log files. The translated node only contains the last N (mega,kilo)bytes. + +## Birthday + +A translator that provides an interface into the birthday program. + +You can cat your calendar, eg. bd/calendar/today bd/calendar/this-week or bd/calendar/this-month. + +And you could write new events into files located in bd/events/DATE/event-name. + +DATE is of the format the birthday expects DD/MM/YYYY. + +The contents of the file are any or none of the following birthday options: ann (An anniversary), bd (A birthday), ev (Some other event), wN (Warn N days in advance of date), toDATE (Event lasts until this DATE), forDAYS (Event runs for DAYS). + +You can optionally just edit the bd/birthdays file if you want to edit the configuration file by hand. It might make sense to write changes from bd/birthdays into ~/.birthdays. + + $ settrans -c bd /hurd/birthday -f ~/.birthdays + $ ls bd/ + birthdays calendar events + $ find bd -print + bd + bd/calendar + bd/calendar/daily + bd/calendar/this-week + bd/calendar/this-month + bd/events + bd/birthdays + $ + +## LVM + +A translator to access block devices from Linux's [Logical Volume Management](http://www.tldp.org/HOWTO/LVM-HOWTO/) would be an useful addition. + + # settrans -cap /dev/VolumeGroup0 /hurd/lvm /dev/PhysicalVolume0 /dev/PhysicalVolume1 ... + # ls /dev/VolumeGroup0/ + home + var + # settrans -cap /home /hurd/ext2fs /dev/VolumeGroup0/home + # settrans -cap /var /hurd/ext2fs /dev/VolumeGroup0/var + +Probably both [LVM2](http://sourceware.org/lvm2/) and the [Device-mapper](http://sourceware.org/dm/) need to be ported. + +## bridging translator + +A [bridging](http://bridge.sourceforge.net/faq.html) translator could improve the Hurd's networking facilities. + + # settrans -cap /dev/br0 /hurd/bridge -i eth0 -i eth1 ... + # settrans -cap /servers/socket/2 /hurd/pfinet -i /dev/br0 -a ... -g ... -m ... + +Perhaps Linux's bridging code and [utilities](http://bridge.sourceforge.net/) can be ported (or glued in) or code from one of the BSDs. + +## SSH translator + +Presenting remote file systems through SSH similar to what gnome-vfs does. + +## SMB translator + +Presenting remote file systems through Samba similar to what gnome-vfs does. Guiseppe Scrivano has worked on this and smbfs is available at [hurdextras](http://savannah.nongnu.org/cgi-bin/viewcvs/hurdextras/smbfs/). + +## Crontab translator + +Presenting a user's crontab in a filesystem where cron entries are files. + +## globlink + +Firmlink to a file according to a filename matching pattern. When a file goes away, the next file that is matched is automatically linked to. + + $ settrans -ac libfoo.so /hurd/globlink '/lib/libfoo*' + +## alphabetfs + +Organize a large group of files by their first letter. Present one subdirectory for each letter in the alphabet. + +## fsysoptsctl + +Send an fsysopts command to a set of translators. When you have a directory full of translators and you want to send each of them the same runtime option, this translator can do it for you. + + $ settrans -ac all /hurd/fsysoptsctl '/tmp/mystuff/*' + $ fsysopts all --update diff --git a/unsorted/ABITransitionStatus.mdwn b/unsorted/ABITransitionStatus.mdwn deleted file mode 100644 index 123e8f8c..00000000 --- a/unsorted/ABITransitionStatus.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -Several transitions have occured recently. - -* [ABI Switch](http://lists.debian.org/debian-hurd/2002/debian-hurd-200204/msg00096.html) from April 17, 2002 - -* [Phase I accomplished](http://lists.debian.org/debian-hurd/2002/debian-hurd-200204/msg00157.html) from April 26, 2002 - -* [status of the ABI transition](http://lists.debian.org/debian-hurd/2002/debian-hurd-200205/msg00242.html) from May 15, 2002 - --- [[Main/GrantBow]] - 15 May 2002 diff --git a/unsorted/AdvancedGrubUsage.mdwn b/unsorted/AdvancedGrubUsage.mdwn deleted file mode 100644 index 8e307b4f..00000000 --- a/unsorted/AdvancedGrubUsage.mdwn +++ /dev/null @@ -1,42 +0,0 @@ -## Advanced Grub - -[Grub](http://www.gnu.org/software/grub/) is a capable boot loader. This document is intended to capture some of its most interesting features and try to explain them a bit better than the texinfo documentation. - -### Debian Grub - -The Debian grub packages do not have networking enabled, so you have to apt-get the source, modify the debian/rules file to include --enable-network-card and dpkg-buildpackage to get a .deb of grub that supports TFTP. - -1. cd /usr/src/debian -2. apt-get source grub -3. cd grub-\_VERSION\_ -4. Add `--enable-tulip` or similar for your NIC to the `./configure` line of the `configure-stamp` target in the `debian/rules` file. -5. `dpkg-buildpackage` (as `root`) -6. `cd ..` -7. `dpkg -i grub*.deb` -8. cp /lib/grub/\_ARCH\_/\* /boot/grub/, e.g., _ARCH_ is `i386-pc` -9. Edit your `/boot/grub/menu.lst` (see below) -10. If your boot disk is `/dev/hda` ==> `grub-install (hd0)` - -### TFTP Boot - -Using trivial ftp to load a kernel is one of the best features of Grub. Here is how it is done. - -The `menu.lst` can look something like this: - - ifconfig --address=192.168.1.2 --server=192.168.1.1 - root (nd) - kernel /gnu/boot/oskit-mach.gz root=device:hd0s2 -- - root (hd0,1) - module /hurd/ext2fs.static \ - --multiboot-command-line=${kernel-command-line} \ - --host-priv-port=${host-port} \ - --device-master-port=${device-port} \ - --exec-server-task=${exec-task} \ - -T typed ${root} $(task-create) $(task-resume) - module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) - -**Note: Make sure there are NO spaces after the trailing backslases (\\)!!** - -For more information on GNUmach modules lines and installation setup, see [[Hurd/InstallNotes]] - --- [[Main/JoachimNilsson]] - 13 Apr 2005 diff --git a/unsorted/AptConfOffline.mdwn b/unsorted/AptConfOffline.mdwn deleted file mode 100644 index c4cc85be..00000000 --- a/unsorted/AptConfOffline.mdwn +++ /dev/null @@ -1,28 +0,0 @@ - APT - { - /* This file belongs in Debian GNU/Hurd's /etc/apt/apt.conf.offline - and will be used when running Debian GNU/Linux. This is only - required when the GNU/Hurd does not have network access. */ - - Architecture "hurd-i386"; - - Get::Download-Only "true"; - }; - - Dir - { - /* Use the disc for state information and redirect the status file from - the /var/lib/dpkg default - assumes Debian GNU/Hurd mounted on /misc/hurd and /var mounted underneath this if necessary */ - - // State::lists should be here, the lists subdirectory. - State "/misc/hurd/var/lib/apt/"; - State::status "/misc/hurd/var/lib/dpkg/status"; - - // Binary caches will be stored locally - Cache::archives "/misc/hurd/var/cache/apt/archives/"; - Cache "/tmp/"; - - // Location of the source list. - Etc "/misc/hurd/etc/apt/"; - }; diff --git a/unsorted/BootProcess.mdwn b/unsorted/BootProcess.mdwn deleted file mode 100644 index 17f7bba7..00000000 --- a/unsorted/BootProcess.mdwn +++ /dev/null @@ -1,36 +0,0 @@ -Describes the GNU/Hurd boot process. - -# Bootloader - -[GRUB](http://www.gnu.org/software/grub/) (GRand Unified Bootloader) is the default (and as far as I know the only supported ) bootloader for GNU/Hurd and is the initial process. - -GRUB can be used for booting multiple Operating Systems on a given machine. Device naming convention for GRUB is different than that of the Hurd. Where the first partition on the primary IDE drive in GNU/Hurd is hd0s1, in GRUB it is (hd0,0). In the case of GNU/Hurd, the first thing that GRUB loads is kernel image. - -Here is a copy of GNU/Hurd multi-user entry from menu.lst. The first two lines are primarily informational and are what get displayed on the GRUB boot menu. - - # Entry 2: 1st partition on first HDD - title GNU/Hurd (IDE 1st partition - hd0s1 multi-user) - root (hd0,0) - kernel /boot/gnumach.gz root=device:hd0s1 - module /hurd/ext2fs.static --multiboot-command-line=${kernel-command-line} \ - --host-priv-port=${host-port} \ - --device-master-port=${device-port} \ - --exec-server-task=${exec-task} \ - -T typed ${root} $(task-create) $(task-resume) - module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) - -**_N.B. the escaped new lines above should end in only a back slash, no spaces!_** - -The line "root (hd0,0)" tells GRUB where to look for the root partition. Notice that the (hd0,0) is using GRUB naming conventions. - -The next line loads the gnumach kernel image itself. Notice here the root=device:hd0s1 argument. This is now using GNU/Hurd device naming convention, telling the Hurd where the root partition exists. - ----- - --- [[Main/BarryDeFreese]] - 29 May 2003 - -Minor formatting and edit check. - -On a side note. The actual description of the GNU/Hurd boot process is a good idea but keeping duplicated information to a bare minimum must be the guide line for a "book" like this. See other topics for more information on Grub configuration for instance. - --- [[Main/JoachimNilsson]] - 30 May 2003 diff --git a/unsorted/GNOME.mdwn b/unsorted/GNOME.mdwn deleted file mode 100644 index 1dbef091..00000000 --- a/unsorted/GNOME.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -![gnome-hurd.png](http://people.debian.org/~mbanck/media/gnome-hurd.png) - -GNOME can now be ported with the new [[Pthreads]], but is still being worked on.The packages are at - -deb ./ - -The caveats: - -Some applications are not yet built, not even all the ones from gnome-core. 'apt-get install gnome-applets gnome-control-center gnome-icon-theme gnome-panel gnome-session metacity nautilus scrollkeeper' (along with the above APT source) should get you started. - -See also: [[Xfree86]]. diff --git a/unsorted/GrubNotes.mdwn b/unsorted/GrubNotes.mdwn deleted file mode 100644 index b0b1fdf5..00000000 --- a/unsorted/GrubNotes.mdwn +++ /dev/null @@ -1,70 +0,0 @@ -This section complements the [[InstallNotes]] with complete information regarding the GRUB boot loader. The syntax is different from Lilo's and so to scratch my own itch I'm creating this quick reference. The [Grub manual](http://www.gnu.org/software/grub/manual/grub.html) is another good reference. - -* update-grub is **Debian specific** and very nice. It will automatically create a /boot/grub/menu.lst file for the kernels in /boot/. It will also append a manually configured set for other partitions like the GNU/Hurd. -* grub-floppy is a **Debian specific** boot floppy creation script. -* mkbimage is a **Debian specific** boot disk image creation script. -* contains a Debian packaged makefile for creating CD & floppy images. Looks like it doesn't work properly. If you fix it, please send patches to the maintainer. -* essential GRUB commands & disk syntax - * root - * kernel - * module - * boot -* sample file - - title GNU/Linux - root (hd0,11) - kernel /boot/vmlinuz-2.4.18 root=/dev/hda12 ro - initrd /boot/initrd.img-2.4.18 - savedefault - - title GNU - root (hd0,15) - kernel /boot/oskit-mach root=device:hd0s16 -- - module /hurd/ext2fs.static \ - --multiboot-command-line=${kernel-command-line} \ - --host-priv-port=${host-port} \ - --device-master-port=${device-port} \ - --exec-server-task=${exec-task} \ - -T typed ${root} $(task-create) $(task-resume) - module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) - savedefault - - title DOS - rootnoverify (hd0,0) - chainloader +1 - --- [[Main/GrantBow]] - 01 Oct 2002
-- [[Main/GrantBow]] - 22 Dec 2002 - -Another example, just as good, but a lot easier to read. The backslash at the end of each line is to "escape" the enter-key. So make sure there are no spaces following the backslashes! - - title GNU/Linux (Linux 2.4.18) - root (hd0,11) - kernel /boot/vmlinuz-2.4.18 root=/dev/hda12 ro - initrd /boot/initrd.img-2.4.18 - savedefault - - title GNUmach 1.3 - root (hd0,1) - kernel /boot/gnumach.gz root=device:hd0s2 - module /hurd/ext2fs.static --readonly \ - --multiboot-command-line=${kernel-command-line} \ - --host-priv-port=${host-port} \ - --device-master-port=${device-port} \ - --exec-server-task=${exec-task} \ - -T typed ${root} $(task-create) $(task-resume) - module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) - - title GNUmach 1.90 (CVS) - root (hd0,1) - kernel /boot/oskit-mach.gz root=device:hd0s2 -- - module /hurd/ext2fs.static --readonly \ - --multiboot-command-line=${kernel-command-line} \ - --host-priv-port=${host-port} \ - --device-master-port=${device-port} \ - --exec-server-task=${exec-task} \ - -T typed ${root} $(task-create) $(task-resume) - module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) - -Note the differences between GNUmach and OSKit-Mach. The latter **needs** the two dashes after the root specification! - --- [[Main/JoachimNilsson]] - 09 Nov 2002 diff --git a/unsorted/InstallNotes.mdwn b/unsorted/InstallNotes.mdwn index 49dcd53d..1cdfca9c 100644 --- a/unsorted/InstallNotes.mdwn +++ b/unsorted/InstallNotes.mdwn @@ -47,7 +47,7 @@ You can always install GRUB onto your hard drive at a later date. For instructions on using GRUB, see either the info documentation or the quick reference notes on this wiki: -* [[Distrib/GrubNotes]] - quick reference +* [[GRUB]] - quick reference ## 4. Cross Install - Cross Installing GNU diff --git a/unsorted/InstallTips.mdwn b/unsorted/InstallTips.mdwn index a735fbf7..c9f5bdc2 100644 --- a/unsorted/InstallTips.mdwn +++ b/unsorted/InstallTips.mdwn @@ -60,7 +60,7 @@ now mount the floppy and copy the files to your partition you may also wish to put my menu.lst file in your grub directory which can be obtained here you will need to edit it to include a -s at the end of the line starting with kernel. Be sure modify the partition numbers, my system is using the third partition of the second harddrive. -More detailed samples for grub config files can be found at the [[GrubNotes]] +More detailed samples for GRUB config files can be found at the [[GRUB]] page. To install grub reboot using the grub floppy and issue: diff --git a/unsorted/LuisBustamanteHurdPage.mdwn b/unsorted/LuisBustamanteHurdPage.mdwn deleted file mode 100644 index abbf1531..00000000 --- a/unsorted/LuisBustamanteHurdPage.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -Nothing much to see right now, I'll add some stuff I'm working in the near future! :) - -Cheers, - --- [[Main/LuisBustamante]] - 16 May 2002 - -After making some trivial/incorrect patches (thanks Neal :) for building um-pppd with gcc 3.0.4 in Debian (see [\#147085](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=147085&repeatmerged=yes)) this weekend I'll finally give it a try, I got an external modem... anyway serial drivers seem to be broken in GNUmach iirc, I won't get much more than 300b/s :). - -Keep Hurding! - --- [[Main/LuisBustamante]] - 17 May 2002 diff --git a/unsorted/NewMachHistory.mdwn b/unsorted/NewMachHistory.mdwn deleted file mode 100644 index 562d1cac..00000000 --- a/unsorted/NewMachHistory.mdwn +++ /dev/null @@ -1,27 +0,0 @@ -# Table of Contents - -%TOC% - -# Early beginnings - -GNUMach is based on Mach4 from University of Utah, which in turn is based on Mach3 from Carnegie-Mellon University. The last release of Mach4 was the [UK22 release](http://www.cs.utah.edu/flux/mach4-i386/html/mach4-UK22.html). - -The oskit-mach version of GNU Mach was presented in November 1999 by Roland McGrath. The purpose of the port was to get better hardware support through new drivers and platform code available in the OSKit. - -On May 27 2002, after the Gnumach 1.3 release, Roland McGrath merged OSKit-Mach onto the HEAD of CVS making it the Gnumach 2.x mainline. - -# Status of the project - -GNU Mach 1.3 was released in May 2002, and features advanced boot script support, support for large disks (>= 10GB) and an improved console. - -GNU Mach is used as the default microkernel in the GNU/Hurd system. It is compatible with other popular Mach distributions. The device drivers for block devices and network cards are taken from Linux 2.0.x kernel versions, and so a broad range of common hardware is supported. - -However, the Linux device drivers have been improved greatly since the 2.0.x version, and a new version of GNU Mach based on the OSKit library is being worked on, which uses newer drivers and in general has cleaner machine specific support code. - ----- - -Copyright (C) 2001 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. - --- [[Main/JoachimNilsson]] - 24 Oct 2002 diff --git a/unsorted/OskitMach.mdwn b/unsorted/OskitMach.mdwn index c28f2d89..b5b92d68 100644 --- a/unsorted/OskitMach.mdwn +++ b/unsorted/OskitMach.mdwn @@ -37,7 +37,7 @@ First you need to get the latest OSKit release and, preferrably, the latest CVS ## Starting -You start Oskit-Mach almost the same way as the old 1.x version of GNUmach. Using [[Hurd/GrubNotes]] an entry can look like this: +You start Oskit-Mach almost the same way as the old 1.x version of GNUmach. Using [[GRUB]] an entry can look like this: title GNUmach 1.90 (CVS) root (hd0,1) diff --git a/unsorted/PppDaemon.mdwn b/unsorted/PppDaemon.mdwn deleted file mode 100644 index f667d449..00000000 --- a/unsorted/PppDaemon.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -There is no PPP solution present for the Hurd. - -* Filed Debian [um-ppp bug](http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no\&bug=147085) -* Clemmitt [asked about um-pppd](http://mail.gnu.org/pipermail/help-hurd/2002-October/006664.html) in this thread of 9 posts beginning Oct 10, 2002. - --- [[Main/GrantBow]] - 20 Oct 2002 diff --git a/unsorted/TranslatorExamples.mdwn b/unsorted/TranslatorExamples.mdwn deleted file mode 100644 index 0c2e5741..00000000 --- a/unsorted/TranslatorExamples.mdwn +++ /dev/null @@ -1,61 +0,0 @@ -## Introduction - -Translators are probably the most known feature of the Hurd, the first thing you should show when doing a demo. - -## run - -Couldn't manage to compile it, but allows you to do nice things with eg. fortune. - -## ftpfs - -hurd:~# settrans -c ftp /hurd/ftpfs 128.101.80.131:/ - -hurd:~# cd ftp - -hurd:~/ftp# ls - -debian debian-archive lost+found - -hurd:~/ftp# cd debian - -hurd:~/ftp/debian# ls - -README README.mirrors.txt doc ls-lR.patch.gz - -README.CD-manufacture README.non-US indices pool - -README.html README.pgp ls-lR project - -README.mirrors.html dists ls-lR.gz tools - -hurd:~/ftp/debian# cp README ~ - -hurd:~/ftp/debian# - -You have to specify the server address with its IP, or your computer will buy a farm or something. - -## ftpfs and hostmux - -currently (28/02/2004) not working, but should be. - -hurd:~# settrans -c ftp /hurd/hostmux /hurd/ftpfs / - -hurd:~# cd ftp - -hurd:~/ftp# cd ftp.debian.org - --bash: cd: ftp.debian.org: Computer bought the farm - -hurd:~/ftp# host ftp.debian.org - -ftp.debian.org A 128.101.80.131 - -ftp.debian.org A 208.185.25.38 - -hurd:~/ftp# cd 128.101.80.131 - --bash: cd: 128.101.80.131: Computer bought the farm - -## Articles about translators - -* [The GNU Hurd - Translators by Gael le Mignot](http://kilobug.free.fr/hurd/pres-en/html/node8.html) diff --git a/unsorted/TranslatorPages.mdwn b/unsorted/TranslatorPages.mdwn deleted file mode 100644 index 8e954521..00000000 --- a/unsorted/TranslatorPages.mdwn +++ /dev/null @@ -1,51 +0,0 @@ -
-
[[NeighborHurd]]
-
A concept possible with microkernels.
-
[[InteractiveTranslators]]
-
Translators that interact with user
-
[[TranslatorExamples]]
-
Examples of what you can do with translators
-
[[TranslatorWishList]]
-
Interesting file translator ideas
-
- -Here are the translators that currently exist: - -* [[AuthTranslator]] -* [[CrashTranslator]] -* [[ExecTranslator]] -* [[ExtTwofsTranslator]] - (actually named ext2fs) Ext2 filesystems, also ext2fs.static -* [[FifoTranslator]] - also [[NewfifoTranslator]] (actually named new-fifo) -* [[FirmlinkTranslator]] -* [[FtpfsTranslator]] - ftp as a filesystem -* [[FwdTranslator]] -* [[HelloTranslator]] - also [[HellomtTranslator]] (actually named hello-mt) -* [[HostmuxTranslator]] -* [[IfsockTranslator]] -* [[InitTranslator]] -* [[IsofsTranslator]] -* [[KbdTranslator]] -* [[MachdefpagerTranslator]] - (actually named mach-defpager) -* [[hurd/translator/magic]] -* [[MouseTranslator]] -* [[NfsTranslator]] -* [[NullTranslator]] -* [[PasswordTranslator]] -* [[PfinetTranslator]] - also [[PflocalTranslator]] -* [[ProcTranslator]] -* [[SmbfsTranslator]] -* [[StoreioTranslator]] -* [[StreamioTranslator]] -* [[SymlinkTranslator]] -* [[TermTranslator]] -* [[TmpfsTranslator]] -* [[UfsTranslator]] - also ufs.static -* [[UsermuxTranslator]] - -Here are the contributed translators: - -* [[CryptTranslator]] - - -This is an old list and might need some updating, please check if you have a Hurd system that this list is accurate. - --- [[Main/GrantBow]] - 03 Mar 2004 diff --git a/unsorted/TranslatorWishList.mdwn b/unsorted/TranslatorWishList.mdwn deleted file mode 100644 index 38bd87d9..00000000 --- a/unsorted/TranslatorWishList.mdwn +++ /dev/null @@ -1,193 +0,0 @@ -## Introduction - -The idea behind file system translators is a powerful concept which hasn't recieved much attention in the mainstream computing world. So here is a list of interesting translators I've been able to dream up. I'm sure there are many more ideas floating around out there, so add them to the list! - -The [ferris project](http://witme.sourceforge.net/libferris.web/features.html) has some great ideas and code in the area of userspace dynamic filesystems, as has the [FUSE project](http://fuse.sourceforge.net/). - -## Audio\_cdfs - -A translator which produces a directory of \*.wav files when you have an audio CD in the drive. - -## Ogg - -This translator could be a sub-directory of the Audio\_cdfs translator and it would translate the \*.wav files into Ogg Vorbis/MP3 format. - -## CDDB - -Of course it would be a lot nicer if the above two translators didn't name their files something worthless like track001.ogg. So we would want a translator which would hook up with a database on the web and produce meaningful file names. - -## Crypto - -A cryptographic/steganographic seem like a nice match with the concept of user-land file systems. I like the idea of something like `settrans -a /secure stegfs --mpeg file001.mpg` - -## Revision control - -All of the empty space on your drive is now being wasted. Why not have a revision control translator which tracks changes to your documents? See also [this guy](http://www.linuxjournal.com/article.php?sid=5976). And then you'd do something like `cd /time-machine/2003/sept/14/` to see what your system looked like on the 14th of septempber 2003. - -## CVSFS - -See [cvsFS for Linux](http://cvsfs.sourceforge.net/). This provides a package which presents the CVS contents as mountable file system. It allows to view the versioned files as like they were ordinary files on a disk. There is also a possibility to check in/out some files for editing. A read-only version has been written by Stefan Siegl and is available at [Berlios](http://cvs.berlios.de/cgi-bin/viewcvs.cgi/cvsfs4hurd/cvsfs/). - -## tar and gzip - -Rumor has it that they are on the way. Actually, a tar + gzip/bzip2 translator does exist (although it hasn't been used much...) : see [the Hurdextras project](http://savannah.nongnu.org/projects/hurdextras/) on Savannah. - -## ROM - -How about a translator which makes it look like you can write to read only media (like CDs), or change files which I don't have permission to change. This translator would make it seem like you could copy files to places where you normally couldn't. Think about combining this translator with the ftp translator and the tar and gzip translators. (cd /ftp/gnu.org/gnome.tar.gz/writes\_allowed; make install). It could be that unionfs does this very thing. - -## Super\_FIFO - -It's like a named pipe which is smart enough to start a process everytime something new tries to read from it. For example, let's say I have a script that reads in a JPEG image and spits out a smaller thumbnail \*.jpg to STDOUT. With a standard fifo (`mknod -p fifo`) this would almost works (`script big.jpg > fifo`). But what if there are two processes trying to read the fifo at once? Ick. And of course the standard way only works once without rerunning the command. I'm not quite sure what the syntax should look like, but I'm sure someone out there has a great idea waiting to happen. - -## Perl - -Perl is a wonderful language for hacking together something useful in a short amount of time. No concept is complete without being able to use it in a perl one-liner. And that goes for Hurd translators too. Right? - - #!/usr/bin/perl - use Hurd::translator; - - #file named "two" can produce an endless supply of twos, etc. (a la /dev/zero) - my $i=0; - for $filename ([zero one two three four]) - { - $libtrivfsread_codehash{$filename}= - sub{ $num_bytes=shift; my $data=$i; return chr($data) x $num_bytes; }; - #that's a hash of references to closures - $i++; - } - translator_startup(); - -A Perl translator has been started by [John Edwin Tobey](http://john-edwin-tobey.org/Hurd/) (pith). - -## Source code - -Here's a crazy thought. How about a translator for source code. You have a C source file like `hello.c` which is your normal everyday file. But there's a translator sitting underneath, so when you `cd hello.c` you get a directory with files like `main()` which represent the subroutines in `hello.c`. And of course you should be able to edit/remove those and have it modify the original source. - -## Libraries - -Here's an [idea](http://www.circlemud.org/~jelson/software/fusd/docs/node13.html) from the people making [userspace drivers in Linux](http://www.circlemud.org/~jelson/software/fusd/): - -* "One particularly interesting application of FUSD that we've found very useful is as a way to let regular user-space libraries export device file APIs. For example, imagine you had a library which factored large composite numbers. Typically, it might have a C interface--say, a function called `int *factorize(int bignum)`. With FUSD, it's possible to create a device file interface--say, a device called `/dev/factorize` to which clients can `write(2)` a big number, then `read(2)` back its factors. - -* This may sound strange, but device file APIs have at least three advantages over a typical library API. First, it becomes much more language independent--any language that can make system calls can access the factorization library. Second, the factorization code is running in a different address space; if it crashes, it won't crash or corrupt the caller. Third, and most interestingly, it is possible to use `select(2)` to wait for the factorization to complete. `select(2)` would make it easy for a client to factor a large number while remaining responsive to other events that might happen in the meantime. In other words, FUSD allows normal user-space libraries to integrate seamlessly with UNIX's existing, POSIX-standard event notification interface: `select(2)`." - -## Mail - -Am I off my rocker, or does an IMAP/POP translator sound like a good idea? It would make your remote mail servers look like local ones. Or what about a translator that makes a mbox format mail spool look like a directory. Can anyone think of a good use for an SMTP translator? - -## UUEncode - -How about a UUEncode translator for those places you can only store ASCII. Combine this with a NNTP translator and store your data in someone's Usenet archive. Or since, (as far as I know), there are no size limitations on file names in the Hurd, why not have a filesystem translator whose underlying store is a file name. (Now ls becomes cat). - -## Computation - -This is from the revenge of the command-line department. Make a directory translator whose contents are a result of the computation specified in the directory name. Here's an example... - - $ settrans -a /comp /hurd/computationfs - $ cd "/comp/3+4" - $ ls -l - total 0 - -rw-r--r-- 1 nobody users 0 Oct 16 11:41 7 - $ - $ cd "/comp/sqrt(2)" - $ ls -l - total 0 - -rw-r--r-- 1 nobody users 0 Oct 16 11:42 1.4142135623731 - $ - -...etc. Now think about your favorite GUI HTML editor and using File->Open on the following directory name, ``"/comp/for i in $( find / -name *.html ); do ln -s $i `basename $i`;done"`` Which would produce a directory listing with soft links to all of the \*.html files on your system. You could have all of the comforts of the shell from within that little File->Open dialog box. - -## Other - -Just found Wolfgang J�hrling's translator [wishlist](http://www.8ung.at/shell/trans.html). - -## Bochs - -A translator which works with [Bochs](http://bochs.sourceforge.net/) disk images would be nice. - -## Rollover - -A translator that uses a circular buffer to store log files. The translated node only contains the last N (mega,kilo)bytes. - -## Birthday - -A translator that provides an interface into the birthday program. - -You can cat your calendar, eg. bd/calendar/today bd/calendar/this-week or bd/calendar/this-month. - -And you could write new events into files located in bd/events/DATE/event-name. - -DATE is of the format the birthday expects DD/MM/YYYY. - -The contents of the file are any or none of the following birthday options: ann (An anniversary), bd (A birthday), ev (Some other event), wN (Warn N days in advance of date), toDATE (Event lasts until this DATE), forDAYS (Event runs for DAYS). - -You can optionally just edit the bd/birthdays file if you want to edit the configuration file by hand. It might make sense to write changes from bd/birthdays into ~/.birthdays. - - $ settrans -c bd /hurd/birthday -f ~/.birthdays - $ ls bd/ - birthdays calendar events - $ find bd -print - bd - bd/calendar - bd/calendar/daily - bd/calendar/this-week - bd/calendar/this-month - bd/events - bd/birthdays - $ - -## LVM - -A translator to access block devices from Linux's [Logical Volume Management](http://www.tldp.org/HOWTO/LVM-HOWTO/) would be an useful addition. - - # settrans -cap /dev/VolumeGroup0 /hurd/lvm /dev/PhysicalVolume0 /dev/PhysicalVolume1 ... - # ls /dev/VolumeGroup0/ - home - var - # settrans -cap /home /hurd/ext2fs /dev/VolumeGroup0/home - # settrans -cap /var /hurd/ext2fs /dev/VolumeGroup0/var - -Probably both [LVM2](http://sourceware.org/lvm2/) and the [Device-mapper](http://sourceware.org/dm/) need to be ported. - -## bridging translator - -A [bridging](http://bridge.sourceforge.net/faq.html) translator could improve the Hurd's networking facilities. - - # settrans -cap /dev/br0 /hurd/bridge -i eth0 -i eth1 ... - # settrans -cap /servers/socket/2 /hurd/pfinet -i /dev/br0 -a ... -g ... -m ... - -Perhaps Linux's bridging code and [utilities](http://bridge.sourceforge.net/) can be ported (or glued in) or code from one of the BSDs. - -## SSH translator - -Presenting remote file systems through SSH similar to what gnome-vfs does. - -## SMB translator - -Presenting remote file systems through Samba similar to what gnome-vfs does. Guiseppe Scrivano has worked on this and smbfs is available at [hurdextras](http://savannah.nongnu.org/cgi-bin/viewcvs/hurdextras/smbfs/). - -## Crontab translator - -Presenting a user's crontab in a filesystem where cron entries are files. - -## globlink - -Firmlink to a file according to a filename matching pattern. When a file goes away, the next file that is matched is automatically linked to. - - $ settrans -ac libfoo.so /hurd/globlink '/lib/libfoo*' - -## alphabetfs - -Organize a large group of files by their first letter. Present one subdirectory for each letter in the alphabet. - -## fsysoptsctl - -Send an fsysopts command to a set of translators. When you have a directory full of translators and you want to send each of them the same runtime option, this translator can do it for you. - - $ settrans -ac all /hurd/fsysoptsctl '/tmp/mystuff/*' - $ fsysopts all --update - ----- - --- [[Main/GregBuchholz]] - updated 17 Oct 2003 -- cgit v1.2.3 From 714738c3aa0d5625cc7dccf0e8c3f1414b8930c6 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 5 Apr 2009 18:39:14 +0200 Subject: unsorted/PortingIssues -> hurd/porting/guidelines --- community/gsoc/project_ideas/maxpath.mdwn | 2 +- hurd/faq/old-stuff.mdwn | 2 +- hurd/porting/guidelines.mdwn | 281 +++++++++++++++++++++++++ hurd/running/debian/GnuDebianRelationship.mdwn | 4 +- hurd/running/distrib.mdwn | 2 +- unsorted/PortingIssues.mdwn | 270 ------------------------ 6 files changed, 286 insertions(+), 275 deletions(-) create mode 100644 hurd/porting/guidelines.mdwn delete mode 100644 unsorted/PortingIssues.mdwn (limited to 'hurd/running/distrib.mdwn') diff --git a/community/gsoc/project_ideas/maxpath.mdwn b/community/gsoc/project_ideas/maxpath.mdwn index 992b91ee..d78297d5 100644 --- a/community/gsoc/project_ideas/maxpath.mdwn +++ b/community/gsoc/project_ideas/maxpath.mdwn @@ -33,7 +33,7 @@ by `char *foo`, and using dynamic memory allocation, i.e. e.g. a loop that tries geometrically growing sizes. Sometimes this is tricky, but more often not very hard. Sometimes it is even trivial because the GNU system has proper replacements. See the corresponding section of the -[[Porting_issues_page|unsorted/PortingIssues]] for more details. With a bit of +[[porting_guidelines_page|hurd/porting/guidelines]] for more details. With a bit of practice, it should be easily possible to fix several programs per day. The goal of this project is to fix the PATH_MAX and related problems in a diff --git a/hurd/faq/old-stuff.mdwn b/hurd/faq/old-stuff.mdwn index 1bcc09a0..e4132d50 100644 --- a/hurd/faq/old-stuff.mdwn +++ b/hurd/faq/old-stuff.mdwn @@ -28,7 +28,7 @@ If you still have problems, do not hesitate to make use of the [[mailing_lists]] * These are different versions of the Mach microkernel that supports the Hurd that runs on top of it. For more info, see [[Mach]] * **_What software is available for GNU?_** - * Most packages from [Debian](http://www.debian.org/) [GNU/Linux](http://www.gnu.org/gnu/linux-and-gnu.html) which aren't linux-specific ([Packages That Won't Be Ported](http://www.debian.org/ports/hurd/hurd-devel-debian)) are expected to work on GNU/Hurd too. See the database in . Programs which need pthreads, including [GNOME](http://www.gnome.org), [KDE](http://www.kde.org), [Mozilla](http://www.mozilla.org), [OpenOffice](http://www.openoffice.org), [SDL](http://www.libsdl.org), etc. are being worked on currently using Neal Walfields libpthreads. See the [[Distrib/PortingIssues]] document for some common build problems and their solutions. + * Most packages from [Debian](http://www.debian.org/) [GNU/Linux](http://www.gnu.org/gnu/linux-and-gnu.html) which aren't linux-specific ([Packages That Won't Be Ported](http://www.debian.org/ports/hurd/hurd-devel-debian)) are expected to work on GNU/Hurd too. See the database in . Programs which need pthreads, including [GNOME](http://www.gnome.org), [KDE](http://www.kde.org), [Mozilla](http://www.mozilla.org), [OpenOffice](http://www.openoffice.org), [SDL](http://www.libsdl.org), etc. are being worked on currently using Neal Walfields libpthreads. See the [[porting/guidelines]] document for some common build problems and their solutions. * If you can't fetch a package with "apt-get install ", try building it from source: "apt-get source && cd <package\_dir> && debian/rules binary". * As of January 2007, 50% of Debian packages have been ported on the Hurd. Of course, bug testing is welcome. diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn new file mode 100644 index 00000000..ee27c9be --- /dev/null +++ b/hurd/porting/guidelines.mdwn @@ -0,0 +1,281 @@ +[[meta copyright="Copyright © 2002, 2003, 2005, 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 +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]]."]]"""]] + +## Table of Contents + +%TOC% + +## Overview + +This is a recompilation of common porting problems and their solutions. Information is gathered from the following sources: + +* [Debian GNU/Hurd port guidelines](http://www.debian.org/ports/hurd/hurd-devel-debian) + +* [James Morrison's GNU/Hurd pages](http://hurd.dyndns.org/) + +as well as other misc. sources. + +First of all, see [[BtsFiling]] if you need instructions on manipulating [Debian](http://www.debian.org/) source packages and submitting patches to their [Bug Tracking System](http://bugs.debian.org/). + +## System API limitations + +Sometimes building or running a program will fail due to bugs in the system API implementation (in Glibc and the Hurd). Make sure you check this list and know them before porting, otherwise you'll end up debugging something just to find out its an already known bug. + +We maintain a separate Wiki page for information on these bugs, see [[Distrib/SystemAPILimits]] + +If you think you can fix any of them and send a patch to the debian BTS, that'd be much appreciated. You may ask in for details or questions on the bug. + +## Undefined `bits/confname.h` macros (`PIPE_BUF`, ...) + +If macro `XXX` is undefined, but macro `_SC_XXX` or `_PC_XXX` is defined in `bits/confname.h`, you probably need to use `sysconf`, `pathconf` or `fpathconf` to obtain it dynamicaly. + +The following macros have been found in this offending situation (add more if you find them): `PIPE_BUF` + +An example with `sysconf`: (when you find a `sysconf` offending macro, put a better example) + + #ifndef XXX + #define XXX sysconf(_SC_XXX) + #endif + /* offending code using XXX follows */ + +An example with `fpathconf`: + + #ifdef PIPE_BUF + read(fd, buff, PIPE_BUF - 1); + #else + read(fd, buff, fpathconf(fd, _PC_PIPE_BUF) - 1); + #endif + /* note we can't #define PIPE_BUF, because it depends + on the "fd" variable */ + +## Bad File Descriptor + +If you get Bad File Descriptor error when trying to read from a file (or accessing it at all), check the `open()` invocation. The second argument is the access method. If it is a hard coded number instead of a symbol defined in the standard header files, the code is screwed and should be fixed to either use `O_RDONLY`, `O_WRONLY` or `O_RDWR`. This bug was observed in the `fortunes` and `mtools` packages for example. + +## `PATH_MAX` / `MAX_PATH` / `MAXPATHLEN` + +Every unconditionalized use of `PATH_MAX`, `MAX_PATH` or `MAXPATHLEN` is a POSIX incompatibility. If there is no upper limit on the length of a path (as its the case for GNU), this symbol is not defined in any header file. Instead, you need to either use a different implementation that does not rely on the length of a string or use `sysconf()` to query the length at runtime. If `sysconf()` returns -1, you have to use `realloc()` to allocate the needed memory dynamically. Usually it is thus simpler to just use dynamic allocation. Sometimes the amount is actually known. Else, a geometrically growing loop can be used: for instance, see [Alioth patch](http://alioth.debian.org/tracker/download.php/30628/410472/303735/1575/cpulimit-path-max-fix.patch). Note that in some cases there are GNU extensions that just work fine: when the `__GLIBC__` macro is defined, `getcwd()` calls can be just replaced by `get_current_dir_name()` calls. + +## `ARG_MAX` + +Same rationale as `PATH_MAX`. There is no limit on the number of arguments. + +## `IOV_MAX` + +Same rationale as `PATH_MAX`. There is no limit on the number of iovec items. + +## `MAXHOSTNAMELEN` + +Same as `PATH_MAX`. When you find a `gethostname()` function, which acts on a static buffer, you can replace it with Neal's [xgethostname function](http://ftp.walfield.org/pub/people/neal/xgethostname/) which returns the hostname as a dynamic buffer. For example: + +Buggy code: + + char localhost[MAXHOSTNAMELEN]; + ... + gethostname(localhost, sizeof(localhost)); + +Fixed code: + + #include "xgethostname.h" + ... + char *localhost; + ... + localhost = xgethostname(); + if (! localhost) + { + perror ("xgethostname"); + return ERROR; + } + ... + /* use LOCALHOST. */ + free (localhost); + +## `NOFILE` + +Replace with `getrlimit(RLIMIT_NOFILE,...)` + +## GNU specific `#define` + +If you need to include specific code for GNU/Hurd using `#if` ... `#endif`, then you can use the `__GNU__` symbol to do so. But think (at least) thrice! before doing so. In most situations, this is completely unnecessary and will create more problems than it may solve. Better ask on the mailing list how to do it right if you can't think of a better solution. + +## `sys_errlist[]` vs. `strerror()` + +If a program has only support for `sys_errlist[]` you will have to do some work to make it compile on GNU, which has dropped support for it and does only provide `strerror()`. Steinar Hamre writes about `strerror()`: + +`strerror()` should be used because: + +* It is the modern, POSIX way. +* It is localized. +* It handles invalid signals/numbers out of range. (better errorhandling and not a buffer-overflow-candidate/security risk) + +`strerror()` should always be used if it is available. Unfortunaly there are still some old non-POSIX systems that do not have `strerror()`, only `sys_errlist[]`. + +Today, only supporting `strerror()` is far better than only supporting `sys_errlist[]`. The best (from a portability viewpoint), however is supporting both. For configure.in, you will need: + + AC_CHECK_FUNCS(strerror) + +To `config.h.in`, you need to add: + + #undef HAVE_STRERROR + +Then something like: + + #ifndef HAVE_STRERROR + static char * + private_strerror (errnum) + int errnum; + { + extern char *sys_errlist[]; + extern int sys_nerr; + + if (errnum > 0 && errnum <= sys_nerr) + return sys_errlist[errnum]; + + return "Unknown system error"; + } + #define strerror private_strerror + #endif /* HAVE_STRERROR */ + +You can for example look in the latest coreutils (the above is a simplified version of what I found there.) Patches should of course be sent to upstream maintainers, this is very useful even for systems with a working `sys_errlist[]`. + +Of course, if you don't care about broken systems (like MS-DOG) not supporting `strerror()` you can just replace `sys_errlist[]` directly (upstream might not accept your patch, but debian should have no problem) + +## C++, `error_t` and `E*` + +On the Hurd, `error_t` is an enumeration of the `E*` constants. However, C++ +does not like `E*` integer macros being directly assigned to that enumeration. In short, replace + + error_t err = EINTR; + +by + + error_t err = error_t(EINTR); + +## Filenames ending in a slash \`/' + +Those are evil if they don't exist and you want to name a directory this way. For example, `mkdir foobar/` will not work on GNU. This is POSIX compatible. POSIX says that the path of a directory may have slashes appended to it. But the directory does not exist yet, so the path does not refer to a directory, and hence trailing slashes are not guaranteed to work. Just drop the slashes, and you're fine. + +## Missing `termio.h` + +Change it to use `termios.h` (check for it properly with autoconf `HAVE_TERMIOS_H` or the `__GLIBC__` macro) + +Also, change calls to `ioctl(fd, TCGETS, ...)` and `ioctl(fd, TCSETS, ...)` with `tcgetattr(fd, ...)` and `tcsetattr(fd, ...)`. + +## `AC_HEADER_TERMIO` + +The autoconf check for `AC_HEADER_TERMIO` tryes to check for termios, but it's only really checking for termio in `termios.h`. It is better to use `AC_CHECK_HEADERS(termio.h termios.h)` + +## missing `_IOT` + +This comes from ioctls. Fixing this is easy if the structure members can be expressed by using the _IOT() macro, else it's simply impossible... See `bits/termios.h` for an instance: + +`#define _IOT_termios /* Hurd ioctl type field. */ \ + _IOT (_IOTS (tcflag_t), 4, _IOTS (cc_t), NCCS, _IOTS (speed_t), 2)` + +because `struct termios` holds 4 members of type `tcflag_ts`, then `NCCS` +members of type `cc_tsi` and finaly 2 members of type `speed_ts`. + +As you can see, this limits the number of kinds of members to 3, and in +addition to that (see the bitfield described in `ioctls.h`), the third +kind of member is limited to 3 members. However, since at the API +compatibility layer you are generally allowed to reorder fields in +structures, you can usually manage to fit into these limits. + +Note: if a field member is a pointer, then the ioctl can't be expressed +this way, and that makes sense, since the server you're talking to +doesn't have direct access to your memory. Ways other than ioctls must +then be found. + +## `SA_SIGINFO` + +Not implemented, packages may be fixed for working around this: use void sighandler(int num) prototype and sa_handler field. + +## `SOL_IP` + +Not implemented yet. + +## `HZ` + +Linuxish and doesn't even make sense since the value may vary according to the running kernel. Should use `sysconf(_SC_CLK_TCK)` or `CLK_TCK` instead. + +## `SIOCDEVPRIVATE` + +Oh, we should probably provide it. + +## `MAP_NORESERVE` + +Not POSIX, but we could implement it. + +## `O_DIRECT` + +Long story to implement. + +## `PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP` + +We could easily provide it; + +## `PTHREAD_STACK_MIN` + +We should actually provide it. + +## `linux/types.h` or `asm/types.h` + +These are not POSIX, `sys/types.h` and `stdint.h` should be used instead. + +## `iopl` + +Not supported. Try to replace with `ioperm(0, 65536, 1)` (conditionned with `__GNU__` as that will not work in Linux). + +## `semget`, `sem_open` + +Not implemented, will always fail. Use `sem_init()` instead if possible. + +## `net/if_arp.h`, `net/ethernet.h`, etc. + +Not implemented, not POSIX. Try to disable the feature in the package. + +## broken libc6 dependency + +Some packages use an erroneous dependency on `libc6-dev`. This is incorrect because `libc6` is specific to GNU/Linux. The corresponding package for GNU is `libc0.3-dev` but other OSes will have different ones. You can locate the problem in the `debian/control` file of the source tree. Typical solutions include detecting the OS using `dpkg-architecture` and hardcoding the soname, or better, use a logical OR. eg: `libc6-dev | libc0.3-dev | libc-dev`. The `libc-dev` is a virtual package that works for any soname but you have to put it only as the last option. + +---- + +## ChangeLog + +-- [[Main/TWikiGuest]] - 13 Jan 2005 + +Fix xgethostname example. - Neal + +-- [[Main/RobertMillan]] - 22 Jul 2002 + +Formatting and minor grammatical fixes. + +-- [[Main/JoachimNilsson]] - 09 Sep 2002 + +Added more examples and misc semantical fixes. + +-- [[Main/RobertMillan]] - 05 Oct 2002 + +Added `xgethostname` example. + +-- [[Main/RobertMillan]] - 15 Nov 2002 + +Added broken libc6 dependency + +-- [[Main/RobertMillan]] - 21 Nov 2002 + +Text formatting. + +-- Ognyan Kulev - 12 Mar 2003 + +Added `ioctl` entry. + +-- [[Main/RobertMillan]] - 19 Mar 2003 diff --git a/hurd/running/debian/GnuDebianRelationship.mdwn b/hurd/running/debian/GnuDebianRelationship.mdwn index ede808c8..94fd6265 100644 --- a/hurd/running/debian/GnuDebianRelationship.mdwn +++ b/hurd/running/debian/GnuDebianRelationship.mdwn @@ -2,11 +2,11 @@ I have hesitated in starting this page due to the sensitive nature of this relat This is a work in progress. Please email me directly if you have comments or suggestions. -* Debian Advantages of Hurd [[Distrib/PortingIssues]] Efforts +* Debian Advantages of Hurd [[porting/guidelines]] Efforts * One of the first ports to non-Linux system along with \*BSD and win32. * Official GNU system distribution. -* Debian Disadvantages of Hurd [[Distrib/PortingIssues]] Efforts +* Debian Disadvantages of Hurd [porting/guidelines]] Efforts * Perceived zealous GNU and FSF promotion. * Hurd Port Advantages of Debian diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index 935c0c2d..607b50af 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -68,7 +68,7 @@ about getting applications to work (if possible).
-
[[PortingIssues]] FAQ
+
[[porting/guidelines]] FAQ
What does it take to move a piece of Debian packaged software to the GNU/Hurd port?
diff --git a/unsorted/PortingIssues.mdwn b/unsorted/PortingIssues.mdwn deleted file mode 100644 index 03980ef3..00000000 --- a/unsorted/PortingIssues.mdwn +++ /dev/null @@ -1,270 +0,0 @@ -## Table of Contents - -%TOC% - -## Overview - -This is a recompilation of common porting problems and their solutions. Information is gathered from the following sources: - -* [Debian GNU/Hurd port guidelines](http://www.debian.org/ports/hurd/hurd-devel-debian) - -* [James Morrison's GNU/Hurd pages](http://hurd.dyndns.org/) - -as well as other misc. sources. - -First of all, see [[BtsFiling]] if you need instructions on manipulating [Debian](http://www.debian.org/) source packages and submitting patches to their [Bug Tracking System](http://bugs.debian.org/). - -## System API limitations - -Sometimes building or running a program will fail due to bugs in the system API implementation (in Glibc and the Hurd). Make sure you check this list and know them before porting, otherwise you'll end up debugging something just to find out its an already known bug. - -We maintain a separate Wiki page for information on these bugs, see [[Distrib/SystemAPILimits]] - -If you think you can fix any of them and send a patch to the debian BTS, that'd be much appreciated. You may ask in for details or questions on the bug. - -## Undefined `bits/confname.h` macros (`PIPE_BUF`, ...) - -If macro `XXX` is undefined, but macro `_SC_XXX` or `_PC_XXX` is defined in `bits/confname.h`, you probably need to use `sysconf`, `pathconf` or `fpathconf` to obtain it dynamicaly. - -The following macros have been found in this offending situation (add more if you find them): `PIPE_BUF` - -An example with `sysconf`: (when you find a `sysconf` offending macro, put a better example) - - #ifndef XXX - #define XXX sysconf(_SC_XXX) - #endif - /* offending code using XXX follows */ - -An example with `fpathconf`: - - #ifdef PIPE_BUF - read(fd, buff, PIPE_BUF - 1); - #else - read(fd, buff, fpathconf(fd, _PC_PIPE_BUF) - 1); - #endif - /* note we can't #define PIPE_BUF, because it depends - on the "fd" variable */ - -## Bad File Descriptor - -If you get Bad File Descriptor error when trying to read from a file (or accessing it at all), check the `open()` invocation. The second argument is the access method. If it is a hard coded number instead of a symbol defined in the standard header files, the code is screwed and should be fixed to either use `O_RDONLY`, `O_WRONLY` or `O_RDWR`. This bug was observed in the `fortunes` and `mtools` packages for example. - -## `PATH_MAX` / `MAX_PATH` / `MAXPATHLEN` - -Every unconditionalized use of `PATH_MAX`, `MAX_PATH` or `MAXPATHLEN` is a POSIX incompatibility. If there is no upper limit on the length of a path (as its the case for GNU), this symbol is not defined in any header file. Instead, you need to either use a different implementation that does not rely on the length of a string or use `sysconf()` to query the length at runtime. If `sysconf()` returns -1, you have to use `realloc()` to allocate the needed memory dynamically. Usually it is thus simpler to just use dynamic allocation. Sometimes the amount is actually known. Else, a geometrically growing loop can be used: for instance, see [Alioth patch](http://alioth.debian.org/tracker/download.php/30628/410472/303735/1575/cpulimit-path-max-fix.patch). Note that in some cases there are GNU extensions that just work fine: when the `__GLIBC__` macro is defined, `getcwd()` calls can be just replaced by `get_current_dir_name()` calls. - -## `ARG_MAX` - -Same rationale as `PATH_MAX`. There is no limit on the number of arguments. - -## `IOV_MAX` - -Same rationale as `PATH_MAX`. There is no limit on the number of iovec items. - -## `MAXHOSTNAMELEN` - -Same as `PATH_MAX`. When you find a `gethostname()` function, which acts on a static buffer, you can replace it with Neal's [xgethostname function](http://ftp.walfield.org/pub/people/neal/xgethostname/) which returns the hostname as a dynamic buffer. For example: - -Buggy code: - - char localhost[MAXHOSTNAMELEN]; - ... - gethostname(localhost, sizeof(localhost)); - -Fixed code: - - #include "xgethostname.h" - ... - char *localhost; - ... - localhost = xgethostname(); - if (! localhost) - { - perror ("xgethostname"); - return ERROR; - } - ... - /* use LOCALHOST. */ - free (localhost); - -## `NOFILE` - -Replace with `getrlimit(RLIMIT_NOFILE,...)` - -## GNU specific `#define` - -If you need to include specific code for GNU/Hurd using `#if` ... `#endif`, then you can use the `__GNU__` symbol to do so. But think (at least) thrice! before doing so. In most situations, this is completely unnecessary and will create more problems than it may solve. Better ask on the mailing list how to do it right if you can't think of a better solution. - -## `sys_errlist[]` vs. `strerror()` - -If a program has only support for `sys_errlist[]` you will have to do some work to make it compile on GNU, which has dropped support for it and does only provide `strerror()`. Steinar Hamre writes about `strerror()`: - -`strerror()` should be used because: - -* It is the modern, POSIX way. -* It is localized. -* It handles invalid signals/numbers out of range. (better errorhandling and not a buffer-overflow-candidate/security risk) - -`strerror()` should always be used if it is available. Unfortunaly there are still some old non-POSIX systems that do not have `strerror()`, only `sys_errlist[]`. - -Today, only supporting `strerror()` is far better than only supporting `sys_errlist[]`. The best (from a portability viewpoint), however is supporting both. For configure.in, you will need: - - AC_CHECK_FUNCS(strerror) - -To `config.h.in`, you need to add: - - #undef HAVE_STRERROR - -Then something like: - - #ifndef HAVE_STRERROR - static char * - private_strerror (errnum) - int errnum; - { - extern char *sys_errlist[]; - extern int sys_nerr; - - if (errnum > 0 && errnum <= sys_nerr) - return sys_errlist[errnum]; - - return "Unknown system error"; - } - #define strerror private_strerror - #endif /* HAVE_STRERROR */ - -You can for example look in the latest coreutils (the above is a simplified version of what I found there.) Patches should of course be sent to upstream maintainers, this is very useful even for systems with a working `sys_errlist[]`. - -Of course, if you don't care about broken systems (like MS-DOG) not supporting `strerror()` you can just replace `sys_errlist[]` directly (upstream might not accept your patch, but debian should have no problem) - -## C++, `error_t` and `E*` - -On the Hurd, `error_t` is an enumeration of the `E*` constants. However, C++ -does not like `E*` integer macros being directly assigned to that enumeration. In short, replace - - error_t err = EINTR; - -by - - error_t err = error_t(EINTR); - -## Filenames ending in a slash \`/' - -Those are evil if they don't exist and you want to name a directory this way. For example, `mkdir foobar/` will not work on GNU. This is POSIX compatible. POSIX says that the path of a directory may have slashes appended to it. But the directory does not exist yet, so the path does not refer to a directory, and hence trailing slashes are not guaranteed to work. Just drop the slashes, and you're fine. - -## Missing `termio.h` - -Change it to use `termios.h` (check for it properly with autoconf `HAVE_TERMIOS_H` or the `__GLIBC__` macro) - -Also, change calls to `ioctl(fd, TCGETS, ...)` and `ioctl(fd, TCSETS, ...)` with `tcgetattr(fd, ...)` and `tcsetattr(fd, ...)`. - -## `AC_HEADER_TERMIO` - -The autoconf check for `AC_HEADER_TERMIO` tryes to check for termios, but it's only really checking for termio in `termios.h`. It is better to use `AC_CHECK_HEADERS(termio.h termios.h)` - -## missing `_IOT` - -This comes from ioctls. Fixing this is easy if the structure members can be expressed by using the _IOT() macro, else it's simply impossible... See `bits/termios.h` for an instance: - -`#define _IOT_termios /* Hurd ioctl type field. */ \ - _IOT (_IOTS (tcflag_t), 4, _IOTS (cc_t), NCCS, _IOTS (speed_t), 2)` - -because `struct termios` holds 4 members of type `tcflag_ts`, then `NCCS` -members of type `cc_tsi` and finaly 2 members of type `speed_ts`. - -As you can see, this limits the number of kinds of members to 3, and in -addition to that (see the bitfield described in `ioctls.h`), the third -kind of member is limited to 3 members. However, since at the API -compatibility layer you are generally allowed to reorder fields in -structures, you can usually manage to fit into these limits. - -Note: if a field member is a pointer, then the ioctl can't be expressed -this way, and that makes sense, since the server you're talking to -doesn't have direct access to your memory. Ways other than ioctls must -then be found. - -## `SA_SIGINFO` - -Not implemented, packages may be fixed for working around this: use void sighandler(int num) prototype and sa_handler field. - -## `SOL_IP` - -Not implemented yet. - -## `HZ` - -Linuxish and doesn't even make sense since the value may vary according to the running kernel. Should use `sysconf(_SC_CLK_TCK)` or `CLK_TCK` instead. - -## `SIOCDEVPRIVATE` - -Oh, we should probably provide it. - -## `MAP_NORESERVE` - -Not POSIX, but we could implement it. - -## `O_DIRECT` - -Long story to implement. - -## `PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP` - -We could easily provide it; - -## `PTHREAD_STACK_MIN` - -We should actually provide it. - -## `linux/types.h` or `asm/types.h` - -These are not POSIX, `sys/types.h` and `stdint.h` should be used instead. - -## `iopl` - -Not supported. Try to replace with `ioperm(0, 65536, 1)` (conditionned with `__GNU__` as that will not work in Linux). - -## `semget`, `sem_open` - -Not implemented, will always fail. Use `sem_init()` instead if possible. - -## `net/if_arp.h`, `net/ethernet.h`, etc. - -Not implemented, not POSIX. Try to disable the feature in the package. - -## broken libc6 dependency - -Some packages use an erroneous dependency on `libc6-dev`. This is incorrect because `libc6` is specific to GNU/Linux. The corresponding package for GNU is `libc0.3-dev` but other OSes will have different ones. You can locate the problem in the `debian/control` file of the source tree. Typical solutions include detecting the OS using `dpkg-architecture` and hardcoding the soname, or better, use a logical OR. eg: `libc6-dev | libc0.3-dev | libc-dev`. The `libc-dev` is a virtual package that works for any soname but you have to put it only as the last option. - ----- - -## ChangeLog - --- [[Main/TWikiGuest]] - 13 Jan 2005 - -Fix xgethostname example. - Neal - --- [[Main/RobertMillan]] - 22 Jul 2002 - -Formatting and minor grammatical fixes. - --- [[Main/JoachimNilsson]] - 09 Sep 2002 - -Added more examples and misc semantical fixes. - --- [[Main/RobertMillan]] - 05 Oct 2002 - -Added `xgethostname` example. - --- [[Main/RobertMillan]] - 15 Nov 2002 - -Added broken libc6 dependency - --- [[Main/RobertMillan]] - 21 Nov 2002 - -Text formatting. - --- Ognyan Kulev - 12 Mar 2003 - -Added `ioctl` entry. - --- [[Main/RobertMillan]] - 19 Mar 2003 -- cgit v1.2.3 From e016e16505f5b97959dba8edc05411ce17bd7b67 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 5 Apr 2009 18:44:10 +0200 Subject: unsorted/SystemAPILimits -> hurd/porting/system_api_limitations --- hurd/porting/guidelines.mdwn | 2 +- hurd/porting/system_api_limitations.mdwn | 41 ++++++++++++++++++++++++++++++++ hurd/running/distrib.mdwn | 2 +- unsorted/SystemAPILimits.mdwn | 30 ----------------------- 4 files changed, 43 insertions(+), 32 deletions(-) create mode 100644 hurd/porting/system_api_limitations.mdwn delete mode 100644 unsorted/SystemAPILimits.mdwn (limited to 'hurd/running/distrib.mdwn') diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index ee27c9be..f37a17e2 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -29,7 +29,7 @@ First of all, see [[BtsFiling]] if you need instructions on manipulating [Debian Sometimes building or running a program will fail due to bugs in the system API implementation (in Glibc and the Hurd). Make sure you check this list and know them before porting, otherwise you'll end up debugging something just to find out its an already known bug. -We maintain a separate Wiki page for information on these bugs, see [[Distrib/SystemAPILimits]] +We maintain a separate Wiki page for information on these bugs, see [[System_API_Limitations]] If you think you can fix any of them and send a patch to the debian BTS, that'd be much appreciated. You may ask in for details or questions on the bug. diff --git a/hurd/porting/system_api_limitations.mdwn b/hurd/porting/system_api_limitations.mdwn new file mode 100644 index 00000000..d536f764 --- /dev/null +++ b/hurd/porting/system_api_limitations.mdwn @@ -0,0 +1,41 @@ +[[meta copyright="Copyright © 2003, 2004, 2005, 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]]."]]"""]] + +## API Limitations of the GNU system + +---- + +Sometimes building or running a program will fail due to bugs in the system API implementation (in Glibc and the Hurd). Make sure you check this list and know them before porting, otherwise you'll end up debugging something just to find out its an already known bug. + +Taken from the bug lists in debian BTS. If you find more of them (and it is clear in the bug log that it is a bug), please add them to the list below. See: + +* ([source](http://packages.qa.debian.org/h/hurd.html) and [binary](http://packages.debian.org/hurd) debs not synchronized) +* ([binary](http://packages.debian.org/hurd-dev)) +* ([source](http://packages.qa.debian.org/g/glibc.html) & [binary](http://packages.debian.org/libc0.3) debs) +* ([binary](http://packages.debian.org/libc0.3-dev)) + +---- + +These are the known system API limits that have porting implications. + +**_[\#47998](http://bugs.debian.org/47998): `msgget` IPC not implemented_** + +**_[\#184565](http://bugs.debian.org/184565): libc0.3: missing shm\* functions (from ``)_**
**breaks:** cdrtools
**error:** warning: shm\* is not implemented and will always fail + +**_[\#190581](http://bugs.debian.org/190581): nice() doesn't work_**
**breaks:** coreutils
**error:** `nice()` doesn't take effect on some situations + +**_[\#187391](http://bugs.debian.org/187391): libc0.3-dev: `sockaddr_un.sun_path` can't be assigned a `const char *` when compiling with g++_**
**breaks:** fam, gail
**status:** maybe this should be in [[PortingIssues]] (see _long_ bug log) + +**_[\#190367](http://bugs.debian.org/190367): libc0.3-dev: `fcntl` `F_GETLK` not implemented (`ENOSYS`)_**
**breaks:** gnome-session (and others) from running
**error:** misc lock-related errors + +-- [[Main/RobertMillan]] - 01 May 2003 + +Text formatting.
-- [[Main/OgnyanKulev]] - 02 May 2003 diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index 607b50af..77736a45 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -95,7 +95,7 @@ about getting applications to work (if possible). * GNU [Coding Standards](http://www.gnu.org/prep/standards.html) * [[TestSuites]] - Posix, Perl, results feedback, etc. * [[Documentation]] -* [[SystemAPILimits]] +* [[System_API_Limitations]] * [[CodeAnnouncements]] - Recent coding projects related to the Hurd
diff --git a/unsorted/SystemAPILimits.mdwn b/unsorted/SystemAPILimits.mdwn deleted file mode 100644 index 8930ef9c..00000000 --- a/unsorted/SystemAPILimits.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -## API Limitations of the GNU system - ----- - -Sometimes building or running a program will fail due to bugs in the system API implementation (in Glibc and the Hurd). Make sure you check this list and know them before porting, otherwise you'll end up debugging something just to find out its an already known bug. - -Taken from the bug lists in debian BTS. If you find more of them (and it is clear in the bug log that it is a bug), please add them to the list below. See: - -* ([source](http://packages.qa.debian.org/h/hurd.html) and [binary](http://packages.debian.org/hurd) debs not synchronized) -* ([binary](http://packages.debian.org/hurd-dev)) -* ([source](http://packages.qa.debian.org/g/glibc.html) & [binary](http://packages.debian.org/libc0.3) debs) -* ([binary](http://packages.debian.org/libc0.3-dev)) - ----- - -These are the known system API limits that have porting implications. - -**_[\#47998](http://bugs.debian.org/47998): `msgget` IPC not implemented_** - -**_[\#184565](http://bugs.debian.org/184565): libc0.3: missing shm\* functions (from ``)_**
**breaks:** cdrtools
**error:** warning: shm\* is not implemented and will always fail - -**_[\#190581](http://bugs.debian.org/190581): nice() doesn't work_**
**breaks:** coreutils
**error:** `nice()` doesn't take effect on some situations - -**_[\#187391](http://bugs.debian.org/187391): libc0.3-dev: `sockaddr_un.sun_path` can't be assigned a `const char *` when compiling with g++_**
**breaks:** fam, gail
**status:** maybe this should be in [[PortingIssues]] (see _long_ bug log) - -**_[\#190367](http://bugs.debian.org/190367): libc0.3-dev: `fcntl` `F_GETLK` not implemented (`ENOSYS`)_**
**breaks:** gnome-session (and others) from running
**error:** misc lock-related errors - --- [[Main/RobertMillan]] - 01 May 2003 - -Text formatting.
-- [[Main/OgnyanKulev]] - 02 May 2003 -- cgit v1.2.3 From 5fb5cd59948b112aaaaa24c406bc1fe7f31a0382 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 5 Apr 2009 19:01:48 +0200 Subject: Remove superseded page. --- hurd/running/debian/BtsFiling.mdwn | 52 -------------------------------------- hurd/running/distrib.mdwn | 2 +- 2 files changed, 1 insertion(+), 53 deletions(-) delete mode 100644 hurd/running/debian/BtsFiling.mdwn (limited to 'hurd/running/distrib.mdwn') diff --git a/hurd/running/debian/BtsFiling.mdwn b/hurd/running/debian/BtsFiling.mdwn deleted file mode 100644 index 90f451a8..00000000 --- a/hurd/running/debian/BtsFiling.mdwn +++ /dev/null @@ -1,52 +0,0 @@ -When you encounter any GNU/Hurd related bugs in a Debian package you can fix, please use the Debian BTS (Bug Tracking System) to report them. - -Managing Debian packages and using the BTS is quite simple. If you're new to Debian, here's a short guide: - -* first of all, check [http://bugs.debian.org/<package>](http://bugs.debian.org) to ensure the problem is not in the BTS already. This is possible for packages and bug numbers. [[TWiki/InterWikis]] is a shorthand way of linking to bugs and packages from this site. i.e. [[DebianBug]]:hurd [[DebianPackage]]:oskit -* you can fetch package sources with: - - apt-get source - -note: this should unpack already - -* and unpack with: - - dpkg-source -x x-y_z.dsc - -* then get all dependencies: - - apt-get -y build-dep - -note: if some dependencies are missing, it most probably means you have to port them first. follow this instructions recursively until done - - :) - -* Debian packages have a makefile in debian/rules, with (at least) the following targets:
-
build
-
Yup, to build
-
binary
-
Generates deb files in ../
-
clean
-
Full clean
-
- -* when you have a patch, send it to the BTS using the reportbug utility (or manually as explained in . The following parameters should be used: - - Severity: important (when the package is unbuildable or uninstallable, lower otherwise.) - Tags: sid, patch - -* be nice to the maintainers. most are friendly and cooperative, and a few could annoy you for months before applying. Be patient. - -Read for extensive documentation on the BTS. - --- [[Main/RobertMillan]] - 10 Jun 2002 - ----- - -Wikification & small changes. - --- [[Main/JoachimNilsson]] - 24 Jun 2002 - -Updates with the new [[TWiki/InterWikis]] rules. - --- [[Main/GrantBow]] - 15 Jan 2003 diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index 77736a45..bbf0a380 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -79,7 +79,7 @@ about getting applications to work (if possible).
Debain Infrastructure
-
Testing is critical in helping the development effort. Bugs (defect reports) can be filed against the Debian software package in which they are found. [[BtsFiling]] tells how to file a Debian bug report. [[DebianPackages]] has some information about how Debian splits the software into packages and some references. There is a buildd autobuilder compiling the Debian Sid archive software for the GNU/Hurd port. [[BuilddStatus]] includes information on the buildd &amp; turtle efforts.
+
Testing is critical in helping the development effort. Bugs (defect reports) can be filed against the Debian software package in which they are found. [[debian/patch_submission]] tells how to file a Debian bug report. [[DebianPackages]] has some information about how Debian splits the software into packages and some references. There is a buildd autobuilder compiling the Debian Sid archive software for the GNU/Hurd port. [[BuilddStatus]] includes information on the buildd &amp; turtle efforts.
-- cgit v1.2.3 From 0075616fc22070b55573da056d0fc6ea42024c63 Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Thu, 4 Jun 2009 15:02:28 +0200 Subject: Updated the Gentoo GNU/Hurd state, removed Bee and cleaned up the dsitrib page a bit. --- hurd/running/distrib.mdwn | 9 ++++++++- hurd/running/gentoo.mdwn | 30 ++++++++++++++++++++++++++++-- 2 files changed, 36 insertions(+), 3 deletions(-) (limited to 'hurd/running/distrib.mdwn') diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index bbf0a380..229e2d8f 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -1,8 +1,15 @@ +Working distributions of GNU/Hurd: + * [[Debian]] + +GNU/Hurd distributions in early stages of development: + * [[Gentoo]] -* [[Bee]] * [[GNU]] + # Issues diff --git a/hurd/running/gentoo.mdwn b/hurd/running/gentoo.mdwn index 89d5d9cf..2a979f41 100644 --- a/hurd/running/gentoo.mdwn +++ b/hurd/running/gentoo.mdwn @@ -3,6 +3,32 @@ Unofficial port to Gentoo and the portage system. It was [announced](http://forums.gentoo.org/viewtopic.php?t=41939&postdays=0&postorder=asc&start=0) March 17, 2003 in the Gentoo forums. There's a #gentoo-irc channel similar to -[[IRC]]. At present (May 2005), there's no activity and Eric Olinger has not -the time to maintain this distri. +[[IRC]]. +### State of the GGH, 2009-05 + +> *Did you work a bit more on the Gentoo GNU/Hurd?* + +I tried to resume my work 3-4 months ago but I found some problems with +portage and python functions not implemented on Hurd so I stopped. I think +that back in 2006 with portage 2.0.54 those functiones weren't necessary. + +> *And do you have some information which might help others advance what you began?* + +I just have all the ebuilds and binary packages I merged online on +[http://www.mundurat.net/ggh/portage](http://www.mundurat.net/ggh/portage). + +To continue my work just take a Debian/Hurd and install portage by hand. + +Once there take the profile and start bootstraping portage and all the +ebuild it needs (patch, python, bzip2...). + +The major problems are: + +- combine the perfect gcc/binutils/glibc/gnumach/hurd and to be able to boot +- lack of development on gnumach/hurd and current 'degraded' status. + +I don't think I can help much right now, but if you have any other +question just write me. + +MiKeL -- cgit v1.2.3 From 50241ad8596afd3d7ce88d526cb8e0f30960263c Mon Sep 17 00:00:00 2001 From: "http://amade.myopenid.com/" Date: Wed, 9 Jun 2010 14:10:32 +0000 Subject: Fix typo & ampersands --- hurd/running/distrib.mdwn | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'hurd/running/distrib.mdwn') diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index 229e2d8f..92904d19 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -71,7 +71,7 @@ about getting applications to work (if possible).
[[SavannahProjects]]
-
Savannah is a CVS &amp; Bug system evolved from a free version of the code that powers sourceforge.net. It has forked and been slightly modified for use by FSF, GNU and non-GNU projects. Actual Development takes place here. There is also a help wanted list.
+
Savannah is a CVS & Bug system evolved from a free version of the code that powers sourceforge.net. It has forked and been slightly modified for use by FSF, GNU and non-GNU projects. Actual Development takes place here. There is also a help wanted list.
@@ -85,8 +85,8 @@ about getting applications to work (if possible).
-
Debain Infrastructure
-
Testing is critical in helping the development effort. Bugs (defect reports) can be filed against the Debian software package in which they are found. [[debian/patch_submission]] tells how to file a Debian bug report. [[DebianPackages]] has some information about how Debian splits the software into packages and some references. There is a buildd autobuilder compiling the Debian Sid archive software for the GNU/Hurd port. [[BuilddStatus]] includes information on the buildd &amp; turtle efforts.
+
Debian Infrastructure
+
Testing is critical in helping the development effort. Bugs (defect reports) can be filed against the Debian software package in which they are found. [[debian/patch_submission]] tells how to file a Debian bug report. [[DebianPackages]] has some information about how Debian splits the software into packages and some references. There is a buildd autobuilder compiling the Debian Sid archive software for the GNU/Hurd port. [[BuilddStatus]] includes information on the buildd & turtle efforts.
-- cgit v1.2.3 From f8aec8d7197e04399df1dca296ee8a867e40600c Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Mon, 2 Aug 2010 12:07:37 +0200 Subject: added arch hurd to the distribution list. --- hurd/running/distrib.mdwn | 1 + 1 file changed, 1 insertion(+) (limited to 'hurd/running/distrib.mdwn') diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index 92904d19..c197ad0e 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -4,6 +4,7 @@ Working distributions of GNU/Hurd: GNU/Hurd distributions in early stages of development: +* [[Arch|arch_hurd]] (features a LiveCD) * [[Gentoo]] * [[GNU]] -- cgit v1.2.3