diff options
| -rw-r--r-- | community/gsoc.mdwn | 9 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/unionmount.mdwn | 55 | ||||
| -rw-r--r-- | community/weblogs/ArneBab/niches_for_the_hurd.mdwn | 24 | ||||
| -rw-r--r-- | community/weblogs/antrik/hurd-mission-statement.mdwn | 39 | ||||
| -rw-r--r-- | contributing.mdwn | 2 | ||||
| -rw-r--r-- | history.mdwn (renamed from hurd/history.mdwn) | 3 | ||||
| -rw-r--r-- | history/hurd-announce (renamed from hurd/history/hurd-announce) | 0 | ||||
| -rw-r--r-- | history/hurd-announce2 (renamed from hurd/history/hurd-announce2) | 0 | ||||
| -rw-r--r-- | history/hurd-flash (renamed from hurd/history/hurd-flash) | 0 | ||||
| -rw-r--r-- | history/hurd-flash10 (renamed from hurd/history/hurd-flash10) | 0 | ||||
| -rw-r--r-- | history/hurd-flash11 (renamed from hurd/history/hurd-flash11) | 0 | ||||
| -rw-r--r-- | history/hurd-flash12 (renamed from hurd/history/hurd-flash12) | 0 | ||||
| -rw-r--r-- | history/hurd-flash13 (renamed from hurd/history/hurd-flash13) | 0 | ||||
| -rw-r--r-- | history/hurd-flash14 (renamed from hurd/history/hurd-flash14) | 0 | ||||
| -rw-r--r-- | history/hurd-flash15 (renamed from hurd/history/hurd-flash15) | 0 | ||||
| -rw-r--r-- | history/hurd-flash2 (renamed from hurd/history/hurd-flash2) | 0 | ||||
| -rw-r--r-- | history/hurd-flash3 (renamed from hurd/history/hurd-flash3) | 0 | ||||
| -rw-r--r-- | history/hurd-flash4 (renamed from hurd/history/hurd-flash4) | 0 | ||||
| -rw-r--r-- | history/hurd-flash5 (renamed from hurd/history/hurd-flash5) | 0 | ||||
| -rw-r--r-- | history/hurd-flash6 (renamed from hurd/history/hurd-flash6) | 0 | ||||
| -rw-r--r-- | history/hurd-flash7 (renamed from hurd/history/hurd-flash7) | 0 | ||||
| -rw-r--r-- | history/hurd-flash8 (renamed from hurd/history/hurd-flash8) | 0 | ||||
| -rw-r--r-- | history/hurd-flash9 (renamed from hurd/history/hurd-flash9) | 0 | ||||
| -rw-r--r-- | history/port_to_l4.mdwn (renamed from hurd/history/port_to_l4.mdwn) | 14 | ||||
| -rw-r--r-- | hurd-l4.mdwn | 11 | ||||
| -rw-r--r-- | hurd/libnetfs.mdwn | 2 | ||||
| -rw-r--r-- | hurd/running.mdwn | 2 | ||||
| -rw-r--r-- | hurd/running/debian.mdwn | 28 | ||||
| -rw-r--r-- | hurd/running/debian/porting.mdwn | 3 | ||||
| -rw-r--r-- | hurd/running/distrib.mdwn | 9 | ||||
| -rw-r--r-- | hurd/running/gentoo.mdwn | 30 | ||||
| -rw-r--r-- | hurd/running/qemu.mdwn | 9 | ||||
| -rw-r--r-- | hurd/running/qemu/babhurd_image.mdwn | 67 | ||||
| -rw-r--r-- | hurd/status.mdwn | 39 | ||||
| -rw-r--r-- | hurd/translator.mdwn | 1 | ||||
| -rw-r--r-- | hurd/translator/tmpfs.mdwn | 11 | ||||
| -rw-r--r-- | hurd/translator/tmpfs/notes_bing.mdwn | 5 | ||||
| -rw-r--r-- | hurd/translator/tmpfs/notes_various.mdwn | 6 | ||||
| -rw-r--r-- | hurd/translator/unionfs.mdwn | 10 | ||||
| -rw-r--r-- | hurd/translator/unionmount.mdwn | 60 | ||||
| -rw-r--r-- | hurd/translator/wishlist_2.mdwn | 2 | ||||
| -rw-r--r-- | index.mdwn | 30 | ||||
| -rw-r--r-- | irc.mdwn | 2 | ||||
| -rw-r--r-- | local.css | 44 | ||||
| -rw-r--r-- | microkernel/mach/gnumach/ports/xen.mdwn | 2 | ||||
| -rw-r--r-- | news/2008-09-11.mdwn | 6 | ||||
| -rw-r--r-- | news/2009-04-20.mdwn | 12 | ||||
| -rw-r--r-- | open_issues/glibc_ptrace.mdwn | 47 | ||||
| -rw-r--r-- | open_issues/grub2.mdwn | 21 | ||||
| -rw-r--r-- | open_issues/grub_legacy.mdwn | 40 | ||||
| -rw-r--r-- | open_issues/grub_legacy/grub-install.patch | 23 | ||||
| -rw-r--r-- | open_issues/tinyproxy.mdwn | 18 | ||||
| -rw-r--r-- | rules/source_repositories.mdwn | 14 | ||||
| -rw-r--r-- | tag/open_issue_porting.mdwn | 7 | ||||
| -rw-r--r-- | user/scolobb.mdwn | 118 |
55 files changed, 709 insertions, 116 deletions
diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn index 2719d2ab..ce3b26fb 100644 --- a/community/gsoc.mdwn +++ b/community/gsoc.mdwn @@ -23,8 +23,13 @@ always open to introducing newcomers to the world of the GNU Hurd outside of any Google Summer of whatever project. Just pick a task from the list pointed to below on this page and get in touch with us! -The GSoC 2009 student application time has come to an end -- we are now -evaluating your applications. +<!-- The GSoC 2009 student application time has come to an end -- we +are now evaluating your applications. --> + +The applications have been evaluated and the following student has +been accepted: + + * [[Sergiu Ivanov|scolobb]] # History diff --git a/community/gsoc/project_ideas/unionmount.mdwn b/community/gsoc/project_ideas/unionmount.mdwn index 47a3d85d..86ef96c7 100644 --- a/community/gsoc/project_ideas/unionmount.mdwn +++ b/community/gsoc/project_ideas/unionmount.mdwn @@ -5,56 +5,7 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[!meta title="Union Mounts"]] - -When setting a translator on Hurd -- similar to mounting a file system on UNIX --- the new node(s) exported by the translator are obscuring the original node -where the translator is set, and any nodes below it in the directory tree. The -translator itself can access the underlying node (which is a very nice feature, -as it allows translators presenting the contents of the node in a different -format); but it's no longer accessible from the "outside". - -Plan9 has a feature where a file system can be mounted in union mode: the new -file system doesn't obscure the mount point in this case, but instead the -contents are combined. (This feature has also been under discussion in Linux -for a couple of years now, under the label "VFS-based union mounts".) - -This kind of union mounts is generally useful, as it's sometimes more -convenient than unioning existing filesystem locations with unionfs -- it's not -necessary to mount a file system that is to be unioned at some external -location first: just union-mount it directly at the target location. - -But union mounts also allow creating passive translator hierarchies: If there -is a passive translator on a parent node, and further passive translators on -child nodes, the union mount allows the child nodes with the further translator -settings still to be visible after the parent translator has started. - -This could be useful for device nodes for example: let's say we have an -ethernet multiplexer at /dev/veth. Now the virtual subnodes could all be -directly under /dev, i.e. /dev/veth0, /dev/veth1 etc., and explicitely refer to -the main /dev/veth node in the translator command line. It would be more -elegant however to store the virtual nodes direcly below the main multiplexer -node -- /dev/veth/0, /dev/veth/1 etc. - -There are two possible approaches how union mounts could be implemented in the -Hurd. The first one is to let the various translators handle union mounts -internally, i.e. let them present the underlying nodes to the clients in -addition to the actual nodes they export themselfs. This probably can be -implemented as some kind of extension to the existing netfs and diskfs -libraries. - -The other possible apporach is less efficient and probably more tricky, but -probably also more generic: create a special unionmount translator, which -serves as a kind of proxy: setting the union-mounted translator on some -internal node; and at the actual mount location, presenting a union of the -nodes exported by this translator, and the nodes from the underlying file -system. - -The goal of this project is implementing union mounts using either of the -approaches described above. (Though it might be useful initially to prototype -both for comparision.) The ethernet multiplexer shall serve as an example use -case -- any changes necessary to allow using it with the union mount -functionality are also to be considered part of the task. +[[!meta redir=hurd/translator/unionmount]] diff --git a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn index 8b6c4226..ff169b0a 100644 --- a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn +++ b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn @@ -112,7 +112,13 @@ monologue at the end... I really should put these ideas into my blog.)"* Another example of features which would be easily possible with the Hurd: -* media-player translator: +* transparent ftp (already possible!): + - settrans -c ftp: /hurd/hostmux /hurd/ftpfs / + - ls ftp://ftp.gnu.org/ + - # -> list the files on the FTP server. + + +* media-player translator: - settrans play /hurd/mediaplayer_play - cp song1.ogg song2.ogg play - # -> files get buffered and played. @@ -246,8 +252,8 @@ Applications A minor phase, which will surely be interleaved with the others: Making the ideas tangible to turn them into ways how people can use the Hurd. -"Hey, look, this is the Hurd. You can use it like this to do that which you can't do -as well/easily/elegantly in any other way." +*"Hey, look, this is the Hurd. You can use it like this to do that which you can't do +as well/easily/elegantly in any other way."* ### Applications for private use @@ -264,18 +270,18 @@ it's too hard. From what I see, each direct cool application must be about as simple as -$ qemu hurd-is-cool.img -$ login root -$ settrans cool /hurd/cool +$ qemu hurd-is-cool.img +$ login root +$ settrans cool /hurd/cool $ ls cool One main focus in this example is: No command line parameters but the ones we really need. No "-a", if the example is also cool without it. No "--console" if it works otherwise. -Especially no "qemu --cd livecd --hda hurd.img ..." - that one is great for -specialists, but the goal here isn't to teach people better usage of qemu, -but to show them that the Hurd is cool, and only that. +Especially no *"qemu --cd livecd --hda hurd.img ..."* - that one is great for +people who already know qemu or want to learn it, but the goal here isn't to teach people +better usage of qemu, but to show them that the Hurd is cool, and only that. All that interesting advanced stuff just gets newcomers confused. diff --git a/community/weblogs/antrik/hurd-mission-statement.mdwn b/community/weblogs/antrik/hurd-mission-statement.mdwn new file mode 100644 index 00000000..592e176a --- /dev/null +++ b/community/weblogs/antrik/hurd-mission-statement.mdwn @@ -0,0 +1,39 @@ +For a while I have been thinking about the lack of a roadmap for the +Hurd; but now I realized that we lack something even more fundamental: a +simple mission statement -- i.e. saying where we want to go, rather +than how we want to get there. I think many of the problems we have are +directly or indirectly related to that. + +As we didn't have such a mission statement so far, the people currently +involved have vastly different ideas about the mission, which of course +makes it a bit hard to come up with a suitable one now. However, I +managed to come up with something that I believe is generic enough so +all contributors can subscribe to it: + +> *The mission of the Hurd project is: to create a general-purpose +> kernel suitable for the GNU operating system, which is viable for +> everyday use, and gives users and programs as much control over their +> computing environment as possible.* + +*"Suitable for GNU"* in the first part implies a number of things. I +explicitely mentioned *"general-purpose"*, because this an important +feature that sets the Hurd apart from many other microkernel projects, +but isn't immediately obvious. + +I didn't mention that it must be entirely free software, as this should +be obvious to anyone familiar with GNU. + +Another thing I did not mention, because it's too controversial: how +much UNIX do we need? I think that being suitable for GNU requires a +pretty high degree of UNIX compatibility, and also that the default +environment looks to the user more or less like UNIX. However, some +people claimed in the past that GNU could do without UNIX -- the wording +used here doesn't totally preclude such views. + +The second part also leaves a lot of slack: I for my part still believe +that a Mach-based Hurd can be viable for everyday use; but those who +think that a microkernel change is required, should be happy with this +wording as well. + +The third part tries to express the major idea behind the Hurd design in +the most compact and generic way possible. diff --git a/contributing.mdwn b/contributing.mdwn index 9e2396cf..a5b3a34e 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -41,7 +41,7 @@ For one there's the implementation of the *[[Hurd]] running on the meant when people are talking about GNU/Hurd systems. This system has mostly been designed and implemented -[[in_the_'90s|hurd/history]]. It works and is usable. +[[in the '90s|history]]. It works and is usable. For example, these web pages are rendered on a [GNU/Hurd system](http://www.bddebian.com/cgi-bin/uptime). diff --git a/hurd/history.mdwn b/history.mdwn index 18a1506f..927482d9 100644 --- a/hurd/history.mdwn +++ b/history.mdwn @@ -48,7 +48,8 @@ full functionality. Later we hope to have a modular emulator divided into multiple processes. [Gnusletter, Jan. 1991]. </BLOCKQUOTE> -RMS explains the relationship between the [[documentation/Hurd_and_Linux]], where he mentions +RMS explains the relationship between [[the Hurd and +Linux|hurd/documentation/hurd-and-linux]], where he mentions that the FSF started developing the Hurd in 1990. As of [Gnusletter, Nov. 1991], the Hurd (running on Mach) is GNU's official kernel. diff --git a/hurd/history/hurd-announce b/history/hurd-announce index 2f165ad8..2f165ad8 100644 --- a/hurd/history/hurd-announce +++ b/history/hurd-announce diff --git a/hurd/history/hurd-announce2 b/history/hurd-announce2 index dce41c43..dce41c43 100644 --- a/hurd/history/hurd-announce2 +++ b/history/hurd-announce2 diff --git a/hurd/history/hurd-flash b/history/hurd-flash index d1bacc79..d1bacc79 100644 --- a/hurd/history/hurd-flash +++ b/history/hurd-flash diff --git a/hurd/history/hurd-flash10 b/history/hurd-flash10 index d6d5685b..d6d5685b 100644 --- a/hurd/history/hurd-flash10 +++ b/history/hurd-flash10 diff --git a/hurd/history/hurd-flash11 b/history/hurd-flash11 index 57851b01..57851b01 100644 --- a/hurd/history/hurd-flash11 +++ b/history/hurd-flash11 diff --git a/hurd/history/hurd-flash12 b/history/hurd-flash12 index 5be9c94e..5be9c94e 100644 --- a/hurd/history/hurd-flash12 +++ b/history/hurd-flash12 diff --git a/hurd/history/hurd-flash13 b/history/hurd-flash13 index a2de6bfd..a2de6bfd 100644 --- a/hurd/history/hurd-flash13 +++ b/history/hurd-flash13 diff --git a/hurd/history/hurd-flash14 b/history/hurd-flash14 index 2d67687a..2d67687a 100644 --- a/hurd/history/hurd-flash14 +++ b/history/hurd-flash14 diff --git a/hurd/history/hurd-flash15 b/history/hurd-flash15 index 0785ac59..0785ac59 100644 --- a/hurd/history/hurd-flash15 +++ b/history/hurd-flash15 diff --git a/hurd/history/hurd-flash2 b/history/hurd-flash2 index b1d4f66f..b1d4f66f 100644 --- a/hurd/history/hurd-flash2 +++ b/history/hurd-flash2 diff --git a/hurd/history/hurd-flash3 b/history/hurd-flash3 index 19a5f371..19a5f371 100644 --- a/hurd/history/hurd-flash3 +++ b/history/hurd-flash3 diff --git a/hurd/history/hurd-flash4 b/history/hurd-flash4 index 89ae9848..89ae9848 100644 --- a/hurd/history/hurd-flash4 +++ b/history/hurd-flash4 diff --git a/hurd/history/hurd-flash5 b/history/hurd-flash5 index 041a0ef7..041a0ef7 100644 --- a/hurd/history/hurd-flash5 +++ b/history/hurd-flash5 diff --git a/hurd/history/hurd-flash6 b/history/hurd-flash6 index e774714e..e774714e 100644 --- a/hurd/history/hurd-flash6 +++ b/history/hurd-flash6 diff --git a/hurd/history/hurd-flash7 b/history/hurd-flash7 index ce6e08d2..ce6e08d2 100644 --- a/hurd/history/hurd-flash7 +++ b/history/hurd-flash7 diff --git a/hurd/history/hurd-flash8 b/history/hurd-flash8 index 555186ec..555186ec 100644 --- a/hurd/history/hurd-flash8 +++ b/history/hurd-flash8 diff --git a/hurd/history/hurd-flash9 b/history/hurd-flash9 index 1ff32ba9..1ff32ba9 100644 --- a/hurd/history/hurd-flash9 +++ b/history/hurd-flash9 diff --git a/hurd/history/port_to_l4.mdwn b/history/port_to_l4.mdwn index ec72def4..cdf048e6 100644 --- a/hurd/history/port_to_l4.mdwn +++ b/history/port_to_l4.mdwn @@ -21,20 +21,20 @@ in November 2000. The project itself then was mostly lead by Marcus Brinkmann and Neal Walfield. Even though there was progress -- see, for example, the -[[QEMU_image_for_L4|running/qemu/image_for_l4]] -- this port never reached a +[[QEMU image for L4|hurd/running/qemu/image for l4]] -- this port never reached a releasable state. Eventually, a straight-forward port of the original Hurd's design wasn't deemed feasible anymore by the developers, partly due to them not cosidering L4 suitable for implementing a general-purpose operating system on top of it, and because of deficiencies in the original Hurd's design, which -they discovered along their way. Read the [[critique]] and a -[[ng/position_paper]]. +they discovered along their way. Read the [[hurd/critique]] and a +[[hurd/ng/position paper]]. By now, the development of Hurd/L4 has stopped. However, Neal Walfield moved on to working on a newly designed kernel called [[microkernel/viengoos]]. Over the years, a lot of discussion have been held on the [[mailing lists/l4-hurd]] mailing list, which today is still the right place -for [[next-generation_Hurd|ng]] discussions. +for [[next-generation Hurd|hurd/ng]] discussions. Development of Hurd/L4 was done in the `hurd-l4` module of the Hurd CVS repository. The `doc` directory contains a design document that is worth @@ -83,10 +83,10 @@ explains: > rejected some parts of the Hurd's design. The > [[open issues/resource management problems]] were > what prompted me to look at L4. Also, some of the problems with -> [[translator]]s were already well-known to us. (For a more detailed -> description of the problems we have identified, see our [[critique]] in the +> [[hurd/translator]]s were already well-known to us. (For a more detailed +> description of the problems we have identified, see our [[hurd/critique]] in the > 2007 July's SIGOPS OSR. We have also written a forward-looking -> [[ng/position_paper]].) +> [[hurd/ng/position paper]].) > We visited Jonathan Shapiro at Hopkins in January 2006. This resulted in a > number of discussions, some quite influential, and not always in a way which diff --git a/hurd-l4.mdwn b/hurd-l4.mdwn new file mode 100644 index 00000000..5ad3c3d4 --- /dev/null +++ b/hurd-l4.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!meta redir=history/port_to_l4]] diff --git a/hurd/libnetfs.mdwn b/hurd/libnetfs.mdwn index fef6a8ef..a2bf47ee 100644 --- a/hurd/libnetfs.mdwn +++ b/hurd/libnetfs.mdwn @@ -148,7 +148,7 @@ result. Therefore, it is not quite right to perceive *libnetfs* nodes as filesystem nodes. Instead, the focus of attention should stay upon light nodes. -##How It Wors: A More Verbose Description +##How It Works: A More Verbose Description At first let us see how the a *libnetfs*-based translator responds to lookup requests. At the beginning the *netfs_attempt_lookup* callback diff --git a/hurd/running.mdwn b/hurd/running.mdwn index 95dc024a..470b5f0b 100644 --- a/hurd/running.mdwn +++ b/hurd/running.mdwn @@ -8,6 +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]]."]]"""]] +There are several different ways to run a GNU/Hurd system: + * [[Distrib]] - Distributions based on the Hurd * [[microkernel/mach/gnumach/ports/Xen]] - In Xen * [[Live_CD]] diff --git a/hurd/running/debian.mdwn b/hurd/running/debian.mdwn index 82d84bbe..97d35bd7 100644 --- a/hurd/running/debian.mdwn +++ b/hurd/running/debian.mdwn @@ -1,16 +1,28 @@ [[!meta title="Debian GNU/Hurd"]] -- Debian [[FAQ]] -- Frequently Asked Questions -- [[After_install]] -- Do this to get networking, new console and X -- [Presentation](http://people.debian.org/~mbanck/talks/hurd_lt2004/html/) - *Debian GNU/Hurd* by [[MichaelBanck]], LinuxTag 2004 Karlsruhe -- [[Status]] -- [[Porting]] -- Helping with porting packages - * [[Patch_submission]] -- How to submit patches for build failures +### Debian Resources - Official page about the Debian GNU/Hurd port: [Debian GNU/Hurd](http://www.debian.org/ports/hurd/) + +- Debian [[FAQ]] -- Frequently Asked Questions + +### Installing + - [Installation Instructions](http://www.debian.org/ports/hurd/hurd-install) - [Upgrading K11 or K14 based systems to unstable](http://lists.debian.org/debian-hurd/2007/09/msg00007.html) -- [Archive Qualification](http://wiki.debian.org/ArchiveQualification/hurd-i386) +- [[After_install]] -- Do this to get networking, new console and X + +### Contributing + +- [[Porting]] -- Helping with porting packages + * [[Patch_submission]] -- How to submit patches for build failures - [[Creating_image_tarball]] + +### Additional Information + +- [Presentation](http://people.debian.org/~mbanck/talks/hurd_lt2004/html/) + *Debian GNU/Hurd* by [[MichaelBanck]], LinuxTag 2004 Karlsruhe +- [[Status]] +- [Archive Qualification](http://wiki.debian.org/ArchiveQualification/hurd-i386) + diff --git a/hurd/running/debian/porting.mdwn b/hurd/running/debian/porting.mdwn index 0882bea3..aa044570 100644 --- a/hurd/running/debian/porting.mdwn +++ b/hurd/running/debian/porting.mdwn @@ -24,6 +24,9 @@ the list below or in the [Alioth task tracker](http://alioth.debian.org/pm/task.php?group_project_id=34&group_id=30628&func=browse) so other people do not do duplicated work. +Also, the [[community/HurdFr]] guys maintain their own [liste des travaux de +packaging](http://wiki.hurdfr.org/index.php/Liste_des_travaux_de_packaging). + Aside from the Alioth task tracker, here is a list of some packages (the important ones, as they're, e.g., blocking other packages from being built) that need someone to work on them. 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]] +<!-- Bee GNU/Hurd doesn't seem to exist anymore. +* [[Bee]] +--> # 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 diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index 661084d3..a059f3b1 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -4,8 +4,9 @@ This page discusses things for [[Unix]] systems, there is a separate page for # Readily Available Images -[Official Debian GNU/Hurd QEMU -image](http://ftp.debian-ports.org/debian-cd/K16/debian-hurd-k16-qemu.img.tar.gz) +To try out the Hurd you can use the image of the Debian GNU/Hurd: + +* [Official Debian GNU/Hurd QEMU image](http://ftp.debian-ports.org/debian-cd/K16/debian-hurd-k16-qemu.img.tar.gz) (!) Note that the following are unofficial images: they have been prepared by volunteers and may not have been tested extensively. @@ -15,7 +16,9 @@ volunteers and may not have been tested extensively. * [Disk image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) with a short intro on translators. Just start it with 'qemu *disk_image.img*'. - It should work without any of the configuration below. when you use it, please [tell me your experience with it](http://draketo.de/contact)! - [[community/weblogs/ArneBab]] + It should work without any of the configuration below. If you want to know what you can do + with it, please have a look at [[its_wikipage|hurd/running/qemu/babhurd_image]]. And when + you use it, please [tell me your experience with it](http://draketo.de/contact)! - [[community/weblogs/ArneBab]] <!--* [Announcement](http://lists.debian.org/debian-hurd/2007/09/msg00000.html) of another image. - The link in the email doesn't work anymore, too old. //--> diff --git a/hurd/running/qemu/babhurd_image.mdwn b/hurd/running/qemu/babhurd_image.mdwn new file mode 100644 index 00000000..c0952fcf --- /dev/null +++ b/hurd/running/qemu/babhurd_image.mdwn @@ -0,0 +1,67 @@ +What this little Hurd image can do +---------------------------------- + +### About this text + +This is the README file accompanying a +[disk\_image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) for +[[running_the_GNU/Hurd_via_qemu|hurd/running/qemu]]. To run the disk image, just use *'qemu +disk_image.img'*. + +You can find the custom *.bashrc* used to tell the user about it as well as this text itself +in the Mercurial repository [hurd_intro](http://bitbucket.org/ArneBab/hurd_intro). + +### Intro + +The Hurd has some unique capabilities, and we created this simple image +to enable you to easily try two of them: + +* The simplest of translators: Hello World! +* Transparent FTP + +### Hello World + +To try out the simplest of translators, you can go the following simple steps: + + $ cat hello + $ setrans hello /hurd/hello + $ cat hello + "Hello World!" + $ settrans -g hello + $ cat hello + +What you do with these steps is first verifying that the file "hello" is empty. + +Then you setup the translator /hurd/hello in the file/node hello. + +After that you check the contents of the file, and the translator returns "Hello World!". + +To finish it, you tell the translator to go away from the file "hello" via "settrans -g hello" and verify that now the file is empty again. + +### Transparent FTP + +We already setup a a transparent FTP translator for you at /ftp: + +With it you can easily access public FTP via the file system, for example the one from the GNU project: + + $ ls /ftp://ftp.gnu.org/ + +But you can also do this very easily yourself: + + $ # Setup the translator on the node ftp: + $ settrans -c ftp: /hurd/hostmux /hurd/ftpfs / + +and you can access FTP sites via the pseudo-directory ftp:, for example with + + $ ls ftp://ftp.gnu.org/ + +What you do here is setting up the translator /hurd/hostmux on ftp: and passing it the translator /hurd/ftpfs to use for resolving accesses as well as / as additional path component. + + +These were only two basic usages of translators on the Hurd. We're sure you'll quickly see many other ways to use this. + +As a last comment: You can setup a translator on any node you have access to, so you can for example mount any filesystems as normal user. + +You might currently be logged in as root, but you could just as well do the same as normal user. + +Why don't you try it out? diff --git a/hurd/status.mdwn b/hurd/status.mdwn index 1122b703..a22802ff 100644 --- a/hurd/status.mdwn +++ b/hurd/status.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2001, 2002, 2007, 2008 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2001, 2002, 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 @@ -61,3 +61,38 @@ well would be unfortunate. Moreover, it would lessen the possibility that they would want to try the Hurd again in the future. +## Usability Reports + +### Olaf Buddenhagen, 2009-06-09 + +> I have been using the Hurd for most of my everyday work for some two +> years now. Most of the time it's pretty OK, but occasionally programs +> crash, or the screen session dies, or even the whole system. Also, +> various programs simply don't work at all, or don't work in certain +> situations. +> +> While I have learned to work around many of these issues, I don't +> believe I would be able to use it as my primary system, without having a +> GNU/Linux system running in parallel, as a fallback for all the stuff +> that doesn't work on the Hurd. +> +> [...] +> +> One particular problem for desktop use is the fact that while X does +> work, it works very poorly -- it's not only slow and jerky all the time, +> but also tends to lock up completely. (At least with the local socket +> transport... Haven't tried whether forcing TCP works better.) +> +> Note that while many of the stability problems are simply bugs to fix, +> the system will still be very fragile in the absence of these -- a +> simple port leak is sufficient to kill it within seconds. This is +> something that can't be easily solved. Properly fixing this will require +> a sound resource accounting framework, i.e. very fundamental changes to +> the system... Though I tend to believe that it could be improved at +> least partially, at the expense of flexibility, by enforcing certain +> fixed limits on users, processes etc. like other UNIX systems do. +> +> [...] +> +> [But] unlike a few years back [...] the system is stable enough under +> load nowadays [...]. diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index 8f2f07b4..5c14cfa9 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -70,6 +70,7 @@ available. * [[cvsfs]] * [[tmpfs]] * [[procfs]] +* [[unionmount]] * ... diff --git a/hurd/translator/tmpfs.mdwn b/hurd/translator/tmpfs.mdwn index abd47c96..0179ad6c 100644 --- a/hurd/translator/tmpfs.mdwn +++ b/hurd/translator/tmpfs.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 @@ -13,7 +14,13 @@ is included in the section entitled It is based on [[libdiskfs]]. -It's not working correctly at the moment. +Even though there are other possibilities of creating a +[[libstore/examples/ramdisk]] and running a regular, for example, [[`ext2` file +system|ext2fs]] on it, having a real `tmpfs` is better, as it need not deal +with the additional block-level indirection layer that `ext2` (or any other +disk-based file system) imposes. + +However, `tmpfs` is not working correctly at the moment: [[!inline pages="hurd/translator/tmpfs/*" diff --git a/hurd/translator/tmpfs/notes_bing.mdwn b/hurd/translator/tmpfs/notes_bing.mdwn index b36fc1aa..fa3eeac2 100644 --- a/hurd/translator/tmpfs/notes_bing.mdwn +++ b/hurd/translator/tmpfs/notes_bing.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 @@ -8,6 +9,8 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] +[[!tag open_issue_hurd]] + 1. to run tmpfs as a regular user, /servers/default-pager must be executable by that user. by default it seems to be set to read/write. diff --git a/hurd/translator/tmpfs/notes_various.mdwn b/hurd/translator/tmpfs/notes_various.mdwn index 3ec649e5..01dc87d2 100644 --- a/hurd/translator/tmpfs/notes_various.mdwn +++ b/hurd/translator/tmpfs/notes_various.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2005, 2006, 2007, 2008 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -9,6 +9,8 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] +[[!tag open_issue_hurd]] + <antrik> hde: what's the status on tmpfs? <hde> Broke <hde> k0ro traced the errors like the assert show above to a pager problem. diff --git a/hurd/translator/unionfs.mdwn b/hurd/translator/unionfs.mdwn index 8a29d0f7..6f845102 100644 --- a/hurd/translator/unionfs.mdwn +++ b/hurd/translator/unionfs.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 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 @@ -15,3 +15,11 @@ is included in the section entitled # `stowfs` ... is a special mode of `unionfs`. + +# See Also + + * [[unionmount]] + +# External Links + + * [*Unioning file systems for Linux*](http://valerieaurora.org/union/) diff --git a/hurd/translator/unionmount.mdwn b/hurd/translator/unionmount.mdwn new file mode 100644 index 00000000..47a3d85d --- /dev/null +++ b/hurd/translator/unionmount.mdwn @@ -0,0 +1,60 @@ +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!meta title="Union Mounts"]] + +When setting a translator on Hurd -- similar to mounting a file system on UNIX +-- the new node(s) exported by the translator are obscuring the original node +where the translator is set, and any nodes below it in the directory tree. The +translator itself can access the underlying node (which is a very nice feature, +as it allows translators presenting the contents of the node in a different +format); but it's no longer accessible from the "outside". + +Plan9 has a feature where a file system can be mounted in union mode: the new +file system doesn't obscure the mount point in this case, but instead the +contents are combined. (This feature has also been under discussion in Linux +for a couple of years now, under the label "VFS-based union mounts".) + +This kind of union mounts is generally useful, as it's sometimes more +convenient than unioning existing filesystem locations with unionfs -- it's not +necessary to mount a file system that is to be unioned at some external +location first: just union-mount it directly at the target location. + +But union mounts also allow creating passive translator hierarchies: If there +is a passive translator on a parent node, and further passive translators on +child nodes, the union mount allows the child nodes with the further translator +settings still to be visible after the parent translator has started. + +This could be useful for device nodes for example: let's say we have an +ethernet multiplexer at /dev/veth. Now the virtual subnodes could all be +directly under /dev, i.e. /dev/veth0, /dev/veth1 etc., and explicitely refer to +the main /dev/veth node in the translator command line. It would be more +elegant however to store the virtual nodes direcly below the main multiplexer +node -- /dev/veth/0, /dev/veth/1 etc. + +There are two possible approaches how union mounts could be implemented in the +Hurd. The first one is to let the various translators handle union mounts +internally, i.e. let them present the underlying nodes to the clients in +addition to the actual nodes they export themselfs. This probably can be +implemented as some kind of extension to the existing netfs and diskfs +libraries. + +The other possible apporach is less efficient and probably more tricky, but +probably also more generic: create a special unionmount translator, which +serves as a kind of proxy: setting the union-mounted translator on some +internal node; and at the actual mount location, presenting a union of the +nodes exported by this translator, and the nodes from the underlying file +system. + +The goal of this project is implementing union mounts using either of the +approaches described above. (Though it might be useful initially to prototype +both for comparision.) The ethernet multiplexer shall serve as an example use +case -- any changes necessary to allow using it with the union mount +functionality are also to be considered part of the task. diff --git a/hurd/translator/wishlist_2.mdwn b/hurd/translator/wishlist_2.mdwn index 3ea68999..a927db55 100644 --- a/hurd/translator/wishlist_2.mdwn +++ b/hurd/translator/wishlist_2.mdwn @@ -76,6 +76,8 @@ Here's an [idea](http://www.circlemud.org/~jelson/software/fusd/docs/node13.html 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? +*Definitely: Copy my email in there to send it.* -- [[ArneBab|community/weblogs/ArneBab]] + ## <a name="UUEncode"> </a> 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). @@ -9,12 +9,25 @@ 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]]."]]"""]] -**What Is the GNU Hurd?** -The GNU Hurd is the GNU project's replacement for the Unix kernel. -The Hurd is a collection of servers that run on the Mach microkernel +<div id="statements"> +<div id="what-is"> +<p class="statement-title">What is the GNU Hurd?</p> +<p>The GNU Hurd is the GNU project's replacement for the Unix kernel. +It is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar -kernels (such as Linux). *[[More_detailed.|hurd/what_is_the_gnu_hurd]]* +kernels (such as Linux). +<em>[[More_detailed|hurd/what_is_the_gnu_hurd]].</em></p> +</div> +<div id="mission"> +<p class="statement-title">What is the mission of the GNU Hurd project?</p> +<p>Our mission is to create a general-purpose kernel suitable +for the GNU operating system, which is viable for everyday use, +and gives users and programs as much control over their +computing environment as possible. +<em>[[Our mission explained|community/weblogs/antrik/hurd-mission-statement]].</em></p> +</div> +</div> --- @@ -73,10 +86,15 @@ The most functional distribution of the Hurd is the one provided by Debian. Find more information about it at the [Debian GNU/Hurd website](http://www.debian.org/ports/hurd/hurd-install). -There are [[various_possibilities|hurd/running]] of running a GNU/Hurd system. +Along with it there are [[various_ways|hurd/running]] to run a GNU/Hurd system. +Three of them are + +* installing a [[GNU/Hurd_distribution|hurd/running/distrib]], +* running it [[in_Xen|microkernel/mach/gnumach/ports/xen]] and +* starting a [[Hurd_qemu_image|hurd/running/qemu]] or [[Hurd_LiveCD|hurd/running/live_cd/]]. And these web pages are a living proof of the usability of the Hurd, as they -are rendered on a Debian GNU/Hurd system. +are rendered on a [[Debian_GNU/Hurd|hurd/running/debian]] system. ## Current Status @@ -53,7 +53,7 @@ to always greet the channel when you enter and before leave. Starting in early 2008, there have been regular IRC meetings held between the (now former) [[community/GSoC]] students and their mentors. These continue to take place even that the [[Google_Summer_of_Code_2008|community/gsoc/2008]] is -over, and still take place, **every Friday at 19:00 UTC in the `#hurd` +over, and still take place, currently **every Tuesday and Friday at 12:00 UTC in the `#hurd` channel**. Of course, the meetings are not only for (former) GSoC students and mentors, but open to any interested party. So, everyone, take your chance to chat with GNU Hurd developers! @@ -192,7 +192,7 @@ a:hover .newsitem { - border: 1px solid black; + border: 1px solid grey; overflow: auto; } .newsitem .newsitemheader .header @@ -200,8 +200,8 @@ a:hover max-width: 30%; float: left; margin-right: 1em; - border-bottom: 1px solid black; - border-right: 1px solid black; + border-bottom: 1px solid grey; + border-right: 1px solid grey; } .newsitem .header, .newsitem .author @@ -216,9 +216,15 @@ a:hover .newsitem .actions ul { border-bottom-style: none; - padding: 0.5em 0; + padding: 0.5em 0em; line-height: 1; } +.newsitemcontent +{ + padding-left: 0.2em; + padding-top: 0.1em; + +} .newsitemcontent p { margin: 0.3em; @@ -251,3 +257,33 @@ a:hover border-width: thin; border-style: dotted; } + +#statements +{ + display: table; +} +.statement-title +{ + text-align: center; + font-weight: bold; +} +#what-is +{ + display: table-cell; + width: 50%; + vertical-align: top; + text-align: justify; + padding-right: 1ex; + padding-top: 0.3em; + padding-bottom: 0.3em; +} + +#mission +{ + display: table-cell; + vertical-align: top; + text-align: justify; + padding-left: 1em; + padding-top: 0.3em; + padding-bottom: 0.3em; +} diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn index a4c27c6a..c544fd57 100644 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ b/microkernel/mach/gnumach/ports/xen.mdwn @@ -22,7 +22,7 @@ You can either get binaries at <http://youpibouh.thefreecat.org/hurd-xen/> or bu ## GNU/Hurd system -/!\ You need an already installed GNU/Hurd system. +/!\ You need an already installed [[GNU/Hurd_system|hurd/running]]. If you have a free partition, you can fdisk to type 0x83, create a filesystem using: diff --git a/news/2008-09-11.mdwn b/news/2008-09-11.mdwn index 8dc39924..7d25e5a6 100644 --- a/news/2008-09-11.mdwn +++ b/news/2008-09-11.mdwn @@ -8,6 +8,6 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -Please see [[the_community/gsoc_page|community/gsoc]] for information about how -our **Google Summer of Code 2008 participation** worked out. **Congratulations -to both students and mentors!** +All five students who worked on the Hurd during the **Google Summer of Code 2008** succeeded +in their projects. For more information please see [[the_community/gsoc_page|community/gsoc]]. +**Congratulations to both students and mentors!** diff --git a/news/2009-04-20.mdwn b/news/2009-04-20.mdwn new file mode 100644 index 00000000..69831cca --- /dev/null +++ b/news/2009-04-20.mdwn @@ -0,0 +1,12 @@ +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +Sergiu Ivanov will be working on [[unionmount_translators|user/scolobb]] during +the **Google Summer of Code 2009**. diff --git a/open_issues/glibc_ptrace.mdwn b/open_issues/glibc_ptrace.mdwn new file mode 100644 index 00000000..b4c529d7 --- /dev/null +++ b/open_issues/glibc_ptrace.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="glibc: ptrace"]] + +[[!tag open_issue_glibc]] + +`ptrace` has some issues (`sysdeps/mach/hurd/ptrace.c`). + + * Our implementation (and the generic one in `misc/ptrace.c`) differ + from the Linux one (`sysdeps/unix/sysv/linux/ptrace.c`) + w.r.t. handling of... + + * the third argument: `int data` vs. `void *data`; + + * `void *addr2` -- Linux doesn't have this, but we provide some + additional functionalty using this; + + * function declaration: Linux has **`long`** `int ptrace (enum + __ptrace_request __request, ...)` **`__THROW`**, we have `int ptrace + (enum __ptrace_request __request, ...)`; + + * interface do differ, e.g., Linux' `PTRACE_GETREGS` uses `void + *data`, we use `void *addr` for returning the struct, and in + Linux this is a `struct user_regs_struct` from `linux/user.h`, + and for us it is a `struct i386_thread_state` from + `mach/i386/thread_status.h`; + + * Linux probides some functionality that we don't provide, e.g., + `PTRACE_SINGLESTEP`. + + * Some parts are wrongly implemented, e.g., `PTRACE_GETREGS` and + `PTRACE_SETREGS` both do the same thing. + + * `return` values are wrong, e.g., `return EOPNOTSUPP` should instead + set `errno = EOPNOTSUPP` and `return -1` in a few places (but not + with the three `PTRACE_PEEK*` requests. + +Also consider the `sysdeps/generic/sys/ptrace.h` and +`sysdeps/unix/sysv/linux/sys/ptrace.h` files. diff --git a/open_issues/grub2.mdwn b/open_issues/grub2.mdwn new file mode 100644 index 00000000..235950a4 --- /dev/null +++ b/open_issues/grub2.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!meta title="GRUB2"]] + +[[!tag open_issue_porting]] + +Just like [[GRUB (legacy)|grub_legacy]], GRUB2 needs to be ported for being +installable when attempted to be installed *from* GNU/Hurd systems: + + $ sudo grub-probe --target=device /boot/grub + grub-probe: error: cannot find a device for /boot/grub. + +Etc. diff --git a/open_issues/grub_legacy.mdwn b/open_issues/grub_legacy.mdwn new file mode 100644 index 00000000..cb69d10b --- /dev/null +++ b/open_issues/grub_legacy.mdwn @@ -0,0 +1,40 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +[[!meta title="GRUB (legacy)"]] + +[[!tag open_issue_porting]] + +Even though it is customarily used *for* booting GNU/Hurd systems, [[GRUB]], +specifically GRUB legacy (which is still in wide-spread use, despite that +rather depricative nickname), has never been ported to be installable when +attempted to be installed *from* GNU/Hurd systems: + + # grub-install \(hd0\) + df: Warning: cannot read table of mounted filesystems + df: Warning: cannot read table of mounted filesystems + Could not find device for /boot: Not found or not a block device. + +There is a patch, [[grub-install.patch]], to fix that. + + +`grub-install`, however, still fails while invoking `grub`: + + # grub-install \(hd0\) + The file /boot/grub/stage1 not read correctly. + + # grub + [...] + grub> dump (hd0,0)/boot/grub/stage1 /tmp/grub_stage1 + + Error 18: Selected cylinder exceeds maximum supported by BIOS + + +The successor, [[GRUB2]], also needs to be ported. diff --git a/open_issues/grub_legacy/grub-install.patch b/open_issues/grub_legacy/grub-install.patch new file mode 100644 index 00000000..3f6341b4 --- /dev/null +++ b/open_issues/grub_legacy/grub-install.patch @@ -0,0 +1,23 @@ +2005-08-23 Thomas Schwinge <tschwinge@gnu.org> + + * grub-install (find_device): Rough port for GNU/Hurd. + + +--- grub-install.orig 2005-08-23 16:56:02.000000000 +0200 ++++ grub-install 2005-08-23 17:01:55.000000000 +0200 +@@ -263,7 +263,14 @@ + find_device () { + # For now, this uses the program `df' to get the device name, but is + # this really portable? +- tmp_fname=`df $1/ | sed -n 's%.*\(/dev/[^ ]*\).*%\1%p'` ++ # No. (Not even on GNU/Linux.) - Thomas Schwinge ++ ++ case $host_os in ++ gnu*) # TODO: What about using multiple devices? ++ tmp_fname=`fsysopts $1/ | sed -n 's%.*device:\([^ ]*\).*%/dev/\1%p'`;; ++ *) ++ tmp_fname=`df $1/ | sed -n 's%.*\(/dev/[^ ]*\).*%\1%p'`;; ++ esac + + if test -z "$tmp_fname"; then + echo "Could not find device for $1" 2>&1 diff --git a/open_issues/tinyproxy.mdwn b/open_issues/tinyproxy.mdwn new file mode 100644 index 00000000..9a4a0cfb --- /dev/null +++ b/open_issues/tinyproxy.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Problem with using tinyproxy for tunneling HTTPS"]] + +`tinyproxy` works fine for HTTP connections, but fails to proxy HTTPS ones: + + ERROR Jun 12 14:58:51 [20676]: relay_connection: select() error "Interrupted system call". Closing connection (client_fd:7, server_fd:8) + +This is supposedly due to the already known select bug, which is a [[!taglink +open_issue_glibc]]. diff --git a/rules/source_repositories.mdwn b/rules/source_repositories.mdwn index 2c2092f8..6240b422 100644 --- a/rules/source_repositories.mdwn +++ b/rules/source_repositories.mdwn @@ -51,6 +51,20 @@ Examples: * `master-viengoos-on-bare-metal` -- port to Viengoos running on bare metal; branched off of `master-viengoos` at some point + * unionfs + + * `master` -- the mainline branch + * `master-unionmount` -- develop `unionmount` based on `unionfs`' master + branch + +To give a concrete example, the latter one was created like this: + + $ git clone --no-checkout ssh://git.savannah.gnu.org/srv/git/hurd/unionfs.git + $ cd unionfs/ + $ git checkout -b master-unionmount origin/master + $ ... + $ git push master-unionmount + ## Merging Merging between Git branches is trivial, at least as long as no conflicts diff --git a/tag/open_issue_porting.mdwn b/tag/open_issue_porting.mdwn index 5ab1e2c0..f89badcb 100644 --- a/tag/open_issue_porting.mdwn +++ b/tag/open_issue_porting.mdwn @@ -10,7 +10,12 @@ License|/fdl]]."]]"""]] [[!meta title=open_issue_porting]] - * List of [[Debian packages that need porting|hurd/running/debian/porting]] +Here is a list of open issues in porting software to run on GNU/Hurd systems. +This list also includes [[hurd/toolchain]]-level items, items that are either +already solved in [[Debian GNU/Hurd|hurd/running/debian]] systems (tagged +*fixed_in_debian*) or being worked around, so if you're out for working on +application-level porting issues, then perusing through the list of [[Debian +packages that need porting|hurd/running/debian/porting]] may be better. [[!map pages="tagged(open_issue_porting) and !open_issues and !*/discussion" show=title]] diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn index 09016edb..2182f12e 100644 --- a/user/scolobb.mdwn +++ b/user/scolobb.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 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 @@ -8,13 +8,122 @@ 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]]."]]"""]] -# scolobb -Sergiu Ivanov, interested non-student +Sergiu Ivanov Mail: <mailto:unlimitedscolobb@gmail.com> -Project: Namespace-based translator selection + +# Google Summer of Code: 2009 Project + +**Unionmount**: The goal of this project is to make it possible to set +translators in unionmount mode, which means that the filesystem +published by the mounted translator will get merged with the directory +tree of the node the translator is mounted onto. + +For documentation, see [[hurd/translator/unionmount]]. + +--- + +## Roadmap + +### DONE + +(Dates in brackets show the completion date) + +* **Make `unionfs` build.** *(24 May)* For reasons unknown to me, + `unionfs` Makefile was configured to search for include files from + under `$(prefix)/include`, while `$(prefix)` was never + defined. Setting `$(prefix)` to `/usr` solved the problem. + +* **Change the command line parsing in `unionfs` to comply with the + requirements of `unionmount`.** *(25 May)* Although the core + functionality of `unionmount` heavily relies on `unionfs`, the + command line interface of these two programs is completely + different: `unionfs` operates on directories, the list of which is + explicitly specified, while `unionmount` *always* merges the + underlying filesystem and the filesystem published by the + mountee. Therefore, options like `--add`, `--remove`, `--underlying` + (specific to `unionfs`) make little sense in `unionmount` + context. These options have been removed. Also, `unionmount` must be + able to pass some switches to the mountee, which means that it + should stop parsing the command line arguments immediately after + having encountered the path to the mountee (very similar to how + `settrans` works). This functionality has also been implemented. + +* **Make `unionmount` capable of starting the mountee.** *(28 May)* + The idea behind implementation of this goal is that `unionmount` + should provide a proxy node on which to set the mountee. The main + issue about this goal was the fact that the mountee *cannot* be + started during the initialization of `unionmount`, because in this + phase `unionmount` is not capable of responding to RPCs, while many + translators try to `io_stat` their underlying node or do other + interesting things on startup. The solution to this problem is, + obviously, *lazy* startup, i.e. the mountee is started at the first + attempt to access (via `dir_lookup` or `dir_readdir`) the merged + filesystem published by `unionmount`. + +* **Include the filesystem published by the mountee in the list of + merged filesystems.** *(1 Jun)* `unionfs` operates on a list of + ports to the underlying filesystems, therefore, to finish the + unionmount functionality, I had to include the port to the mountee + in this list. + +* **Learn Texinfo.** *(Jun 4)* In order to produce canonical + documentation I had to learn the Texinfo documentation format. + +* **Write documentation for `unionmount`.** *(Jun 5)* The basic + unionmount functionality being finished, it has to be documented + properly, lest it should lag behind and remain unfinished + eventually. + +* **Write documentation for `unionfs`.** *(Jun 5)* `unionfs` is not + exactly well-documented at the moment, the only help being provided + by the comments in the sources. The goal is to write a more coherent + documentation. + +### TODO + +(Dates in brackets show the *expected* completion date) + +* **Study eth-multiplexer.** *(12 Jun)* In order to get an idea of + what should the rules for eth-multipexer be, I will have to study + the current state of eth-multiplexer. + +* **Start with a clean unionfs and implement the `--mount` argument** + *(12 Jun)* It was suggested to implement the union mount + functionality first, instead of doing some partial adaptation of + `unionfs` to `unionmount` and leaving the complete adaptation for + the future. + +* **Implement merging rules.** *(25 Jul)* Some details are still + awaiting discovery by me. + +* **Wrap up the project for upstream inclusion.** *(1 Aug)* + `unionmount` is intended to be included upstream, therefore it + should be mostly complete and polished by the end of GSoC. + +* **Decide as to location of unionmount.** *(1 Aug)* Presently, + `unionmount` is a (local) branch in `unionfs` git repository. The + first step of publishing it is planned to be pushing it to the + Savannah `unionfs` repository. Some agree that there should also be + a second step consisting in splitting `unionmount` in a separate git + repository, since the destinations of `unionfs` and `unionmount` are + *similar*, and not identical. + +* **Employ `unionmount` in eth-multiplexer.** *(10 Aug)* I still have + to scrounge for details. + +* **Use a different (better?) implementation idea.** *(17 Aug)* It has + been pointed out several times that `unionmount` could be + implemented not by forking off `unionfs`, but by keeping the merging + functionality in a stand-alone module (which could then be used by + `unionfs` as well). Different implementation ideas with their own + specific advantages may also arise in the future. + +--- + +# Google Summer of Code: 2008 Project: Namespace-based translator selection --- @@ -131,4 +240,3 @@ The code is at <http://github.com/scolobb/nsmux/tree/master>. ####0: Sun Apr 27: > Followed the code of *dmesgd* (<http://www.bddebian.com/junk/dmesgd/>) kindly offered by **bddebian** and rewrote it from scratch as a tutorial. - |