diff options
163 files changed, 3824 insertions, 886 deletions
diff --git a/.templates/autotag.tmpl b/.templates/autotag.tmpl index 87b76eef..1a963267 100644 --- a/.templates/autotag.tmpl +++ b/.templates/autotag.tmpl @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011 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 diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn index 2ce92d19..73a69b8f 100644 --- a/community/gsoc.mdwn +++ b/community/gsoc.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,49 +6,44 @@ 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="Google Summer of Code"]] -# 2010 +# 2011 -This year we are again participating in [Google Summer of Code](http://socghop.appspot.com) -under the [GNU umbrella](http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/gnuproject). +We're in! The GNU Hurd project will again participate in the [Google Summer of +Code](http://www.google-melange.com/gsoc/homepage/google/gsoc2011) under the +[GNU umbrella](http://www.gnu.org/software/soc-projects/). - * *[[Jeremie Koenig|jkoenig]]*, mentored by *[[Samuel - Thibault|samuelthibault]]*, is working on adapting the Debian Installer to - [produce working Debian GNU/Hurd installation - images](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/debian/t127230758239) - so we can easily offer up to date disc-sets. - ([Details](http://wiki.debian.org/SummerOfCode2010/HurdDebianInstaller/JeremieKoenig).) +As of Monday, 2011-03-28 it's the *student application period*. This will last +until [Friday, +2011-04-08](http://www.google-melange.com/gsoc/events/google/gsoc2011), which +is plenty of time for preparing and discussing your applications -- but please +don't wait to the last minute! - * *[[Emilio Pozuelo Monfort|pochu]]*, mentored by *Carl Fredrik Hammar* (who - was a GSoC student in 2007), is working on a task that may be perceived as - less exciting from the outside, but yet is extremely valuable: [fixing - compatibility problems exposed by projects' - testsuites](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gnuproject/t127230759396). - ([[Details|community/gsoc/project_ideas/testsuites]].) - * *[[Karim Allah Ahmed|kam]]*, mentored by *Sergio López*, is working on - [tuning the VM Subsystem in - GNU/Hurd](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gnuproject/t127230759587) - to bring the virtual memory management in Hurd/Mach up to date. - ([[Details|community/gsoc/project_ideas/vm_tuning]].) +## Applying for a Task + +We have a list of [[project_ideas]], and students are likewise encouraged to +submit their own project proposals. We always ask students that want to apply for a task (in the course of the Google Summer of Code) to mind our distinct [[student_application_form]]. -Apart from our own [[project_ideas]], there are also two [Hurd-related ideas -for X.Org](http://wiki.x.org/wiki/Hurd_Porting). +Then, don't forget to visit +<http://www.google-melange.com/gsoc/org/google/gsoc2011/gnu>, and push the big +button for submitting your proposal. -As the Google Summer of Code 2010 has already started, you can no longer -participate as a GSoC student. However, -working on one of these projects is still a good opportunity to get started with Hurd development. Please read up about [[contributing]] in general; and feel free to ask any questions you might have at one of our [[regular_IRC_meetings|IRC#regular_meetings]]. Generally it's a good idea to [[contact_us|communication]] when starting to work on some project. +Working on one of these projects is generally a good opportunity to get started +with Hurd development, even outside of the GSoC context. + + # History In 2006 and [[2007]], we participated in GSoC under the umbrella of the GNU @@ -59,5 +54,5 @@ In the following year, we successfully participated on our own, not only as a suborganization of the GNU project. Read about our five students' success on the [[2008]] page. -The next year, we participated under the GNU umbrella with one slot again. -Read about it on the [[2009]] page. +The next two year, we participated under the GNU umbrella with one slot in +[[2009]], and three in [[2010]]. diff --git a/community/gsoc/2010.mdwn b/community/gsoc/2010.mdwn new file mode 100644 index 00000000..4388636b --- /dev/null +++ b/community/gsoc/2010.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 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="Google Summer of Code 2010"]] + +In 2010 we have again been participating in the Google Summer of Code +under the GNU umbrella, with three slots: + + * *[[Jeremie Koenig|jkoenig]]*, mentored by *[[Samuel + Thibault|samuelthibault]]*, has been working on adapting the Debian Installer to + [produce working Debian GNU/Hurd installation + images](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/debian/t127230758239) + so we can easily offer up to date disc-sets. + ([Details](http://wiki.debian.org/SummerOfCode2010/HurdDebianInstaller/JeremieKoenig).) + + * *[[Emilio Pozuelo Monfort|pochu]]*, mentored by *Carl Fredrik Hammar* (who + was a GSoC student in [[2007]]), has been working on a task that may be perceived as + less exciting from the outside, but yet is extremely valuable: [fixing + compatibility problems exposed by projects' + testsuites](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gnuproject/t127230759396). + ([[Details|community/gsoc/project_ideas/testsuites]].) + + * *[[Karim Allah Ahmed|kam]]*, mentored by *Sergio López*, has been working on + [tuning the VM Subsystem in + GNU/Hurd](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gnuproject/t127230759587) + to bring the virtual memory management in Hurd/Mach up to date. + ([[Details|community/gsoc/project_ideas/vm_tuning]].) diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index 649e05c1..38355e70 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -74,7 +74,17 @@ After all, the purpose of GSoC is to introduce you to free software development before the end of the application process, with our help -- contact us, and we will assist you as well as we can. -See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/Hurd_Porting). +See also the list of **[Hurd-related X.org project +ideas](http://wiki.x.org/wiki/Hurd_Porting)**. + +<!-- These X.org tasks are also listed on +<http://xorg.freedesktop.org/wiki/SummerOfCodeIdeas>, which is the page used by +X.org for referring to their GSoC projects. Probabaly we should get rid of one +of these pages (to avoid duplication). --> + +Also, note that there is a task about **[porting GCC's implementation of the +Google Go programming language to +GNU/Hurd](http://gcc.gnu.org/wiki/SummerOfCode#gccgo_hurd)**. [[!inline pages="community/gsoc/project_ideas/language_bindings" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/virtualization" show=0 feeds=no actions=yes]] @@ -82,10 +92,9 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H [[!inline pages="community/gsoc/project_ideas/server_overriding" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/tcp_ip_stack" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/nfs" show=0 feeds=no actions=yes]] -[[!inline pages="open_issues/locking" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/pthreads" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/sound" show=0 feeds=no actions=yes]] -[[!inline pages="open_issues/performance/io_system" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/disk_io_performance" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/vm_tuning" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/mtab" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/gnumach_cleanup" show=0 feeds=no actions=yes]] @@ -95,7 +104,6 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H [[!inline pages="community/gsoc/project_ideas/lexical_dot-dot" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/secure_chroot" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/package_manager" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/debian_installer" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/download_backends" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/libgtop" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/maxpath" show=0 feeds=no actions=yes]] @@ -104,6 +112,9 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H [[!inline pages="community/gsoc/project_ideas/cdparanoia" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/perl_python" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/testsuites" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/testing_framework" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/libcap" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/xattr" show=0 feeds=no actions=yes]] -[[!inline pages="open_issues/valgrind" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/valgrind" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/driver_glue_code" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/dtrace" show=0 feeds=no actions=yes]] diff --git a/open_issues/performance/io_system.mdwn b/community/gsoc/project_ideas/disk_io_performance.mdwn index 0d41d3c7..ae634709 100644 --- a/open_issues/performance/io_system.mdwn +++ b/community/gsoc/project_ideas/disk_io_performance.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,10 +6,10 @@ 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="I/O System"]] +[[!meta title="Disk I/O Performance Tuning"]] [[!tag open_issue_hurd]] @@ -20,7 +20,8 @@ slow hard disk access. The reason for this slowness is lack and/or bad implementation of common optimization techniques, like scheduling reads and writes to minimize head movement; effective block caching; effective reads/writes to partial blocks; -reading/writing multiple blocks at once; and read-ahead. The +[[reading/writing multiple blocks at once|open_issues/performance/io_system/clustered_page_faults]]; and +[[open_issues/performance/io_system/read-ahead]]. The [[ext2_filesystem_server|hurd/translator/ext2fs]] might also need some optimizations at a higher logical level. @@ -30,12 +31,12 @@ requires understanding the data flow through the various layers involved in disk access on the Hurd ([[filesystem|hurd/virtual_file_system]], [[pager|hurd/libpager]], driver), and general experience with optimizing complex systems. That said, the killing feature we are definitely -missing is the read-ahead, and even a very simple implementation would bring +missing is the [[open_issues/performance/io_system/read-ahead]], and even a very simple implementation would bring very big performance speedups. Here are some real testcases: - * [[binutils_ld_64ksec]]; + * [[open_issues/performance/io_system/binutils_ld_64ksec]]; * running the Git testsuite which is mostly I/O bound; diff --git a/community/gsoc/project_ideas/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn index 9c063e9f..65ea4f0f 100644 --- a/community/gsoc/project_ideas/driver_glue_code.mdwn +++ b/community/gsoc/project_ideas/driver_glue_code.mdwn @@ -1,5 +1,4 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 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,41 +8,64 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title="New Driver Glue Code"]] +[[!meta title="New Driver Framework"]] -Although a driver framework in user space would be desirable, presently the Hurd -uses kernel drivers in the microkernel, -[[GNU_Mach|microkernel/mach/gnumach]]. (And changing this would be far beyond a -GSoC project...) - -The problem is that the drivers in GNU Mach are presently old Linux drivers -(mostly from 2.0.x) accessed through a glue code layer. This is not an ideal -solution, but works quite OK, except that the drivers are very old. The goal of -this project is to redo the glue code, so we can use drivers from current Linux -versions, or from one of the free BSD variants. - -While it would be certainly possible to create custom glue code again, a more -sustainable and probably also easier approach is to use -[[DDE]] instead -- it already -does the hard work of providing an environment where the foreign drivers can -run, and has the additional advantage of being externally maintained. - -This is a doable, but pretty involved project. Previous experience with driver -programming probably is a must. (No Hurd-specific knowledge is required, -though.) +The Hurd presently uses hardware drivers +implemented in the microkernel, [[GNU_Mach|microkernel/mach/gnumach]]. +These drivers are old Linux drivers (mostly from 2.0.x) +accessed through a glue code layer. +This is not an ideal solution, but works quite OK, +except that the drivers are extremely old by now. +Thus we need a new framework, +so we can use drivers from current Linux versions instead, +or perhaps from one of the free BSD variants. This is [[!GNU_Savannah_task 5488]]. [[open issues/user-space device drivers]]. [[open issues/device drivers and io systems]]. +The most promising approach for getting newer drivers seems to be [[DDE]]: +it already does the hard work of providing an environment +where the foreign drivers can run, +and offers the additional benefit of being externally maintained. +DDE also offers the necessary facilities +for running all drivers in separate userspace processes, +which is more desirable than drivers running in the microkernel. -Possible mentors: Samuel Thibault (youpi) +[[Zheng Da|zhengda]] has already done considerable work on this. +The basic framework for using DDE in the Hurd is present, +and network card drivers are already working very well. +However, this work isn't fully integrated in the Hurd yet. +The additional kernel interfaces that were created for this +are still prototypes, and will need to be reworked. +Also, there is no build system for automatically compiling +all Linux network card drivers in one go. + +Other types of drivers are missing so far. +Support for IDE drivers has been partially implemented, +but isn't fully working yet. +To fully replace the old in-kernel drivers, +further infrastructure will be necessary +to make userspace disk drivers usable for the root filesystem. -Exercise: Take a driver for some newer piece of hardware (e.g. Intel e1000 -ethernet) from a recent system, and try to port it to run in the existing -driver framework in GNU Mach. Completing the port might be too involved for the -exercise; but it's pretty likely that you will find something else to improve -in the glue code while working on this... +Some other subsystems are missing or incomplete in DDE itself, +and will require additional work that is not specific to the Hurd implementation. + +The goal of this task is to fix at least one of the mentioned major shortcomings: +rework the kernel interfaces; +provide a streamlined build system for the drivers; +finish IDE support; +or implement support for some other subsystem. +<!-- should probably provide separate task descriptions for each... --> + +This is a doable, but pretty involved project. +Previous experience with driver programming probably is a must. +To be able to work on the framework, +the student will also have to get a good understanding of certain aspects of Hurd, +such as memory management for example. + +Possible mentors: Samuel Thibault (youpi) -*Status*: [[Zheng Da|zhengda]] is working on DDE, and has mostly completed the -initial port. +Exercise: Get one of the not yet integrated Linux network card drivers to work. +(Note: This should be straightforward, +once you have the framework properly built and set up...) diff --git a/community/gsoc/project_ideas/dtrace.mdwn b/community/gsoc/project_ideas/dtrace.mdwn index 4a46cf38..6261c03e 100644 --- a/community/gsoc/project_ideas/dtrace.mdwn +++ b/community/gsoc/project_ideas/dtrace.mdwn @@ -1,22 +1,25 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[!meta title="dtrace Support"]] +[[!meta title="Kernel Instrumentation"]] + +[[!tag open_issue_gnumach]] One of the main problems of the current Hurd implementation is very poor -performance. While we have a bunch of ideas what could cause the performance +[[open_issues/performance]]. While we have a bunch of ideas what could cause the performance problems, these are mostly just guesses. Better understanding what really causes bad performance is necessary to improve the situation. For that, we need tools for performance measurements. While all kinds of more -or less specific profiling tools could be conceived, the most promising and +or less specific [[open_issues/profiling]] tools could be conceived, the most promising and generic approach seems to be a framework for logging certain events in the running system (both in the microkernel and in the Hurd servers). This would allow checking how much time is spent in certain modules, how often certain @@ -24,23 +27,36 @@ situations occur, how things interact, etc. It could also prove helpful in debugging some issues that are otherwise hard to find because of complex interactions. -The most popular framework for that is Sun's dtrace; but there might be others. -The student has to evaluate the existing options, deciding which makes most -sense for the Hurd; and implement that one. (Apple's implementation of dtrace -in their Mach-based kernel might be helpful here...) - -This project requires ability to evaluate possible solutions, and experience -with integrating existing components as well as low-level programming. +The most popular kernel instrumentation framework is Sun's dtrace, +originally written for Solaris, +but also adopted by some other systems. +However, the GPL-incompatible license means it can't be used in Linux, +and thus Linux developers created their own frameworks instead: +first [[SystemTap]], and now [[LTTng]]. + +In 2008, Andrei Barbu did initial work on kernel probes for the Hurd. +However, not all of his patches got merged, +because some turned out not to be fully functional. +Also, he didn't get around to work on userspace probes, +nor on a nice frontend for writing test scripts employing the probes. + +The goal of this project is to make the instrumentation framework +more usable and complete, +and to better integrate it in the Hurd. +For that, the student will have to work +on some real profiling and/or debugging tasks, +and fix any shortcomings he encounters in the framework. + +This is a pretty involved task. +Previous experience with low-level programming is a must; +and it also requires a good grasp on interactions in complex systems. + +To work on this project, +the student will have to get familiar with GNU Mach. +(The microkernel employed by the Hurd.) +Some understanding of other aspects of the Hurd will also be required, +depending on the exact nature of the profiling/debugging performed. Possible mentors: Samuel Thibault (youpi) -Exercise: In lack of a good exercise directly related to this task, just pick -one of the kernel-related or generally low-level tasks from the bug/task -trackers on savannah, and make a go at it. You might not be able to finish the -task in a limited amount of time, but you should at least be able to make a -detailed analysis of the issue. - -*Status*: Andei Barbu was working on -[SystemTap](http://csclub.uwaterloo.ca/~abarbu/hurd/) for GSoC 2008, but it -turned out too Linux-specific. He implemented kernel probes, but there is no -nice frontend yet. +Exercise: Use the existing probes to perform some simple measurement. diff --git a/open_issues/locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn index 11a10524..faac8bd9 100644 --- a/open_issues/locking.mdwn +++ b/community/gsoc/project_ideas/libdiskfs_locking.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -9,14 +9,12 @@ 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]] +[[!meta title="Fix libdiskfs Locking Issues"]] -Every now and then, new locking issues are discovered in -[[hurd/libdiskfs]] or [[hurd/translator/ext2fs]], for example. Nowadays -these in fact seem to be the most often encountered cause of Hurd crashes -/ lockups. +[[!tag open_issue_hurd]] -One of these could be traced +Nowadays the most often encountered cause of Hurd crashes seems to be lockups +in the [[hurd/translator/ext2fs]] server. One of these could be traced recently, and turned out to be a lock inside [[hurd/libdiskfs]] that was taken and not released in some cases. There is reason to believe that there are more faulty paths causing these lockups. @@ -24,17 +22,24 @@ faulty paths causing these lockups. The task is systematically checking the [[hurd/libdiskfs]] code for this kind of locking issues. To achieve this, some kind of test harness has to be implemented: For example instrumenting the code to check locking correctness constantly at -runtime. Or implementing a [[unit testing]] framework that explicitly checks +runtime. Or implementing a [[open_issues/unit_testing]] framework that explicitly checks locking in various code paths. (The latter could serve as a template for implementing unit tests in other parts of the Hurd codebase...) -(A [[systematic code review|security]] would probably suffice to find the +(A [[systematic code review|open_issues/security]] would probably suffice to find the existing locking issues; but it wouldn't document the work in terms of actual code produced, and thus it's not suitable for a GSoC project...) This task requires experience with debugging locking issues in -[[multithreaded|multithreading]] applications. +[[multithreaded|open_issues/multithreading]] applications. -Tools have been written for automated [[code analysis]]; these can help to +Tools have been written for automated [[open_issues/code_analysis]]; these can help to locate and fix such errors. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: If you could actually track down and fix one of the existing locking +errors before the end of the application process, that would be excellent. This +might be rather tough though, so probably you need to talk to us about an +alternative exercise task... diff --git a/community/gsoc/project_ideas/procfs.mdwn b/community/gsoc/project_ideas/procfs.mdwn new file mode 100644 index 00000000..0434ab9c --- /dev/null +++ b/community/gsoc/project_ideas/procfs.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 2008, 2009, 2011 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="procfs"]] + +Although there is no standard (POSIX or other) for the layout of the `/proc` +pseudo-filesystem, it turned out a very useful facility in GNU/Linux and other +systems, and many tools concerned with process management use it. (`ps`, `top`, +`htop`, `gtop`, `killall`, `pkill`, ...) + +Instead of porting all these tools to use [[hurd/libps]] (Hurd's official method for +accessing process information), they could be made to run out of the box, by +implementing a Linux-compatible `/proc` filesystem for the Hurd. + +The goal is to implement all `/proc` functionality needed for the various process +management tools to work. (On Linux, the `/proc` filesystem is used also for +debugging purposes; but this is highly system-specific anyways, so there is +probably no point in trying to duplicate this functionality as well...) + +The [[existing_partially_working_procfs_implementation|hurd/translator/procfs]] +can serve as a starting point, but needs to be largely rewritten. (It should +use [[hurd/libnetfs]] rather than [[hurd/libtrivfs]]; the data format needs to +change to be more Linux-compatible; and it needs adaptation to newer system +interfaces.) + +This project requires learning [[hurd/translator]] programming, and +understanding some of the internals of process management in the Hurd. It +should not be too hard coding-wise; and the task is very nicely defined by the +existing Linux `/proc` interface -- no design considerations necessary. + +**Note**: We already have several applications for this task. + +Possible mentors: Olaf Buddenhagen (antrik) + +Exercise: Add or fix one piece in the existing procfs translator. + +*Status*: Madhusudan.C.S has implemented a new, fully functional [[procfs|madhusudancs]] for +GSoC 2008. He is still working on some outstanding issues. + +--- + +Note that this was not the end of the story: [[jkoenig's +`procfs`|hurd/translator/procfs/jkoenig]] is yet another re-written and +improved version. diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn index 57739861..bfaf330b 100644 --- a/community/gsoc/project_ideas/secure_chroot.mdwn +++ b/community/gsoc/project_ideas/secure_chroot.mdwn @@ -12,7 +12,7 @@ License|/fdl]]."]]"""]] [[!meta title="Secure chroot Implementation"]] As the Hurd attempts to be (almost) fully [[UNIX]]-compatible, it also implements a -`chroot` [[system call]]. However, the current implementation is not really +`chroot()` [[system call]]. However, the current implementation is not really good, as it allows easily escaping the `chroot`, for example by use of [[passive_translators|hurd/translator]]. diff --git a/community/gsoc/project_ideas/testing_framework.mdwn b/community/gsoc/project_ideas/testing_framework.mdwn new file mode 100644 index 00000000..ff9899d9 --- /dev/null +++ b/community/gsoc/project_ideas/testing_framework.mdwn @@ -0,0 +1,55 @@ +[[!meta copyright="Copyright © 2011 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="Automated Testing Framework"]] + +Hurd development would benefit greatly from automated tests. +Unit tests should be added for all the major components +(Mach; Hurd servers and libraries). +Also, functional tests can be performed on various levels: +Mach; individual servers; and interaction of several servers. + +(The highest level would actually be testing libc functionality, +which in turn uses the various Hurd mechanisms. +glibc already comes with a test suite -- +though it might be desirabe to add some extra tests +for exercising specific aspects of the Hurd...) + +Our page on [[automated testing|open_issues/unit_testing]] collects some relevant material. + +The Goal of this task is to provide testing frameworks +that allow automatically running tests +as part of the Hurd and Mach build processes. +The student will have to create the necessary infrastrucure, +and a couple of sample tests employing it. +Ideally, all the aspects mentioned above should be covered. +At least some have to be ready for use and upstream merging +before the end of the summer. + +(As a bonus, +in addition to these explicit tests, +it would be helpful to integrate some methods +for testing [[locking validity|libdiskfs_locking]], +performing static code analysis etc.) + +This task probably requires some previous experience +with unit testing of C programs, +as well as dealing with complex build systems. +No in-depth knowledge about any specific parts of the Hurd should be necessary, +but some general understanding of the Hurd architecture +will have to be aquired to complete this project. +This makes it a very good project +to get started on Hurd development :-) + +Possible mentors: ? + +Exercise: Create a program performing some simple test(s) on the Hurd or Mach code. +It doesn't need to be integrated in the build process yet -- +a standalone progrem with it's own Makefile is fine for now. diff --git a/community/gsoc/project_ideas/testing_framework/discussion.mdwn b/community/gsoc/project_ideas/testing_framework/discussion.mdwn new file mode 100644 index 00000000..872d0eb7 --- /dev/null +++ b/community/gsoc/project_ideas/testing_framework/discussion.mdwn @@ -0,0 +1,270 @@ +[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]] + +freenode, #hurd channel, 2011-03-05: + + <nixness> what about testing though? + <nixness> like sort of "what's missing? lets write tests for it so that + when someone gets to implementing it, he knows what to do. Repeat" + project + <antrik> you mean creating an automated testing framework? + <antrik> this is actually a task I want to add for this year, if I get + around to it :-) + <nixness> yeah I'd very much want to apply for that one + <nixness> cuz I've never done Kernel hacking before, but I know that with + the right tasks like "test VM functionality", I would be able to write up + the automated tests and hopefully learn more about what breaks/makes the + kernel + <nixness> (and it would make implementing the feature much less hand-wavy + and more correct) + <nixness> antrik, I believe the framework(CUnit right?) exists, but we just + need to write the tests. + <antrik> do you have prior experience implementing automated tests? + <nixness> lots of tests! + <nixness> yes, in Java mostly, but I've played around with CUnit + <antrik> ah, great :-) + <nixness> here's what I know from experience: 1) write basic tests. 2) + write ones that test multiple features 3) stress test [option 4) + benchmark and record to DB] + <youpi> well, what we'd rather need is to fix the issues we already know + from the existing testsuites :) + +[[GSoC project propsal|community/gsoc/project_ideas/testsuites]]. + + <nixness> youpi, true, and I think I should check what's available in way + of tests, but if the tests are "all or nothing" then it becomes really + hard to fix your mistakes + <youpi> they're not all or nothing + <antrik> youpi: the existing testsuites don't test specific system features + <youpi> libc ones do + <youpi> we could also check posixtestsuite which does too + +[[open_issues/open_posix_test_suite]]. + + <antrik> AFAIK libc has very few failing tests + +[[open_issues/glibc_testsuite]]. + + <youpi> err, like twenty? + <youpi> € grep -v '^#' expected-results-i486-gnu-libc | wc -l + <youpi> 67 + <youpi> nope, even more + <antrik> oh, sorry, I confused it with coreutils + <pinotree> plus the binutils ones, i guess + <youpi> yes + +[[open_issues/binutils#weak]]. + + <antrik> anyways, I don't think relying on external testsuites for + regression testing is a good plan + <antrik> also, that doesn't cover unit testing at all + <youpi> why ? + <youpi> sure there can be unit testing at the translator etc. level + <antrik> if we want to implement test-driven development, and/or do serious + refactoring without too much risk, we need a test harness where we can + add specific tests as needed + <youpi> but more than often, the issues are at the libc / etc. level + because of a combination o fthings at the translator level, which unit + testing won't find out + * nixness yewzzz! + <nixness> sure unit testing can find them out. if they're good "unit" tests + <youpi> the problem is that you don't necessarily know what "good" means + <youpi> e.g. for posix correctness + <youpi> since it's not posix + <nixness> but if they're composite clever tests, then you lose that + granularity + <nixness> youpi, is that a blackbox test intended to be run at the very end + to check if you're posix compliant? + <antrik> also, if we have our own test harness, we can run tests + automatically as part of the build process, which is a great plus IMHO + <youpi> nixness: "that" = ? + <nixness> oh nvm, I thought there was a test stuie called "posix + correctness" + <youpi> there's the posixtestsuite yes + <youpi> it's an external one however + <youpi> antrik: being external doesn't mean we can't invoke it + automatically as part of the build process when it's available + <nixness> youpi, but being internal means it can test the inner workings of + certain modules that you are unsure of, and not just the interface + <youpi> sure, that's why I said it'd be useful too + <youpi> but as I said too, most bugs I've seen were not easy to find out at + the unit level + <youpi> but rather at the libc level + <antrik> of course we can integrate external tests if they exist and are + suitable. but that that doesn't preclude adding our own ones too. in + either case, that integration work has to be done too + <youpi> again, I've never said I was against internal testsuite + <antrik> also, the major purpose of a test suite is checking known + behaviour. a low-level test won't directly point to a POSIX violation; + but it will catch any changes in behaviour that would lead to one + <youpi> what I said is that it will be hard to write them tight enough to + find bugs + <youpi> again, the problem is knowing what will lead to a POSIX violation + <youpi> it's long work + <youpi> while libc / posixtestsuite / etc. already do that + <antrik> *any* unexpected change in behaviour is likely to cause bugs + somewher + <youpi> but WHAT is "expected" ? + <youpi> THAT is the issue + <youpi> and libc/posixtessuite do know that + <youpi> at the translator level we don't really + <youpi> see the recent post about link() + +[link(dir,name) should fail with +EPERM](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00007.html) + + <youpi> in my memory jkoenig pointed it out for a lot of such calls + <youpi> and that issue is clearly not known at the translator level + <nixness> so you're saying that the tests have to be really really + low-level, and work our way up? + <youpi> I'm saying that the translator level tests will be difficult to + write + <antrik> why isn't it known at the translator level? if it's a translator + (not libc) bug, than obviously the translator must return something wrong + at some point, and that's something we can check + <youpi> because you'll have to know all the details of the combinations + used in libc, to know whether they'll lead to posix issues + <youpi> antrik: sure, but how did we detect that that was unexpected + behavior? + <youpi> because of a glib test + <youpi> at the translator level we didn't know it was an unexpected + behavior + <antrik> gnulib actually + <youpi> and if you had asked me, I wouldn't have known + <antrik> again, we do *not* write a test suite to find existing bugs + <youpi> right, took one for the other + <youpi> doesn't really matter actually + <youpi> antrik: ok, I don't care then + <antrik> we write a test suite to prevent future bugs, or track status of + known bugs + <youpi> (don't care *enough* for now, I mean) + <nixness> hmm, so write something up antrik for GSoC :) and I'll be sure to + apply + <antrik> now that we know some translators return a wrong error status in a + particular situation, we can write a test that checks exactly this error + status. that way we know when it is fixed, and also when it breaks again + <antrik> nixness: great :-) + <nixness> sweet. that kind of thing would also need a db backend + <antrik> nixness: BTW, if you have a good idea, you can send an application + for it even if it's not listed among the proposed tasks... + <antrik> so you don't strictly need a writeup from me to apply for this :-) + <nixness> antrik, I'll keep that in mind, but I'll also be checking your + draft page + <nixness> oh cool :) + <antrik> (and it's a well known fact that those projects which students + proposed themselfs tend to be the most successful ones :-) ) + * nixness draft initiated + <antrik> youpi: BTW, I'm surprised that you didn't mention libc testsuite + before... working up from there is probably a more effective plan than + starting with high-level test suites like Python etc... + <youpi> wasn't it already in the gsoc proposal? + <youpi> bummer + <antrik> nope + +freenode, #hurd channel, 2011-03-06: + + <nixness> how's the hurd coding workflow, typically? + +*nixness* -> *foocraft*. + + <foocraft> we're discussing how TDD can work with Hurd (or general kernel + development) on #osdev + <foocraft> so what I wanted to know, since I haven't dealt much with GNU + Hurd, is how do you guys go about coding, in this case + <tschwinge> Our current workflow scheme is... well... is... + <tschwinge> Someone wants to work on something, or spots a bug, then works + on it, submits a patch, and 0 to 10 years later it is applied. + <tschwinge> Roughly. + <foocraft> hmm so there's no indicator of whether things broke with that + patch + <foocraft> and how low do you think we can get with tests? A friend of mine + was telling me that with kernel dev, you really don't know whether, for + instance, the stack even exists, and a lot of things that I, as a + programmer, can assume while writing code break when it comes to writing + kernel code + <foocraft> Autotest seems promising + +See autotest link given above. + + <foocraft> but in any case, coming up with the testing framework that + doesn't break when the OS itself breaks is hard, it seems + <foocraft> not sure if autotest isolates the mistakes in the os from + finding their way in the validity of the tests themselves + <youpi> it could be interesting to have scripts that automatically start a + sub-hurd to do the tests + +[[hurd/subhurd#unit_testing]]. + + <tschwinge> foocraft: To answer one of your earlier questions: you can do + really low-level testing. Like testing Mach's message passing. A + million times. The questions is whether that makes sense. And / or if + it makes sense to do that as part of a unit testing framework. Or rather + do such things manually once you suspect an error somewhere. + <tschwinge> The reason for the latter may be that Mach IPC is already + heavily tested during normal system operation. + <tschwinge> And yet, there still may be (there are, surely) bugs. + <tschwinge> But I guess that you have to stop at some (arbitrary?) level. + <foocraft> so we'd assume it works, and test from there + <tschwinge> Otherwise you'd be implementing the exact counter-part of what + you're testing. + <tschwinge> Which may be what you want, or may be not. Or it may just not + be feasible. + <foocraft> maybe the testing framework should have dependencies + <foocraft> which we can automate using make, and phony targets that run + tests + <foocraft> so everyone writes a test suite and says that it depends on A + and B working correctly + <foocraft> then it'd go try to run the tests for A etc. + <tschwinge> Hmm, isn't that -- on a high level -- have you have by + different packages? For example, the perl testsuite depends (inherently) + on glibc working properly. A perl program's testsuite depends on perl + working properly. + <foocraft> yeah, but afaik, the ordering is done by hand + +freenode, #hurd channel, 2011-03-07: + + <antrik> actually, I think for most tests it would be better not to use a + subhurd... that leads precisely to the problem that if something is + broken, you might have a hard time running the tests at all :-) + <antrik> foocraft: most of the Hurd code isn't really low-level. you can + use normal debugging and testing methods + <antrik> gnumach of course *does* have some low-level stuff, so if you add + unit tests to gnumach too, you might run into issues :-) + <antrik> tschwinge: I think testing IPC is a good thing. as I already said, + automated testing is *not* to discover existing but unknown bugs, but to + prevent new ones creeping in, and tracking progress on known bugs + <antrik> tschwinge: I think you are confusing unit testing and regression + testing. http://www.bddebian.com/~hurd-web/open_issues/unit_testing/ + talks about unit testing, but a lot (most?) of it is actually about + regression tests... + <tschwinge> antrik: That may certainly be -- I'm not at all an expert in + this, and just generally though that some sort of automated testing is + needed, and thus started collecting ideas. + <tschwinge> antrik: You're of course invited to fix that. + +IRC, freenode, #hurd, 2011-03-08 + +(After discussing the [[open_issues/anatomy_of_a_hurd_system]].) + + <antrik> so that's what your question is actually about? + <foocraft> so what I would imagine is a set of only-this-server tests for + each server, and then we can have fun adding composite tests + <foocraft> thus making debugging the composite scenarios a bit less tricky + <antrik> indeed + <foocraft> and if you were trying to pass a composite test, it would also + help knowing that you still didn't break the server-only test + <antrik> there are so many different things that can be tested... the + summer will only suffice to dip into this really :-) + <foocraft> yeah, I'm designing my proposal to focus on 1) make/use a + testing framework that fits the Hurd case very well 2) write some tests + and docs on how to write good tests + <antrik> well, doesn't have to be *one* framework... unit testing and + regression testing are quite different things, which can be covered by + different frameworks diff --git a/community/gsoc/project_ideas/testsuites.mdwn b/community/gsoc/project_ideas/testsuites.mdwn index 4f8d43fc..f5ee2084 100644 --- a/community/gsoc/project_ideas/testsuites.mdwn +++ b/community/gsoc/project_ideas/testsuites.mdwn @@ -1,20 +1,27 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Fix Compatibility Problems Exposed by Testsuites"]] A number of software packages come with extensive testsuites. -Some notable ones are Perl, Python, GNU Coreutils, and glib. +Some notable ones are [[glibc|open_issues/glibc_testsuite]], gnulib, Perl, +Python, GNU Coreutils, and glib. While these testsuites were written mostly to track regressions in the respective packages, some of the tests fail on the Hurd in general. +There is also the [[Open POSIX Testsuite|open_issues/open_posix_test_suite]] +which is more of a whole system interface testing suite. + +Then, there is the [[open_issues/File_System_Exerciser]] which we can use to +test our file system servers for conformity. + While in some cases these might point to wrong usage of system interfaces, most of the time such failures are actually caused by shortcomings in Hurd's implementation of these interfaces. These shortcomings are often not obvious in normal use, @@ -42,6 +49,9 @@ While tracking down the various issues, the student will be digging into the inner workings of the Hurd, and thus gradually gaining the knowledge required for Hurd development in general. +A complementary task is adding a proper [[open_issues/unit_testing]] framework +to the GNU Hurd's code base, and related packages. + Possible mentors: Samuel Thibault (youpi) Exercise: Take a stab at one of the testsuite failures, diff --git a/open_issues/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn index 2b0624d7..e9e94857 100644 --- a/open_issues/valgrind.mdwn +++ b/community/gsoc/project_ideas/valgrind.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2010, 2011 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 @@ -10,6 +11,8 @@ License|/fdl]]."]]"""]] [[!meta title="Porting Valgrind to the Hurd"]] +[[!tag open_issue_gnumach open_issue_hurd]] + [Valgrind](http://valgrind.org/) is an extremely useful debugging tool for memory errors. (And some other kinds of hard-to-find errors too.) Aside from being useful for program development in general, @@ -32,14 +35,14 @@ Compared to Linux, [[microkernel/Mach]] (the microkernel used by the Hurd) has very few kernel traps. Almost all [[system call]]s are implemented as [[RPC]]s instead -- either handled by Mach itself, or by the various [[Hurd servers|hurd/translator]]. -All RPCs use a pair of `mach_msg` invocations: +All RPCs use a pair of `mach_msg()` invocations: one to send a request message, and one to receive a reply. -However, while all RPCs use the same `mach_msg` trap, +However, while all RPCs use the same `mach_msg()` trap, the actual effect of the call varies greatly depending on which RPC is invoked -- -similar to the `ioctl` call on Linux. +similar to the `ioctl()` call on Linux. Each request thus must be handled individually. -Unlike `ioctl`, +Unlike `ioctl()`, the RPC invocations have explicit type information for the parameters though, which can be retrieved from the message header. By analyzing the parameters of the RPC reply message, diff --git a/community/meetings/fosdem_2011.mdwn b/community/meetings/fosdem_2011.mdwn index 76a02c0a..8522e10f 100644 --- a/community/meetings/fosdem_2011.mdwn +++ b/community/meetings/fosdem_2011.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 2010 Free Software +[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -21,8 +21,13 @@ Bruxelles. [[!table class="table_style_1" data=""" "Name","Attending","Arrival","Return","Share room with us" +"Emilio Pozuelo Monfort","yes"," "," "," " +"Marcus Brinkmann","yes"," "," "," " +"Michael Banck","yes"," "," "," " "Neal Walfield","yes","Friday noon","Monday noon","yes" +"Richard Braun","no","n/a","n/a","n/a" "[[Thomas Schwinge|tschwinge]]","no","n/a","n/a","n/a" +"Wouter van Heyst","yes"," "," "," " """]] diff --git a/community/weblogs/ArneBab/Hurd-showcase-qemu-image.mdwn b/community/weblogs/ArneBab/Hurd-showcase-qemu-image.mdwn index d55527a7..00d09094 100644 --- a/community/weblogs/ArneBab/Hurd-showcase-qemu-image.mdwn +++ b/community/weblogs/ArneBab/Hurd-showcase-qemu-image.mdwn @@ -56,7 +56,9 @@ For that I want to use: ### Tarfs apt-get install zip libz-dev libbz2-dev - hg clone http://bitbucket.org/ArneBab/hurd-tarfs tarfs + git clone git://git.sv.gnu.org/hurd/incubator.git tarfs + cd tarfs/ + git checkout tarfs/master cd tarfs make make install @@ -86,9 +88,12 @@ For that I want to use: cd ../.. mkdir test - settrans -c test2 /usr/local/bin/nsmux test - tar -cf test/intro.tar repos/hurd_intro - ls test2/intro.tar,,tarfs + touch test/hello + settrans -ca test2 /usr/local/bin/nsmux test + # tar -cvf test/intro.tar repos/hurd_intro + cat test2/hello + cat test2/hello,,hello + # Hello, World! ### clisp diff --git a/contributing.mdwn b/contributing.mdwn index 01140927..7d8d2a0e 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 2010 Free Software +[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -9,6 +9,8 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] +[[!tag stable_URL]] + So, you are interested in contributing to the GNU Hurd project? Welcome! Every single contribution is very much encouraged. @@ -20,9 +22,12 @@ If someone of you is lurking around here and would like to contribute, but feels she / he could do so better under formal mentoring: please speak up at one of the [[regular_IRC_meetings|IRC#regular_meetings]]! -Generally we also have a list of [[open_issues]] and one for -[[project_ideas|community/gsoc/project_ideas]] - the latter written for the -Google Summer of Code. +Generally we also have a list of [[open_issues]] and one for +[[project_ideas|community/gsoc/project_ideas]] - the latter written for the +Google Summer of Code. Even just investigating open issues, without being able +to fix them, can be useful, because a tracked down issue often becomes obvious +to people who know the stuff (but those people don't have the time to spend to +do the tracking down). # Documentation @@ -56,6 +61,8 @@ things you're going to work on (and on your internet connection), this may be an easy way of getting used to Hurd systems. Installing in a virtual machine is another possibility, see the page about [[running_a_Hurd_system|hurd/running]] for the full story. +In particular, running a Debian GNU/Hurd [[QEMU image|hurd/running/QEMU]] may +be a viable alternative. Then you can either play around and eventually strive to do something useful or -- if you want -- [[ask_us|contact_us]] to assign something to you, depending @@ -86,6 +93,8 @@ Here is a You can also just [[install_Debian_GNU/Hurd|hurd/running/debian]] and find what doesn't work or suit you and try to improve that. +You can also have a look at the [List of failing packages](http://people.debian.org/~sthibault/failed_packages.txt). + ### Open Issues Here is a list of [[open_issues]]. diff --git a/contributing/web_pages.mdwn b/contributing/web_pages.mdwn index 105d9dd5..351c82bd 100644 --- a/contributing/web_pages.mdwn +++ b/contributing/web_pages.mdwn @@ -234,6 +234,6 @@ download them from. Files to update: - * `/config_edittemplate/*.mdwn` + * `/config_edittemplate/*.mdwn`, `/.templates/autotag.tmpl` * `/contributing/web_pages/news/skeleton.mdwn` * `/copyright.mdwn` diff --git a/faq/how_many_developers.mdwn b/faq/how_many_developers.mdwn index a553df21..3c430ca4 100644 --- a/faq/how_many_developers.mdwn +++ b/faq/how_many_developers.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 +13,7 @@ License|/fdl]]."]]"""]] Not many. One handful work on it in their free time, and another two handful do help with [[Debian GNU/Hurd|hurd/running/debian]] and [[hurd/running/Arch_Hurd]] packaging. Also, an additional handful of -former developers are still availble for answering technical questions, +former developers are still available for answering technical questions, but are not really participating in the current development anymore. For reaching out to new developers, we're participating in [[Google's diff --git a/faq/posix_compatibility.mdwn b/faq/posix_compatibility.mdwn index a54822c5..4490b7cb 100644 --- a/faq/posix_compatibility.mdwn +++ b/faq/posix_compatibility.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -30,20 +30,3 @@ striving for total POSIX compliance -- and the high-level programs (that is, their users) may not even notice this, but we would avoid a lot of overhead that comes with wrapping the [[Hurd interfaces|hurd/interface]] to be POSIX compliant. - - -\#hurd IRC channel on Freenode, 2010-12-21: - - <antrik> tschwinge: the writeup ignores the fact that POSIX compatibility - is not only for applications, but also for users familiar with the UNIX - environment - <antrik> also, I still don't buy the fact that most software is not written - for POSIX. even if assuming that GNOME programs don't use POSIX (which is - only half true), there is a lot of other software in a system that is - just as important, though less visible - <antrik> (server software, startup system, device management, automation, - ...) - <antrik> tschwinge: BTW, I meant to (and partially did) write a blog - article on this topic -- but I didn't get around to finish it... - -[[!tag open_issue_documentation]] diff --git a/faq/posix_compatibility/discussion.mdwn b/faq/posix_compatibility/discussion.mdwn new file mode 100644 index 00000000..0d722c9e --- /dev/null +++ b/faq/posix_compatibility/discussion.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]] + +[[!tag open_issue_documentation]] + +\#hurd IRC channel on Freenode, 2010-12-21: + + <antrik> tschwinge: the writeup ignores the fact that POSIX compatibility + is not only for applications, but also for users familiar with the UNIX + environment + <antrik> also, I still don't buy the fact that most software is not written + for POSIX. even if assuming that GNOME programs don't use POSIX (which is + only half true), there is a lot of other software in a system that is + just as important, though less visible + <antrik> (server software, startup system, device management, automation, + ...) + <antrik> tschwinge: BTW, I meant to (and partially did) write a blog + article on this topic -- but I didn't get around to finish it... diff --git a/faq/smp.mdwn b/faq/smp.mdwn new file mode 100644 index 00000000..e95edcd2 --- /dev/null +++ b/faq/smp.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2009, 2011 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="Does GNU/Hurd support SMP/Multicore?"]] + +The Hurd servers themselves are multithreaded, so they should be able to take benefit of the parallelism brought by SMP/Multicore boxes. This has however never been tested yet because of the following. + +[[microkernel/Mach]] used to be running on SMP boxes like the [[!wikipedia +Intel_iPSC/860]], so principally has the required infrastructure. It has +however not yet been enhanced to support nowadays' SMP standards like ACPI, +etc. Also, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue +code likely isn't SMP-safe. As this glue code layer is not used in the +[[microkernel/mach/gnumach/ports/Xen]] port of GNU Mach, the plan is to try it +in this enviroment first. + +[[!tag open_issue_gnumach open_issue_xen]] + +That is why for now GNU/Hurd will only use one logical processor (i.e. one core or one thread, depending on the socket type). + +Once this issue is solved, there are follow-up issues about +[[open_issues/multiprocessing]] and [[open_issues/multithreading]]. diff --git a/faq/which_microkernel.mdwn b/faq/which_microkernel.mdwn new file mode 100644 index 00000000..0852cf09 --- /dev/null +++ b/faq/which_microkernel.mdwn @@ -0,0 +1,55 @@ +[[!meta copyright="Copyright © 2009, 2011 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="What happened with the Hurd ports to the L4 / Coyotos / Viengoos +microkernels?"]] + +<!-- This page shares some text with history/port_to_another_microkernel. --> + +It is a frequently asked question, which microkernel the Hurd should be based +upon assuming that [[microkernel/Mach]] is no longer considered state of the +art, and it is well known that there has been a lot of discussion about this +topic, and also some code produced, but then, years later, the Hurd is still +based on [[GNU Mach|microkernel/mach/gnumach]]. + +Around the turn of the millenium, some of the Hurd developers began +experimenting with using other [[microkernel]]s for the Hurd, as they have been +encountering a number of fundamental design issues with the [[Mach +microkernel|microkernel/mach]], mostly with respect to +[[open_issues/resource_management_problems]]. + +At that time, L4 (Pistachio) was the prime candidate. A reimplementation of +the Hurd on this microkernel looked promising, and got pretty far (running some +simple POSIX programs, such as `banner`). However, over time some lingering +design issues turned out to be fundamental problems: the original L4 is not +suitable for building object-capability systems like the Hurd. Thus +development was aborted in 2005. + +During that process, Neal Walfield and Marcus Brinkmann started on a period of +research on other microkernels, getting in deeper contact with other +researchers. There was a lot of discussion, and a lot of good ideas produced, +but a straight-forward port of the Hurd to such a modern microkernel (Coyotos, +or the new L4 variants, for example) didn't seem feasible to them anymore: they +found microkernel design and system design to be interconnected in very +intricate ways, and this demanded design changes in the Hurd's core itself. + +Based on this experience, the next step was to write an own microkernel +instead, which Neal Walfield began doing with his experimental +[[microkernel/Viengoos]] project, for his research on resource management. +Currently he works in another research area though, and thus Viengoos is on +hold. + +Note that while none of the microkernel research work is active now, the +previous experiments already yielded a lot of experience, which will be very +useful in the further development / improvement of the mainline (Mach-based) +Hurd implementation. + +For more detauls about this topic, please see our history page about the +[[history/port_to_another_microkernel]]. diff --git a/gnu.mdwn b/gnu.mdwn new file mode 100644 index 00000000..4efc0bad --- /dev/null +++ b/gnu.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +{{$gnustatus-2011-01}} + + +[[!ymlfront data=""" + +gnustatus-2011-01: + + "[GNU Status Reports: January + 2011](http://www.gnu.org/bulletins/gnustatus-2011-01.html)" + +"""]] diff --git a/history.mdwn b/history.mdwn index 8f155b54..0abcbd52 100644 --- a/history.mdwn +++ b/history.mdwn @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 1998, 1999, 2001, 2002, 2007, 2008, 2009 Free -Software Foundation, Inc."]] +[[!meta copyright="Copyright © 1998, 1999, 2001, 2002, 2007, 2008, 2009, 2011 +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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag stable_URL]] @@ -91,4 +91,4 @@ mailing lists. --- - * [[Port_to_L4]] + * [[Port_to_another_microkernel]] diff --git a/history/port_to_another_microkernel.mdwn b/history/port_to_another_microkernel.mdwn new file mode 100644 index 00000000..a8ec3fe7 --- /dev/null +++ b/history/port_to_another_microkernel.mdwn @@ -0,0 +1,178 @@ +[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, +2009, 2010, 2011 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="Porting the Hurd to another microkernel"]] + +<!-- This page shares some text with faq/which_microkernel. --> + +It is a frequently asked question, [[faq/which_microkernel]] the Hurd should be +based upon assuming that [[microkernel/Mach]] is no longer considered state of +the art, and it is well known that there has been a lot of discussion about +this topic, and also some code produced, but then, years later, the Hurd is +still based on [[GNU Mach|microkernel/mach/gnumach]]. + +At first, there was an effort to directly port the Hurd to the +[[L4_microkernel_family|microkernel/l4]]. Then the story continued... + +[[!toc levels=2]] + + +# L4 + +## Initial Idea + +Encountering a number of fundamental design issues with the [[Mach +microkernel|microkernel/mach]] (mostly regarding [[resource +management|open_issues/resource_management_problems]]), some of the Hurd +developers began experimenting with using other microkernels for the Hurd +around the turn of the millenium. + +The idea of using L4 as a [[microkernel]] for a Hurd system was initially +voiced in the [[community]] by Okuji Yoshinori, who, for discussing this +purpose, created the [[mailing_lists/l4-hurd]] mailing list in November 2000. + +Over the years, a lot of discussion have been held on this mailing list, which +today is still the right place for [[next-generation Hurd|hurd/ng]] +discussions. + + +## Why? + +Even though that said resource management issues constitute a broad research +topic, there was no hope that the original Mach project would work on these: +[[microkernel/Mach]] wasn't maintained by its original authors anymore. Mach +had served its purpose as a research vehicle, and has been retired by its +stakeholders. + +Thus, switching to a well-maintained current [[microkernel]] was expected to +yield a more solid foundation for a Hurd system than the [[decaying +Mach|microkernel/mach/history]] design and implementation was able to. + +At that time, the [[L4 microkernel family|microkernel/L4]] was one obvious +choice. Being a second-generation microkernel, it was deemed to provide for a +faster system kernel implementation, especially in the time-critical [[IPC]] +paths. Also, as L4 was already implemented for a bunch of different +architectures (x86, Alpha, MIPS; also including SMP support), and the Hurd +itself being rather archtecture-agnostic, it was expected to be able to easily +support more platforms than with the existing system. + + +## Steps and Goals + +At the same time, the idea was -- while mucking with the system's core anyway +-- to improve on some fundamental design issues, too -- like the resource +management problems, for example. + +One goal of porting the Hurd to L4 was to make the Hurd independent of +[[microkernel/Mach]] interfaces, to make it somewhat microkernel-agnostic. + +One idea was to first introduce a Mach-on-L4 emulation layer, to easily get a +usable (though slow) Hurd-using-Mach-interfaces-on-L4 system, and then +gradually move the Hurd servers to use L4 intefaces rather than Mach ones. + +A design upon the lean L4 kernel would finally have made it feasible to move +devices drivers out of the kernel's [[TCB]]. + + +# Implementation + +The project itself then was mostly lead by Marcus Brinkmann and Neal Walfield. +Neal started the original Hurd/L4 port while visiting Karlsruhe university in +2002. He explains: + +> My intention was to adapt the Hurd to exploit L4's concepts and intended +> [[design_pattern]]s; it was not to simply provide a Mach +> [[compatibility_layer]] on top of L4. When I left Karlsruhe, I no longer had +> access to [[microkernel/l4/Pistachio]] as I was unwilling to sign an NDA. +> Although the specification was available, the Karlsruhe group only [released +> their code in May +> 2003](https://lists.ira.uni-karlsruhe.de/pipermail/l4ka/2003-May/000345.html). +> Around this time, Marcus began hacking on Pistachio. He created a relatively +> complete run-time. I didn't really become involved again until the second +> half of 2004, after I complete by Bachelors degree. + +Development of Hurd/L4 was done in the [CVS module +`hurd-l4`](http://savannah.gnu.org/cgi-bin/viewcvs/hurd/hurd-l4/). The `doc` +directory contains a design document that is worth reading for anyone who +wishes to learn more about Hurd/L4. + +Even though there was progress -- see, for example, the [[QEMU image for +L4|hurd/running/qemu/image_for_l4]] -- this port never reached a releasable +state. Simple POSIX programs, such as `banner` could run, but for more complex +system interfaces, a lot more work was needed. + +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. Neal goes on: + +> Before Marcus and I considered [[microkernel/Coyotos]], we had already +> 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 +> [[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 +> [[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 +> aligned our position with that of Jonathan's. This was particularly true of +> a number of security issues. + +A lange number of discussion threads can be found in the archives of the +[[mailing_lists/l4-hurd]] mailing list. + +> Hurd-NG, as we originally called it, was an attempt to articulate the system +> that we had come to envision in terms of interfaces and description of the +> system's structure. The new name was selected, if I recall correctly, as it +> clearly wasn't the Hurd nor the Hurd based on L4. + + +## Termination + +As of 2005, development of Hurd/L4 has stopped. + + +# Coyotos + +Following that, an attempt was started to use the kernel of the +[[microkernel/Coyotos]] system. As Coyotos is an object-capability system +througout, the microkernel would obviously be more suitable for this purpose; +and it looked pretty promising in the beginning. However, further +investigations found that there are some very fundamental philosophical +differences between the Coyotos and Hurd designs; and thus this this attempt +was also abandonned, around 2006 / 2007. (This time before producing any +actual code.) + + +# Viengoos + +By now (that is, after 2006), there were some new [[microkernel/L4]] variants +available, which added protected [[IPC]] paths and other features necessary for +object-capability systems; so it might be possible to implement the Hurd on top +of these. However, by that time the developers concluded that microkernel +design and system design are interconnected in very intricate ways, and thus +trying to use a third-party microkernel will always result in trouble. So Neal +Walfield created the experimental [[microkernel/Viengoos]] kernel instead -- +based on the experience from the previous experiments with L4 and Coyotos -- +for his [[research on resource +management|open_issues/resource_management_problems]]. Currently he works in +another research area though, and thus Viengoos is on hold. + + +# Intermediate Results + +Note that while none of the microkernel work is active now, the previous +experiments already yielded a lot of experience, which will be very useful in +the further development / improvement of the mainline (Mach-based) Hurd +implementation. diff --git a/history/port_to_another_microkernel/discussion.mdwn b/history/port_to_another_microkernel/discussion.mdwn new file mode 100644 index 00000000..f2161195 --- /dev/null +++ b/history/port_to_another_microkernel/discussion.mdwn @@ -0,0 +1,69 @@ +[[!meta copyright="Copyright © 2009, 2011 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]]."]]"""]] + +IRC, #hurd, 2011-01-12. + +[[!taglink open_issue_documentation]] + + <Pete-J> Hello i am just curious of the development of Hurd - what's the + current mission on the microkernel i see projects like l4 and viengoos, + will one of these projects replace Mach? or will you stick with Mach + <Pete-J> as i understand is that Mach is a first generation microkernel + that's very old in design and causes alot of issues + <Pete-J> that's where l4 and viengoos comes in - they are trying to be the + next generation Mach - am i correct? + <neal> l4 is not a drop in replacement for Mach + <neal> it doesn't actually do much resource management + <neal> for instance, you still have to implement a memory manager + <neal> this is where several issues are with Mach + <neal> l4 doesn't address those issues; it punts to the operating system + <Pete-J> and what about viengoos? + <neal> it's unfinished + <neal> and it implemented some untested ideas + <neal> i.e., parts of viengoos were research + <neal> there has not been a sufficient evaluation of those ideas to + determine whether they are a good approach + <Pete-J> meaning that viengoos is a research kernel that could aid Mach? + <neal> I'm not sure I understand your question + <Pete-J> Well is viengoos trying to be a replacement for Mach, or will + viengoos be an experiment of new ideas that could be implemented in Mach? + <Pete-J> i am sorry for my limited english + <neal> viengoos was designed with a Hurd-like user-land in mind + <neal> in that sense it was a Mach replacement + <neal> (unlike L4) + <neal> viengoos consisted of a few experiments + <neal> one could implement them in mach + <neal> but it would require exposing new interfaces + <neal> in which case, I'm not sure you could call the result Mach + <Pete-J> Well as i understand you develop two microkernels side by side, + wouldnt it be more effective to investigate viengoos more and maybe move + the focus to viengoos? + <antrik> no + <antrik> having something working all the time is crucial + <antrik> it's very hard to motivate people to work on a project that might + be useful, in a couple of years, perhaps... + <Pete-J> Well Mach is meant to be replaced one day - i see no reason to + keep on developing it just because it works at this moment + <Pete-J> *if Mach is meant to be replaced + <antrik> it's not at all clear that it will be replaced by something + completely different. I for my part believe that modifying the existing + Mach is a more promising approach + <Pete-J> as i understand man power is something you need - and by spreading + out the developers just makes the progress more slow + <antrik> but even if it *were* to be replaced one day, it doesn't change + the fact that we need it *now* + <antrik> all software will be obsolete one day. doesn't mean it's not worth + working on + <antrik> the vast majority of work is not on the microkernel anyways, but + on the system running on top of it + <Pete-J> ahh i see + <antrik> manpower is not something that comes from nowhere. again, having + something working is crucial in a volunteer project like this + <antrik> there are no fixed plans diff --git a/history/port_to_l4.mdwn b/history/port_to_l4.mdwn index b58c0d91..3f951a64 100644 --- a/history/port_to_l4.mdwn +++ b/history/port_to_l4.mdwn @@ -1,108 +1,13 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, -2009, 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[!meta title="Porting the Hurd to L4: Hurd/L4"]] +[[!tag stable_URL]] -There was an effort to port the Hurd from [[microkernel/Mach]] to the -[[L4_microkernel_family|microkernel/L4]]. - -The idea of using L4 as a [[microkernel]] for a [[Hurd_system|hurd]] was -initially voiced in the [[Hurd_community|community]] by Okuji Yoshinori, who, -for discussing this purpose, created the [[mailing lists/l4-hurd]] mailing list -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|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 [[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|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 -reading for anyone who wishes to learn more about Hurd/L4. - - -One goal of porting the Hurd to L4 was to make the Hurd independend of Mach -interfaces, to make it somewhat microkernel-agnostic. - -Mach wasn't maintained by its original authors anymore, so switching to a -well-maintained current [[microkernel]] was expected to yield a more solid -foundation for a Hurd system than the decaying Mach design and implementation -was able to. - -L4 being a second-generation [[microkernel]] was deemed to provide for a faster -system kernel implementation, especially in the time-critical [[IPC]] paths. -Also, as L4 was already implemented for a bunch of different architectures -(IA32, Alpha, MIPS; SMP), and the Hurd itself being rather archtecture-unaware, -it was expected to be able to easily support more platforms than with the -existing system. - -A design upon the lean L4 kernel would finally have moved devices drivers out -of the kernel's [[TCB]]. - - -One idea was to first introduce a Mach-on-L4 emulation layer, to easily get a -usable (though slow) Hurd-using-Mach-interfaces-on-L4 system, and then -gradually move the Hurd servers to use L4 intefaces rather than Mach ones. - - -Neal Walfield started the original Hurd/L4 port while at Karlsruhe in 2002. He -explains: - -> My intention was to adapt the Hurd to exploit L4's concepts and intended -> [[design_pattern]]s; it was not to simply provide a Mach -> [[compatibility_layer]] on top of L4. When I left Karlsruhe, I no longer had -> access to [[microkernel/l4/Pistachio]] as I was unwilling to sign an NDA. -> Although the specification was available, the Karlsruhe group only [released -> their code in May -> 2003](https://lists.ira.uni-karlsruhe.de/pipermail/l4ka/2003-May/000345.html). -> Around this time, Marcus began hacking on Pistachio. He created a relatively -> complete run-time. I didn't really become involved again until the second -> half of 2004, after I complete by Bachelors degree. - -> Before Marcus and I considered [[microkernel/Coyotos]], we had already -> 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 -> [[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 -> [[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 -> aligned our position with that of Jonathan's. This was particularly true of -> a number of security issues. - -A lange number of discussion threads can be found in the archives of the -[[mailing lists/l4-hurd]] mailing list. - -> Hurd-NG, as we originally called it, was an attempt to articulate the system -> that we had come to envision in terms of interfaces and description of the -> system's structure. The new name was selected, if I recall correctly, as it -> clearly wasn't the Hurd nor the Hurd based on L4. - - -The source code is still available in [CVS module -`hurd-l4`](http://savannah.gnu.org/cgi-bin/viewcvs/hurd/hurd-l4/) (note that -this repository has in the beginning also been used for Neal's -[[microkernel/Viengoos]]). +[[!meta redir=port_to_another_microkernel]] diff --git a/hurd-l4.mdwn b/hurd-l4.mdwn index 579c1190..afc8f8f3 100644 --- a/hurd-l4.mdwn +++ b/hurd-l4.mdwn @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag stable_URL]] -[[!meta redir=history/port_to_l4]] +[[!meta redir=history/port_to_another_microkernel]] @@ -1,16 +1,16 @@ [[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, -2009, 2010 Free Software Foundation, Inc."]] +2009, 2010, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] The GNU Hurd is under active development. Because of that, there is no -*stable* version. We distribute the Hurd sources only through CVS at present. +*stable* version. We distribute the Hurd sources only through [[Git|source_repositories]] at present. Although it is possible to bootstrap the GNU/Hurd system from the sources by cross-compiling and installing the system software and the basic applications, @@ -31,7 +31,7 @@ in the *unstable* branch of the Debian archive. * [[What_Is_the_GNU_Hurd]] - A Brief Description * [[Advantages]]. And [[challenges]]. * [[History]] - * [[history/Port_to_L4]] + * [[history/Port_to_another_microkernel]] * [[Logo]] * [[Status]] * [[KnownHurdLimits]] diff --git a/hurd/building.mdwn b/hurd/building.mdwn index 1674b770..a7066465 100644 --- a/hurd/building.mdwn +++ b/hurd/building.mdwn @@ -22,9 +22,9 @@ details. ## Getting the Source Code You can chose between getting the [sources from the developers's -RCS](http://savannah.gnu.org/cvs/?group=hurd): +git](http://savannah.gnu.org/git/?group=hurd): - $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co hurd + $ git clone git://git.sv.gnu.org/hurd/hurd.git ... or (if you are working on a Debian system) the ones that are used for the [current Debian hurd package](http://packages.debian.net/source/unstable/hurd): diff --git a/hurd/building/example.mdwn b/hurd/building/example.mdwn index bf31bf7e..7c84b102 100644 --- a/hurd/building/example.mdwn +++ b/hurd/building/example.mdwn @@ -11,7 +11,7 @@ is included in the section entitled I checked out the source code on my Ubuntu GNU/Linux system connected to the Internet using: - cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co hurd + git clone git://git.sv.gnu.org/hurd/hurd.git I mounted the hurd directory on Ubuntu from my GNU Hurd system connected to the LAN through NFS: diff --git a/hurd/faq/off.mdwn b/hurd/faq/off.mdwn new file mode 100644 index 00000000..363436b0 --- /dev/null +++ b/hurd/faq/off.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2010 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="How am I supposed to shut my Hurd system down?"]] + +The GNU/Hurd does not use SYSV runlevels, so commands like + + $ shutdown -h now + +will not work. Simply use the equivalent shortcut + + $ halt + +which is provided natively on GNU/Hurd, instead of from SYSV runlevels. diff --git a/hurd/faq/smp.mdwn b/hurd/faq/smp.mdwn deleted file mode 100644 index 953784da..00000000 --- a/hurd/faq/smp.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -[[!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="Does GNU/Hurd support SMP/Multicore?"]] - -The Hurd servers themselves are multithreaded, so they should be able to take benefit of the parallelism brought by SMP/Multicore boxes. This has however never been tested yet because of the following. - -Mach used to be running on SMP boxes like the [[http://en.wikipedia.org/wiki/Intel_iPSC/860 | iPSC 860]], so has an infrastructure for running on them. It has however not (yet) been ported to nowadays' SMP standards like ACPI etc. - -That is why for now GNU/Hurd will only uses one logical processor (i.e. one core or one thread, depending on the socket type). diff --git a/hurd/faq/which_microkernel.mdwn b/hurd/faq/which_microkernel.mdwn deleted file mode 100644 index 6180dbbb..00000000 --- a/hurd/faq/which_microkernel.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -[[!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="What happened to the L4/Coyotos/viengoos micro-kernels?"]] - -L4 was promising but happened to not be suitable for implementing a general-purpose operating system on top of it. See [[history/port_to_l4]]. - -Coyotos is abandoned upstream - -Neal Walfield started working on a newly designed kernel called [[viengoos|microkernel/viengoos]]. Unfortunately, he currently lacks time and the projects it paused. - -In the meanwhile, people are thus continuing with [[microkernel/mach]]. diff --git a/hurd/libihash.mdwn b/hurd/libihash.mdwn index 8da04095..03ebae82 100644 --- a/hurd/libihash.mdwn +++ b/hurd/libihash.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2010, 2011 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 @@ -52,3 +53,5 @@ is included in the section entitled * <http://libhashish.sourceforge.net/> * <http://www.azillionmonkeys.com/qed/hash.html> + + * CCAN's htable, idtree diff --git a/hurd/ng.mdwn b/hurd/ng.mdwn index de33949d..481386a4 100644 --- a/hurd/ng.mdwn +++ b/hurd/ng.mdwn @@ -13,7 +13,7 @@ This section explains the motivations behind the new design: * [[Issues_with_L4_Pistachio]] * [[Limitations_of_the_original_Hurd_design]] - * History of the [[history/port_to_L4]] + * History of the [[history/port_to_another_microkernel]] # Work already done diff --git a/hurd/running/debian.mdwn b/hurd/running/debian.mdwn index 97d35bd7..fcd4d49b 100644 --- a/hurd/running/debian.mdwn +++ b/hurd/running/debian.mdwn @@ -1,28 +1,24 @@ [[!meta title="Debian GNU/Hurd"]] -### Debian Resources - +# Debian Resources - Official page about the Debian GNU/Hurd port: [Debian GNU/Hurd](http://www.debian.org/ports/hurd/) +- Debian [[FAQ]] — Frequently Asked Questions -- Debian [[FAQ]] -- Frequently Asked Questions - -### Installing +## QEMU Image +[[!inline pages=hurd/running/debian/qemu_image raw=yes feeds=no]] +# 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) -- [[After_install]] -- Do this to get networking, new console and X - -### Contributing + - [Upgrading K11 or K14 based systems to unstable](http://lists.debian.org/debian-hurd/2007/09/msg00007.html) +- [[After_install]] — Do this to get networking, new console and X -- [[Porting]] -- Helping with porting packages - * [[Patch_submission]] -- How to submit patches for build failures +# Contributing +- [[Porting]] — Helping with porting packages + * [[Patch_submission]] — How to submit patches for build failures - [[Creating_image_tarball]] -### Additional Information - +# Additional Information - [Presentation](http://people.debian.org/~mbanck/talks/hurd_lt2004/html/) - *Debian GNU/Hurd* by [[MichaelBanck]], LinuxTag 2004 Karlsruhe + *Debian GNU/Hurd*, [[MichaelBanck]], LinuxTag 2004 Karlsruhe - [[Status]] - [Archive Qualification](http://wiki.debian.org/ArchiveQualification/hurd-i386) - diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn new file mode 100644 index 00000000..9f828556 --- /dev/null +++ b/hurd/running/debian/qemu_image.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +There is a QEMU image with [[Debian GNU/Hurd|debian]] pre-installed available +as <http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz>. + +Usage: + + $ wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz + $ tar -xz < debian-hurd.img.tar.gz + $ qemu -net nic,model=rtl8139 -net user debian-hurd-*.img + +Just in case you were wondering: the *root* password is *root*. + +[[!if test="destpage(hurd/running/qemu)" then="" else="For more detailed +instructions, please see the [[hurd/running/QEMU]] page."]] diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index c197ad0e..90211e34 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -15,7 +15,7 @@ GNU/Hurd distributions in early stages of development: # Issues <dt>[[SoftwareLicensing]]</dt> -<dd> The copyright and license information for software that is distributed with the Hurd software is important. Debian has it's DFSG guidelines. Other distributions will need to address these same issues. </dd> +<dd> The copyright and license information for software that is distributed with the Hurd software is important. Debian has its DFSG guidelines. Other distributions will need to address these same issues. </dd> [[GnuDebianRelationship]] diff --git a/hurd/running/gnu/discussion.mdwn b/hurd/running/gnu/discussion.mdwn deleted file mode 100644 index 7a96803b..00000000 --- a/hurd/running/gnu/discussion.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -## <a name="GNU_Web_Meta_Discussion"> </a> GNU Web Meta Discussion - -Where did you get that logo? Maybe it's the color but it looks very elegant compared to <http://www.gnu.org> - --- [[Main/GrantBow]] - 23 Oct 2002 - -I did it myself. Somewhat inspired by another GNU artwork, but completely hand made in the Gimp. - -I'm working on a cool Mach logo as well. Inspiration is the old Atari arcade game M.A.C.H. 3. :-) - --- [[Main/JoachimNilsson]] - 29 Oct 2002 - -What do you feel about the new copyright notice at the bottom of this web? - -I'm afraid that I will have to add another page to the edit process to actually enforce this stuff. Perhaps I can combine the old Preview with this copyright assignment, what do you think? - -Oh, btw. It seems RMS is right. At least according to Swedish law (as far as I've checked) transfer/assignment of copyright can be made the way he describes. The user has to select a checkbox or press a button to accept the copyright assignment each time. But as long as that is done we don't have to have any other form of "legal contract" between the users and the FSF. - --- [[Main/JoachimNilsson]] - 29 Oct 2002 diff --git a/hurd/running/live_cd.mdwn b/hurd/running/live_cd.mdwn index 42d85c5b..c9360594 100644 --- a/hurd/running/live_cd.mdwn +++ b/hurd/running/live_cd.mdwn @@ -1,4 +1,6 @@ -You can download a gzipped iso of a Hurd Live CD at +[[Arch Hurd|hurd/running/arch_hurd/]] offers Hurd LiveCDs at <http://www.archhurd.org/gethurd.php>. + +Also you can download a gzipped iso of a Hurd Live CD at <http://www.superunprivileged.org/hurd/live-cd/>. The Superunpriveleged crew also offers a tiny Hurd Live CD that is under 10 diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index 6989cf72..aea20ae8 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -1,18 +1,29 @@ +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011 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]]."]]"""]] + This page discusses things for [[Unix]] systems, there is a separate page for [[Microsoft_Windows]] systems. - # Readily Available Images -To try out the Hurd you can use the image of the Debian GNU/Hurd: +You can use the following images to give the GNU/Hurd a try. -* [Official Debian GNU/Hurd QEMU image](http://ftp.debian-ports.org/debian-cd/K16/debian-hurd-k16-qemu.img.tar.gz) +## Debian GNU/Hurd -(!) Note that the following are unofficial images: they have been prepared by -volunteers and may not have been tested extensively. +[[!inline pages=hurd/running/debian/qemu_image raw=yes feeds=no]] -<!--* [Disk image](http://www.numenor.art.pl/balrog/hurd/) with an installation of - [[Debian_GNU/Hurd|running/debian]].--> +## Unofficial Images + +Note that the following images are unofficial ones: they have been prepared by +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*'. @@ -20,45 +31,155 @@ volunteers and may not have been tested extensively. 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]] -Also you can use qemu to easily try one of our [[Hurd_LiveCDs|hurd/running/live_cd/]]. +# Arch Hurd Live CD -<!--* [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. //--> +Also you can use QEMU to easily try one of the +[[Hurd_LiveCDs|hurd/running/live_cd/]]. # What is Needed to create a QEMU image +## Debian Installer + +Instructions for creating a qemu image from the install CDs from debian installer can be found in the README alongside the d-i Hurd images: <http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/> + +## Old method + 1. First thing is to install [[/QEMU]]. 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 and 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. +# KVM acceleration + +Check if your CPU supports kvm: + + $ egrep '^flags.*(vmx|svm)' /proc/cpuinfo + +#### If you don't have hardware support (slow): + $ apt-get install qemu + +#### If you have hardware support (recommended): + $ apt-get install qemu-kvm + $ modprobe kvm + +Intel VTx/VTd: Enable Intel kvm in the BIOS + +On a HP xw4600 Workstation: F10, Security->System Security; Enable VTx and VTd + +Check that the kvm module is loaded: + + $ lsmod|grep kvm + kvm_intel 38050 0 + kvm 213800 1 kvm_intel + + $ ls -l /dev/kvm + crw-rw----+ 1 root kvm 10, 232 Mar 14 15:02 /dev/kvm + +Add yourself to the kvm group: + + $ adduser your_user kvm; logout; login + +AMD SVM (AMD-V): Enable AMD-V in the BIOS if not enabled. + +Check that the kvm module is loaded: + + $ lsmod|grep kvm + kvm_amd 31862 0 + kvm 214088 1 kvm_amd + +More info on kvm at: http://www.linux-kvm.org/page/FAQ + +If your machine supports hardware acceleration, you should really use the kvm variant of qemu, as it speeds things quite a lot. Note however that kvm tends to make assumptions when accelerating things in the linux kernel, you may need some -no-kvm-something option. At the moment in Debian you need to pass + + -no-kvm-irqchip + +to the command line, see below, if you are running Linux kernels 2.6.37 or 2.6.38 else IRQs may hang sooner or later. The kvm irq problems will be solved in kernel 2.6.39. + +# Installing Debian/Hurd with QEMU using the Debian installer + +Note: If you have hardware support, replace the qemu commands below with kvm, e.g. qemu-ing -> kvm-img. + +First off you will need to create a disk image using `qemu-img`. I have set mine to 4 GiB, although you should be able to get away with less. + + $ qemu-img create hd0.img 4G + +Next you will want to start up QEMU and begin the installation process. + + $ qemu -m 512 -hda hd0.img -cdrom mini.iso -net nic,model=rtl8139 -net user -# Installing Debian/Hurd with QEMU +Now at his point do the regular install using `hd0` as your harddrive. Partition it and install the base system. -First off you will need to create a disk image using `qemu-img`. I have set mine to 2 gigabytes, although you should be able to get away with less(Currently, the maximum disk image size one can create with QEMU is 4.5G). +In the installer make your choice of install option: Default install (or your choice) - $ qemu-img create hd0.img 2G + Language: English + Country, territory or area: your_choice + Locale: your_choice -Next you will want to start up QEMU and begin the installation process. The first time you run it you will want to use the `-boot d` option to boot off the cdrom. +Note that even if you can set the country and locale, your local keyboard is not yet supported. - $ qemu -hda hd0.img -cdrom debian-K16-hurd-i386-CD1.iso -fda floppy.img -boot d +In case of problems with timezone or locale settings do the following after the installation is completed -Now at his point do the regular install using `hd0` as your harddrive. Partition it and install the base system. Once you have finished installing the base system select the reboot option as this will ensure the disk is properly un-mounted. When the Debian CD menu comes up again simply close QEMU. + To get the correct timezone: + $ dpkg-reconfigure tzdata + To get your locale setting: + $ nano /etc/locale.gen + $ locale-gen -Now run your image with floppy booting (`-boot a`) and finish the install (`./native-install` .. etc). -You'll want to add more memory or activate swap for `./native-install` or it will hang. -Starting qemu with `-m 512` worked for me. -Swap can be activated like this (replace hd0s2 with your swap partition): +Network: Now configured automatically with dhcp - $ cd /dev/ - $ MAKEDEV hd0s2 - $ /hurd/mach-defpager - $ swapon /dev/hd0s2 + IP address: 10.0.2.15 + Netmask: 255.255.0.0 + Gateway: 10.0.2.2 + Nameserver: 10.0.2.3 -**Important:** Older versions on gnumach needed that the `-M isapc` was passed to qemu. This is not needed anymore. + Qemu network setup: + QEMU VLAN <------> Firewall/DHCP server <-----> Internet + | (10.0.2.2) + | + ----> DNS server (10.0.2.3) + | + ----> SMB server (10.0.2.4) + +Partitioning method: Guided (or your choice) + +Partitioning `/dev/hd0`: All files in one partition. + +**Important**: Since partman does not yet mount other partitions than / automatically at reboot, it is crucial that you choose this option for now. + +Once you have finished installing the base system (might take some time) the system is rebooted and next boot will be from the hard disk. Now you are able to log in to your newly installed GNU/Hurd system. Also see another text about how to [[gnu/create_an_image]] for the [[GNU_system|gnu]]. +## Running the installed system + +Starting qemu/qemu-kvm: + + $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -hda hd0.img -vga vmware + vmsvga_value_write: guest runs Linux. + +Note: See below on port forwarding in the networking section. + +Note: Using the vmware vga driver is useful for setting up X windows, see [Debian GNU/Hurd](http://www.debian.org/ports/hurd/hurd-install) + +If you have problems with grub hanging during boot with the vmware vga driver: Disable the graphic boot + + $ nano /etc/default/grub + uncomment GRUB_TERMINAL=console + $ /usr/sbin/update-grub + +### A few words about the qemu console + +During the graphical emulation, you can use the following keys: + + <Ctrl><Alt>-f Toggle full screen + <Ctrl><Alt>-u Restore the screen's un-scaled dimensions + <Ctrl><Alt>-n Switch to virtual console 'n'. Standard console mappings are: + 1 Target system display + 2 Monitor + 3 Serial port + <Ctrl><Alt> Toggle mouse and keyboard grab. + # Transferring Files @@ -75,13 +196,13 @@ You may wish to mount your disk image on your host system to transfer files. To hd0.img1 * 63 3515903 1757920+ 83 Linux hd0.img2 3515904 4193279 338688 82 Linux swap / Solaris -Now take the number of sectors for the beginning of the partition and multiply it by the sector size. My partition starts at sector 63 and I have a sector size of 512 therefor my offset is 32256. +Now take the number of sectors for the beginning of the partition and multiply it by the sector size. My partition starts at sector 63 and I have a sector size of 512 therefore my offset is 32256. For a start at 2048 the ofsset is 1048576. # mount -o loop,offset=32256 hd0.img /mnt/diskimage ## Having QEMU create *virtual FAT disk images* -[Manual](http://www.nongnu.org/qemu/qemu-doc.html#SEC25). +[Link to the manual](http://www.nongnu.org/qemu/qemu-doc.html#SEC25). QEMU has a facility to create FAT file systems on-the-fly: @@ -107,6 +228,14 @@ If you just want to access the internet from within QEMU, you can setup pfinet f # settrans -afgp /servers/socket/2 /hurd/pfinet -i eth0 -a 10.0.2.15 -g 10.0.2.2 -m 255.255.255.0 # echo "nameserver 10.0.2.3" > /etc/resolv.conf +Alternately DHCP does work now: + + # dhclient eth0 + +To get ssh working: + + # apt-get install random-egd openssh-server (Similarly for telnet if preferred) + (See also <http://www.nongnu.org/qemu/qemu-doc.html#SEC32>.) Outgoing internet connections should just work then. @@ -116,8 +245,40 @@ but `apt-get update` should work after you have filled out After that you should be able to install other network packages, but note that `ping` doesn't work with QEMU's user-networking stack. -If you want to connect from the host system to the Hurd system running in QEMU, you need to setup something more advanced, like bridged networking. +If you want to connect from the host system to the Hurd system running in QEMU, you can use port forwarding in QEMU or to setup something more advanced, like bridged networking. + +## Port Forwarding in QEMU +(In the following we assume we use kvm!) + +#### Logging in to Hurd from a terminal in your host system +This is the recommended way to work with a Command Line Interface (CLI) since all your keyboard and locale settings are preserved. + +a) with ssh (assuming you have installed openssh-server) + + $ kvm -m 1024 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -hda hd0.img & + +Logging in to the running Hurd: + + $ ssh -p5555 localhost + +Copying files: + 1) On your host + To Hurd: scp -p -P5555 file localhost: + From Hurd: scp -p -P5555 localhost:file . + 2) On Hurd + To host: scp -p file {10.0.2.2,your_host_ip}: . + From host: scp -p {10.0.2.2,your_host_ip}:file . + +b) with telnet (assuming you have installed a telnet server, like telnetd) + + $ kvm -m 1024 -net nic,model=rtl8139 -net user,hostfwd=tcp::5556-:23 -hda hurd-install.qemu & + +Logging in to the running Hurd: + + $ telnet localhost 5556 + +c) With the tap interface, see below. ## Bridged Networking @@ -171,31 +332,3 @@ system after installation. [[Image_for_L4]] -- a QEMU image for the Hurd/L4 project. <http://eyeside.net/hurd/Hurd-on-QEMU.html> - - -# TODO - -[[IRC]], #hurd, 2007-07-04. - - <azeem-uni> so, is there a way to use a Debian GNU/Hurd partition (/dev/hda6) with qemu directly? - <tschwinge> Don't dare to do that, please. - <tschwinge> It will lead to inconsistencies. - <tschwinge> Because the Linux kernel thinks that it has complete control over the disk, or something. - <tschwinge> In theory you could run something like ``-hda /dev/hda'', having GRUB installed on there to offer you to boot your Hurd system from hda6 and that will even work, but then don't get the idea to stop qemu, mount that partition on your Linux system and restart qemu. That's where I got lots of inconsistencies then, afterwards. - <azeem-uni> it's probably the same problem as having that partition mounted, suspending to disk, booting into it in the Hurd, and resume Linux - <neal> right - <tschwinge> That's a different problem. - <tschwinge> Then the partitoon is still mounted. - <neal> no, I think it is basically the same problem - <tschwinge> The file system stuff is cached in the kernel. - <neal> you have data that has not been written to disk yet - <tschwinge> Right. - <neal> and neither is prepared for the resource to be shared - <tschwinge> In the azeem-uni scenarion the data is on the file system layer and in my scenarion it's some disk block caching inside the Linux kernel, I guess. - <azeem-uni> anyway, do you guys think if I use -hda /dev/hda and tell Grub to boot off /dev/hda6, that the rest of hda should be fine, right? - <azeem-uni> maybe adding -snapshot makes it totally safe - <neal> azeem: Should be fine. - <tschwinge> Yes. - -The problem is actually that the linux block cache doesn't make any consistency between /dev/hda and /dev/hda6, so if you give /dev/hda to qemu, qemu writings won't be consistent with mounting /dev/hda6 in linux. You can give /dev/hda6 directly to qemu and it will be fine. - diff --git a/hurd/running/qemu/discussion.mdwn b/hurd/running/qemu/discussion.mdwn new file mode 100644 index 00000000..fd0df4c5 --- /dev/null +++ b/hurd/running/qemu/discussion.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011 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]]."]]"""]] + +[[!tag open_issue_documentation]] + +# Using Partitions + +[[IRC]], #hurd, 2007-07-04. + + <azeem-uni> so, is there a way to use a Debian GNU/Hurd partition + (/dev/hda6) with qemu directly? + <tschwinge> Don't dare to do that, please. + <tschwinge> It will lead to inconsistencies. + <tschwinge> Because the Linux kernel thinks that it has complete control + over the disk, or something. + <tschwinge> In theory you could run something like ``-hda /dev/hda'', + having GRUB installed on there to offer you to boot your Hurd system from + hda6 and that will even work, but then don't get the idea to stop qemu, + mount that partition on your Linux system and restart qemu. That's where + I got lots of inconsistencies then, afterwards. + <azeem-uni> it's probably the same problem as having that partition + mounted, suspending to disk, booting into it in the Hurd, and resume + Linux + <neal> right + <tschwinge> That's a different problem. + <tschwinge> Then the partitoon is still mounted. + <neal> no, I think it is basically the same problem + <tschwinge> The file system stuff is cached in the kernel. + <neal> you have data that has not been written to disk yet + <tschwinge> Right. + <neal> and neither is prepared for the resource to be shared + <tschwinge> In the azeem-uni scenarion the data is on the file system layer + and in my scenarion it's some disk block caching inside the Linux kernel, + I guess. + <azeem-uni> anyway, do you guys think if I use -hda /dev/hda and tell Grub + to boot off /dev/hda6, that the rest of hda should be fine, right? + <azeem-uni> maybe adding -snapshot makes it totally safe + <neal> azeem: Should be fine. + <tschwinge> Yes. + +The problem is actually that the linux block cache doesn't make any consistency +between /dev/hda and /dev/hda6, so if you give /dev/hda to qemu, qemu writings +won't be consistent with mounting /dev/hda6 in linux. You can give /dev/hda6 +directly to qemu and it will be fine. diff --git a/hurd/running/vmware/discussion.mdwn b/hurd/running/vmware/discussion.mdwn deleted file mode 100644 index 2db08654..00000000 --- a/hurd/running/vmware/discussion.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -[[!meta copyright="Copyright © 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]]."]]"""]] - -I find that this is all quite quick to try and that I can run through the -./native-install and reboot cycle twice OK. However, at that point the -installed Hurd boots up but fails to display a login prompt. This is the case -for both K10 and K14 using VMware Workstation 5.0.0 under Windows XP. Maybe -I'm doing something wrong but it is hard to see what. I'd be interested to -know more precisely what other people find does work. - ---IanMiller - 01 Apr 2007 diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn index cb4a40a8..b8e595d3 100644 --- a/hurd/subhurd.mdwn +++ b/hurd/subhurd.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -21,6 +21,8 @@ possible to use [[debugging/gdb/noninvasive_debugging]], but this is less flexible.) Vice versa, it is also possible to use a subhurd to debug the *main* Hurd system, for example, the latter's root file system. +[[!toc levels=2]] + # Howto @@ -139,3 +141,47 @@ translator|translator/ext2fs]]'s [[PID]], but this is no problem, as currently [[PID]]s are visible across subhurd boundaries. (It is a [[!taglink open_issue_hurd]] whether this is the right thing to do in [[open_issues/virtualization]] contexts, but that's how it currently is.) + + +<a name="unit_testing"></a> +## Unit Testing + +freenode, #hurd channel, 2011-03-06: + +From [[open_issues/unit_testing]]. + + <youpi> it could be interesting to have scripts that automatically start a + sub-hurd to do the tests + <youpi> though that'd catch sub-hurd issues :) + <foocraft> so a sub-hurd is a hurd that I can run on something that I know + works(like linux)? + <foocraft> Virtual machine I would think + <foocraft> and over a network connection it would submit results back to + the host :p + * foocraft brain damage + <youpi> sub-hurd is a bit like chroot + <youpi> except that it's more complete + <foocraft> oh okay + <youpi> i.e. almost everything gets replaced with what you want, except the + micro-kernel + <youpi> that way you can even test the exec server for instance, without + risks of damaging the host OS + <foocraft> and we know the micro-kernel works correctly, right youpi? + <youpi> well, at least it's small enough that most bugs are not there + <foocraft> 1) all tests run in subhurd 2) output results in a place in the + subhurd 3) tester in the host checks the result and pretty-prints it 4) + rinse & repeat + <youpi> the output can actually be redirected iirc + <youpi> since you give the sub-hurd a "console" + <foocraft> youpi, yup yeah, so now it's more like chroot if that's the case + <youpi> it really looks like chroot, yes + <foocraft> but again, there's this subset of tests that we need to have + that ensures that even the tester running on the subhurd is valid, and it + didn't break because of a bug in the subhurd + <tschwinge> As long as you do in-system testing, you'll always (have to) + rely on some functionality provided by the host system. + <foocraft> the worst thing that could happen with unit testing is false + results that lead someone to try to fix something that isn't broken :p + <tschwinge> Yes. + <youpi> usually one tries to repeat the test by hand in a normal + environment diff --git a/hurd/translator/procfs/jkoenig.mdwn b/hurd/translator/procfs/jkoenig.mdwn index 1275ce52..9543b658 100644 --- a/hurd/translator/procfs/jkoenig.mdwn +++ b/hurd/translator/procfs/jkoenig.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -21,56 +21,3 @@ Testing it is as simple as this: $ make $ settrans -ca proc procfs --compatible $ ls -l proc/ - - -# Open Issues - -[[!tag open_issue_hurd]] - - * IRC, #hurd, around September 2010 - - <youpi> jkoenig: from a quick read, your procfs implementation seems quite - simple, probably much more what I was expecting from Madhusudan (who probably - now hates you :) ) - <youpi> jkoenig: is it not possible to provide a /proc/self which points at the - client's pid? - <pinotree> (also, shouldn't /proc/version say something else than "Linux"?) - <youpi> to make linux tools work, no :/ - <youpi> kfreebsd does that too - <pinotree> really? - <youpi> yes - <youpi> (kfreebsd, not freebsd) - <pinotree> does kbsd's one print just "Linux version x.y.z" too, or something - more eg in a second line? - <pinotree> (as curiosity) - <youpi> % cat /proc/version - <youpi> Linux version 2.6.16 (des@freebsd.org) (gcc version 4.3.5) #4 Sun Dec - 18 04:30:00 CET 1977 - <pinotree> k - <giselher> I had some problems with killall5 to read the pid from /proc, Is - this now more reliable? - <youpi> I haven't tested with jkoenig's implementation - [...] - <pinotree> looks like he did 'self' too, see rootdir_entries[] in rootdir.c - <youpi> but it doesn't point at self - <antrik> youpi: there is no way to provide /proc/self, because the server - doesn't know the identity of the client - <youpi> :/ - <antrik> youpi: using the existing mechanisms, we would need another magic - lookup type - <antrik> an alternative idea I discussed with cfhammer once would be for the - client to voluntarily provide it's identity to the server... but that would - be a rather fundamental change that requires careful consideration - <antrik> also, object migration could be used, so the implementation would be - provided by the server, but the execution would happen in the client... but - that's even more involved :-) - <youpi> but we've seen how much that'd help with a lot of other stuff - <antrik> I'm not sure whether we discussed this on the ML at some point, or - only on IRC - <youpi> it "just" needs to be commited :) - <antrik> in either case, it can't hurt to bring this up again :-) - - * IRC, #hurd, around October 2010 - - <pinotree> the only glitch is that files/dirs have the right user as - owner, but always with root group diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn new file mode 100644 index 00000000..b66af7de --- /dev/null +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -0,0 +1,168 @@ +[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]] + +[[!tag open_issue_hurd]] + +[[!toc]] + + +# Miscellaneous + +IRC, #hurd, around September 2010 + + <youpi> jkoenig: from a quick read, your procfs implementation seems quite + simple, probably much more what I was expecting from Madhusudan (who + probably now hates you :) ) + <youpi> jkoenig: is it not possible to provide a /proc/self which points at + the client's pid? + <pinotree> (also, shouldn't /proc/version say something else than "Linux"?) + <youpi> to make linux tools work, no :/ + <youpi> kfreebsd does that too + <pinotree> really? + <youpi> yes + <youpi> (kfreebsd, not freebsd) + <pinotree> does kbsd's one print just "Linux version x.y.z" too, or + something more eg in a second line? + <pinotree> (as curiosity) + <youpi> % cat /proc/version + <youpi> Linux version 2.6.16 (des@freebsd.org) (gcc version 4.3.5) #4 Sun + Dec 18 04:30:00 CET 1977 + <pinotree> k + <giselher> I had some problems with killall5 to read the pid from /proc, Is + this now more reliable? + <youpi> I haven't tested with jkoenig's implementation + [...] + <pinotree> looks like he did 'self' too, see rootdir_entries[] in rootdir.c + <youpi> but it doesn't point at self + <antrik> youpi: there is no way to provide /proc/self, because the server + doesn't know the identity of the client + <youpi> :/ + <antrik> youpi: using the existing mechanisms, we would need another magic + lookup type + <antrik> an alternative idea I discussed with cfhammer once would be for + the client to voluntarily provide it's identity to the server... but that + would be a rather fundamental change that requires careful consideration + <antrik> also, object migration could be used, so the implementation would + be provided by the server, but the execution would happen in the + client... but that's even more involved :-) + <youpi> but we've seen how much that'd help with a lot of other stuff + <antrik> I'm not sure whether we discussed this on the ML at some point, or + only on IRC + <youpi> it "just" needs to be commited :) + <antrik> in either case, it can't hurt to bring this up again :-) + + +# root group + +IRC, #hurd, around October 2010 + + <pinotree> the only glitch is that files/dirs have the right user as + owner, but always with root group + + +# `/proc/$pid/stat` being 400 and not 444, and some more + +IRC, freenode, #hurd, 2011-03-27 + + <pochu> is there a reason for /proc/$pid/stat to be 400 and not 444 like on + Linux? + <pochu> there is an option to procfs to make it 444 like Linux + <pochu> jkoenig: ^ + <jkoenig> pochu, hi + <jkoenig> /proc/$pid/stat reveals information which is not usually + available on Hurd + <jkoenig> so I made it 400 by default to avoid leaking anything + <pochu> is there a security risk in providing that info? + <jkoenig> probably not so much, but it seemed like it's not really a + descision procfs should make + <jkoenig> I'm not sure which information we're speaking about, though, I + just remember the abstract reason. + <pochu> things like the pid, the memory, the priority, the state... + <pochu> sounds safe to expose + <jkoenig> also it's 0444 by default in "compatible" mode + <jkoenig> (which is necessary for the linux tools to work well) + <pochu> yeah I saw that :) + <pochu> my question is, should we change it to 0444 by default? if there + are no security risks and this improves compatibility, sounds like a good + thing to me + <pochu> we're already 'leaking' part of that info through e.g. ps + <jkoenig> I think /proc should be translated by /hurd/procfs --compatible + by default (I'm not sure whether it's already the case) + <jkoenig> also I'm not sure why hurd-ps is setuid root, rather than the + proc server being less paranoid, but maybe I'm missing something. + <pochu> jkoenig: it's not, at least not on Debian + <pochu> youpi: hi, what do you think about starting procfs with + --compatible by default? + <pochu> youpi: or changing /proc/$pid/stat to 0444 like on Linux + (--compatible does that among a few other things) + <youpi> I guess you need it for something? + <pochu> I'm porting libgtop :) + <youpi> k + <pochu> though I still think we should do this in procfs itself + <youpi> ymmv + <jkoenig> pochu, youpi, --compatible is also needed because mach's high + reported sysconf(_SC_CLK_TCK) makes some integers overflow (IIRC) + <youpi> agreed + <jkoenig> luckily, tools which use procfs usually try to detect the value + /proc uses rather than rely on CLK_TCK + <jkoenig> (so we can choose whatever reasonable value we want) + +IRC, freenode, #hurd, 2011-03-28 + + <antrik> jkoenig: does procfs expose any information that is not available + to everyone through the proc server?... + <antrik> also, why is --compatible not the default; or rather, why is there + even another mode? the whole point of procfs is compatibility... + <jkoenig> antrik, yes, through the <pid>/environ and (as mentionned above) + <pid>/stat files, but I've been careful to make these files readable only + to the process owner + <jkoenig> --compatible is not the default because it relaxes this paranoia + wrt. the stat file, and does not conform to the specification with regard + to clock tick counters + <antrik> what specification? + <jkoenig> the linux proc(5) manpage + <jkoenig> which says clock tick counters are in units of + 1/sysconf(_SC_CLK_TCK) + <antrik> so you are saying that there is some information that the Hurd + proc server doesn't expose to unprivileged processes, but linux /proc + does? + <jkoenig> yes + <antrik> that's odd. I wonder what the reasoning behind that could be + <antrik> but this information is available through Hurd ps? + <antrik> BTW, what exactly is _SC_CLK_TCK supposed to be? + <pinotree> jkoenig: hm, just tried with two random processes on linux + (2.6.32), and enrivon is 400 + <pinotree> (which makes sense, as you could have sensible informations eg + in http_proxy or other envvars) + <jkoenig> antrik, CLK_TCK is similar to HZ (maybe clock resolution instead + of time slices ?) + <jkoenig> sysconf(3) says "The number of clock ticks per second." + <jkoenig> antrik, I don't remember precisely what information this was, but + ps-hurd is setuid root. + <jkoenig> anyway, if you run procfs --compatible as a user and try to read + foo/1/stat, the result is an I/O error, which is the result of the proc + server denying access. + <antrik> but Linux /proc acutally uses HZ as the unit IIRC? or is + _SC_CLK_TCK=HZ on Linux?... + <jkoenig> I expect they're equal. + <jkoenig> in practice procps uses heuristics to guess what value /proc uses + (for compatibility purposes with older kernels) + <jkoenig> I don't think HZ is POSIX, while _SC_CLK_TCK is specifies as the + unit for (at least) the values returned by times() + <jkoenig> s/specifies/specified/ + <jkoenig> antrik, some the information is fetched directly from mach by + libps, and understandably, the proc server does not give the task port to + anyone who asks. + <antrik> well, as long as the information is exposed through ps, there is + no point in hiding it in procfs... + <antrik> and I'm aware of the crazy guessing in libproc... I was actually + mentoring the previous procfs implementation + <antrik> (though I never got around to look at his buggy code...) + <jkoenig> ok diff --git a/hurd/translator/tmpfs.mdwn b/hurd/translator/tmpfs.mdwn index 0179ad6c..d1476a92 100644 --- a/hurd/translator/tmpfs.mdwn +++ b/hurd/translator/tmpfs.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,8 +6,8 @@ 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]]."]]"""]] `tmpfs` is a file system server for temporary data storage without using a real (permanent) [[backing_store]]. @@ -21,9 +21,3 @@ 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/*" -show=0 -feeds=no -actions=yes]] diff --git a/open_issues/sudo_date_crash.mdwn b/hurd/translator/tmpfs/discussion.mdwn index 53303abc..d7a08491 100644 --- a/open_issues/sudo_date_crash.mdwn +++ b/hurd/translator/tmpfs/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011 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,9 +8,10 @@ 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_gnumach]] +[[!tag open_issue_hurd]] -IRC, unknown channel, unknown date. + * [[notes_bing]] - <grey_gandalf> I did a sudo date... - <grey_gandalf> and the machine hangs + * [[notes_various]] + + * [[tmpfs_vs_defpager]] diff --git a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn index ef041a23..f0eb473c 100644 --- a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn +++ b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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,9 +8,12 @@ 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]] + \#hurd, freenode, 2010 - <slpz> humm... why does tmpfs try to use the default pager? that's a bad idea, and probably will never work correctly... + <slpz> humm... why does tmpfs try to use the default pager? that's a bad + idea, and probably will never work correctly... * slpz is thinking about old issues <slpz> tmpfs should create its own pagers, just like ext2fs, storeio... <slpz> slopez@slp-hurd:~$ settrans -a tmp /hurd/tmpfs 10M @@ -21,53 +24,99 @@ License|/fdl]]."]]"""]] <slpz> :-) <pochu> slpz: woo you fixed it? <slpz> pochu: well, it's WIP, but reading/writing works... - <slpz> I've replaced the use of default pager for the standard pager creation mechanism - <antrik> slpz: err... how is it supposed to use swap space if not using the default pager? - <antrik> slpz: or do you mean that it should act as a proxy, just allocating anonymous memory (backed by the default pager) itself? - <youpi> antrik: the kernel uses the default pager if the application pager isn't responsive enough - <slpz> antrik: it will just create memory objects and provide zerofilled pages when requested by the kernel (after a page fault) - <antrik> youpi: that makes sense I guess... but how is that relevant to the question at hand?... + <slpz> I've replaced the use of default pager for the standard pager + creation mechanism + <antrik> slpz: err... how is it supposed to use swap space if not using the + default pager? + <antrik> slpz: or do you mean that it should act as a proxy, just + allocating anonymous memory (backed by the default pager) itself? + <youpi> antrik: the kernel uses the default pager if the application pager + isn't responsive enough + <slpz> antrik: it will just create memory objects and provide zerofilled + pages when requested by the kernel (after a page fault) + <antrik> youpi: that makes sense I guess... but how is that relevant to the + question at hand?... <slpz> antrik: memory objects will contain the data by themselves - <slpz> antrik: as youpi said, when memory is scarce, GNU Mach will start paging out data from memory objects to the default pager + <slpz> antrik: as youpi said, when memory is scarce, GNU Mach will start + paging out data from memory objects to the default pager <slpz> antrik: that's the way in which pages will get into swap space <slpz> (if needed) - <youpi> the thing being that the tmpfs pager has a chance to select pages he doesn't care any more about - <antrik> slpz: well, the point is that instead of writing the pages to a backing store, tmpfs will just keep them in anonymous memory, and let the default pager write them out when there is pressure, right? - <antrik> youpi: no idea what you are talking about. apparently I still don't really understand this stuff :-( + <youpi> the thing being that the tmpfs pager has a chance to select pages + he doesn't care any more about + <antrik> slpz: well, the point is that instead of writing the pages to a + backing store, tmpfs will just keep them in anonymous memory, and let the + default pager write them out when there is pressure, right? + <antrik> youpi: no idea what you are talking about. apparently I still + don't really understand this stuff :-( <youpi> ah, but tmpfs doesn't have pages he doesn't care about, does it? - <slpz> antrik: yes, but the term "anonymous memory" could be a bit confusing. - <slpz> antrik: in GNU Mach, anonymous memory is backed by a memory object without a pager. In tmpfs, nodes will be allocated in memory objects, and the pager for those memory objects will be tmpfs itself - <antrik> slpz: hm... I thought anynymous memory is backed by memory objects created from the default pager? - <antrik> yes, I understand that tmpfs is supposed to be the pager for the objects it provides. they are obviously not anonymoust -- they have inodes in the tmpfs name space - <antrik> but my understanding so far was that when Mach returns pages to the pager, they end up in anonymous memory allocated to the pager process; and then this pager is responsible for writing them back to the actual backing store + <slpz> antrik: yes, but the term "anonymous memory" could be a bit + confusing. + <slpz> antrik: in GNU Mach, anonymous memory is backed by a memory object + without a pager. In tmpfs, nodes will be allocated in memory objects, and + the pager for those memory objects will be tmpfs itself + <antrik> slpz: hm... I thought anynymous memory is backed by memory objects + created from the default pager? + <antrik> yes, I understand that tmpfs is supposed to be the pager for the + objects it provides. they are obviously not anonymoust -- they have + inodes in the tmpfs name space + <antrik> but my understanding so far was that when Mach returns pages to + the pager, they end up in anonymous memory allocated to the pager + process; and then this pager is responsible for writing them back to the + actual backing store <antrik> am I totally off there?... - <antrik> (i.e. in my understanding the returned pages do not reside in the actual memory object the pager provides, but in an anonymous memory object) - <slpz> antrik: you're right. The trick here is, when does Mach return the pages? - <slpz> antrik: if we set the attribute "can_persist" in a memory object, Mach will keep it until object cache is full or memory is scarce + <antrik> (i.e. in my understanding the returned pages do not reside in the + actual memory object the pager provides, but in an anonymous memory + object) + <slpz> antrik: you're right. The trick here is, when does Mach return the + pages? + <slpz> antrik: if we set the attribute "can_persist" in a memory object, + Mach will keep it until object cache is full or memory is scarce <slpz> or we change the attributes so it can no longer persist, of course - <slpz> without a backing store, if Mach starts sending us pages to be written, we're in trouble - <slpz> so we must do something about it. One option, could be creating another pager and copying the contents between objects. + <slpz> without a backing store, if Mach starts sending us pages to be + written, we're in trouble + <slpz> so we must do something about it. One option, could be creating + another pager and copying the contents between objects. <antrik> another pager? not sure what you mean - <antrik> BTW, you didn't really say why we can't use the default pager for tmpfs objects :-) - <slpz> well, there're two problems when using the default pager as backing store for translators - <slpz> 1) Mach relies on it to do swapping tasks, so meddling with it is not a good idea - <slpz> 2) There're problems with seqnos when trying to work with the default pager from tasks other the kernel itself + <antrik> BTW, you didn't really say why we can't use the default pager for + tmpfs objects :-) + <slpz> well, there're two problems when using the default pager as backing + store for translators + <slpz> 1) Mach relies on it to do swapping tasks, so meddling with it is + not a good idea + <slpz> 2) There're problems with seqnos when trying to work with the + default pager from tasks other the kernel itself <slpz> (probably, the latter could be fixed) - <slpz> antrik: pager's terminology is a bit confusing. One can also say creating another memory object (though the function in libpager is "pager_create") + <slpz> antrik: pager's terminology is a bit confusing. One can also say + creating another memory object (though the function in libpager is + "pager_create") <antrik> not sure why "meddling" with it would be a problem... - <antrik> and yeah, I was vaguely aware that there is some seqno problem with tmpfs... though so far I didn't really understand what it was about :-) + <antrik> and yeah, I was vaguely aware that there is some seqno problem + with tmpfs... though so far I didn't really understand what it was about + :-) <antrik> makes sense now - <antrik> anyways, AIUI now you are trying to come up with a mechanism where the default pager is not used for tmpfs objects directly, but without making it inefficient? - <antrik> slpz: still don't understand what you mean by creating another memory object/pager... + <antrik> anyways, AIUI now you are trying to come up with a mechanism where + the default pager is not used for tmpfs objects directly, but without + making it inefficient? + <antrik> slpz: still don't understand what you mean by creating another + memory object/pager... <antrik> (and yeat, the terminology is pretty mixed up even in Mach itself) - <slpz> antrik: I meant creating another pager, in terms of calling again to libpager's pager_create - <antrik> slpz: well, I understand what "create another pager" means... I just don't understand what this other pager would be, when you would create it, and what for... + <slpz> antrik: I meant creating another pager, in terms of calling again to + libpager's pager_create + <antrik> slpz: well, I understand what "create another pager" means... I + just don't understand what this other pager would be, when you would + create it, and what for... <slpz> antrik: oh, ok, sorry - <slpz> antrik: creating another pager it's just a trick to avoid losing information when Mach's objects cache is full, and it decides to purge one of our objects - <slpz> anyway, IMHO object caching mechanism is obsolete and should be replaced + <slpz> antrik: creating another pager it's just a trick to avoid losing + information when Mach's objects cache is full, and it decides to purge + one of our objects + <slpz> anyway, IMHO object caching mechanism is obsolete and should be + replaced <slpz> I'm writting a comment to bug #28730 which says something about this <slpz> antrik: just one more thing :-) - <slpz> if you look at the code, for most time of their lives, anonymous memory objects don't have a pager + <slpz> if you look at the code, for most time of their lives, anonymous + memory objects don't have a pager <slpz> not even the default one - <slpz> only the pageout thread, when the system is running really low on memory, gives them a reference to the default pager by calling vm_object_pager_create + <slpz> only the pageout thread, when the system is running really low on + memory, gives them a reference to the default pager by calling + vm_object_pager_create <slpz> this is not really important, but worth noting ;-) @@ -1,5 +1,5 @@ [[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, -2009, 2010 Free Software Foundation, Inc."]] +2009, 2010, 2011 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 @@ -39,15 +39,11 @@ computing environment as possible. [[!inline pages="news/* and !*/discussion" feedonly=yes -feedshow=10 -sort=title -reverse=yes]] +feedshow=10]] [[!inline pages="news/* and !*/discussion" show=5 feeds=no -sort=title -reverse=yes template=newsitem actions=yes]] @@ -64,6 +60,11 @@ recommendations about how to contribute|contributing]]. See our [[source_repositories]] for the source code. +## Access to a GNU/Hurd System + +We provide accounts on our [[public_Hurd_boxen]], and there are also +[[hurd/running/QEMU]] images available. + # Getting Help @@ -1,13 +1,13 @@ [[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2006, 2007, 2008, 2009, -2010 Free Software Foundation, Inc."]] +2010, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="IRC"]] @@ -53,10 +53,13 @@ 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) [[Google Summer of Code|community/gsoc]] students and their mentors. These meetings turned out to considerably help student-mentor -interactions, and other developers regularely took part, too. For this reason, -we decided to continue having these meetings, even if it's not currently Google -Summer of Code time. The meetings take place in the **`#hurd` channel every -Monday and Thursday at 10:30 UTC** and are open to any interested party. So, +interactions, and other developers regularely took part, too. +<!-- +For this reason, we decided to continue having these meetings, even if it's not +currently Google Summer of Code time. +--> +Currently, the meetings take place in the **`#hurd` channel every +Tuesday at 19:00 UTC** and are open to any interested party. So, everyone, take your chance to chat with GNU Hurd developers! @@ -161,7 +161,6 @@ a:hover /* Placement. */ .sidebar { - width: auto; margin-left: 20px; } diff --git a/lttng.mdwn b/lttng.mdwn new file mode 100644 index 00000000..840312c4 --- /dev/null +++ b/lttng.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2011 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="Linux Trace Toolkit Next Generation (LTTng)"]] + +[[!tag open_issue_hurd open_issue_gnumach]] + +# Overview + + * {{$toupin_lttng_2011}} + + +# Related + + * [[community/gsoc/project_ideas/dtrace]] + + * [[SystemTap]] + + +[[!ymlfront data=""" + +toupin_lttng_2011: + + Dominique Toupin's article [*Using Tracing to Diagnose or Monitor + Systems*](http://www.computer.org/cms/Computer.org/ComputingNow/homepage/2011/0111/rW_SW_UsingTracing.pdf) + (IEEE Software, January / February 2011) + +"""]] diff --git a/mailing_lists.mdwn b/mailing_lists.mdwn index e4bd1368..f89a6e72 100644 --- a/mailing_lists.mdwn +++ b/mailing_lists.mdwn @@ -1,13 +1,14 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 -Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, +2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + # On Posting @@ -30,21 +31,20 @@ Also see these general notes about [[community/communication]]. # Main Lists -The lists are [[unmoderated]] and most of them are hosted on -<http://lists.gnu.org/>. Try to post to the appropriate mailing list. +Most of these lists are [[unmoderated]], and most of them are hosted on +<http://lists.gnu.org/>. Some of the Hurd user groups listed on [[community]] also host additional mailing lists. -<!-- TODO. Need some real ikiwiki way of adding such anchors. --> - <a name="bug-hurd"></a> ## bug-hurd <bug-hurd@gnu.org> <http://lists.gnu.org/mailman/listinfo/bug-hurd> -Technical discussion and bug reports; main development list. If you want to **contribute**, please meet us here. +Technical discussion and bug reports; main development list. If you want to +[[*contribute*|contributing]], please meet us here. <a name="hurd-devel"></a> ## hurd-devel @@ -59,8 +59,8 @@ Subscribe to [[hurd-devel-readers]] instead. <http://lists.gnu.org/mailman/listinfo/hurd-devel-readers> -This list is a read-only mirror of [[hurd-devel]]. In contrast to subscribing -to the latter, everyone is free to subscribe to this read-only list. +This list is a read-only mirror of [[hurd-devel]]. In contrast to the former, +everyone is free to subscribe to this read-only list. <a name="help-hurd"></a> ## help-hurd @@ -68,7 +68,8 @@ to the latter, everyone is free to subscribe to this read-only list. <help-hurd@gnu.org> <http://lists.gnu.org/mailman/listinfo/help-hurd> -Hurd-specific questions; for users of the Hurd. If you need help on **using the Hurd** please ask in this list. +Hurd-specific questions, for users of the Hurd. If you need help with [[*using +the Hurd*|hurd/running]], please ask on this list. <a name="web-hurd"></a> ## web-hurd @@ -103,6 +104,16 @@ Discussion around and questions regarding the Discussion about the [[GNU_system|hurd/running/gnu]]. +<a name="libc-alpha"></a> +## libc-alpha + +<libc-alpha@sourceware.org> +<http://sourceware.org/ml/libc-alpha/> + +Discussion about [[glibc]], where the Hurd's POSIX et al. interfaces are +implemented, amongst a lot of other bits and pieces. This list is *moderated*, +but on-topic development topics will generally be accepted. + # Spam diff --git a/mailing_lists/libc-alpha.mdwn b/mailing_lists/libc-alpha.mdwn new file mode 100644 index 00000000..2f997922 --- /dev/null +++ b/mailing_lists/libc-alpha.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2011 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=mailing_lists#libc-alpha]] diff --git a/media_appearances.mdwn b/media_appearances.mdwn index d15a0c8b..61e74840 100644 --- a/media_appearances.mdwn +++ b/media_appearances.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -12,6 +12,10 @@ This is a collection of some Hurd-related media appearances. A lot of stuff is missing here. +# 2011 + + * {{$gnu#gnustatus-2011-01}} + # 2010 ## August diff --git a/microkernel/coyotos.mdwn b/microkernel/coyotos.mdwn index 5ecea688..fec023ba 100644 --- a/microkernel/coyotos.mdwn +++ b/microkernel/coyotos.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2010 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2006, 2007, 2008, 2010, 2011 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 @@ -28,3 +28,6 @@ design. The coyotos microkernel specification can be found [here](http://www.coyotos.org/docs/ukernel/spec.html). + +There once was the idea of a GNU/Hurd [[port using the Coyotos +microkernel|history/port_to_another_microkernel]], but this didn't come live. diff --git a/microkernel/for_beginners/discussion.mdwn b/microkernel/for_beginners/discussion.mdwn deleted file mode 100644 index 9831796b..00000000 --- a/microkernel/for_beginners/discussion.mdwn +++ /dev/null @@ -1,20 +0,0 @@ -[[!meta copyright="Copyright © 2010 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]]."]]"""]] - -Good day. - -I am a developer, have some c knowledge, and in perspective hope to be able to make a contribution in Hurd kernel. At the moment I consider myself as a beginner. - -My question is about the second exercise. - ->Implement your own pager. Write a server that synthesizes content on the fly and have a client map the object into its address space and print out the file. - -* The second sentence "Write a server that..." is too long and too difficult for me to understand perhaps because English is not my native language. Could you please explain it in a little bit easier phrases? -* Am I write that in a given context "pager" means just "memory manager"? diff --git a/microkernel/l4.mdwn b/microkernel/l4.mdwn index 45929842..7af5e6fc 100644 --- a/microkernel/l4.mdwn +++ b/microkernel/l4.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2004, 2006, 2007, 2008, 2010 Free Software +[[!meta copyright="Copyright © 2004, 2006, 2007, 2008, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -20,7 +20,8 @@ on formally verifying an L4 microkernel. * {{$sel4}} -There was a GNU/Hurd [[history/port_to_L4]], which is now stalled. +There was a GNU/Hurd [[port to L4|history/port_to_another_microkernel]], which +is now stalled. [[!ymlfront data=""" diff --git a/microkernel/mach/discussion.mdwn b/microkernel/mach/discussion.mdwn deleted file mode 100644 index 589e302d..00000000 --- a/microkernel/mach/discussion.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -## <a name="Maintenance_of_the_Mach_web"> Maintenance of the Mach web </a> - -**_Old discussions:_** [[WIKIHOMEURLMachTOPICrev13]] - -Interesting, for consistency sake I'll think about making your changes you made on the right hand side to the other web WebHome pages. I guess it's not critical that they are identical, but I was trying to keep them identical if possible. I also wanted it to be "light" enough feature wise that it doesn't overpower the page. You've added back a few of the features, so we obviously differ in how important you and I think these features are. That's OK, I'll think about it some more and we'll see what happens. - -Oh, I see you added back [[WebTopicList]] and [[WebPreferences]]. I purposely removed [[WebPreferences]] from the lists on the right because it has nothing to do with navigation. I also didn't think that people actually use topic names to navigate. If they do they could search for them. Keeping the number to four items instead of six and keeping the descriptions concise makes a big difference when I view the page. - -(goes off to think more...) - -and eat... ;-) - --- [[Main/GrantBow]] - 29 Dec 2002 - -**_Reasons for my change:_** - -1. [[WebTopicList]] is a lot quicker than the [[WebIndex]] - brings down the load times and the load of the server -2. [[WebPreferences]] - users might be curious to see what can be modified. Changes should of course only be made in their home topics, like in %WIKIUSERNAME%. However, the [[WebPreferences]] can serve as an inspiration. Therefore we should perhaps make sure only the [[Main/TWikiAdminGroup]] members can alter the \*Preferences topics. -3. If you look closely I've also reordered the links. Shorter names first and long ones last, I tried to keep the descriptions brief and in proportional length as well. - -I don't know about you, but keeping the number of items to four rather than six doesn't really matter to me. The text is quite small and if it's the space we're after the [[WebStatistics]] does take up more than the navigation links. - --- [[Main/JoachimNilsson]] - 29 Dec 2002 diff --git a/microkernel/mach/external_pager_mechanism.mdwn b/microkernel/mach/external_pager_mechanism.mdwn index d9b6c2c8..05a6cc56 100644 --- a/microkernel/mach/external_pager_mechanism.mdwn +++ b/microkernel/mach/external_pager_mechanism.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2002, 2007, 2008, 2010 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2002, 2007, 2008, 2010, 2011 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 @@ -181,3 +181,15 @@ fashion. The server is not required to send a response to the kernel. (D) The manager then transfers the data to the storeio server which eventually sends it to disk. The device driver consumes the memory doing the equivalent of a `vm_deallocate`. + + +# Issues + + * [[open_issues/performance/io_system/read-ahead]] + + * [[open_issues/performance/io_system/clustered_page_faults]] + + +# GNU Hurd Usage + +Read about the [[Hurd's I/O path|hurd/io_path]]. diff --git a/microkernel/mach/gnumach.mdwn b/microkernel/mach/gnumach.mdwn index f3d6d5f9..b385ca09 100644 --- a/microkernel/mach/gnumach.mdwn +++ b/microkernel/mach/gnumach.mdwn @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 2001, 2002, 2007, 2008 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2001, 2002, 2007, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] GNU Mach is the microkernel that the [[GNU_Hurd|hurd]] system is based on. @@ -75,6 +75,7 @@ GNU/Hurd. * [[Building]] * [[Debugging]] * [[Boot_Trace]] + * [[Memory_Management]] * [[Projects]] * [[Rules]] * [[Open Issues|tag/open_issue_gnumach]] diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 9c075600..99e566bb 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -1,6 +1,3 @@ -Additional to the following text, a further [[example]] has be posted. - - # Building [[GNU_Mach|gnumach]] from Source If you want to build the [[GNU_Mach|gnumach]] kernel yourself instead of just using a diff --git a/microkernel/mach/gnumach/building/example.mdwn b/microkernel/mach/gnumach/building/example.mdwn deleted file mode 100644 index 7db98547..00000000 --- a/microkernel/mach/gnumach/building/example.mdwn +++ /dev/null @@ -1,54 +0,0 @@ -[[!meta copyright="Copyright © 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]]."]]"""]] - -## Compiling GNU Mach microkernel - -Host development system is IBM T41 running Debian Sarge 3.1r0a GNU/Linux. - -* gcc version: 3.3.5 -* GNU sed version: 4.1.2 -* GNU make version: 3.8 -* mig version: 1.3-4 - -Obtained gnumach-1-branch sources from cvs: - - export CVS_RSH="ssh" - cvs -z3 -d:ext:anoncvs@ savannah.gnu.org:/cvsroot/hurd co -r gnumach-1-branch gnumach - -Obtained mig_1.3-4_i386.deb from -http://www.hadrons.org/~guillem/debian/pool/main/mig/. Installed it using dpkg: - - dpkg -i mig_1.3-4_i386.deb - -Entered into the gnumach sources and did the following for compilation: - - mkdir build - cd build - ../configure --host=i386-unknown-gnu0.2 --build=i586-pc-linux-gnu \ - --enable-kdb --enable-ide - make - -The kernel file is created in the build directory. Move it to /boot on the -testing x86 system Hurd partition. Rename it as gnumach1 and compress it: - - mv kernel gnumach1 - gzip gnumach1 - -Add a new entry on the testing machine /boot/grub/menu.lst to boot the new -kernel. - - title GNU Hurd K10 Compiled gnumach - kernel (hd0,3)/boot/gnumach1.gz root=device:hd2s4 -s - module (hd0,3)/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 (hd0,3)/lib/ld.so.1 /hurd/exec $(exec-task=task-create) - -Reboot into the new compiled mygnumach1.gz kernel! diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn new file mode 100644 index 00000000..17c7ad79 --- /dev/null +++ b/microkernel/mach/gnumach/memory_management.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!tag open_issue_documentation]] + +IRC, freenode, #hurd, 2011-02-15 + + <braunr> etenil: originally, mach had its own virtual space (the kernel + space) + <braunr> etenil: in order to use linux 2.0 drivers, it now directly maps + physical memory, as linux does + <braunr> etenil: but there is nothing similar to kmap() or vmalloc() in + mach, so the kernel is limited to its 1 GiB + <braunr> (3 GiB userspace / 1 GiB kernelspace) + <braunr> that's the short version, there is a vmalloc() in mach, but this + trick made it behave almost like a kmalloc() + <antrik> braunr: the direct mapping is *only* for the benefit of Linux + drivers?... + <braunr> also, the configuration of segments limits the kernel space + <braunr> antrik: i'm not sure, as i said, this is the short version + <braunr> antrik: but there is a paper which describes the integration of + those drivers in mach + <etenil> you mean the linux 2.0 drivers? + <antrik> braunr: I read it once, but I don't remember anything about the + physical mapping in there... + <antrik> etenil: well, originally it was 1.3, but essentially that's the + same... + <braunr> i don't see any other reason why there would be a direct mapping + <braunr> except for performance (because you can use larger - even very + lage - pages without resetting the mmu often thanks to global pages, but + that didn't exist at the time) + +IRC, freenode, #hurd, 2011-02-15 + + <antrik> however, the kernel won't work in 64 bit mode without some changes + to physical memory management + <braunr> and mmu management + <braunr> (but maybe that's what you meant by physical memory) + +IRC, freenode, #hurd, 2011-02-16 + + <braunr> antrik: youpi added it for xen, yes + <braunr> antrik: but you're right, since mach uses a direct mapped kernel + space, the true problem is the lack of linux-like highmem support + <braunr> which isn't required if the kernel space is really virtual diff --git a/microkernel/mach/gnumach/ports/xen/discussion.mdwn b/microkernel/mach/gnumach/ports/xen/discussion.mdwn new file mode 100644 index 00000000..2980e3b2 --- /dev/null +++ b/microkernel/mach/gnumach/ports/xen/discussion.mdwn @@ -0,0 +1,14 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!tag open_issue_documentation]] + +Stuff from <http://youpibouh.thefreecat.org/hurd-xen> should be merged into +these pages here. diff --git a/microkernel/mach/gnumach/projects.mdwn b/microkernel/mach/gnumach/projects.mdwn index 47a2756c..f4ef192a 100644 --- a/microkernel/mach/gnumach/projects.mdwn +++ b/microkernel/mach/gnumach/projects.mdwn @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 2005, 2006, 2007, 2008 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] This page is a place to keep track of ideas about things that may be improved in GNU Mach, so that it'll evolve to a reliable microkernel for The Hurd, both @@ -58,7 +58,8 @@ so that no duplicate efforts end up. * Improve the external pagers interface - * Implement read-ahead (huge I/O improvements expected). + * Implement [[open_issues/performance/io_system/read-ahead]] (huge I/O + improvements expected). * Making this interface synchronous should improve I/O performance significantly, without (almost) any drawbacks (we also get some diff --git a/microkernel/mach/memory_object.mdwn b/microkernel/mach/memory_object.mdwn index 2342145c..f32fe778 100644 --- a/microkernel/mach/memory_object.mdwn +++ b/microkernel/mach/memory_object.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2002, 2003, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -29,3 +29,5 @@ last one tried is the *default memory manager* that resides in the microkernel, in contrast to most of the others. The default memory manager is needed because the microkernel can't wait infinitely for someone else to free the memory cache: it just calls the next memory manager hoping it to succeed. + +Read about [[GNU Mach's memory management|gnumach/memory_management]]. @@ -1,17 +1,17 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag stable_URL]] [[!inline pages="news/* and !*/discussion" show=0 feeds=no -sort=title -reverse=yes actions=yes]] diff --git a/news/2002-01-13.mdwn b/news/2002-01-13.mdwn index 920c2593..684fed13 100644 --- a/news/2002-01-13.mdwn +++ b/news/2002-01-13.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-01-13"]] An <A HREF="http://www.pl-berichte.de/berichte/brinkmann.html">interview diff --git a/news/2002-01-19.mdwn b/news/2002-01-19.mdwn index c6923220..5adbfc60 100644 --- a/news/2002-01-19.mdwn +++ b/news/2002-01-19.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-01-19"]] The Toronto Hurd User Group meets: The University of Waterloo Computer Science Club will be hosting a talk on the Hurd and the diff --git a/news/2002-02-18.mdwn b/news/2002-02-18.mdwn index e550a8f6..a01bd857 100644 --- a/news/2002-02-18.mdwn +++ b/news/2002-02-18.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-02-18"]] Pro-Linux has published a <A HREF="http://www.pl-berichte.de/berichte/hurd/hurd-status/">GNU/Hurd diff --git a/news/2002-03-03.mdwn b/news/2002-03-03.mdwn index 8b60ed9b..6f88208b 100644 --- a/news/2002-03-03.mdwn +++ b/news/2002-03-03.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-03-03"]] There is a new mailing list called <A HREF="http://mail.gnu.org/mailman/listinfo/hurd-devel-readers"> diff --git a/news/2002-03-08.mdwn b/news/2002-03-08.mdwn index f64f04f1..aa3d6e8c 100644 --- a/news/2002-03-08.mdwn +++ b/news/2002-03-08.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-03-08"]] We are pleased to announce version 1.3 of the GNU distribution of the Mach 3.0 interface generator `MIG'. It may be found in the file diff --git a/news/2002-03-23.mdwn b/news/2002-03-23.mdwn index f3c12633..68180ba8 100644 --- a/news/2002-03-23.mdwn +++ b/news/2002-03-23.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-03-23"]] Added the [[hurd/Hurd_Hacking_Guide]] to the documentation section. Thanks to Wolfgang Jährling for providing this introduction into GNU/Hurd and Mach diff --git a/news/2002-05-05.mdwn b/news/2002-05-05.mdwn index 2b38863e..0908b78f 100644 --- a/news/2002-05-05.mdwn +++ b/news/2002-05-05.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-05-05"]] We are currently finishing the transition from a stdio-based GNU C Library (glibc) to a libio-based one. This is the result of about diff --git a/news/2002-05-18.mdwn b/news/2002-05-18.mdwn index 7017e410..10104a5e 100644 --- a/news/2002-05-18.mdwn +++ b/news/2002-05-18.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-05-18"]] The "Linux and Unix User Group Heilbronn" (in Germany) is organizing a Debian GNU/Hurd <A diff --git a/news/2002-05-24.mdwn b/news/2002-05-24.mdwn index a65d5c6d..57c7549f 100644 --- a/news/2002-05-24.mdwn +++ b/news/2002-05-24.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-05-24"]] Finally, the transition from the stdio-based GLibC Application Binary Interface (ABI) to the libio-based GLibC ABI has been diff --git a/news/2002-05-28.mdwn b/news/2002-05-28.mdwn index dcf7c86d..5cfe129b 100644 --- a/news/2002-05-28.mdwn +++ b/news/2002-05-28.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-05-28"]] We are pleased to announce version 1.3 of the GNU distribution of the Mach kernel, featuring advanced boot script support, support for diff --git a/news/2002-06-22.mdwn b/news/2002-06-22.mdwn index b6a606da..3bb316b3 100644 --- a/news/2002-06-22.mdwn +++ b/news/2002-06-22.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-06-22"]] Various developers of the Hurd and people interested in it will meet at the <A HREF="http://lsm.abul.org/">Libre Software Meeting</A> in diff --git a/news/2002-08-16.mdwn b/news/2002-08-16.mdwn index 9e70d686..9814295f 100644 --- a/news/2002-08-16.mdwn +++ b/news/2002-08-16.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-08-16"]] The Hurd sources have stabilized again after a short period in which some of the interfaces were changed to prepare support of long diff --git a/news/2002-10-03.mdwn b/news/2002-10-03.mdwn index 90f4da9f..5e25a55b 100644 --- a/news/2002-10-03.mdwn +++ b/news/2002-10-03.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-10-03"]] A new article about [[the_authentication_server|hurd/documentation/auth]] has been added to the web pages. It resembles the talk diff --git a/news/2002-10-03_2.mdwn b/news/2002-10-03_2.mdwn index e08e2b3c..281d24c8 100644 --- a/news/2002-10-03_2.mdwn +++ b/news/2002-10-03_2.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-10-03"]] Marcus Brinkmann speaks about the GNU Hurd at "Reflections | Projections 2002", the <A diff --git a/news/2002-10-19.mdwn b/news/2002-10-19.mdwn index 0d3f34a0..9153fb41 100644 --- a/news/2002-10-19.mdwn +++ b/news/2002-10-19.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-10-19"]] The Toronto Hurd Users Group meets again: The <A HREF="http://www.uwaterloo.ca/"> University of Waterloo</A> <A diff --git a/news/2002-11-18.mdwn b/news/2002-11-18.mdwn index 805f2726..9db912a1 100644 --- a/news/2002-11-18.mdwn +++ b/news/2002-11-18.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-11-18"]] For one month now, the pthread implementation by Neal Walfield is part of the Hurd CVS source tree, and has been used to compile more diff --git a/news/2003-01-18.mdwn b/news/2003-01-18.mdwn index 90c41f27..8f342d1d 100644 --- a/news/2003-01-18.mdwn +++ b/news/2003-01-18.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2003, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2003-01-18"]] Gaël Le Mignot, president of HurdFr, <A HREF="http://news.hurdfr.org/gen.php3/2002/11/05/44,0,1,0,0.html"> diff --git a/news/2003-02-14.mdwn b/news/2003-02-14.mdwn index 2754d737..4584c525 100644 --- a/news/2003-02-14.mdwn +++ b/news/2003-02-14.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2003, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2003-02-14"]] The <A HREF="/software/hurd/docs.html#UsersGuide">GNU/Hurd User's Guide</A> is now accessible through the <A HREF="/software/hurd/docs.html">Documentation diff --git a/news/2003-07-02.mdwn b/news/2003-07-02.mdwn index 7e9634b7..27d9702a 100644 --- a/news/2003-07-02.mdwn +++ b/news/2003-07-02.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2003, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2003-07-02"]] The tarball for Debian GNU/Hurd that Marcus Brinkmann made over the years has been discontinued in favour of Jeff Bailey's diff --git a/news/2003-07-16.mdwn b/news/2003-07-16.mdwn index da1fc12a..a37bed26 100644 --- a/news/2003-07-16.mdwn +++ b/news/2003-07-16.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2003, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2003-07-16"]] GNU/LinuxTag 2003 is now over and since there was a talk given about the Hurd, a demo GNU/Hurd machine running and the sale of Hurd diff --git a/news/2003-08-21.mdwn b/news/2003-08-21.mdwn index fcd2adb8..1a44c1d2 100644 --- a/news/2003-08-21.mdwn +++ b/news/2003-08-21.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2003, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2003-08-21"]] Added a link to Patrick Strasser's <A HREF="http://www.htu.tugraz.at/~past/hurd/global/">the Hurd Source diff --git a/news/2005-01-28.mdwn b/news/2005-01-28.mdwn index 3360fd3e..9e54ff60 100644 --- a/news/2005-01-28.mdwn +++ b/news/2005-01-28.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2005, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2005, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2005-01-28"]] Marcus Brinkmann added <A HREF="/software/hurd/hurd-l4.html">a small web page</A> describing diff --git a/news/2005-09-20.mdwn b/news/2005-09-20.mdwn index 09e156eb..e2af05d7 100644 --- a/news/2005-09-20.mdwn +++ b/news/2005-09-20.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2005, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2005, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2005-09-20"]] Material from the Operating System topic during the <A HREF="http://libresoftwaremeeting.org/">Libre Software diff --git a/news/2006-04-27.mdwn b/news/2006-04-27.mdwn index 9f99488a..befce295 100644 --- a/news/2006-04-27.mdwn +++ b/news/2006-04-27.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2006, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2006, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2006-04-27"]] <p>The GNU Hurd project will participate in this year's <strong>Google Summer of Code</strong>, under the aegis of the GNU project.</p> diff --git a/news/2007-01-07.mdwn b/news/2007-01-07.mdwn index 530491f2..3b7ed1be 100644 --- a/news/2007-01-07.mdwn +++ b/news/2007-01-07.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2007-01-07"]] A number of GNU Hurd developers will again (as already in the previous years) meet at the time of the FOSDEM 2007, which will take place from 2007-02-24 to diff --git a/news/2007-01-14.mdwn b/news/2007-01-14.mdwn index f99eda87..e33270e4 100644 --- a/news/2007-01-14.mdwn +++ b/news/2007-01-14.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2007-01-14"]] <p>Neal Walfield and Marcus Brinkmann have written and submitted for publication <a diff --git a/news/2007-03-14.mdwn b/news/2007-03-14.mdwn index 9895291c..5b601a35 100644 --- a/news/2007-03-14.mdwn +++ b/news/2007-03-14.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2007-03-14"]] <p>The GNU Hurd project will participate in this year's <strong>Google Summer of Code</strong>, under the aegis of the GNU project.</p> diff --git a/news/2007-10-01.mdwn b/news/2007-10-01.mdwn index b35bc337..0284f3dc 100644 --- a/news/2007-10-01.mdwn +++ b/news/2007-10-01.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2007-10-01"]] This year the GNU Hurd had again been assigned one slot within the **Google Summer of Code** program, which was assigned to the task **design and implement diff --git a/news/2007-10-12.mdwn b/news/2007-10-12.mdwn index ae125149..82ff8843 100644 --- a/news/2007-10-12.mdwn +++ b/news/2007-10-12.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2007-10-12"]] Stefan Siegl added [[support_for_IPv6_networking|hurd/translator/pfinet/ipv6]] to the *pfinet* translator. diff --git a/news/2008-02-11.mdwn b/news/2008-02-11.mdwn index 0805287c..060c0b94 100644 --- a/news/2008-02-11.mdwn +++ b/news/2008-02-11.mdwn @@ -1,12 +1,14 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2008-02-11"]] A number of GNU Hurd developers will again (as already in the previous years) meet at the time of the FOSDEM 2008, which will take place from diff --git a/news/2008-03-19.mdwn b/news/2008-03-19.mdwn index 02ea4c5f..fbfb4c60 100644 --- a/news/2008-03-19.mdwn +++ b/news/2008-03-19.mdwn @@ -1,12 +1,14 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2008-03-19"]] The GNU Hurd project has been accepted as a mentoring organisation for the **Google Summer of Code 2008**! If you are a student and looking for a job diff --git a/news/2008-09-11.mdwn b/news/2008-09-11.mdwn index 7d25e5a6..0765a269 100644 --- a/news/2008-09-11.mdwn +++ b/news/2008-09-11.mdwn @@ -1,12 +1,14 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2008-09-11"]] 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]]. diff --git a/news/2008-11-14.mdwn b/news/2008-11-14.mdwn index 58e035c3..0d357900 100644 --- a/news/2008-11-14.mdwn +++ b/news/2008-11-14.mdwn @@ -1,12 +1,14 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2008-11-14"]] [[Samuel_Thibault|samuelthibault]] has implemented support for the PAE feature offered by modern x86 processors. This largely faciliates the deployment of diff --git a/news/2008-12-12.mdwn b/news/2008-12-12.mdwn index b2e92ef0..0bd750b8 100644 --- a/news/2008-12-12.mdwn +++ b/news/2008-12-12.mdwn @@ -1,12 +1,14 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2008-12-12"]] Neal Walfield has submitted a paper to [[community/meetings/EuroSys_2009]] describing how resource management diff --git a/news/2009-03-28.mdwn b/news/2009-03-28.mdwn index 00aebb09..78c40688 100644 --- a/news/2009-03-28.mdwn +++ b/news/2009-03-28.mdwn @@ -1,12 +1,14 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2009-03-28"]] The application phase for the **Google Summer of Code 2009** has already started. Please see our [[page_about_the_GSoC|community/gsoc]] for diff --git a/news/2009-04-20.mdwn b/news/2009-04-20.mdwn index 69831cca..3755a7fb 100644 --- a/news/2009-04-20.mdwn +++ b/news/2009-04-20.mdwn @@ -1,12 +1,14 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2009-04-20"]] Sergiu Ivanov will be working on [[unionmount_translators|user/scolobb]] during the **Google Summer of Code 2009**. diff --git a/news/2009-06-30.mdwn b/news/2009-06-30.mdwn index 92bc8a20..5031de6c 100644 --- a/news/2009-06-30.mdwn +++ b/news/2009-06-30.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2011 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 +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]]."]]"""]] +[[!meta date="2009-06-30"]] + A month of the Hurd: *Git migration*, *stand-alone libpthread* and *updated status*. [[!if test="included()" then="""[[!toggle id=full_news diff --git a/news/2010-09.mdwn b/news/2010-09.mdwn index e6afd397..2829de73 100644 --- a/news/2010-09.mdwn +++ b/news/2010-09.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 +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]]."]]"""]] +[[!meta date="2010-10-23 12:47:26 UTC"]] + A month of the Hurd: *new translators* / *bug fixing*. [[!if test="included()" then="""[[!toggle id=full_news text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" diff --git a/news/2010-10.mdwn b/news/2010-10.mdwn index 6f909005..c7312256 100644 --- a/news/2010-10.mdwn +++ b/news/2010-10.mdwn @@ -18,7 +18,7 @@ else=" [[!cut id="full_news" text=""" -A bit of bug fixing has bee going on: +A bit of bug fixing has been going on: Samuel Thibault taught [[GNU Mach|microkernel/mach/gnumach]] that Intel Pentium 4 and Opteron-class CPUs [are not just diff --git a/news/2010-11.mdwn b/news/2010-11.mdwn index ea21d91f..0fcc6551 100644 --- a/news/2010-11.mdwn +++ b/news/2010-11.mdwn @@ -23,7 +23,7 @@ That's a short one. Apart from the regular business of having internal design running, we had Diego Nieto Cid post patches ([1](http://lists.gnu.org/archive/html/bug-hurd/2010-11/msg00019.html), [2](http://lists.gnu.org/archive/html/bug-hurd/2010-11/msg00023.html)) to -corrent two programming errors, which Samuel Thibault quickly reviewed and +correct two programming errors, which Samuel Thibault quickly reviewed and applied to the [[source repositories]]. """]] diff --git a/news/2010.mdwn b/news/2010.mdwn new file mode 100644 index 00000000..2ba85266 --- /dev/null +++ b/news/2010.mdwn @@ -0,0 +1,130 @@ +[[!meta copyright="Copyright © 2011 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 date="2011-02-05 12:00 UTC"]] + +A year of the Hurd: *2010*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +Originally published in {{$gnu#gnustatus-2011-01}}. + +From Olaf Buddenhagen, Arne Babenhauserheide, Thomas Schwinge: Yeah, +that's quite right: the GNU Hurd project is still alive! + +According to our mission statement, the goal is creating *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*. It has a unique +multi-server microkernel-based architecture---bringing advanced +operating system research to the mainstream. More concretely, it's a +collection of user-space server processes that run on the GNU Mach +microkernel. + +The Hurd doesn't fully deliver on the *everyday usability* goal +yet, but it is seeing continuous improvement---and 2010 has been no +exception. Let's take a look at the progress throughout the year. + + * +Apart from having done a lot of other work, Samuel Thibault, our Jack +of all trades, merged his development branch that added Xen domU +support to GNU Mach, which makes it possible to run a GNU/Hurd system +as a Xen guest. Development of this started in 2007, and since then +it has been heavily tested by using it for the Debian GNU/Hurd build +servers, most of our public GNU/Hurd systems, +<http://www.gnu.org/software/hurd/public_hurd_boxen.html>, and the +Hurd project's wiki web server. + + * +We had Zheng Da work on a new hardware device driver framework, which +is based on the Dresden L4 (Fiasco) group's DDE project, and allows +running modern Linux kernel drivers as user-space server processes. +Many network cards already work perfectly with this new framework. +(It has not yet been integrated into the mainstream Hurd code base, so +it needs to be compiled and set up by hand.) Other driver classes, +such as hard disk controllers, will require further work. + + * +As in the previous years, we again participated in the Google Summer +of Code 2010. Olaf Buddenhagen is our main guy for organizing this. + + Jérémie Koenig ported the modern Debian Installer to Debian +GNU/Hurd. Installation images using the new installer are replacing +the previous CD images, which were using an installer based on the old +Debian boot floppies (and running under the Linux kernel)---Philip +Charles has been maintaining these single-handedly for almost ten +years! The new installer images are available from +<http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/>. + + Emilio Pozuelo Monfort was investigating specific compatibility +problems exposed by the extensive test suites coming with some +software packages. Emilio's analysis uncovered a number of +programming errors in the Hurd code, and he fixed several of them. As +these typically affected other programs too, this improved stability +and compatibility in general. + + * +Jérémie Koenig created a new implementation of a `procfs` +translator, which is considerably more robust and efficient than the +previous one. Tools such as `top` can now be used without +problems. + + Some other translators (`gopherfs`, `netio`, +`tarfs`) which have been created by external contributors in +the past have been fixed up by Manuel Menal, and packaged in Debian. +Thus, some of the results of Hurd's extensible architecture are now +easier to access, and these updated translators can serve as examples +for other developers to implement their own ideas. + + * +In addition to various general stability, compatibility, and +portability fixes, several people (Samuel Thibault, Pino Toscano, +Emilio Pozuelo Monfort, and others) have been working on fixing issues +with specific Debian packages. So far, about 68% of all Debian +packages are also available for Debian GNU/Hurd. + + * +Michael Walker started the Arch Hurd distribution, and together with +other enthusiastic Arch developers (Allan McRae, Matthias Lanzinger, +Alexander Preisinger, Stephen Gilles, Diego Nieto Cid) they got it +working in an amazingly short amount of time, both as an installable +system, and a live CD. So now there is a choice between two +well-featured distributions for the Hurd. These new people of course +also help forwarding Hurd development in general---Diego in particular +contributed various patches to the Hurd console and other components. + + * +Carl Fredrik Hammar finished and presented his thesis, *Generalizing +mobility for the Hurd*, +<http://lists.gnu.org/archive/html/bug-hurd/2010-01/msg00078.html>, +and passed with distinction. + +This is a very short digest of what happened in the last year. You +can read our regular *Month of the Hurd* at +<http://www.gnu.org/software/hurd/news.html>, or by subscribing to +our RSS feed at <http://www.gnu.org/software/hurd/index.rss>. + +If you are interested, for example, in doing a university project on a +multi-server microkernel-based operating system, or if you are +interested in contributing to Hurd development in general, please see +<http://www.gnu.org/software/hurd/contributing.html>. Or just +talk to us at <bug-hurd@gnu.org> or the `#hurd` IRC +channel on freenode. + +--- + +French article by Manuel Menal, [*Gnu : L'année 2010 du +Hurd*](http://linuxfr.org/news/lann%C3%A9e-2010-du-hurd). + +"""]] diff --git a/news/2011-03-26.mdwn b/news/2011-03-26.mdwn new file mode 100644 index 00000000..588f5fcf --- /dev/null +++ b/news/2011-03-26.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2011 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 date="2011-03-26 14:20 UTC"]] + +The **Google Summer of Code 2011** is on! If you're a student, consider +applying for a GNU Hurd project -- details to be found on our +*[[community/GSoC]] page*. diff --git a/news/2011-04-01.mdwn b/news/2011-04-01.mdwn new file mode 100644 index 00000000..3c0c3869 --- /dev/null +++ b/news/2011-04-01.mdwn @@ -0,0 +1,44 @@ +[[!meta copyright="Copyright © 2011 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 date="2011-04-01 08:30 UTC"]] + +[[!meta title="2011-04-01: GNU/Hurd 0.401 is released!"]] + +We'd like to pass on these marvelous news from our Release Management +Team, headed by Release Manager Samuel Thibault: + +> Hello, +> +> There are rumors that Duke Nukem Forever will actually be released in +> Apr^WMa^WJune 2011, so there's no escape for the Hurd any more, we had +> to finish and release. There has been considerable progress lately, +> so it is with great pleasure that the Hurd maintainers team decided +> to release *version 0.401 of the GNU/Hurd Operating System*. As the +> version number and image size suggest, this is only a small preview +> of course, but we expect GNU/Hurd to be of production-quality within +> the third millenium, to be sure. +> +> A *LiveCD demo* is available on +> <http://people.debian.org/~sthibault/hurd-0.401/hurd-0.401.iso> +> and can be trivially tried using +> `qemu -cdrom hurd-0.401.iso` +> +> We hope that you will appreciate its features and speed. +> +> Are you interested in contributing to the GNU Hurd project? Just +> request an shell account on one of our servers and get started. +> +> <http://www.gnu.org/software/hurd/public_hurd_boxen.html> +> +> It is also worth noting that like in previous years, GNU/Hurd runs +> for the GSoC program, details can be found on +> +> <http://www.gnu.org/software/hurd/community/gsoc.html> diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn new file mode 100644 index 00000000..e1d5c9d8 --- /dev/null +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -0,0 +1,73 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!taglink open_issue_documentation]] + +A bunch of this should also be covered in other (introductionary) material, +like Bushnell's Hurd paper. All this should be unfied and streamlined. + +IRC, freenode, #hurd, 2011-03-08 + + <foocraft> I've a question on what are the "units" in the hurd project, if + you were to divide them into units if they aren't, and what are the + dependency relations between those units(roughly, nothing too pedantic + for now) + <antrik> there is GNU Mach (the microkernel); there are the server + libraries in the Hurd package; there are the actual servers in the same; + and there is the POSIX implementation layer in glibc + <antrik> relations are a bit tricky + <antrik> Mach is the base layer which implements IPC and memory management + <foocraft> hmm I'll probably allocate time for dependency graph generation, + in the worst case + <antrik> on top of this, the Hurd servers, using the server libraries, + implement various aspects of the system functionality + <antrik> client programs use libc calls to use the servers + <antrik> (servers also use libc to communicate with other servers and/or + Mach though) + <foocraft> so every server depends solely on mach, and no other server? + <foocraft> s/mach/mach and/or libc/ + <antrik> I think these things should be pretty clear one you are somewhat + familiar with the Hurd architecture... nothing really tricky there + <antrik> no + <antrik> servers often depend on other servers for certain functionality + +--- + +IRC, freenode, #hurd, 2011-03-12 + + <dEhiN> when mach first starts up, does it have some basic i/o or fs + functionality built into it to start up the initial hurd translators? + <antrik> I/O is presently completely in Mach + <antrik> filesystems are in userspace + <antrik> the root filesystem and exec server are loaded by grub + <dEhiN> o I see + <dEhiN> so in order to start hurd, you would have to start mach and + simultaneously start the root filesystem and exec server? + <antrik> not exactly + <antrik> GRUB loads all three, and then starts Mach. Mach in turn starts + the servers according to the multiboot information passed from GRUB + <dEhiN> ok, so does GRUB load them into ram? + <dEhiN> I'm trying to figure out in my mind how hurd is initially started + up from a low-level pov + <antrik> yes, as I said, GRUB loads them + <dEhiN> ok, thanks antrik...I'm new to the idea of microkernels, but a + veteran of monolithic kernels + <dEhiN> although I just learned that windows nt is a hybrid kernel which I + never knew! + <rm> note there's a /hurd/ext2fs.static + <rm> I belive that's what is used initially... right? + <antrik> yes + <antrik> loading the shared libraries in addition to the actual server + would be unweildy + <antrik> so the root FS server is linked statically instead + <dEhiN> what does the root FS server do? + <antrik> well, it serves the root FS ;-) + <antrik> it also does some bootstrapping work during startup, to bring the + rest of the system up diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn index 81fafaca..ca7496f0 100644 --- a/open_issues/binutils.mdwn +++ b/open_issues/binutils.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -9,7 +9,7 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!tag open_issue_binutils]] +[[!tag stable_URL open_issue_binutils]] Here's what's to be done for maintaining GNU Binutils. @@ -30,15 +30,14 @@ though, as explained below. # Configuration -Last reviewed up to the [[Git mirror's e347ef3b343fc42ed312d5125047d59ae15df795 -(2010-12-20) sources|source_repositories/binutils]]. +Last reviewed up to the [[Git mirror's a446ef2f3862fb5f89c669b34a2b6a2ab943ff96 +(2011-02-10) sources|source_repositories/binutils]]. * Globally * a.out, COFF, PE image support and 64 bit support are not interesting. - * In the [[testsuite]]s, `.exp` and `.d` files very likely should not - only + * In the testsuites, `.exp` and `.d` files very likely should not only care for `*-*-linux*`, but also `*-*-gnu*`. (If the need to be conditionalized like this at all.) @@ -96,7 +95,7 @@ Last reviewed up to the [[Git mirror's e347ef3b343fc42ed312d5125047d59ae15df795 * `*-*-gnu*` TODO: resolve `crt0.o` vs. `crt1.o` issue. [[Testsuite - failures|testsuite#static]]. + failures|binutils#static]]. * `configure.tgt` @@ -109,7 +108,7 @@ Last reviewed up to the [[Git mirror's e347ef3b343fc42ed312d5125047d59ae15df795 # Build Here's a log of a binutils build run; this is from our [[Git -repository's 245f62b817ee31135a190793dddb340f04ac95e6 (2010-12-20) +repository's e8052e7548e0d5523f1764b7d3896ca000bfaed7 (2011-02-10) sources|source_repositories/binutils]], run on kepler.SCHWINGE and grubber. $ export LC_ALL=C @@ -121,7 +120,7 @@ sources|source_repositories/binutils]], run on kepler.SCHWINGE and grubber. (kepler.SCHWINGE defaults to using /bin/sh for libtool, grubber to /bin/bash; thus harmonized.) -On grubber, this takes roughly one hour. +On grubber, this needs roughly one hour, and takes up around 100 MiB. ## Analysis @@ -145,7 +144,7 @@ GNU/Linux defining `-DTRAD_CORE`, `-DHAVE_i386linux_vec` (kepler.SCHWINGE defaults to using /bin/sh, grubber to /bin/bash; thus harmonized.) -On grubber, this needs roughly 15 minutes, and takes up around 0.7 GiB. +On grubber, this needs roughly 5 minutes, and takes up around 60 MiB. ## Analysis @@ -170,12 +169,12 @@ On grubber, this takes roughly one hour. Comparing the results files, [[sum_linux]] to [[sum_hurd]]: $ diff -u -F ^Running open_issues/binutils/sum_linux open_issues/binutils/sum_hurd - --- open_issues/binutils/sum_linux 2010-12-20 19:01:06.000000000 +0100 - +++ open_issues/binutils/sum_hurd 2010-12-20 19:01:20.000000000 +0100 + --- open_issues/binutils/sum_linux 2011-02-10 19:01:56.000000000 +0100 + +++ open_issues/binutils/sum_hurd 2011-02-10 20:27:17.000000000 +0100 @@ -1,5 +1,5 @@ - -Test Run By thomas on Mon Dec 20 11:34:53 2010 + -Test Run By thomas on Thu Feb 10 18:57:42 2011 -Native configuration is i686-pc-linux-gnu - +Test Run By tschwinge on Mon Dec 20 11:35:47 2010 + +Test Run By tschwinge on Thu Feb 10 18:58:16 2011 +Native configuration is i686-unknown-gnu0.3 === binutils tests === @@ -184,9 +183,9 @@ Comparing the results files, [[sum_linux]] to [[sum_hurd]]: # of expected passes 83 # of unsupported tests 2 - -Test Run By thomas on Mon Dec 20 11:35:19 2010 + -Test Run By thomas on Thu Feb 10 18:58:10 2011 -Native configuration is i686-pc-linux-gnu - +Test Run By tschwinge on Mon Dec 20 11:44:29 2010 + +Test Run By tschwinge on Thu Feb 10 19:06:15 2011 +Native configuration is i686-unknown-gnu0.3 === ld tests === @@ -232,21 +231,21 @@ Comparing the results files, [[sum_linux]] to [[sum_hurd]]: PASS: ELF DSO small bar (size) PASS: ELF DSO foo with small bar (size) PASS: ELF DSO big bar (size) - @@ -873,13 +873,14 @@ Running [...]/hurd/master/ld/testsuite/l + @@ -882,13 +882,14 @@ Running [...]/hurd/master/ld/testsuite/l === ld Summary === - -# of expected passes 618 + -# of expected passes 626 -# of expected failures 8 - +# of expected passes 608 + +# of expected passes 616 +# of unexpected successes 1 +# of expected failures 17 # of untested testcases 6 - /media/data[...]/hurd/master.build/ld/ld-new 2.21.51.20101220 + /media/data[...]/hurd/master.build/ld/ld-new 2.21.51.20110210 - -Test Run By thomas on Mon Dec 20 11:34:59 2010 + -Test Run By thomas on Thu Feb 10 18:57:49 2011 -Native configuration is i686-pc-linux-gnu - +Test Run By tschwinge on Mon Dec 20 11:38:03 2010 + +Test Run By tschwinge on Thu Feb 10 19:00:16 2011 +Native configuration is i686-unknown-gnu0.3 === gas tests === @@ -255,7 +254,7 @@ Comparing the results files, [[sum_linux]] to [[sum_hurd]]: ## Analysis - * <a name="static">`FAIL: static [...]`</a> + * <a name="static"><!-- stable_URL -->`FAIL: static [...]`</a> The testsuite isn't prepared for using `crt0.o` instead of `crt1.o` depending on whether a static or dynamic executable is created. Documented @@ -269,7 +268,7 @@ Comparing the results files, [[sum_linux]] to [[sum_hurd]]: weakness|performance/io_system/binutils_ld_64ksec]]), so assuming some system load variation, the testsuite's timeout may trigger. - * <a name="weak">`FAIL: ELF weak [...]`</a> + * <a name="weak"><!-- stable_URL -->`FAIL: ELF weak [...]`</a> [[I|tschwinge]] suppose this is due to us having an override w.r.t. weak symbol handling in glibc, needed for our external [[/libpthread]]. TODO: diff --git a/open_issues/binutils/log_build-diff b/open_issues/binutils/log_build-diff index 802d510c..3408d97d 100644 --- a/open_issues/binutils/log_build-diff +++ b/open_issues/binutils/log_build-diff @@ -1,5 +1,5 @@ ---- /dev/fd/63 2010-12-20 11:34:03.204493002 +0100 -+++ /dev/fd/62 2010-12-20 11:34:03.208493002 +0100 +--- /dev/fd/63 2011-02-10 17:33:04.738225001 +0100 ++++ /dev/fd/62 2011-02-10 17:33:04.738225001 +0100 @@ -1,6 +1,6 @@ -checking build system type... i686-pc-linux-gnu -checking host system type... i686-pc-linux-gnu @@ -530,7 +530,7 @@ checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed -@@ -2450,28 +2429,28 @@ +@@ -2453,28 +2432,28 @@ checking for BSD- or MS-compatible name lister (nm)... nm checking the name lister (nm) interface... BSD nm checking whether ln -s works... yes @@ -566,23 +566,37 @@ checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes -@@ -2555,13 +2534,13 @@ +@@ -2486,11 +2465,11 @@ + checking whether the g++ linker (ld) supports shared libraries... yes + checking for g++ option to produce PIC... -fPIC -DPIC + checking if g++ PIC flag -fPIC -DPIC works... yes +-checking if g++ static flag -static works... yes ++checking if g++ static flag -static works... no + checking if g++ supports -c -o file.o... yes + checking if g++ supports -c -o file.o... (cached) yes + checking whether the g++ linker (ld) supports shared libraries... yes +-checking dynamic linker characteristics... (cached) GNU/Linux ld.so ++checking dynamic linker characteristics... gnu0.3 ld.so + checking how to hardcode library paths into programs... immediate + checking whether NLS is requested... yes + checking for catalogs to be installed... bg da es fi fr ga id ja sv tr vi zh_CN zh_TW +@@ -2570,13 +2549,13 @@ /bin/bash ../../master/ld/../ylwrap ../../master/ld/ldgram.y y.tab.c ldgram.c y.tab.h ldgram.h y.output ldgram.output -- bison -y -d updating ldgram.h (echo "/* This file is automatically generated. DO NOT EDIT! */";\ -- for f in `echo " " eelf_i386.o ei386linux.o "" \ +- for f in `echo " " eelf_i386.o ei386linux.o eelf32_x86_64.o "" \ + for f in `echo " " eelf_i386.o "" \ | sed -e 's/ e/ ld/g' -e 's/ ld/ /g' -e 's/[.]o//g'`; do \ echo "extern ld_emulation_xfer_type ld_${f}_emulation;"; \ done;\ echo "";\ echo "#define EMULATION_LIST \\";\ -- for f in `echo " " eelf_i386.o ei386linux.o "" \ +- for f in `echo " " eelf_i386.o ei386linux.o eelf32_x86_64.o "" \ + for f in `echo " " eelf_i386.o "" \ | sed -e 's/ e/ ld/g' -e 's/ ld/ /g' -e 's/[.]o//g'`; do \ echo " &ld_${f}_emulation, \\"; \ done;\ -@@ -2650,8 +2629,8 @@ +@@ -2665,8 +2644,8 @@ mv -f .deps/ldctor.Tpo .deps/ldctor.Po gcc -DHAVE_CONFIG_H -I. -I../../master/ld -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT ldmain.o -MD -MP -MF .deps/ldmain.Tpo -c -o ldmain.o \ -DDEFAULT_EMULATION='"elf_i386"' \ @@ -593,7 +607,7 @@ ../../master/ld/ldmain.c mv -f .deps/ldmain.Tpo .deps/ldmain.Po gcc -DHAVE_CONFIG_H -I. -I../../master/ld -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT ldwrite.o -MD -MP -MF .deps/ldwrite.Tpo -c -o ldwrite.o ../../master/ld/ldwrite.c -@@ -2665,7 +2644,7 @@ +@@ -2680,7 +2659,7 @@ gcc -DHAVE_CONFIG_H -I. -I../../master/ld -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT ldmisc.o -MD -MP -MF .deps/ldmisc.Tpo -c -o ldmisc.o ../../master/ld/ldmisc.c mv -f .deps/ldmisc.Tpo .deps/ldmisc.Po gcc -DHAVE_CONFIG_H -I. -I../../master/ld -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT ldfile.o -MD -MP -MF .deps/ldfile.Tpo -c -o ldfile.o \ @@ -602,19 +616,22 @@ ../../master/ld/ldfile.c mv -f .deps/ldfile.Tpo .deps/ldfile.Po gcc -DHAVE_CONFIG_H -I. -I../../master/ld -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT ldcref.o -MD -MP -MF .deps/ldcref.Tpo -c -o ldcref.o ../../master/ld/ldcref.c -@@ -2673,14 +2652,11 @@ +@@ -2688,17 +2667,11 @@ gcc -DHAVE_CONFIG_H -I. -I../../master/ld -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT plugin.o -MD -MP -MF .deps/plugin.Tpo -c -o plugin.o ../../master/ld/plugin.c mv -f .deps/plugin.Tpo .deps/plugin.Po cp ../../master/ld/emultempl/astring.sed stringify.sed --LIB_PATH='' /bin/bash ../../master/ld/genscripts.sh "../../master/ld" "[...]/hurd/master.build.install/lib" "[...]/hurd/master.build.install" "[...]/hurd/master.build.install" i686-pc-linux-gnu i686-pc-linux-gnu i686-pc-linux-gnu "elf_i386" "/usr/local/lib /lib /usr/lib" no yes elf_i386 "i686-pc-linux-gnu" +-LIB_PATH='' /bin/bash ../../master/ld/genscripts.sh "../../master/ld" "[...]/hurd/master.build.install/lib" "[...]/hurd/master.build.install" "[...]/hurd/master.build.install" i686-pc-linux-gnu i686-pc-linux-gnu i686-pc-linux-gnu "elf_i386 elf32_x86_64" "/usr/local/lib /lib /usr/lib" no yes elf_i386 "i686-pc-linux-gnu" +LIB_PATH='' /bin/bash ../../master/ld/genscripts.sh "../../master/ld" "[...]/hurd/master.build.install/lib" "[...]/hurd/master.build.install" "[...]/hurd/master.build.install" i686-unknown-gnu0.3 i686-unknown-gnu0.3 i686-unknown-gnu0.3 "elf_i386" "/usr/local/lib /lib /usr/lib" no yes elf_i386 "i686-unknown-gnu0.3" gcc -DHAVE_CONFIG_H -I. -I../../master/ld -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT eelf_i386.o -MD -MP -MF .deps/eelf_i386.Tpo -c -o eelf_i386.o eelf_i386.c mv -f .deps/eelf_i386.Tpo .deps/eelf_i386.Po --LIB_PATH='' /bin/bash ../../master/ld/genscripts.sh "../../master/ld" "[...]/hurd/master.build.install/lib" "[...]/hurd/master.build.install" "[...]/hurd/master.build.install" i686-pc-linux-gnu i686-pc-linux-gnu i686-pc-linux-gnu "elf_i386" "/usr/local/lib /lib /usr/lib" no yes i386linux "i686-pc-linux-gnuaout" +-LIB_PATH='' /bin/bash ../../master/ld/genscripts.sh "../../master/ld" "[...]/hurd/master.build.install/lib" "[...]/hurd/master.build.install" "[...]/hurd/master.build.install" i686-pc-linux-gnu i686-pc-linux-gnu i686-pc-linux-gnu "elf_i386 elf32_x86_64" "/usr/local/lib /lib /usr/lib" no yes i386linux "i686-pc-linux-gnuaout" -gcc -DHAVE_CONFIG_H -I. -I../../master/ld -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT ei386linux.o -MD -MP -MF .deps/ei386linux.Tpo -c -o ei386linux.o ei386linux.c -mv -f .deps/ei386linux.Tpo .deps/ei386linux.Po --/bin/bash ./libtool --tag=CC --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -o ld-new ldgram.o ldlex-wrapper.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o plugin.o eelf_i386.o ei386linux.o ../bfd/libbfd.la ../libiberty/libiberty.a -lz -ldl --libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -o ld-new ldgram.o ldlex-wrapper.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o plugin.o eelf_i386.o ei386linux.o ../bfd/.libs/libbfd.a ../libiberty/libiberty.a -lz -ldl +-LIB_PATH='' /bin/bash ../../master/ld/genscripts.sh "../../master/ld" "[...]/hurd/master.build.install/lib" "[...]/hurd/master.build.install" "[...]/hurd/master.build.install" i686-pc-linux-gnu i686-pc-linux-gnu i686-pc-linux-gnu "elf_i386 elf32_x86_64" "/usr/local/lib /lib /usr/lib" no yes elf32_x86_64 "i686-pc-linux-gnu" +-gcc -DHAVE_CONFIG_H -I. -I../../master/ld -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT eelf32_x86_64.o -MD -MP -MF .deps/eelf32_x86_64.Tpo -c -o eelf32_x86_64.o eelf32_x86_64.c +-mv -f .deps/eelf32_x86_64.Tpo .deps/eelf32_x86_64.Po +-/bin/bash ./libtool --tag=CC --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -o ld-new ldgram.o ldlex-wrapper.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o plugin.o eelf_i386.o ei386linux.o eelf32_x86_64.o ../bfd/libbfd.la ../libiberty/libiberty.a -lz -ldl +-libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -o ld-new ldgram.o ldlex-wrapper.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o plugin.o eelf_i386.o ei386linux.o eelf32_x86_64.o ../bfd/.libs/libbfd.a ../libiberty/libiberty.a -lz -ldl +/bin/bash ./libtool --tag=CC --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -o ld-new ldgram.o ldlex-wrapper.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o plugin.o eelf_i386.o ../bfd/libbfd.la ../libiberty/libiberty.a -lz -ldl +libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -o ld-new ldgram.o ldlex-wrapper.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o plugin.o eelf_i386.o ../bfd/.libs/libbfd.a ../libiberty/libiberty.a -lz -ldl touch ld.1 diff --git a/open_issues/binutils/log_install-diff b/open_issues/binutils/log_install-diff index 83c8d7b6..00496f8b 100644 --- a/open_issues/binutils/log_install-diff +++ b/open_issues/binutils/log_install-diff @@ -1,5 +1,5 @@ ---- /dev/fd/63 2010-12-20 19:00:16.368493004 +0100 -+++ /dev/fd/62 2010-12-20 19:00:16.368493004 +0100 +--- /dev/fd/63 2011-02-10 18:56:20.086225001 +0100 ++++ /dev/fd/62 2011-02-10 18:56:20.086225001 +0100 @@ -68,7 +68,6 @@ libtool: install: /usr/bin/install -c .libs/libbfd.a [...]/hurd/master.build.install/lib/libbfd.a libtool: install: chmod 644 [...]/hurd/master.build.install/lib/libbfd.a diff --git a/open_issues/binutils/sum_hurd b/open_issues/binutils/sum_hurd index 96dd0cb2..15d225f9 100644 --- a/open_issues/binutils/sum_hurd +++ b/open_issues/binutils/sum_hurd @@ -1,4 +1,4 @@ -Test Run By tschwinge on Mon Dec 20 11:35:47 2010 +Test Run By tschwinge on Thu Feb 10 18:58:16 2011 Native configuration is i686-unknown-gnu0.3 === binutils tests === @@ -114,7 +114,7 @@ Running [...]/hurd/master/binutils/testsuite/binutils-all/x86-64/x86-64.exp ... # of expected passes 83 # of unsupported tests 2 -Test Run By tschwinge on Mon Dec 20 11:44:29 2010 +Test Run By tschwinge on Thu Feb 10 19:06:15 2011 Native configuration is i686-unknown-gnu0.3 === ld tests === @@ -640,6 +640,8 @@ PASS: ld-ifunc/ifunc-1-local-x86 PASS: ld-ifunc/ifunc-1-x86 PASS: ld-ifunc/ifunc-10-i386 PASS: ld-ifunc/ifunc-11-i386 +PASS: ld-ifunc/ifunc-12-i386 +PASS: ld-ifunc/ifunc-13-i386 PASS: ld-ifunc/ifunc-2-i386 PASS: ld-ifunc/ifunc-2-local-i386 PASS: ld-ifunc/ifunc-3a-x86 @@ -669,6 +671,8 @@ Running [...]/hurd/master/ld/testsuite/ld-m68k/m68k.exp ... Running [...]/hurd/master/ld/testsuite/ld-mep/mep.exp ... Running [...]/hurd/master/ld/testsuite/ld-mips-elf/mips-elf-flags.exp ... Running [...]/hurd/master/ld/testsuite/ld-mips-elf/mips-elf.exp ... +Running [...]/hurd/master/ld/testsuite/ld-misc/defsym.exp ... +PASS: ld-misc/defsym1 Running [...]/hurd/master/ld/testsuite/ld-mmix/mmix.exp ... Running [...]/hurd/master/ld/testsuite/ld-mn10300/mn10300.exp ... Running [...]/hurd/master/ld/testsuite/ld-pe/pe-compile.exp ... @@ -705,6 +709,7 @@ Running [...]/hurd/master/ld/testsuite/ld-scripts/alignof.exp ... PASS: ALIGNOF Running [...]/hurd/master/ld/testsuite/ld-scripts/assert.exp ... PASS: ASSERT +PASS: ld-scripts/assert2 Running [...]/hurd/master/ld/testsuite/ld-scripts/crossref.exp ... PASS: NOCROSSREFS 1 PASS: NOCROSSREFS 2 @@ -720,6 +725,8 @@ Running [...]/hurd/master/ld/testsuite/ld-scripts/defined.exp ... PASS: DEFINED (PRMS 5699) PASS: ld-scripts/defined2 PASS: ld-scripts/defined3 +PASS: ld-scripts/defined4 +PASS: ld-scripts/defined5 Running [...]/hurd/master/ld/testsuite/ld-scripts/dynamic-sections.exp ... PASS: dynamic sections Running [...]/hurd/master/ld/testsuite/ld-scripts/empty-address.exp ... @@ -735,6 +742,8 @@ Running [...]/hurd/master/ld/testsuite/ld-scripts/empty-orphan.exp ... PASS: ld-scripts/empty-orphan Running [...]/hurd/master/ld/testsuite/ld-scripts/expr.exp ... PASS: ld-scripts/expr1 +PASS: ld-scripts/expr2 +PASS: ld-scripts/sane1 Running [...]/hurd/master/ld/testsuite/ld-scripts/extern.exp ... PASS: EXTERN Running [...]/hurd/master/ld/testsuite/ld-scripts/include.exp ... @@ -873,13 +882,13 @@ Running [...]/hurd/master/ld/testsuite/ld-xtensa/xtensa.exp ... === ld Summary === -# of expected passes 608 +# of expected passes 616 # of unexpected successes 1 # of expected failures 17 # of untested testcases 6 -/media/data[...]/hurd/master.build/ld/ld-new 2.21.51.20101220 +/media/data[...]/hurd/master.build/ld/ld-new 2.21.51.20110210 -Test Run By tschwinge on Mon Dec 20 11:38:03 2010 +Test Run By tschwinge on Thu Feb 10 19:00:16 2011 Native configuration is i686-unknown-gnu0.3 === gas tests === @@ -961,8 +970,8 @@ PASS: CFI common 2 PASS: CFI common 3 PASS: CFI common 4 PASS: CFI common 5 -PASS: CFI common 7 PASS: CFI common 6 +PASS: CFI common 7 Running [...]/hurd/master/gas/testsuite/gas/cr16/cr16.exp ... Running [...]/hurd/master/gas/testsuite/gas/cr16/pic.exp ... Running [...]/hurd/master/gas/testsuite/gas/cris/cris.exp ... @@ -1001,6 +1010,7 @@ PASS: section flags PASS: DWARF2 1 PASS: DWARF2 2 PASS: DWARF2 3 +PASS: DWARF2 4 PASS: Check bad section flag Running [...]/hurd/master/gas/testsuite/gas/fr30/allinsn.exp ... Running [...]/hurd/master/gas/testsuite/gas/fr30/fr30.exp ... @@ -1094,8 +1104,10 @@ PASS: i386 -mtune=i686 nops 3 PASS: i386 nops 4 PASS: i386 nops -mtune=i386 4 PASS: i386 -mtune=i686 nops 4 +PASS: i386 -march=i686+nop nops 4a PASS: i386 nops 5 PASS: i386 -march=i686 nops 5 +PASS: i386 nops 6 PASS: i386 16-bit addressing in 32-bit mode. PASS: i386 32-bit addressing in 16-bit mode. PASS: i386 SSE4.1 @@ -1176,6 +1188,10 @@ PASS: i386 FMA scalar insns (Intel disassembly) PASS: i386 FMA4 PASS: i386 LWP PASS: i386 XOP +PASS: i386 BMI insns +PASS: i386 BMI insns (Intel disassembly) +PASS: i386 TBM +PASS: i386 TBM insns (Intel disassembly) PASS: i386 F16C PASS: i386 F16C (Intel disassembly) PASS: i386 FSGSBase @@ -1217,6 +1233,10 @@ PASS: i386 list-1 PASS: i386 list-2 PASS: i386 list-3 PASS: DWARF2 debugging information 1 +Running [...]/hurd/master/gas/testsuite/gas/i386/ilp32/cfi/ilp32.exp ... +Running [...]/hurd/master/gas/testsuite/gas/i386/ilp32/elf/ilp32.exp ... +Running [...]/hurd/master/gas/testsuite/gas/i386/ilp32/ilp32.exp ... +Running [...]/hurd/master/gas/testsuite/gas/i386/ilp32/lns/ilp32.exp ... Running [...]/hurd/master/gas/testsuite/gas/i860/i860.exp ... Running [...]/hurd/master/gas/testsuite/gas/ia64/ia64.exp ... Running [...]/hurd/master/gas/testsuite/gas/ieee-fp/x930509a.exp ... @@ -1317,6 +1337,6 @@ Running [...]/hurd/master/gas/testsuite/gas/z8k/z8k.exp ... === gas Summary === -# of expected passes 319 -../as-new 2.21.51.20101220 +# of expected passes 326 +../as-new 2.21.51.20110210 diff --git a/open_issues/binutils/sum_linux b/open_issues/binutils/sum_linux index c2dae925..49cf53fb 100644 --- a/open_issues/binutils/sum_linux +++ b/open_issues/binutils/sum_linux @@ -1,4 +1,4 @@ -Test Run By thomas on Mon Dec 20 11:34:53 2010 +Test Run By thomas on Thu Feb 10 18:57:42 2011 Native configuration is i686-pc-linux-gnu === binutils tests === @@ -114,7 +114,7 @@ Running [...]/hurd/master/binutils/testsuite/binutils-all/x86-64/x86-64.exp ... # of expected passes 83 # of unsupported tests 2 -Test Run By thomas on Mon Dec 20 11:35:19 2010 +Test Run By thomas on Thu Feb 10 18:58:10 2011 Native configuration is i686-pc-linux-gnu === ld tests === @@ -640,6 +640,8 @@ PASS: ld-ifunc/ifunc-1-local-x86 PASS: ld-ifunc/ifunc-1-x86 PASS: ld-ifunc/ifunc-10-i386 PASS: ld-ifunc/ifunc-11-i386 +PASS: ld-ifunc/ifunc-12-i386 +PASS: ld-ifunc/ifunc-13-i386 PASS: ld-ifunc/ifunc-2-i386 PASS: ld-ifunc/ifunc-2-local-i386 PASS: ld-ifunc/ifunc-3a-x86 @@ -669,6 +671,8 @@ Running [...]/hurd/master/ld/testsuite/ld-m68k/m68k.exp ... Running [...]/hurd/master/ld/testsuite/ld-mep/mep.exp ... Running [...]/hurd/master/ld/testsuite/ld-mips-elf/mips-elf-flags.exp ... Running [...]/hurd/master/ld/testsuite/ld-mips-elf/mips-elf.exp ... +Running [...]/hurd/master/ld/testsuite/ld-misc/defsym.exp ... +PASS: ld-misc/defsym1 Running [...]/hurd/master/ld/testsuite/ld-mmix/mmix.exp ... Running [...]/hurd/master/ld/testsuite/ld-mn10300/mn10300.exp ... Running [...]/hurd/master/ld/testsuite/ld-pe/pe-compile.exp ... @@ -705,6 +709,7 @@ Running [...]/hurd/master/ld/testsuite/ld-scripts/alignof.exp ... PASS: ALIGNOF Running [...]/hurd/master/ld/testsuite/ld-scripts/assert.exp ... PASS: ASSERT +PASS: ld-scripts/assert2 Running [...]/hurd/master/ld/testsuite/ld-scripts/crossref.exp ... PASS: NOCROSSREFS 1 PASS: NOCROSSREFS 2 @@ -720,6 +725,8 @@ Running [...]/hurd/master/ld/testsuite/ld-scripts/defined.exp ... PASS: DEFINED (PRMS 5699) PASS: ld-scripts/defined2 PASS: ld-scripts/defined3 +PASS: ld-scripts/defined4 +PASS: ld-scripts/defined5 Running [...]/hurd/master/ld/testsuite/ld-scripts/dynamic-sections.exp ... PASS: dynamic sections Running [...]/hurd/master/ld/testsuite/ld-scripts/empty-address.exp ... @@ -735,6 +742,8 @@ Running [...]/hurd/master/ld/testsuite/ld-scripts/empty-orphan.exp ... PASS: ld-scripts/empty-orphan Running [...]/hurd/master/ld/testsuite/ld-scripts/expr.exp ... PASS: ld-scripts/expr1 +PASS: ld-scripts/expr2 +PASS: ld-scripts/sane1 Running [...]/hurd/master/ld/testsuite/ld-scripts/extern.exp ... PASS: EXTERN Running [...]/hurd/master/ld/testsuite/ld-scripts/include.exp ... @@ -873,12 +882,12 @@ Running [...]/hurd/master/ld/testsuite/ld-xtensa/xtensa.exp ... === ld Summary === -# of expected passes 618 +# of expected passes 626 # of expected failures 8 # of untested testcases 6 -/media/data[...]/hurd/master.build/ld/ld-new 2.21.51.20101220 +/media/data[...]/hurd/master.build/ld/ld-new 2.21.51.20110210 -Test Run By thomas on Mon Dec 20 11:34:59 2010 +Test Run By thomas on Thu Feb 10 18:57:49 2011 Native configuration is i686-pc-linux-gnu === gas tests === @@ -960,8 +969,8 @@ PASS: CFI common 2 PASS: CFI common 3 PASS: CFI common 4 PASS: CFI common 5 -PASS: CFI common 7 PASS: CFI common 6 +PASS: CFI common 7 Running [...]/hurd/master/gas/testsuite/gas/cr16/cr16.exp ... Running [...]/hurd/master/gas/testsuite/gas/cr16/pic.exp ... Running [...]/hurd/master/gas/testsuite/gas/cris/cris.exp ... @@ -1000,6 +1009,7 @@ PASS: section flags PASS: DWARF2 1 PASS: DWARF2 2 PASS: DWARF2 3 +PASS: DWARF2 4 PASS: Check bad section flag Running [...]/hurd/master/gas/testsuite/gas/fr30/allinsn.exp ... Running [...]/hurd/master/gas/testsuite/gas/fr30/fr30.exp ... @@ -1093,8 +1103,10 @@ PASS: i386 -mtune=i686 nops 3 PASS: i386 nops 4 PASS: i386 nops -mtune=i386 4 PASS: i386 -mtune=i686 nops 4 +PASS: i386 -march=i686+nop nops 4a PASS: i386 nops 5 PASS: i386 -march=i686 nops 5 +PASS: i386 nops 6 PASS: i386 16-bit addressing in 32-bit mode. PASS: i386 32-bit addressing in 16-bit mode. PASS: i386 SSE4.1 @@ -1175,6 +1187,10 @@ PASS: i386 FMA scalar insns (Intel disassembly) PASS: i386 FMA4 PASS: i386 LWP PASS: i386 XOP +PASS: i386 BMI insns +PASS: i386 BMI insns (Intel disassembly) +PASS: i386 TBM +PASS: i386 TBM insns (Intel disassembly) PASS: i386 F16C PASS: i386 F16C (Intel disassembly) PASS: i386 FSGSBase @@ -1216,6 +1232,10 @@ PASS: i386 list-1 PASS: i386 list-2 PASS: i386 list-3 PASS: DWARF2 debugging information 1 +Running [...]/hurd/master/gas/testsuite/gas/i386/ilp32/cfi/ilp32.exp ... +Running [...]/hurd/master/gas/testsuite/gas/i386/ilp32/elf/ilp32.exp ... +Running [...]/hurd/master/gas/testsuite/gas/i386/ilp32/ilp32.exp ... +Running [...]/hurd/master/gas/testsuite/gas/i386/ilp32/lns/ilp32.exp ... Running [...]/hurd/master/gas/testsuite/gas/i860/i860.exp ... Running [...]/hurd/master/gas/testsuite/gas/ia64/ia64.exp ... Running [...]/hurd/master/gas/testsuite/gas/ieee-fp/x930509a.exp ... @@ -1316,6 +1336,6 @@ Running [...]/hurd/master/gas/testsuite/gas/z8k/z8k.exp ... === gas Summary === -# of expected passes 319 -../as-new 2.21.51.20101220 +# of expected passes 326 +../as-new 2.21.51.20110210 diff --git a/open_issues/binutils_gold.mdwn b/open_issues/binutils_gold.mdwn index f9008154..aa6843a3 100644 --- a/open_issues/binutils_gold.mdwn +++ b/open_issues/binutils_gold.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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,3 +11,177 @@ License|/fdl]]."]]"""]] [[!tag open_issue_binutils]] Have a look at GOLD / port as needed. + + +# teythoon's try / `mremap` issue + +IRC, #hurd, 2011-01-12 + + <teythoon> I've been looking into building gold on hurd and it built fine + with one minor tweak + <teythoon> and it's working fine according to its test suite + <teythoon> the only problem is that the build system is failing to detect + the hurdish mremap which lives in libmemusage + <teythoon> on linux it is in the libc so the check succeeds + <teythoon> any hints on how to fix this properly? + <antrik> hm... it's strange that it's a different library on the Hurd + <antrik> are the implementations compatible? + <teythoon> antrik: it seems so, though the declarations differ slightly + <antrik> I guess the best thing is to ask on the appropriate list(s) why + they are different... + <teythoon> teythoon@ganymede:~/build/gold/binutils-2.21/gold$ grep -A1 + mremap /usr/include/sys/mman.h + <teythoon> extern void *mremap (void *__addr, size_t __old_len, size_t + __new_len, int __flags, ...) __THROW; + <teythoon> vs + <antrik> of course it would be possible to modify the configure script to + check for the Hurd variant too; but first we should establish whether + here is actually any reason for being different, or it's just some + historical artefact that should be fixed... + <teythoon> teythoon@ganymede:~/build/gold/binutils-2.21/gold$ fgrep 'extern + void *mremap' mremap.c + <teythoon> extern void *mremap (void *, size_t, size_t, int, ...); + <teythoon> the problem is that the test fails to link due to the fact that + mremap isn't in the libc on hurd + <antrik> yeah, it would be possible for the configure script to check + whether it works when the hurdish extra library is added explicitely + <antrik> but again, I don't see any good reason for being different here in + the first place... + <teythoon> so should I create a patch to move mremap? + <antrik> if it's not too complicated, that would be nice... it's always + easier to discuss when you already have code :-) + <antrik> OTOH, asking first might spare you some useless work if it turns + out there *is* some reason for being different after all... + so where is the right place to discuss this? + <antrik> bug-hurd mailing list and/or glibc mailing list. not sure which + one is better -- I guess it doesn't hurt to crosspost... + +[[mailing_lists/libc-alpha]] is the correct list, and cross-posting to +[[mailing_lists/bug-hurd]] would be fine, too. + + <teythoon> antrik: some further digging revealed that mremap belongs to + /lib/libmemusage.so on both hurd and linux + <teythoon> the only difference is that on linux there is a weak reference + to that function in /lib/libc-2.11.2.so + <teythoon> $ objdump -T /lib/libc-2.11.2.so | fgrep mremap + <teythoon> 00000000000cf7e0 w DF .text 0000000000000028 GLIBC_2.2.5 + mremap + <antrik> ah, it's probably simply a bug that we don't have this weak + reference too + <antrik> IIRC we had similar bugs before + <antrik> teythoon: can you provide a patch for that? + <teythoon> antrik: unfortunately I have no idea how that weak ref ended up + there + + <guillem> teythoon: also the libmemusage.s seems to be just a debugging + library to be used by LD_PRELOAD or similar + <guillem> which override those memory functions + <guillem> the libc should provide actual code for those functions, even if + the symbol is declared weak (so overridable) + <guillem> teythoon: are you sure that's the actual problem? can you paste + somewhere the build logs with the error? + <teythoon> guillem: sure + <teythoon> http://paste.debian.net/104437/ + <teythoon> that's the part of config.log that shows the detection (or the + failure to detect it) of mremap + <teythoon> this results in HAVE_MREMAP not being defined + <teythoon> as a consequence it is declared in gold.h and this declaration + conflicts with the one from sys/mman.h http://paste.debian.net/104438/ + <teythoon> on linux the test for mremap succeeds + <guillem> teythoon: hmm oh I guess it's just what that, mremap is linux + specific so it's not available on the hurd + <guillem> teythoon: I just checked glibc and seems to confirm that + <braunr> CONFORMING TO This call is Linux-specific, and should not be used + in programs intended to be portable. + <teythoon> ah okay + <teythoon> so I guess we shouldn't ship an header with that declaration... + <guillem> teythoon: yeah :/ good luck telling that to drepper :) + <guillem> teythoon: I guess he'll suggest that everyone else needs to get + our own copy of sys/mman.h + <guillem> s/our/their/ + <teythoon> hm, so how should I proceed? + <braunr> what's your goal ? + <braunr> detecting mremap ? + <teythoon> making binutils/gold compile ootb on hurd + <teythoon> I picked it from the open issues page ;) + <braunr> well, if there is no mremap, you need a replacement + <teythoon> gold has a replacement + <braunr> ok + <braunr> so your problem is fixing the detection of mremap right ? + <teythoon> yes + <braunr> ok, that's a build system question then :/ + <braunr> you need to ask an autotools guy + <teythoon> well, actually the build system correctly detects the absence of + mremap + <braunr> (gold does use the autotools right ?) + <teythoon> yes + <braunr> oh, i'm lost now (i admit i didn't read the whole issue :/) + <teythoon> it is just that the declaration in sys/mman.h conflicts with + their own declaration + <braunr> ah + <braunr> so in the absence of mremap, they use their own builtin function + <teythoon> yes + <teythoon> and according to the test suite it is working perfectly + <teythoon> gold that is + <teythoon> the declaration in mman.h has an extra __THROW + <guillem> a workaround would be to rename gold's mremap to something else, + gold_mremap for example + <braunr> that's really the kind of annoying issue + <braunr> you either have to change glibc, or gold + <guillem> yeah + <braunr> you'll face difficulty changing glibc, as guillem told you + <guillem> the correct solution though IMO is to fix glibc + <braunr> but this may be true for gold too + <braunr> guillem: i agree + <antrik> maybe it would be easiest actually to implement mremap()?... + <braunr> but as this is something quite linux specific, it makes sense to + use another internal name, and wrap that to the linux mremap if it's + detected + <braunr> antrik: i'm nto sure + <antrik> braunr: I don't think using such workarounds is a good + idea. clearly there would be no issue if the header file wouldn't be + incorrect on Hurd + <braunr> antrik: that's why i said i agree with guillem when he says "the + correct solution though IMO is to fix glibc" + <teythoon> what exactly is the problem with getting a patch into glibc? + <braunr> the people involved + <guillem> teythoon: and touching a generic header file + <braunr> but feel free to try, you could be lucky + <teythoon> but glibc is not an linux specific piece of software, right? + <braunr> teythoon: no, it's not + <guillem> erm... + <braunr> teythoon: but in practice, it is + <guillem> supposedly not :) + <antrik> braunr: BTW, by "easiest" I don't mean coding alone, but + coding+pushing upstream :-) + <guillem> so the problem is, misc/sys/mman.h should be a generic header and + as such not include linux specific parts, which are not present on hurd, + kfreebsd, etc etc + <braunr> antrik: yes, that's why guillem and i suggested the workaround + thing in gold + <antrik> that also requires pushing upstream. and quite frankly, if I were + the gold maintainer, I wouldn't accept it. + <guillem> but the easiest (and wrong) solution in glibc to avoid maintainer + conflict will probably be copying that file under hurd's glibc tree and + install that instead + <braunr> antrik: implementing mremap could be relatively easy to do + actually + <braunr> antrik: IIRC, vm_map() supports overlapping + <antrik> well, actually the easiest solution would be to create a patch + that never goes upstream but is included in Debian, like many + others... but that's obviously not a good long-term plan + <antrik> braunr: yes, I think so too + <antrik> braunr: haven't checked, but I have a vague recollection that the + fundamentals are pretty much there + <antrik> teythoon: so, apart from an ugly workaround in gold, there are + essentially three options: 1. implement mremap; 2. make parts of mman.h + conditional; 3. use our own copy of mman.h + <antrik> 1. would be ideal, but might be non-trivial; 2. would might be + tricky to get right, and even more tricky to get upstream; 3. would be + simple, but a maintenance burden in the long term + <teythoon> looking at golds replacement code (mmap & memcpy) 1 sounds like + the best option performance wise + +[[!taglink open_issue_glibc]]: check if it is possible to implement `mremap`. +[[I|tschwinge]] remember some discussion about this, but have not yet worked on +locating it. [[Talk to me|tschwinge]] if you'd like to have a look at this. diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn index ad59f962..21e09089 100644 --- a/open_issues/code_analysis.mdwn +++ b/open_issues/code_analysis.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -40,7 +40,7 @@ analysis|performance]], [[formal_verification]], as well as general * <http://blog.llvm.org/2010/04/whats-wrong-with-this-code.html> - * [[Valgrind]] + * [[community/gsoc/project_ideas/Valgrind]] * [Smatch](http://smatch.sourceforge.net/) diff --git a/open_issues/crash_server.mdwn b/open_issues/crash_server.mdwn index d97f5458..7ed4afbf 100644 --- a/open_issues/crash_server.mdwn +++ b/open_issues/crash_server.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2010, 2011 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 @@ -187,3 +188,8 @@ one... /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/ipc_kobject.c:76 mach_msg_trap /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/ipc/mach_msg.c:1367 + +--- + +If someone is working in this area, they may want to have a look at +[[GDB_gcore]], and port <http://code.google.com/p/google-coredumper/>, too. diff --git a/open_issues/debian_cross_toolchain.mdwn b/open_issues/debian_cross_toolchain.mdwn new file mode 100644 index 00000000..e0665466 --- /dev/null +++ b/open_issues/debian_cross_toolchain.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!tag open_issue_hurd]] + +Have a look at the Debian *Cross Toolchain* project, +<https://alioth.debian.org/projects/crosstoolchain/>, +<http://wiki.debian.org/ToolChain/Cross>. diff --git a/open_issues/debugging.mdwn b/open_issues/debugging.mdwn index e66a086f..e5fbf7a0 100644 --- a/open_issues/debugging.mdwn +++ b/open_issues/debugging.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -42,7 +42,10 @@ We have debugging infrastructure. For example: Continues: <http://lwn.net/Articles/414264/>, which introduces <http://dmtcp.sourceforge.net/>. - * [[locking]] + * [[crash_server}}, [[GDB_gcore]], + <http://code.google.com/p/google-coredumper/> + + * [[community/gsoc/project_ideas/libdiskfs_locking]] * <http://lwn.net/Articles/415728/>, or <http://lwn.net/Articles/415471/> -- just two examples; there's a lot of such stuff for Linux. diff --git a/open_issues/ext2fs_page_cache_swapping_leak.mdwn b/open_issues/ext2fs_page_cache_swapping_leak.mdwn new file mode 100644 index 00000000..0ace5cd3 --- /dev/null +++ b/open_issues/ext2fs_page_cache_swapping_leak.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, OFTC, #debian-hurd, 2011-03-24 + + <youpi> I still believe we have an ext2fs page cache swapping leak, however + <youpi> as the 1.8GiB swap was full, yet the ld process was only 1.5GiB big + <pinotree> a leak at swapping time, you mean? + <youpi> I mean the ext2fs page cache being swapped out instead of simply + dropped + <pinotree> ah + <pinotree> so the swap tends to accumulate unuseful stuff, i see + <youpi> yes + <youpi> the disk content, basicallyt :) diff --git a/open_issues/file_system_exerciser.mdwn b/open_issues/file_system_exerciser.mdwn new file mode 100644 index 00000000..4277e5e7 --- /dev/null +++ b/open_issues/file_system_exerciser.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!tag open_issue_hurd]] + +Test our file system implementations with the File System Exerciser. + + * <http://codemonkey.org.uk/projects/fsx/> diff --git a/open_issues/gdb_gcore.mdwn b/open_issues/gdb_gcore.mdwn index 7d4980f1..69211ac0 100644 --- a/open_issues/gdb_gcore.mdwn +++ b/open_issues/gdb_gcore.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2011 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 @@ -21,3 +21,6 @@ GDB's `gcore` command doesn't work / needs to be implemented / ported in GDB: /media/data/home/tschwinge/core.cA0ICY:2: Error in sourced command file: Undefined command: "gcore". Try "help". gcore: failed to create core.8371 + +If someone is working in this area, they may want to port +<http://code.google.com/p/google-coredumper/>, too. diff --git a/open_issues/gdb_noninvasive_mode_new_threads.mdwn b/open_issues/gdb_noninvasive_mode_new_threads.mdwn new file mode 100644 index 00000000..9b3992f4 --- /dev/null +++ b/open_issues/gdb_noninvasive_mode_new_threads.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!tag open_issue_gdb]] + +Debugging a translator. `gdb binary`. `set noninvasive on`. `attach [PID]`. +Translator does some work. GDB doesn't notice new threads. `detach`. `attach +[PID]` -- now new threads are visible. diff --git a/open_issues/gdb_thread_ids.mdwn b/open_issues/gdb_thread_ids.mdwn index c31a9967..c04a10ee 100644 --- a/open_issues/gdb_thread_ids.mdwn +++ b/open_issues/gdb_thread_ids.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,8 +6,8 @@ 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="GDB: thread ids"]] @@ -23,3 +23,9 @@ GNU GDB's Pedro Alves: Also see [[thread numbering of ps and GDB]]. + +--- + +`attach` to a multi-threaded process. See threads 1 to 5. `detach`. `attach` +again -- thread numbers continue where they stopped last time: now they're +threads 6 to 10. diff --git a/open_issues/gnumach_console_timestamp.mdwn b/open_issues/gnumach_console_timestamp.mdwn new file mode 100644 index 00000000..b36b47b9 --- /dev/null +++ b/open_issues/gnumach_console_timestamp.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, freenode, #hurd, 2011-02-17 + + <azeem> task 39011c10 deallocating an invalid port 349, most probably a + bug. + <azeem> kernel: Page fault (14), code=6 + <azeem> Stopped at 0x28b9c7: orb %bh,0(%ecx,%edi,2) + <azeem> db> + [...] + <antrik> tschwinge: I doubt the deallocating warning is related to the + later fault + <tschwinge> antrik: YOu may be right. + <tschwinge> Perhaps it'd be a good idea to add some sort of timestamp to + Mach messages. + <tschwinge> Like in Linux' dmesg. + <tschwinge> Or just RDTSC (internal processor counter). diff --git a/open_issues/hurd_build_without_parted.mdwn b/open_issues/hurd_build_without_parted.mdwn new file mode 100644 index 00000000..06ecf56d --- /dev/null +++ b/open_issues/hurd_build_without_parted.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!tag open_issue_hurd]] + +Seen with `cross-gnu`. + +If the *parted* libraries aren't available, we explicitly have to set +`--without-parted` or the build will fail. diff --git a/open_issues/implementing_hurd_on_top_of_another_system.mdwn b/open_issues/implementing_hurd_on_top_of_another_system.mdwn index 23512aa9..95b71ebb 100644 --- a/open_issues/implementing_hurd_on_top_of_another_system.mdwn +++ b/open_issues/implementing_hurd_on_top_of_another_system.mdwn @@ -78,3 +78,40 @@ IRC, #hurd, 2010-12-28 <antrik> though I must say that I'm more and more convinced running the Hurd on top of a monolithic kernel would actually be a useful approach for the time being... + +--- + +IRC, #hurd, 2011-02-11 + + <neal> marcus and I were discussing how to add Mach to Linux + <neal> one could write a module to implement Mach IPC + <neal> and another to implement Mach VM + <neal> the big thing missing with Mach VM is the ability for a tracing + process to easily map or unmap an inferior process's memory + <antrik> neal: why would a tracing process need to map the inferior's + memory? + <neal> the simple answer is that is how it is done on Mach + <antrik> neal: is it? not sure we are talking about the same thing + here. GDB uses vm_read()/vm_write() to access the inferior's memory AFAIK + <neal> on linux? + <neal> I think it use /proc/pid/mem + <antrik> on Hurd + <neal> I'm talking about adding Mach to Linux + <neal> by adding some functionality to Linux + <neal> and then implementing a bunch in user space + <antrik> yeah, but I don't understand the point about mapping inferior's + memory :-( + <antrik> what would be in user space? + <neal> there are a number of different cut points + <neal> one could imagine just using Linux's device drivers, CPU scheduler, + memory management, etc. + <neal> another possibility would be something higher where Hurd processes + just use some Hurdish servers + <antrik> neal: yeah, these are all options I have been considering... too + bad I wasn't able to come to FOSDEM -- I'd love to have participated in + this discussion :-( + <antrik> neal: BTW, were you just discussing this as a hypothetical idea, + or something you are seriously considering? + <neal> I'm unlikely to work on it, sorry + <antrik> didn't really expect that :-) + <antrik> would be nice though if you could write up your conclusions... diff --git a/open_issues/inotify_file_notice_changes.mdwn b/open_issues/inotify_file_notice_changes.mdwn new file mode 100644 index 00000000..a30cd3d3 --- /dev/null +++ b/open_issues/inotify_file_notice_changes.mdwn @@ -0,0 +1,42 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +IRC, freenode, #hurd, 2011-03-28 + +[[!tag open_issue_hurd]] + + <barrucadu> I've been going through the xmlfs code, and plan to have it + monitor the backing store (xml file) for changes and update the presented + directory hierarchy when something is changed; is there a better way to + check a file for changes beyond checking its modification time every few + minutes? + <tschwinge> barrucadu: In the Hurd spirit, you'd use file_notice_changes + (fs.defs). + <barrucadu> thanks + <youpi> we should manage to work out an inotify interface around it, btw + <pochu> like gamin? + <pinotree> imho making gamin work should gain all the fam-using + applications + <pochu> (which, looking at the sources, seems to support hurd already, not + sure why it's not built) + <pinotree> pochu: the hurd_notify of gamin does not build OOTB + <pochu> > /build/buildd/gamin-0.1.10/./libgamin/gam_data.c:476: error: + 'PTHREAD_MUTEX_RECURSIVE' undeclared (first use in this function) + <pinotree> there are few patches in bugzilla to make it compile + <pochu> if they work, and you point me to them, I can upload a new gamin + with them included + <pinotree> #315644, #588337. #605246 + <pinotree> and iirc there's something else i have locally but not send yet + <pochu> please check and submit :) + <pinotree> ah no, those three contains all the build issues + <pinotree> .. plus relative proposed fixes + <pochu> ok, I'll try to get to it soonish + <pinotree> and you should know about two of them already ;D + <pochu> please remind me if I don't :) diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn index 39203333..addc29c3 100644 --- a/open_issues/multithreading.mdwn +++ b/open_issues/multithreading.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -10,7 +10,21 @@ License|/fdl]]."]]"""]] [[!tag open_issue_hurd]] -Hurd servers / VFS libraries are multithreaded, roughly using one thread per +Hurd servers / VFS libraries are multithreaded. + + +# Implementation + + * well-known threading libraries + + * [[hurd/libthreads]] + + * [[hurd/libpthread]] + + +# Design + +Roughly using one thread per incoming request. This is not the best approach: it doesn't really make sense to scale the number of worker threads with the number of incoming requests, but instead they should be scaled according to the backends' characteristics. @@ -18,7 +32,9 @@ instead they should be scaled according to the backends' characteristics. The [[hurd/Critique]] should have some more on this. -Alternative approaches: +# Alternative approaches: + + * <http://www.concurrencykit.org/> * Continuation-passing style diff --git a/open_issues/nightly_builds.mdwn b/open_issues/nightly_builds.mdwn index 506697bb..5d1257fb 100644 --- a/open_issues/nightly_builds.mdwn +++ b/open_issues/nightly_builds.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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,6 +15,8 @@ Resources: * [[toolchain/cross-gnu]] + * [[Debian_Cross_Toolchain]] + * As reported in the [[news/2010-05-31]] news, there's Hydra doing nightly builds / Nix packages. diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn index 9f5e2373..11fc4c79 100644 --- a/open_issues/nightly_builds_deb_packages.mdwn +++ b/open_issues/nightly_builds_deb_packages.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -24,4 +24,8 @@ There is infrastructure available to test whole OS installations. --- +[[Debian_Cross_Toolchain]] for cross-building? + +--- + See also [[nightly_builds]]. diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn index 9b3701b3..eb9f3f8a 100644 --- a/open_issues/performance.mdwn +++ b/open_issues/performance.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -18,7 +18,7 @@ In [[microkernel]]-based systems, there is generally a considerable [[RPC]] overhead. In a multi-server system, it is non-trivial to implement a high-performance -[[I/O System|io_system]]. +[[I/O System|community/gsoc/project_ideas/disk_io_performance]]. When providing [[faq/POSIX_compatibility]] (and similar interfaces) in an environemnt that doesn't natively implement these interfaces, there may be a diff --git a/open_issues/performance/fork.mdwn b/open_issues/performance/fork.mdwn index 2748be53..5ceb6455 100644 --- a/open_issues/performance/fork.mdwn +++ b/open_issues/performance/fork.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -14,3 +14,24 @@ Our [[`fork` implementation|glibc/fork]] is nontrivial. To do: hard numbers. [[Microbenchmarks]]? + + +# Windows / Cygwin + + * <http://www.google.com/search?q=cygwin+fork> + + * <http://www.redhat.com/support/wpapers/cygnus/cygnus_cygwin/architecture.html> + + In particular, *5.6. Process Creation*. + + * <http://archive.gamedev.net/community/forums/topic.asp?topic_id=360290> + + * <http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/how-cygheap-works.txt?cvsroot=src> + + > Cygwin has recently adopted something called the "cygwin heap". This is + > an internal heap that is inherited by forked/execed children. It + > consists of process specific information that should be inherited. So + > things like the file descriptor table, the current working directory, and + > the chroot value live there. + + * <http://www.perlmonks.org/?node_id=588994> diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn index b59a87a7..79c2300f 100644 --- a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn +++ b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -10,7 +10,8 @@ License|/fdl]]."]]"""]] [[!tag open_issue_hurd]] -This one may be considered as a testcase for I/O system optimization. +This one may be considered as a testcase for [[I/O system +optimization|community/gsoc/project_ideas/disk_io_performance]]. It is taken from the [[binutils testsuite|binutils]], `ld/ld-elf/sec64k.exp`, where this diff --git a/open_issues/performance/io_system/clustered_page_faults.mdwn b/open_issues/performance/io_system/clustered_page_faults.mdwn new file mode 100644 index 00000000..37433e06 --- /dev/null +++ b/open_issues/performance/io_system/clustered_page_faults.mdwn @@ -0,0 +1,105 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +[[community/gsoc/project_ideas/disk_io_performance]]. + +IRC, freenode, #hurd, 2011-02-16 + + <braunr> exceptfor the kernel, everything in an address space is + represented with a VM object + <braunr> those objects can represent anonymous memory (from malloc() or + because of a copy-on-write) + <braunr> or files + <braunr> on classic Unix systems, these are files + <braunr> on the Hurd, these are memory objects, backed by external pagers + (like ext2fs) + <braunr> so when you read a file + <braunr> the kernel maps it from ext2fs in your address space + <braunr> and when you access the memory, a fault occurs + <braunr> the kernel determines it's a region backed by ext2fs + <braunr> so it asks ext2fs to provide the data + <braunr> when the fault is resolved, your process goes on + <etenil> does the faul occur because Mach doesn't know how to access the + memory? + <braunr> it occurs because Mach intentionnaly didn't back the region with + physical memory + <braunr> the MMU is programmed not to know what is present in the memory + region + <braunr> or because it's read only + <braunr> (which is the case for COW faults) + <etenil> so that means this bit of memory is a buffer that ext2fs loads the + file into and then it is remapped to the application that asked for it + <braunr> more or less, yes + <braunr> ideally, it's directly written into the right pages + <braunr> there is no intermediate buffer + <etenil> I see + <etenil> and as you told me before, currently the page faults are handled + one at a time + <etenil> which wastes a lot of time + <braunr> a certain amount of time + <etenil> enough to bother the user :) + <etenil> I've seen pages have a fixed size + <braunr> yes + <braunr> use the PAGE_SIZE macro + <etenil> and when allocating memory, the size that's asked for is rounded + up to the page size + <etenil> so if I have this correctly, it means that a file ext2fs provides + could be split into a lot of pages + <braunr> yes + <braunr> once in memory, it is managed by the page cache + <braunr> so that pages more actively used are kept longer than others + <braunr> in order to minimize I/O + <etenil> ok + <braunr> so a better page cache code would also improve overall performance + <braunr> and more RAM would help a lot, since we are strongly limited by + the 768 MiB limit + <braunr> which reduces the page cache size a lot + <etenil> but the problem is that reading a whole file in means trigerring + many page faults just for one file + <braunr> if you want to stick to the page clustering thing, yes + <braunr> you want less page faults, so that there are less IPC between the + kernel and the pager + <etenil> so either I make pages bigger + <etenil> or I modify Mach so it can check up on a range of pages for faults + before actually processing + <braunr> you *don't* change the page size + <etenil> ah + <etenil> that's hardware isn't it? + <braunr> in Mach, yes + <etenil> ok + <braunr> and usually, you want the page size to be the CPU page size + <etenil> I see + <braunr> current CPU can support multiple page sizes, but it becomes quite + hard to correctly handle + <braunr> and bigger page sizes mean more fragmentation, so it only suits + machines with large amounts of RAM, which isn't the case for us + <etenil> ok + <etenil> so I'll try the second approach then + <braunr> that's what i'd recommand + <braunr> recommend* + <etenil> ok + +--- + +IRC, freenode, #hurd, 2011-02-16 + + <antrik> etenil: OSF Mach does have clustered paging BTW; so that's one + place to start looking... + <antrik> (KAM ported the OSF code to gnumach IIRC) + <antrik> there is also an existing patch for clustered paging in libpager, + which needs some adaptation + <antrik> the biggest part of the task is probably modifying the Hurd + servers to use the new interface + <antrik> but as I said, KAM's code should be available through google, and + can serve as a starting point + +<http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00023.html> diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn new file mode 100644 index 00000000..b6851edd --- /dev/null +++ b/open_issues/performance/io_system/read-ahead.mdwn @@ -0,0 +1,301 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +[[community/gsoc/project_ideas/disk_io_performance]] + +IRC, #hurd, freenode, 2011-02-13: + + <etenil> youpi: Would libdiskfs/diskfs.h be in the right place to make + readahead functions? + <youpi> etenil: no, it'd rather be at the memory management layer, + i.e. mach, unfortunately + <youpi> because that's where you see the page faults + <etenil> youpi: Linux also provides a readahead() function for higher level + applications. I'll probably have to add the same thing in a place that's + higher level than mach + <youpi> well, that should just be hooked to the same common implementation + <etenil> the man page for readahead() also states that portable + applications should avoid it, but it could be benefic to have it for + portability + <youpi> it's not in posix indeed + +--- + +IRC, #hurd, freenode, 2011-02-14: + + <etenil> youpi: I've investigated prefetching (readahead) techniques. One + called DiskSeen seems really efficient. I can't tell yet if it's patented + etc. but I'll keep you informed + <youpi> don't bother with complicated techniques, even the most simple ones + will be plenty :) + <etenil> it's not complicated really + <youpi> the matter is more about how to plug it into mach + <etenil> ok + <youpi> then don't bother with potential pattents + <antrik> etenil: please take a look at the work KAM did for last year's + GSoC + <youpi> just use a trivial technique :) + <etenil> ok, i'll just go the easy way then + + <braunr> antrik: what was etenil referring to when talking about + prefetching ? + <braunr> oh, madvise() stuff + <braunr> i could help him with that + +--- + +[[Etenil]] is now working in this area. + +--- + +IRC, freenode, #hurd, 2011-02-15 + + <etenil> oh, I'm looking into prefetching/readahead to improve I/O + performance + <braunr> etenil: ok + <braunr> etenil: that's actually a VM improvement, like samuel told you + <etenil> yes + <braunr> a true I/O improvement would be I/O scheduling + <braunr> and how to implement it in a hurdish way + <braunr> (or if it makes sense to have it in the kernel) + <etenil> that's what I've been wondering too lately + <braunr> concerning the VM, you should look at madvise() + <etenil> my understanding is that Mach considers devices without really + knowing what they are + <braunr> that's roughly the interface used both at the syscall() and the + kernel levels in BSD, which made it in many other unix systems + <etenil> whereas I/O optimisations are often hard disk drives specific + <braunr> that's true for almost any kernel + <braunr> the device knowledge is at the driver level + <etenil> yes + <braunr> (here, I separate kernels from their drivers ofc) + <etenil> but Mach also contains some drivers, so I'm going through the code + to find the apropriate place for these improvements + <braunr> you shouldn't tough the drivers at all + <braunr> touch + <etenil> true, but I need to understand how it works before fiddling around + <braunr> hm + <braunr> not at all + <braunr> the VM improvement is about pagein clustering + <braunr> you don't need to know how pages are fetched + <braunr> well, not at the device level + <braunr> you need to know about the protocol between the kernel and + external pagers + <etenil> ok + <braunr> you could also implement pageout clustering + <etenil> if I understand you well, you say that what I'd need to do is a + queuing system for the paging in the VM? + <braunr> no + <braunr> i'm saying that, when a page fault occurs, the kernel should + (depending on what was configured through madvise()) transfer pages in + multiple blocks rather than one at a time + <braunr> communication with external pagers is already async, made through + regular ports + <braunr> which already implement message queuing + <braunr> you would just need to make the mapped regions larger + <braunr> and maybe change the interface so that this size is passed + <etenil> mmh + <braunr> (also don't forget that page clustering can include pages *before* + the page which caused the fault, so you may have to pass the start of + that region too) + <etenil> I'm not sure I understand the page fault thing + <etenil> is it like a segmentation error? + <etenil> I can't find a clear definition in Mach's manual + <braunr> ah + <braunr> it's a fundamental operating system concept + <braunr> http://en.wikipedia.org/wiki/Page_fault + <etenil> ah ok + <etenil> I understand now + <etenil> so what's currently happening is that when a page fault occurs, + Mach is transfering pages one at a time and wastes time + <braunr> sometimes, transferring just one page is what you want + <braunr> it depends on the application, which is why there is madvise() + <braunr> our rootfs, on the other hand, would benefit much from such an + improvement + <braunr> in UVM, this optimization is account for around 10% global + performance improvement + <braunr> accounted* + <etenil> not bad + <braunr> well, with an improved page cache, I'm sure I/O would matter less + on systems with more RAM + <braunr> (and another improvement would make mach support more RAM in the + first place !) + <braunr> an I/O scheduler outside the kernel would be a very good project + IMO + <braunr> in e.g. libstore/storeio + <etenil> yes + <braunr> but as i stated in my thesis, a resource scheduler should be as + close to its resource as it can + <braunr> and since mach can host several operating systems, I/O schedulers + should reside near device drivers + <braunr> and since current drivers are in the kernel, it makes sens to have + it in the kernel too + <braunr> so there must be some discussion about this + <etenil> doesn't this mean that we'll have to get some optimizations in + Mach and have the same outside of Mach for translators that access the + hardware directly? + <braunr> etenil: why ? + <etenil> well as you said Mach contains some drivers, but in principle, it + shouldn't, translators should do disk access etc, yes? + <braunr> etenil: ok + <braunr> etenil: so ? + <etenil> well, let's say if one were to introduce SATA support in Hurd, + nothing would stop him/her to do so with a translator rather than in Mach + <braunr> you should avoid the term translator here + <braunr> it's really hurd specific + <braunr> let's just say a user space task would be responsible for that + job, maybe multiple instances of it, yes + <etenil> ok, so in this case, let's say we have some I/O optimization + techniques like readahead and I/O scheduling within Mach, would these + also apply to the user-space task, or would they need to be + reimplemented? + <braunr> if you have user space drivers, there is no point having I/O + scheduling in the kernel + <etenil> but we also have drivers within the kernel + <braunr> what you call readahead, and I call pagein/out clustering, is + really tied to the VM, so it must be in Mach in any case + <braunr> well + <braunr> you either have one or the other + <braunr> currently we have them in the kernel + <braunr> if we switch to DDE, we should have all of them outside + <braunr> that's why such things must be discussed + <etenil> ok so if I follow you, then future I/O device drivers will need to + be implemented for Mach + <braunr> currently, yes + <braunr> but preferrably, someone should continue the work that has been + done on DDe so that drivers are outside the kernel + <etenil> so for the time being, I will try and improve I/O in Mach, and if + drivers ever get out, then some of the I/O optimizations will need to be + moved out of Mach + <braunr> let me remind you one of the things i said + <braunr> i said I/O scheduling should be close to their resource, because + we can host several operating systems + <braunr> now, the Hurd is the only system running on top of Mach + <braunr> so we could just have I/O scheduling outside too + <braunr> then you should consider neighbor hurds + <braunr> which can use different partitions, but on the same device + <braunr> currently, partitions are managed in the kernel, so file systems + (and storeio) can't make good scheduling decisions if it remains that way + <braunr> but that can change too + <braunr> a single storeio representing a whole disk could be shared by + several hurd instances, just as if it were a high level driver + <braunr> then you could implement I/O scheduling in storeio, which would be + an improvement for the current implementation, and reusable for future + work + <etenil> yes, that was my first instinct + <braunr> and you would be mostly free of the kernel internals that make it + a nightmare + <etenil> but youpi said that it would be better to modify Mach instead + <braunr> he mentioned the page clustering thing + <braunr> not I/O scheduling + <braunr> theseare really two different things + <etenil> ok + <braunr> you *can't* implement page clustering outside Mach because Mach + implements virtual memory + <braunr> both policies and mechanisms + <etenil> well, I'd rather think of one thing at a time if that's alright + <etenil> so what I'm busy with right now is setting up clustered page-in + <etenil> which need to be done within Mach + <braunr> keep clustered page-outs in mind too + <braunr> although there are more constraints on those + <etenil> yes + <etenil> I've looked up madvise(). There's a lot of documentation about it + in Linux but I couldn't find references to it in Mach (nor Hurd), does it + exist? + <braunr> well, if it did, you wouldn't be caring about clustered page + transfers, would you ? + <braunr> be careful about linux specific stuff + <etenil> I suppose not + <braunr> you should implement at least posix options, and if there are + more, consider the bsd variants + <braunr> (the Mach VM is the ancestor of all modern BSD VMs) + <etenil> madvise() seems to be posix + <braunr> there are system specific extensions + <braunr> be careful + <braunr> CONFORMING TO POSIX.1b. POSIX.1-2001 describes posix_madvise(3) + with constants POSIX_MADV_NORMAL, etc., with a behav‐ ior close to that + described here. There is a similar posix_fadvise(2) for file access. + <braunr> MADV_REMOVE, MADV_DONTFORK, MADV_DOFORK, MADV_HWPOISON, + MADV_MERGEABLE, and MADV_UNMERGEABLE are Linux- specific. + <etenil> I was about to post these + <etenil> ok, so basically madvise() allows tasks etc. to specify a usage + type for a chunk of memory, then I could apply the relevant I/O + optimization based on this + <braunr> that's it + <etenil> cool, then I don't need to worry about knowing what the I/O is + operating on, I just need to apply the optimizations as advised + <etenil> that's convenient + <etenil> ok I'll start working on this tonight + <etenil> making a basic readahead shouldn't be too hard + <braunr> readahead is a misleading name + <etenil> is pagein better? + <braunr> applies to too many things, doesn't include the case where + previous elements could be prefetched + <braunr> clustered page transfers is what i would use + <braunr> page prefetching maybe + <etenil> ok + <braunr> you should stick to something that's already used in the + literature since you're not inventing something new + <etenil> yes I've read a paper about prefetching + <etenil> ok + <etenil> thanks for your help braunr + <braunr> sure + <braunr> you're welcome + <antrik> braunr: madvise() is really the least important part of the + picture... + <antrik> very few applications actually use it. but pretty much all + applications will profit from clustered paging + <antrik> I would consider madvise() an optional goody, not an integral part + of the implementation + <antrik> etenil: you can find some stuff about KAM's work on + http://www.gnu.org/software/hurd/user/kam.html + <antrik> not much specific though + <etenil> thanks + <antrik> I don't remember exactly, but I guess there is also some + information on the mailing list. check the archives for last summer + <antrik> look for Karim Allah Ahmed + <etenil> antrik: I disagree, madvise gives me a good starting point, even + if eventually the optimisations should run even without it + <antrik> the code he wrote should be available from Google's summer of code + page somewhere... + <braunr> antrik: right, i was mentioning madvise() because the kernel (VM) + interface is pretty similar to the syscall + <braunr> but even a default policy would be nice + <antrik> etenil: I fear that many bits were discussed only on IRC... so + you'd better look through the IRC logs from last April onwards... + <etenil> ok + + <etenil> at the beginning I thought I could put that into libstore + <etenil> which would have been fine + + <antrik> BTW, I remembered now that KAM's GSoC application should have a + pretty good description of the necessary changes... unfortunately, these + are not publicly visible IIRC :-( + +--- + +IRC, freenode, #hurd, 2011-02-16 + + <etenil> braunr: I've looked in the kernel to see where prefetching would + fit best. We talked of the VM yesterday, but I'm not sure about it. It + seems to me that the device part of the kernel makes more sense since + it's logically what manages devices, am I wrong? + <braunr> etenil: you are + <braunr> etenil: well + <braunr> etenil: drivers should already support clustered sector + read/writes + <etenil> ah + <braunr> but yes, there must be support in the drivers too + <braunr> what would really benefit the Hurd mostly concerns page faults, so + the right place is the VM subsystem + +[[clustered_page_faults]] diff --git a/open_issues/perlmagick.mdwn b/open_issues/perlmagick.mdwn index 1daac62b..8a57a8fd 100644 --- a/open_issues/perlmagick.mdwn +++ b/open_issues/perlmagick.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -57,6 +57,49 @@ Etc. +/usr/lib/gcc/i486-gnu/4.4.2/include/omp.h: +# State as of 2011-03-06 + +freenode, #hurd channel, 2011-03-06: + + <pinotree> tschwinge: (speaking on working perl, how did it en with that + "(glibc) double free" crash with perl?) + <pinotree> *end + <tschwinge> I think I remember I suspected it's a libgomp (!) issue in the + end. I have not yet continued working on that. + <pinotree> libogmp? looks like you know more than me, then :) + <youpi> tschwinge: oh, I'm interested + <youpi> I know a bit about libgomp :) + <tschwinge> I bisected this down to where Imagemagick added -fgomp (or + whatever it is). And then the perl library (Imagemagick.pm?) which loads + the imagemagick.so segfaulted. + <tschwinge> ImageMagick did this change in the middle of a x.x.x.something + release.. + <tschwinge> My next step would have been to test whether libgomp works at + all for us. + <youpi> ./usr/sbin/debootstrap:DEBOOTSTRAP_CHECKSUM_FIELD="SHA$SHA_SIZE" + <youpi> erf + <youpi> so they switched to another checksum + <youpi> but we don't have that one on all of our packages :) + <youpi> tschwinge: + <youpi> buildd@bach:~$ OMP_NUM_THREADS=2 ./test + <youpi> I'm 0x1 + <youpi> I'm 0x3 + <youpi> libgomp works at least a bit + <tschwinge> OK. + <pinotree> i guess we should hope the working bits don't stop at that point + ;) + <tschwinge> If open_issues/perlmagick is to be believed a diff of 6.4.1-1 + and 6.4.1-2 should tell what exactly was changed. + <tschwinge> Oh! + <tschwinge> I even have it on the page already! ;-) + <tschwinge> -fopenmp + <youpi> I've tried the pragmas that imagemagick uses + <youpi> they work + <tschwinge> Might be the issue fixed itself? + <youpi> I don't know, it's the latest libc here + <youpi> (and latest hurd, to be uploaded) + + # Other [[!debbug 551017]] diff --git a/open_issues/pfinet.mdwn b/open_issues/pfinet.mdwn new file mode 100644 index 00000000..8782fe08 --- /dev/null +++ b/open_issues/pfinet.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, #hurd + +pfinet explosion + + <antrik> I reproduce it with freeciv client connected to a remote X server + <antrik> it suffices to run freeciv-gtk2, and clicking "new game" diff --git a/open_issues/pfinet_vs_system_time_changes.mdwn b/open_issues/pfinet_vs_system_time_changes.mdwn new file mode 100644 index 00000000..714c8784 --- /dev/null +++ b/open_issues/pfinet_vs_system_time_changes.mdwn @@ -0,0 +1,42 @@ +[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <grey_gandalf> I did a sudo date... + <grey_gandalf> and the machine hangs + +This was very likely a misdiagnosis: + +IRC, freenode, #hurd, 2011-03-25 + + <tschwinge> antrik: I suspect it'S some timing stuff in pfinet that perhaps + uses absolute time, and somehow wildely gets confused? + <antrik> tschwinge: BTW, pfinet doesn't actually die I think -- it just + drops open connections... + <antrik> perhaps it thinks they timed out + <tschwinge> antrik: Isn't the translator restarted instead? + <antrik> don't think so + <antrik> when pfinet actually dies, I also loose the NFS mounts, which + doesn't happen in this case + <antrik> hehe "... and the machine hangs" + <antrik> he didn't bother to check that the machine is perfectly fine, only + the SSH connection got dropped + <tschwinge> Ah, I see. So it'S perhaps indeed simply closes TCP + connections that have been without data for ``too long''? + <antrik> yeah, that's my guess + <antrik> my clock is speeding, so ntpdate sets it in the past + <antrik> perhaps there is some math that concludes the connection have been + inactive for -200 seconds, which (unsigned) is more than any timeout :-) + <tschwinge> (The other way round, you might likely get some integer + wrap-around, and thus the same result.) + <tschwinge> Yes. diff --git a/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn b/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn new file mode 100644 index 00000000..5a71412e --- /dev/null +++ b/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn @@ -0,0 +1,42 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +IRC, freenode, #hurd, 2011-03-28 + +[[!tag open_issue_hurd]] + + <pinotree> basically, i'm trying to implement socket credentials for local + sockets, and i guessed doing it in pflocal would be the appropriate place + <pinotree> what i thought was filling the cmsg data for MSG_CRED at + S_socket_recv() call + <pinotree> in case i missed it, would there be a way to "identify" the + other side of the port associated to the sock_user of that call? + <pochu> pinotree: that's needed by dbus right? cool! (and I don't know) + <pinotree> (yes, and gamin) + <youpi> pinotree: you have them already, they're just not stored + <youpi> see S_io_reauthenticate + <youpi> Throw away the ids we went through all that trouble to get... + <youpi> (comment) + * pinotree looks + <pinotree> hm, and who calls that rpc? + <youpi> everybody + <youpi> since that's how ext2fs knows the permission to apply, for instance + <pinotree> ah, i was referring to the reauthenticate of pflocal, not + auth_server_authenticate() + <youpi> that's what I'm saying + <youpi> see __hurd_file_name_lookup_retry, which is the very internal part + of open() + <youpi> it calls io_reauthenticate() + <youpi> to authenticate itself to the underlying translator of the opened + node + <pinotree> youpi: so, hm, could be an option make the result of pflocal's + S_io_reauthenticate cached in the sock_user struct? + <youpi> yes + <pinotree> nice thanks, i will try that change first diff --git a/open_issues/profiling.mdwn b/open_issues/profiling.mdwn index f56ae974..7e3c7350 100644 --- a/open_issues/profiling.mdwn +++ b/open_issues/profiling.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -21,6 +21,8 @@ done for [[performance analysis|performance]] reasons. Have a look at this, integrate it into the main trees. - * <http://fosdem.org/2010/interview/mark-wielaard> + * [[LTTng]] - ... or some other Linux thing. + * [[SystemTap]] + + * ... or some other Linux thing. diff --git a/open_issues/rm_fr.mdwn b/open_issues/rm_fr.mdwn new file mode 100644 index 00000000..89a803ab --- /dev/null +++ b/open_issues/rm_fr.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!tag open_issue_hurd]] + +From: Samuel Thibault <samuel.thibault@gnu.org> +Subject: rm -fr slowness + +I have always been surprised by the slowness of a mere rm -fr. Looking a +bit inside, I see that diskfs_dirremove_hard() calls diskfs_file_update +(dp, 1) (as does diskfs_truncate, diskfs_direnter_hard, and +diskfs_dirrewrite_hard). diskfs_file_update then calls pager_sync on +the pager, which thus writes back the whole ext2fs pager! + +This sounds a bit excessive to me, an unlink could just record it in +memory and actually sync later. Also, the wait flag is set, so we +really waits for all I/Os, which basically means strictly serializing +file removals: remove one file, wait for the disk to have done it +(~10ms), remove the next one, etc. I guess this is for safety reasons +against crashes, but isn't the sync option there for such kind of diff --git a/open_issues/rpc_to_self_with_rendez-vous_leading_to_duplicate_port_destroy.mdwn b/open_issues/rpc_to_self_with_rendez-vous_leading_to_duplicate_port_destroy.mdwn new file mode 100644 index 00000000..9db92250 --- /dev/null +++ b/open_issues/rpc_to_self_with_rendez-vous_leading_to_duplicate_port_destroy.mdwn @@ -0,0 +1,163 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!tag open_issue_hurd]] + +[RPC to self with rendez-vous leading to duplicate port +destroy](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00045.html) + +IRC, freenode, #hurd, 2011-03-14 + + <antrik> youpi: I wonder, why does the root FS call diskfs_S_dir_lookup() + at all?... + <youpi> errr, because a client asked for it? + <youpi> (problem with RPCs is you can't easily know where they come from :) + ) + <youpi> (especially when it's the root fs...) + <antrik> ah, it's about a client request... didn't see that + <youpi> well, I just said "is called", yes + <antrik> I do not really understand though why it tries to reauthenticate + against itself... + <antrik> I fear my memory of the lookup mechanism grew a bit dim + <youpi> see the source + <youpi> it's about a translated entry + <antrik> (and I never fully understood some aspects anyways...) + <youpi> it needs to start the translated entry as another user, possibly + <antrik> yes, but a translated entry normally would be served by *another* + process?... + <youpi> sure, but ext2fs has to prepare it + <youpi> thus reauthenticate to prepare the correct set of rights + <antrik> prepare what? + <youpi> rights + <youpi> so the process is not root, doesn't have / opened as root, etc. + <antrik> rights for what? + <youpi> err, about everything + <antrik> IIRC the reauthentication is done by the parent FS on the port to + the *translated* node + <antrik> and the translated node should be a different process?... + <youpi> that's not what I read in the source + <youpi> fshelp_fetch_root + <youpi> ports[INIT_PORT_CRDIR] = reauth (getcrdir ()); + <youpi> here, getcrdir() returns ext2fs itself + <antrik> well, perhaps the issue is that I have no idea what + fshelp_fetch_root() does, nor why it is called here... + <youpi> it notably starts the translator that dir_lookup is looking at, if + needed + <youpi> possibly as a different user, thus reauthentication of CRDIR + <antrik> so this is about a port that is passed to the translator being + started? + <youpi> no + <youpi> well, depends on what you mean by "port" + <youpi> it's about reauthenticating a port to be passed to the translator + being started + <youpi> and for that a rendez-vous port is needed for the reauthentication + <youpi> and that's the one at stake + <antrik> yeah, I meant the port that is reauthenticated + <antrik> what is CRDIR? + <youpi> current root dir ... + <antrik> so the parent translator passes it's own root dir to the child + translator; and the issue is that for the root FS the root dir points to + the root FS itself... + <youpi> yes + <antrik> OK, that makes sense + <youpi> (but that's only one example, rgrep mach_port_destroy hurd/ show + other potential issues) + <antrik> well, that's actually what I wanted to mention next... why is the + rendez-vous port destroyed, instead of just deallocating the port right + and letting reference counting to it's thing?... + <antrik> do its thing + <youpi> "just to make sure" I guess + <antrik> it's pretty obvious that this will cause trouble for any RPC + referencing itself... + <youpi> well, follow-up with that on the list + <youpi> with roland/tb in CC + <youpi> only they would know any real reason for destroy + <youpi> btw, if you knew how we could make _hurd_select()'s raw __mach_msg + call be interruptible by signals, that'll permit to fix sudo + <youpi> (damn, I need sleep, my tenses are all wrong) + <antrik> BTW, does this cause any actual trouble?... + <antrik> I don't know much about interruption... cfhammer might have a + better idea, he look into that stuff quite a bit AIUI + <antrik> looked + <antrik> (hehe, it's not only your tenses... guess there's something in the + ether ;-) ) + <youpi> it makes sudo, mailq, etc. fail sometimes + <antrik> I mean the rendez-vous thing + <youpi> that's it, yes + <youpi> sudo etc. fail at least due to this + <antrik> so these are two different problems that both affect sudo? + <antrik> (rendez-vous and interruption I mean) + <youpi> yes + <youpi> with my patch the buildds have much fewer issues, but still some + <youpi> (my interrupt-related patch) + <youpi> I'm installing a s/destroy/deallocate/ version of ext2fs on the + buildds, we'll see how it behaves + <youpi> (it fixes my testcase at least) + <antrik> interrupt-related patch? + <antrik> only thing interrupt-related I remember was the reauthentication + race... + <youpi> that's what I mean + <antrik> well, cfhammer investigated this is quite some depth, explaining + quite well why the race is only mitigated but still exists... problem is + that we didn't know how to fix it properly + <antrik> because nobody seems to understand the cancellation code, except + perhaps for Roland and Thomas + <antrik> (and I'm not even entirely sure about them :-) ) + <antrik> I think his findings and our conclusions are documented on the + ML... + <youpi> by "much fewer issues", I mean that some of the symptoms have + disappeared, others haven't + <antrik> BTW, couldn't the rendez-vous thing be worked around by simply + ignoring the errors from the failing deallocate?... + <youpi> no, failing deallocate are actually dangerous + <antrik> why? + <youpi> since the name might have been reused for something else in the + meanwhile + <youpi> that's the whole point of the warning I had added in the kernel + itself + <antrik> I see + <youpi> such things really deserve tracking, since they can have any kind + of consequence + <antrik> does Mach try to reuse names quickly, rather than only after + wrapping around?... + <youpi> it seems to + <antrik> OK, then this is a serious problem indeed + <youpi> (note: I rarely divine issues when there aren't actual frequent + symptoms :) ) + <antrik> well, the problem with the warning is that it only shows in the + cases that do *not* cause a problem... so it's hard to associate them + with any specific issues + <youpi> well, most of the time the port is not reused quickly enough + <youpi> so in most case it shows up more often than causing problem + +IRC, freenode, #hurd, 2011-03-14 + + <youpi> ok, mach_port_deallocate actually can't be used + <youpi> since mach_reply_port() returns a receive right, not a send right + * youpi guesses he will really have to manage to understand all that port + stuff completely + <antrik> oh, right + <antrik> youpi: hm... now I'm confused though. if one client holds a + receive right, the other client (or in this case the same process) should + have a send or send-once right -- these should *not* share the same name + in my understanding + <antrik> destroying the receive right should turn the send right into a + dead name + <antrik> so unless I'm missing something, the destroy shouldn't be a + problem, and there must be something else going wrong + <antrik> hm... actually I'm probably wrong + <antrik> yeah, definitely wrong. receive rights and "ordinary" send rights + share the name. only send-once rights are special + <antrik> I wonder whether the problem could be worked around by using a + send-once right... + <antrik> mach_port_mod_refs(mach_task_self(), name, + MACH_PORT_RIGHT_RECEIVE, -1) can be used to deallocate only the receive + right + <antrik> oh, you already figured that out :-) diff --git a/open_issues/secure_file_descriptor_handling.mdwn b/open_issues/secure_file_descriptor_handling.mdwn index 1a514e69..45e983a7 100644 --- a/open_issues/secure_file_descriptor_handling.mdwn +++ b/open_issues/secure_file_descriptor_handling.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -12,7 +12,8 @@ License|/fdl]]."]]"""]] `O_CLOEXEC`, `dup3` et al.; see <http://udrepper.livejournal.com/20407.html>. [[tschwinge]] once worked -on this, posted patches to libc-alpha. This works needs to be resumed +on this, posted patches to [[mailing_lists/libc-alpha]]. This works needs to +be resumed and finished. --- diff --git a/open_issues/sync_but_still_unclean_filesystem.mdwn b/open_issues/sync_but_still_unclean_filesystem.mdwn index f1fbb4e0..83c7951e 100644 --- a/open_issues/sync_but_still_unclean_filesystem.mdwn +++ b/open_issues/sync_but_still_unclean_filesystem.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -10,9 +10,19 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach open_issue_hurd]] +Also filed as [[!GNU_Savannah_bug 29292]]. + \#hurd, 2010, end of May / beginning of June [runnign sync, but sill unclean filesystem at next boot] - <slpz> guillem: when libpager syncs an object, it sends an m_o_lock_request and waits (if the synchronous argument was specified) for a m_o_lock_completed. But m_o_lock_completed only means that dirty pages have been sent to the translator, and this one still needs to write them to the backing storage - <slpz> guillem: there's no problem if sync() returns before actually writting the changes to disk, but this also happens when shutting down the translator - <slpz> guillem: in theory, locking mechanisms in libpager should prevent this from happening by keeping track of write operations, but this seems to fail in some situations + <slpz> guillem: when libpager syncs an object, it sends an m_o_lock_request + and waits (if the synchronous argument was specified) for a + m_o_lock_completed. But m_o_lock_completed only means that dirty pages + have been sent to the translator, and this one still needs to write them + to the backing storage + <slpz> guillem: there's no problem if sync() returns before actually + writting the changes to disk, but this also happens when shutting down + the translator + <slpz> guillem: in theory, locking mechanisms in libpager should prevent + this from happening by keeping track of write operations, but this seems + to fail in some situations diff --git a/open_issues/system_initialization.mdwn b/open_issues/system_initialization.mdwn new file mode 100644 index 00000000..9048b615 --- /dev/null +++ b/open_issues/system_initialization.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, freenode, #hurd, 2011-03-30 + + <kilobug> init=/bin/sh hack doesn't work for GNU/Hurd ? + <antrik> kilobug: I don't think you can override init on Hurd. the init + server is actually involved in bootstrapping part of the system core + <antrik> at some point we discussed the possibility to reduce the Hurd init + server to *only* do that, and then pass on to standard sysv init... with + that it could actually work + +--- + + * [[systemd]], etc. diff --git a/open_issues/unit_testing.mdwn b/open_issues/unit_testing.mdwn index 1cf7cfb8..a3dd9c18 100644 --- a/open_issues/unit_testing.mdwn +++ b/open_issues/unit_testing.mdwn @@ -8,6 +8,11 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] +This task may be suitable for [[community/GSoC]]: +[[community/gsoc/project_ideas/testing_framework]] + +--- + A collection of thoughts with respect to unit testing. We definitely want to add unit test suites to our code base. @@ -27,6 +32,14 @@ abandoned). * The [[glibc_testsuite]] has a home-grown system (Makefile-based), likewise does the [[Open_POSIX_Test_Suite]]. + * [Kyua](http://code.google.com/p/kyua/) (and its predecessor [ATF](http://www.NetBSD.org/~jmmv/atf/)). + + * Primarily used by NetBSD as its testing framework; FreeBSD is in the process of adopting it. + + * Provides bindings to write tests in C, C++ and POSIX shell. Lua is planned. + + * Builds and runs on many different Unix-based operating systems. + * [check](http://check.sourceforge.net/) * used by some GNU packages, for example GNU PDF (Jose E. Marchesi) @@ -54,6 +67,8 @@ abandoned). Developers*](http://lwn.net/Articles/412302/) by Steven Rostedt, 2010-10-28. [v2](http://lwn.net/Articles/414064/), 2010-11-08. + * <http://autotest.kernel.org/wiki/WhitePaper> + # Related @@ -66,3 +81,14 @@ abandoned). testing, too? * <http://ltp.sourceforge.net/> + + * [LaBrea](https://github.com/dustin/labrea/wiki), or similar tools can be + used for modelling certain aspects of system behavior (long response times, + for example). + + +# Discussion + +See the [[GSoC project idea|community/gsoc/project_ideas/testing_framework]]'s +[[discussion +subpage|community/gsoc/project_ideas/testing_framework/discussion]]. diff --git a/public_hurd_boxen.mdwn b/public_hurd_boxen.mdwn index f81f46a6..33fe5cbc 100644 --- a/public_hurd_boxen.mdwn +++ b/public_hurd_boxen.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 2010 Free Software +[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -9,7 +9,14 @@ 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]]."]]"""]] -Here are some Hurd boxes that users have made available to the public: +[[!tag stable_URL]] + +There are GNU/Hurd boxes that we're offering shell accounts on. These are +generally available for everyone interested in [[contributing]], or just having +a look at a GNU/Hurd system. + +An alternative to online shell access may be using a [[QEMU +image|hurd/running/qemu]]. [[!table class="table_style_1" data=""" "Hoster","Name","Distribution","Machine Specs","Comments" @@ -21,10 +28,11 @@ Here are some Hurd boxes that users have made available to the public: "[[bddebian]]","goober","Debian GNU/Hurd","?" "[[bddebian]]","grubber","Debian GNU/Hurd","Celeron 2.2 GHz; 554 MiB","Xen domU on [[zenhost]]; for experimental stuff" "[[bddebian]]","[[zenhost]]","Debian GNU/Linux","Celeron 2.2 GHz","Xen dom0 for several hosts" +"Debian","[strauss.debian.net](http://strauss.debian.net/ssh)","Debian GNU/Hurd",,"all Debian Developers have access" """]] To request an account on the *[[bddebian]]* machines either contact -*bddebian* or *tschwinge* (other people might also be able to help) in [[IRC]] +*tschwinge* (other people might also be able to help) in [[IRC]] or send email to <hurd-shell-account@gnu.org> (please include your desired user name and public SSH key). Also use these contact addresses for requesting support with respect to software installations, etc. @@ -33,8 +41,10 @@ addresses for requesting support with respect to software installations, etc. For easy access, you should append your public SSH key(s) to `~/.ssh/authorized_keys` on the remote machine. -Also, add the following stanza to `~/.ssh/config` of the machine you're -connecting from: +Also, add the [[!toggle id=bddebian_ssh_config text="following stanza"]] to +`~/.ssh/config` file of the machine you're connecting from. + +[[!toggleable id=bddebian_ssh_config text=""" Host blubber.bddebian.com blubber HostName blubber.bddebian.com @@ -74,3 +84,5 @@ connecting from: The `CheckHostIP` statement is for not having to worry about the machines's IP addresses changing (due to being behind a dial-up connection). + +"""]] diff --git a/shortcuts.mdwn b/shortcuts.mdwn index bd4a7ee3..145f5af8 100644 --- a/shortcuts.mdwn +++ b/shortcuts.mdwn @@ -15,7 +15,7 @@ This page controls what shortcut links the wiki supports. * [[!shortcut name=archive url="http://web.archive.org/*/%S"]] * [[!shortcut name=gmap url="http://maps.google.com/maps?q=%s"]] * [[!shortcut name=gmsg url="http://groups.google.com/groups?selm=%s"]] -* [[!shortcut name=wikipedia url="http://en.wikipedia.org/wiki/%s"]] +* [[!shortcut name=wikipedia url="http://en.wikipedia.org/wiki/%S"]] * [[!shortcut name=wikitravel url="http://wikitravel.org/en/%s"]] * [[!shortcut name=wiktionary url="http://en.wiktionary.org/wiki/%s"]] * [[!shortcut name=debbug url="http://bugs.debian.org/%S" desc="Debian bug #%s"]] diff --git a/sidebar.mdwn b/sidebar.mdwn index d283436b..f398820a 100644 --- a/sidebar.mdwn +++ b/sidebar.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -11,12 +11,26 @@ is included in the section entitled Welcome to... [[!img /logo/boxes-redrawn.png link=/logo]] ... the GNU Hurd! +--- + +[[!template id=highlight text="""**Breaking News** + +--- + +The **Google Summer of Code 2011** is on! If you're a student, consider +applying for a GNU Hurd project -- details to be found on our +*[[community/GSoC]] page*."""]] + +--- * **[[Home|/index]]** * **[[Community]]** + * **[[Contributing]]** + * *[[Public_Hurd_Boxen]]* + * *[[QEMU Images|hurd/running/qemu]]* + * *[[Getting Help]]* + * *[[Open Issues]]* * **[[Documentation]]** * *[[FAQ]]* - * **[[Getting Help]]** - * **[[Open Issues]]** --- diff --git a/systemtap.mdwn b/systemtap.mdwn new file mode 100644 index 00000000..ba64c0d4 --- /dev/null +++ b/systemtap.mdwn @@ -0,0 +1,34 @@ +[[!meta copyright="Copyright © 2011 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="SystemTap"]] + +[[!tag open_issue_hurd open_issue_gnumach]] + +# Overview + + * {{$wielaard_fosdem_2010}} + + +# Related + + * [[community/gsoc/project_ideas/dtrace]] + + * [[LTTng]] + + +[[!ymlfront data=""" + +wielaard_fosdem_2010: + + "[*Interview with Mark + Wielaard*](http://fosdem.org/2010/interview/mark-wielaard) for FOSDEM 2010" + +"""]] diff --git a/templates/highlight.mdwn b/templates/highlight.mdwn new file mode 100644 index 00000000..c8da1377 --- /dev/null +++ b/templates/highlight.mdwn @@ -0,0 +1,3 @@ +<div class="infobox"> +<TMPL_VAR text> +</div> diff --git a/topgit.mdwn b/topgit.mdwn index b71038ec..fb374337 100644 --- a/topgit.mdwn +++ b/topgit.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -30,7 +30,8 @@ development branches, for example [[source_repositories/binutils]] or # Running it on GNU/Hurd Nothing special to that, technically, *only* that our [[I/O system's (non-) -performance|open_issues/performance/io_system]] will render this unbearably +performance|community/gsoc/project_ideas/disk_io_performance]] will render this +unbearably slow for anything but simple test cases. So don't try to run it on the [[GCC]] or [[glibc]] repositories. Talk to [[tschwinge]] about how he's using it on a GNU/Linux machine and push the resulting trees to GNU/Hurd systems. diff --git a/user/El_Dream_Machine.mdwn b/user/El_Dream_Machine.mdwn index f86d4bfd..ac3a0cfc 100644 --- a/user/El_Dream_Machine.mdwn +++ b/user/El_Dream_Machine.mdwn @@ -8,19 +8,29 @@ 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]]."]]"""]] +**January 13, 2011** - My story comics on the Hurd continues. I think I can introduce you to page 2 in a month. -I just try to become an end user of The Hurd. In 2004, I was able to install K9 on an old computer. +**January 11, 2011** - The goal was to install the Hurd in VirtualBox... +It happened on january,7 2011, a very nice day... Thanks to [http://www.paranoiaque.fr](http://www.paranoiaque.fr) for [the *Hurd.vdi* machine.](http://www.paranoiaque.fr/Hurd.vdi.tar.lzma) + +[A testimony](http://www.sites.google.com/site/hurdexperiences/en-hurd-vdi-tar-lzma) of this install and a video capture [Hurd operating.](http://www.dailymotion.com/video/xgl3nr_hurd-screenscat-ffmpeg-01_webcam) + +**October 14, 2010** - Here's the [french version.](http://art9libre.tuxfamily.org/gaetan/TheCallOfTheHurd-01-fr-png.jpg) + +**October 13, 2010** - Page 1 out ! The beginning of the [the comics is here :](http://eldreammachine.free.fr/gaetan/TheCallOfTheHurd-01.jpg) +Hope it will pleased for you. + +**October 3, 2010** - I just try to become an end user of The Hurd. In 2004, I was able to install K9 on an old computer. These times, my goal is to install it on my laptop (maybe with crosshurd or with a lzma image for virtualbox, or any other way...) Also, I'm currently working on a comics'The Call Of The Hurd'. It's free licensed cc-by-sa/Copyleft Art Libre. 1st page will be done before the end of the year I think (I look for good quality). -And it's nice to be here :) -Page 1 out ! The beginning of the [the comics is here :](http://eldreammachine.free.fr/gaetan/TheCallOfTheHurd-01.jpg) -Hope it will pleased for you. -Here's the [french version.](http://art9libre.tuxfamily.org/gaetan/TheCallOfTheHurd-01-fr-png.jpg) + + + diff --git a/user/Erkan-Yilmaz.mdwn b/user/Erkan-Yilmaz.mdwn new file mode 100644 index 00000000..aea4e7ff --- /dev/null +++ b/user/Erkan-Yilmaz.mdwn @@ -0,0 +1 @@ +see <http://wiki.archhurd.org/wiki/User:Erkan_Yilmaz> diff --git a/user/Etenil.mdwn b/user/Etenil.mdwn new file mode 100644 index 00000000..a1a3373b --- /dev/null +++ b/user/Etenil.mdwn @@ -0,0 +1,40 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!toc]] + +## Current task + +Implement clustered paging in GNU Mach + +- - - + +## What the problem is +In Mach, memory access is ensured by the VM, an abstraction in the kernel. The VM is mapped by pages, which size is arbitrary and defined based on hardware specs. A single block of memory can then span over many pages, i.e. a file on a file system can represent a lot of pages. + +When a process attempts to access pages that don't reside in the physical memory (RAM), the MMU detects this and triggers a page fault. Page faults are then handled and the kernel calls down the process associated with the memory pages on a *one by one basis*. + +This is where the problem lies. Hard disks are inherently efficient at sequentially writing large chunks of data whereas they cope badly with random access, plus the kernel wastes time writing/reading a page and handling the next page. All of these make for slow I/O in Mach. + +## Solutions +There are a couple of ways I could think of to solve this problem. Pages could be enlarged, but that would cause a lot more problems. Or pages must be handled by groups instead of one by one. This means the changes will also need to be applied in the way user-space processes talk to Mach. + +## What's already been done +[[user/KAM]] has already made a patch that provides basic page clustering. I have yet to understand it completely, but there are troubling changes in the patch, most notably the removal of continuations in *vm_fault* and *vm_fault_page*. + +So far, what I can tell is that KAM seems to have modified the memory objects in Mach so that they handle clusters of pages. + +## What I intend to do +Starting from KAM's work, I'll try and at least proxy the current behaviour in the kernel so as to keep backwards compatibility, at least until all user-space processes are converted (maybe some sort of deprecation warning would help porting). I'll also need to modify ext2fs to make it use the clustered paging feature, hopefully it'll improve performance quite a bit. + +## Problems +As *braunr* and *antrik* pointed out on IRC, I seriously lack knowledge about kernel programming, and this is quite a big task. I also don't fully understand the inner workings of the kernel yet, even though *braunr* helped me a lot to understand the VM and page handling. + +I'll do what I can and keep maintaining this page so others may pickup where I left if I were to give up. diff --git a/user/jkoenig.mdwn b/user/jkoenig.mdwn index 247d61cb..0b9f9f7d 100644 --- a/user/jkoenig.mdwn +++ b/user/jkoenig.mdwn @@ -123,8 +123,8 @@ installer kindof works, with documented manual intervention required** (2010-06-25) * (./) sent as patches as requested (2010-07-08) - * backport any additional changes onto the debian branch - * hijack [[!debbug 323670]] and submit my patches + * (./) backport any additional changes onto the debian branch + * (./) hijack [[!debbug 323670]] and submit my patches * **aptitude**: * Currently broken on hurd-i386: @@ -220,7 +220,7 @@ installer works but it's still somewhat ugly and broken** * Fix the hurd console for fonts with 16 pixels wide glyphs (ie. handle the 8-wide glyph in there correclty) * Support double-width glyphs (2010-07-24) - * {X} However the reduced font can't be loaded yet, + * (./) However the reduced font can't be loaded yet, so make installer/build/Makefile ship the whole `/usr/src/unifont.bgf` as `/usr/share/hurd/vga-system.bgf`. @@ -259,7 +259,7 @@ installer works but it's still somewhat ugly and broken** * debian/rules: set `partman/mount_style` to `traditional` on Hurd. * finish.d/create\_fstab\_header: add a Hurd case. -* **rootskel**: FTBFS on Hurd and other quirks +* (./) **rootskel**: FTBFS on Hurd and other quirks (to be fixed very soon) * **d-i/installer/build**: (expected soon) @@ -275,7 +275,7 @@ installer works but it's still somewhat ugly and broken** * Maybe settrans could be made to accept -o/--owner and -p/--perm, to set the permissions for the underlying node? -* Silence the "no kernel" warning somehow. +* (./) Silence the "no kernel" warning somehow. * Investigate the wget/libc/pfinet/whatever bug which corrupts Packages.gz, see the IRC log for 2010-07-23, around 1am UTC+0200 @@ -312,7 +312,7 @@ installer works but it's still somewhat ugly and broken** test library reduction, make it copy the ld.so -> ld.so.1 symlink. -* hurd console fonts +* (./) hurd console fonts **Milestone (expected 2010-07-19): it works great and it's beautiful** |