diff options
Diffstat (limited to 'community')
72 files changed, 3871 insertions, 1507 deletions
diff --git a/community/communication.mdwn b/community/communication.mdwn index d2eccceb..33941000 100644 --- a/community/communication.mdwn +++ b/community/communication.mdwn @@ -1,12 +1,12 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] The GNU Hurd community comprises of a crowd of people living in different areas of the whole world. For that, having regular working-[[meetings]] -- usually @@ -14,7 +14,7 @@ one of the more productive ways of coordination works -- is not easily possible. The two key resources most often used for communication are the Debian and GNU -[[mailing_lists]], as well as [[IRC]]. +[[mailing lists]], as well as [[IRC]]. These are measures of communication that work (compared to, e.g., a one-to-one telephone call) one-to-many. It is important to not send email only to a @@ -31,10 +31,10 @@ discussing with single developers. And always use *reply to all* instead of *reply* when answering to email. If you're interested in keeping up with current events and taking part in -discussions, you'll want to join the [[mailing_lists/bug-hurd]] mailing list or +discussions, you'll want to join the [[mailing lists/bug-hurd]] mailing list or have a look at its [archives](http://lists.gnu.org/archive/html/bug-hurd/). Even if you're a beginner (we've also been, and some of us even still remember), don't hesitate to make the first move and make active use of these resources. But -- of course -- please try to adhere to the conventions as -described on the [[mailing_lists]] and [[IRC]] pages. +described on the [[mailing lists]] and [[IRC]] pages. diff --git a/community/facebook.mdwn b/community/facebook.mdwn index b5340224..27893cf9 100644 --- a/community/facebook.mdwn +++ b/community/facebook.mdwn @@ -1,12 +1,12 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] There is [a Facebook group for the Hurd](http://www.facebook.com/group.php?gid=5141429597). If you're on Facebook, join it and say hello. diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn index aa27fd4f..2ce92d19 100644 --- a/community/gsoc.mdwn +++ b/community/gsoc.mdwn @@ -1,34 +1,63 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] -# 2009 +[[!meta title="Google Summer of Code"]] -The Google Summer of Code is currently in the planning phase. +# 2010 +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). -# History + * *[[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).) -2006 and 2007 we participated in GSoC under the umbrella of the GNU project, -getting one slot each year. + * *[[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]].) -<!-- TODO. Extend. --> + * *[[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]].) -In 2008 we successfully participated on our own, no longer within the GNU -project. Read about our five students' success on the [[2008]] page. +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). +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. -# Joining in +# History + +In 2006 and [[2007]], we participated in GSoC under the umbrella of the GNU +project, +getting one slot each year. -If these successes got you interested in contributing some larger part yourself - -in your free time or maybe in next years Google Summer of Code - -please have a look at our [[project_ideas]] and read up about [[contributing]]. +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. -Also, feel free to ask your questions at one of our -[[regular_IRC_meetings|IRC#regular_meetings]]. +The next year, we participated under the GNU umbrella with one slot again. +Read about it on the [[2009]] page. diff --git a/community/gsoc/2007.mdwn b/community/gsoc/2007.mdwn new file mode 100644 index 00000000..fa22f785 --- /dev/null +++ b/community/gsoc/2007.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2008, 2009, 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]]."]]"""]] + +Participated under the umbrella of the GNU project, getting one slot: + + * Carl Fredrik Hammar has been working on [[hurd/libchannel]]; [Google's + project + page](http://code.google.com/soc/2007/gnu/appinfo.html?csaid=44FB3FD69C665A08). diff --git a/community/gsoc/2008.mdwn b/community/gsoc/2008.mdwn index 5bb5f314..d994f2b0 100644 --- a/community/gsoc/2008.mdwn +++ b/community/gsoc/2008.mdwn @@ -1,12 +1,12 @@ -[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] The GNU Hurd project has successfully participated in the [Google Summer of Code 2008](http://code.google.com/soc/2008/hurd/about.html)! @@ -23,7 +23,8 @@ did a great job! vacation). The project however was hampered by various misunderstandings, wrong assumptions, and several major redesigns during the course of the work -- which is probably more our fault than the student's. In the end, though, he - completed nsmux (the main namespace proxy handling the magic filename + completed [[hurd/translator/nsmux]] (the main namespace proxy handling the + magic filename lookups, running dynamic translators on demand); he still works on finishing the translator stack filtering necessary to implement some of the desired functionality (accessing files while skipping existing translators). diff --git a/community/gsoc/2008/minutes-2008-04-25.mdwn b/community/gsoc/2008/minutes-2008-04-25.mdwn index 3f2c0313..4c2039d4 100644 --- a/community/gsoc/2008/minutes-2008-04-25.mdwn +++ b/community/gsoc/2008/minutes-2008-04-25.mdwn @@ -1,12 +1,12 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] - People agreed that some small projects should be done to during the bonding period: ideas that floated around were fixing some of the build failures or diff --git a/community/gsoc/2008/minutes-2008-05-02.mdwn b/community/gsoc/2008/minutes-2008-05-02.mdwn index 9c99a8e7..1dc99abe 100644 --- a/community/gsoc/2008/minutes-2008-05-02.mdwn +++ b/community/gsoc/2008/minutes-2008-05-02.mdwn @@ -1,12 +1,12 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] - madrazr wanted a wiki to keep track of progress. antrik suggested: http://www.bddebian.com/~wiki/community/gsoc/ and that everyone use diff --git a/community/gsoc/2008/minutes-2008-05-16.mdwn b/community/gsoc/2008/minutes-2008-05-16.mdwn index 8adb838c..7e7da845 100644 --- a/community/gsoc/2008/minutes-2008-05-16.mdwn +++ b/community/gsoc/2008/minutes-2008-05-16.mdwn @@ -1,12 +1,12 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] * **madrazr** said that web commits for the wiki stall forever (more than half an hour); the reason is unknown. **antrik** said that it is not much of a problem if the problems with git access are solved. diff --git a/community/gsoc/2009.mdwn b/community/gsoc/2009.mdwn new file mode 100644 index 00000000..6efeb839 --- /dev/null +++ b/community/gsoc/2009.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2008, 2009, 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="Google Summer of Code 2009"]] + +The GNU Hurd project unfortunately was not in the list of accepted +mentoring organizations. + +We did get one slot from the GNU project's. + +The applications have been evaluated and the following student has +been accepted: + + * [[Sergiu Ivanov|scolobb]] -- working on a *[[VFS-style union + mount|hurd/translator/unionmount]]* functionality; [Google's project + page](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2009/karlberry/t124022551214). diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index be6867bb..8e672af1 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -1,161 +1,141 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] -* What is your Organization's Name? +* Organization Name: GNU Hurd -* What is your Organization's Homepage? +* Description: + +The mission of the Hurd project is to create a general-purpose kernel suitable +for the [GNU operating system](http://gnu.org), which is viable for everyday +use, and gives users and programs as much control over their computing +environment as possible. + +In traditional operating systems, most system functionality is provided by the +kernel, and thus cannot be easily modified. The Hurd on the other hand -- +following the GNU spirit of giving users more control over the software they +use -- implements a unique design, which makes it feasible to change almost +everything, down to the core features of the system. + +While on other systems, such changes would require a lot of effort and special +privileges to rebuild the system core, with the Hurd this is not necessary: the +extensible architecture enables users (or applications) to simply modify their +local system environment at any time, while leaving the rest of the system in +place. + +The most obvious example is the completely decentralized VFS mechanism: it can +be extended in almost any imaginable way, simply by setting up suitable server +processes (translators). Not only does this empower users, but also it helps +application development: desktop environments such as GNOME for example, when +making use of these possibilities, wouldn't need to create their own VFS +mechanism -- they simply could extend the system VFS to suit their needs. + +One major element of the design which enables this extensibility, is the use of +a true multiserver microkernel architecture. The Hurd is quite unique in being +the only general-purpose multiserver microkernel system in development today, +that is nearly ready for everyday use, and offering almost perfect UNIX +compatibility. (About 65% of all packages in the Debian repository are +available for the Hurd.) The "general-purpose" and "everyday use" bits are +decisive here: all other existing true microkernel systems are either research +projects not nearly complete enough for actual use; or limited to embedded +systems and other special purposes; or both. + +Marcus Brinkmann and Neal Walfield, while working on improvements to the Hurd +design, pushed at the forefront of microkernel operating system research. They +worked with the most distinguished researchers in this field from the +[L4](http://l4hq.org/) and +[EROS](http://www.eros-os.org/eros.html)/[Coyotos](http://www.coyotos.org/) +microkernel operating system groups, and published a couple of [research +papers](http://walfield.org/) as well in this process. + +* Home Page: http://hurd.gnu.org -* Describe your organization. - -The Hurd project is a loose community of people sharing a common interest in -developing the Hurd kernel, which is the official kernel of the [GNU operating -system](http://gnu.org). - -When the Hurd was originally started in 1990, it was the last missing major -component for a complete GNU system. Today Linux and other free kernels are -available to fill this gap, and the combination of GNU and Linux (often -[incorrectly](http://www.gnu.org/gnu/why-gnu-linux.html) called just "Linux") -is in wide use. However, the Hurd is still interesting due to its unique -design, better fitting the GNU philosophy than traditional monolithic kernels -like Linux. - -The GNU GPL guarantees that all users of software published under this license -get the legal permission to adapt the software they are using according to -their wishes, and also get the source code and other tools necessary to put -this permission to use. However, in traditional operating systems, the kernel -and related low-level system software are protected from normal users, and -cannot be easily modified; only the system administrator has power over these. - -The Hurd offers special mechanisms that allow any user to change almost all of -the system functionality he uses, without affecting the rest of the system, and -thus easily (at runtime) and without any special permissions. - -This ability to run subenvironments more or less independant from the rest of -the system, can be classified as a very sophisticated [lightweight -virtualization](http://tri-ceps.blogspot.com/2007/10/advanced-lightweight-virtualization.html) -approach. - -To offer these possibilities, the Hurd uses a true multiserver microkernel -architecture. That makes it quite unique: The Hurd is the only general-purpose -multiserver microkernel system in development today that is nearly ready for -everyday use, and offering almost perfect UNIX compatibility. (More than half -of the packages in the Debian repository are available for the Hurd.) All other -existing true microkernel systems are either research projects not nearly -complete enough for actual use, or limited to embedded systems and other -special purposes, or both. - -Marcus Brinkmann and Neal Walfield from the Hurd project are working at the -bleeding edge of microkernel operating system research. They have been in -contact with the most distinguished researchers in that field from the -[L4](http://l4hq.org/) and -[EROS](http://www.eros-os.org/eros.html)/[Coyotos](http://www.coyotos.org/) -microkernel operating system groups, and have written a couple of [research -papers](http://walfield.org/). +* Main Organization License: -* Why is your organization applying to participate in GSoC 2009? What do you -hope to gain by participating? +GNU General Public License (GPL) -The primary goal of course is to find and introduce new long-term contributors -to the project. +* Why is your organization applying to participate in GSoC 2010? What do you hope to gain by participating? -Aside from that, it is a way to make progress with tasks that require an amount of -focused work, that is hard to do for volunteers working in their spare time -only. +The primary goal of our participation is of course to find and introduce new long-term contributors +to the Hurd. We are trying to optimise for this in our student selection +process, our mentoring approach, and our choice of project ideas. -Also it is a good possibility to get valuable input from new people, as well as -spreading technical and other knowledge about the Hurd among actual and -potential contributors. More generally, participation should help raising -awareness among people who might know about the existence of the Hurd, but -otherwise having very little idea what the project is all about, and how its -progress is. +The mentor-student setup, together with the period of focused work during the +summer session, also offer a unique opportunity for kick-starting innovative +new projects apart from mainline development, which are hard to fit in among +the normal day-to-day development work. This is particularily important for the +Hurd, as innovative uses are crucial to show the benefits of the unique +architecture. Several such projects came into being through the GSoC program +over the past years. -Last but not least, we hope the participation will have a positive effect on -our community -- new impulses, increased communication etc. +Last but not least, GSoC participation always yields a lot of valuable input from new people, and helps +spreading technical and other knowledge about the Hurd among actual and +potential contributors. It has a very positive effect on +our community -- new impulses, increased communication, etc. -* Did your organization participate in past GSoCs? If so, please summarize -your involvement and the successes and challenges of your participation. +* Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. In 2006 and 2007, we participated under the umbrella of the GNU project, getting one slot each year. -The 2006 participation was mostly a failure. After some intitial work -(available in CVS), the student disappeared -- moving to another country and -other personal issues from what we heard. - -The 2007 participation was a considerable success. The student was very bright -and dedicated. We got some code, as well as a lot of ideas, which we continued -discussing after the end of GSoC, and he intends to put into code as well in -the future. - In 2008 we participated as an organisation on our own for the first time. This -turned out extremely beneficial: Not only did it give us much better -possibilities to find and select good students, as we hoped. We also get a lot -more applications, mostly of good or excellent quality. +turned out extremely beneficial: with the better visibility, we got a lot +more applications (more than 20), mostly of good or excellent quality. -We ended up with four slots. (We didn't request more, because we were not sure -whether we would be able to mentor them properly, and generally didn't want to -overdo it on our first "full" participation.) There was also a fifth student, -who worked on his project in spite of not getting a slot. +In 2009, we were rejected as an organisation, so we participated under the GNU +umbrella again. -All five students were pretty successful, most of them completing or almost -completing the original goals -- some even exceeding them. Even our weakest -student, after serious struggling in the beginning, did quite well in the end. +While the 2006 student disappeared midway, in all the later years all of our +students were successful -- even including one who worked on his project in +spite of not getting an official slot. Half of them are regular Hurd contributors now. -Two students are still regularily working on the Hurd -- not as much as we -hoped of course, but probably as much as can be realistically expected... +Selecting the most promising students, as well as suitable mentors, turned out +to be the most tricky part of GSoC participation -- but we learned our lesson +after the first failure: we didn't have any students that didn't meet our +expectations since then, and we also believe our mentoring is exceptionally +good now -- one project that was in serious trouble, turned out well after all, +due to effective mentor intervention. -All in all, the participation was a considerable amount of work, but it was -definitely worth it :-) +* If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006. -* If your organization has not previously participated in GSoC, have you -applied in the past? If so, for what year(s)? +2008: 4/4 --- +(+1 inofficial in 2008) +(under GNU umbrella: 2006: 0/1; 2007: 1/1; 2009: 1/1) -* What license(s) does your project use? +* If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)? -Mostly GPLv2 or later. Some bits are GPLv2 only, and some three-clause BSD. +-- * What is the URL for your ideas page? -[[project_ideas]] +http://www.gnu.org/software/hurd/community/gsoc/project_ideas.html -* What is the main development mailing list or forum for your organization? +* What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2010. If your organization uses more than one list, please make sure to include a description of the list so students know which to use. -bug-hurd@gnu.org, see http://lists.gnu.org/mailman/listinfo/bug-hurd +bug-hurd@gnu.org ( http://lists.gnu.org/mailman/listinfo/bug-hurd ) * What is the main IRC channel for your organization? \#hurd on freenode.net -* Does your organization have an application template you would like to see -students use? If so, please provide it now. +* Does your organization have an application template you would like to see students use? If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2010 site. [[student_application_form]] -* Who will be your backup organization administrator? Please include Google -Account information. - - - -* Who will your mentors be? Please include Google Account information. - -antrik at gmx.net - -* What criteria did you use to select these individuals as mentors? Please be -as specific as possible. +* What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible: The most important criterium is that the person is involved in the project for some time, knowing the ways; so he can actually instruct the student; and if @@ -167,9 +147,9 @@ won't be left on their own with any problems they face. * What is your plan for dealing with disappearing students? -The plan is mostly to avoid that happening in the first place. For that, we -will be particularily careful with the selection of the students: Making sure -that they have no other obligations during that time; that they are motivated +The plan is mostly to avoid that happening in the first place. To this end, we +are particularily careful with selection of students: Making sure +that they have no other major obligations during that time; that they are motivated enough; that they actually have the necessary skills to complete the task; that they fit in our community. @@ -177,49 +157,55 @@ Also, we will make sure that we are constantly in contact with the students -- asking about progress, discussing technical issues, etc. -- so we can act in time if things go wrong. -If a student disappears in spite of that, there is little we can do. Of course +If a student disappears in spite of all this, there is little we can do. Of course we will try to contact him and find out what the problem is; whether the -project can perhaps be scaled down, or at least wrapped up to bring it in a -state where it is useful even if not finished. - -We will also try to limit damage by insisting that students regularily check in -their work, so that we get partial results at least if someone disappears. +project can perhaps be scaled down, or otherwise salvaged, so that the effort +already invested in the student and the project is not wasted. We also try to +make sure that all important design discussions are archieved, and that all +code produced is suitable for upstream inclusion from the beginning -- to allow +others to pick up the project if necessary, without having to start from zero. * What is your plan for dealing with disappearing mentors? As our mentors all have been with the project for some time, the risk of them disappearing is not too big. If one of them disappears nevertheless, it's not a -problem for us: We have enough mentors, and someone else will take over. +problem for us: we have enough mentors, and someone else will take over. We will encourage the students to keep discussions public as much as possible, keeping private conversations with the mentors to a minimum, so the transition should go smoothly. -* What steps will you take to encourage students to interact with your -project's community before, during and after the program? +* What steps will you take to encourage students to interact with your project's community before, during and after the program? We try to make it very clear that we expect the students to get into regular -contact with us before the end of the student selection process, and won't +contact with us early during the student selection process already, and won't consider their applications otherwise. This way we know that the students are able and willing to communicate with us in the first place. -After the selection, the regular contact will be kept up: We require the -students to participate in weekly IRC meetings, where we ask the students -actively about the work they do, problems they face, decisions they take etc. -Furthermore, we will ask them to hang around on IRC most of the time while -working on their projects, so we keep in close contact. +After selection, the regular contact is kept up: we require the +students to participate in IRC meetings up to twice a week, where we ask the students +actively about the work they do, problems they face, decisions they take, etc. +Furthermore, we ask them to be available on IRC while working on their +projects, so we can communicate easily. We also require the students to join our main development mailing list, so any -design questions etc. can be discussed there. We will encourage them to take +design questions, etc. can be discussed there. We encourage them to take part in other conversations, not directly related to their projects, as well. -After the program we continue the regular meetings, still discussing the -projects: The application of the code created, future directions etc. +After the program we continue the regular meetings, discussing the further +development of their original projects; as well as new projects, after the +original ones are done. -* What will you do to ensure that your accepted students stick with the project -after GSoC concludes? +* What will you do to ensure that your accepted students stick with the project after GSoC concludes? -We will try to invite all participating students to a conference afterwards, -where we will discuss the projects, as well as other Hurd-related topics. We -hope this will motivate them to follow up on the work they have done during the +In addition to keeping up the regular IRC meetings, +we try to invite all participating students to meet us at conferences afterwards, +where we discuss the projects, as well as other Hurd-related topics. This should +keep them motivated to follow up on the work they have done during the program, and generally help keeping them involved. + +* Is there anything else you would like to tell the Google Summer of Code program administration team? : + +* Backup Admin (Link ID): + +tschwinge diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index bfd03ba6..ca10c8a2 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -1,1015 +1,108 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under 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 list offers a wide range of tasks: From rather straightforward to pretty -involved ones; from low-level kernel hacking (drivers, VM) to high-level -translators; from fixing bugs, implementing new functionality based on existing -interfaces, to creating totally new mechanisms. - -If you have questions regarding the projects, or if there is more than one that -you are interested in and you are unsure which to choose, don't hesitate to -[[contact_us|communication]]. - -Most project descriptions mention a possible exercise related to the respective -task. Doing this exercise is part of the application process -- the purpose is -to get more familiar with the stuff you will need to complete the project and -with the Hurd community. Contact us if you encounter any difficulties -- we -will assist you with as well as we can :-) - -Please report on the progress you make with the exercise. This allows us to get -a better picture of how well you can cope with the task; as well as how well -you manage the necessary communication with us :-) - -The exercise is part of the application process, but it's perfectly OK if you -do it only after handing in the first version of your application. (The -experience you get with the exercise should help you to further improve your -application afterwards...) In general, don't hesitate too long -- the sooner -you submit your first proposal, the sooner we can give feedback! - -Take a look at our [[application_template|student_application_form]] to get an -idea what your application should contain. - - -## Bindings to Other Programming Languages - -The main idea of the Hurd design is giving users the ability to easily -modify/extend the system's functionality ([[extensible_system|extensibility]]). -This is done by creating [[filesystem_translators|hurd/translator]] and other -kinds of Hurd servers. - -However, in practice this is not as easy as it should, because creating -translators and other servers is quite involved -- the interfaces for doing -that are not exactly simple, and available only for C programs. Being able to -easily create simple translators in RAD languages is highly desirable, to -really be able to reap the advantages of the Hurd architecture. - -Originally Lisp was meant to be the second system language besides C in the GNU -system; but that doesn't mean we are bound to Lisp. Bindings for any popular -high-level language, that helps quickly creating simple programs, are highly -welcome. - -Several approaches are possible when creating such bindings. One way is simply -to provide wrappers to all the available C libraries ([[hurd/libtrivfs]], [[hurd/libnetfs]] -etc.). While this is easy (it requires relatively little consideration), it may -not be the optimal solution. It is preferable to hook in at a lower level, thus -being able te create interfaces that are specially adapted to make good use of -the features available in the respective language. - -These more specialised bindings could hook in at some of the lower level -library interfaces ([[hurd/libports]], [[hurd/glibc]], etc.); use the -[[microkernel/mach/MIG]]-provided [[microkernel/mach/RPC]] stubs directly; or -even create native stubs directly from the interface definitions. - -The task is to create easy to use Hurd bindings for a language of the student's -choice, and some example servers to prove that it works well in practice. This -project will require gaining a very good understanding of the various Hurd -interfaces. Skills in designing nice programming interfaces are a must. - -There has already been some [earlier work on Python -bindings](http://www.sigill.org/files/pytrivfs-20060724-ro-test1.tar.bz2), that -perhaps can be re-used. Also some work on [Perl -bindings](http://www.nongnu.org/hurdextras/#pith) is availabled. - -### Lisp - -Most Lisp implementations provide a Foreign Function Interface (FFI) that -enables the Lisp code to call functions written in another language. -Specifically, most implementations provide an FFI to the C ABI (hence giving -access to C, Fortran and possibly C++). - -Common Lisp has even a portability layer for such FFI, -[CFFI](http://common-lisp.net/project/cffi/), so that you can write bindings -purely in Lisp and use the same binding code on any implementation supported by -CFFI. - -Many Scheme implementation also provide an FFI. [Scheme48](http://www.s48.org/) -is even the implementation used to run scsh, a Scheme shell designed to provide -instant access to POSIX functions. -[Guile](http://www.gnu.org/software/guile/guile.html) is the GNU project's -Scheme implementation, meant to be embeddable and provide access to C. At least -[Gambit](http://dynamo.iro.umontreal.ca/~gambit/), -[Chicken](http://www.call-with-current-continuation.org/), -[Bigloo](http://www-sop.inria.fr/mimosa/fp/Bigloo/) and -[PLT](http://www.plt-scheme.org/) are known to provide an FFI too. - -With respect to the packaging and dependencies, the good news is that Debian -comes handy: 5 Common Lisp implementations are packaged, one of which has -already been ported to Hurd (ECL), and CFFI is also packaged. As far as Scheme -is concerned, 14 [R5RS](http://www.schemers.org/Documents/Standards/R5RS/) -implementations are provided and 1 [R6RS](http://www.r6rs.org/). - -Possible mentors: Pierre THIERRY (nowhere_man) for Common Lisp or Scheme, and perhaps Python - -Exercise: Write some simple program(s) using Hurd-specific interfaces in the -language you intend to work on. For a start, you could try printing the system -uptime. A more advanced task is writing a simple variant of the hello -translator (you can use the existing C imlementation as reference), -implementing only open() and read() calls. Don't only write an implementations -using the existing C libraries (libps, libtrivfs), but also try to work with -the MiG-generated stubs directly. If you are ambitious, you could even try to -write your own stubs... - -*Status*: Flavio Cruz has completed [[Lisp_bindings|flaviocruz]] for GSoC 2008! - - -## Virtualization Using Hurd Mechanisms - -The main idea behind the Hurd design is to allow users to replace almost any -system functionality ([[extensible_system|extensibility]]). Any user can easily -create a subenvironment using some custom [[servers|hurd/translator]] instead -of the default system servers. This can be seen as an -[[advanced_lightweight_virtualization|hurd/virtualization]] mechanism, which -allows implementing all kinds of standard and nonstandard virtualization -scenarios. - -However, though the basic mechanisms are there, currently it's not easy to make -use of these possibilities, because we lack tools to automatically launch the -desired constellations. - -The goal is to create a set of powerful tools for managing at least one -desirable virtualization scenario. One possible starting point could be the -[[hurd/subhurd]]/[[hurd/neighborhurd]] mechanism, which allows a second almost totally -independant instance of the Hurd in parallel to the main one. The current -implementation has serious limitations though. A subhurd can only be started by -root. There are no communication channels between the subhurd and the main one. -There is no mechanism for safe sharing of hardware devices. Fixing this issues -could turn subhurds into a very powerful solution for lightweight -virtualization using so-called logical partitions. (Similar to Linux-vserver, -OpenVZ etc.) - -While subhurd allow creating a complete second system instance, with an own set -of Hurd servers and [[UNIX]] daemons and all, there are also situations where it is -desirable to have a smaller subenvironment, living withing the main system and -using most of its facilities -- similar to a chroot environment. A simple way -to create such a subenvironment with a single command would be very helpful. - -It might be possible to implement (perhaps as a prototype) a wrapper using -existing tools (chroot and [[hurd/translator/unionfs]]); or it might require more specific tools, -like some kind of unionfs-like filesytem proxy that mirrors other parts of the -filesystem, but allows overriding individual locations, in conjuction with -either chroot or some similar mechanism to create a subenvironment with a -different root filesystem. - -It's also desirable to have a mechanism allowing a user to set up such a custom -environment in a way that it will automatically get launched on login -- -practically allowing the user to run a customized operating system in his own -account. - -Yet another interesting scenario would be a subenvironment -- using some kind -of special filesystem proxy again -- in which the user serves as root, being -able to create local sub-users and/or sub-groups. - -This would allow the user to run "dangerous" applications (webbrowser, chat -client etc.) in a confined fashion, allowing it access to only a subset of the -user's files and other resources. (This could be done either using a lot of -groups for individual resources, and lots of users for individual applications; -adding a user to a group would give the corresponding application access to the -corresponding resource -- an advanced [[ACL]] mechanism. Or leave out the groups, -assigning the resources to users instead, and use the Hurd's ability for a -process to have multiple user IDs, to equip individual applications with sets -of user IDs giving them access to the necessary resources -- basically a -[[capability]] mechanism.) - -The student will have to pick (at least) one of the described scenarios -- or -come up with some other one in a similar spirit -- and implement all the tools -(scripts, translators) necessary to make it available to users in an -easy-to-use fashion. While the Hurd by default already offers the necessary -mechanisms for that, these are not perfect and could be further refined for -even better virtualization capabilities. Should need or desire for specific -improvements in that regard come up in the course of this project, implementing -these improvements can be considered part of the task. - -Completing this project will require gaining a very good understanding of the -Hurd architecture and spirit. Previous experience with other virtualization -solutions would be very helpful. - -Possible mentors: Olaf Buddenhagen (antrik) - -Exercise: Make some modification to the "boot" programm used to start subhurds. -(More specific suggestions welcome... :-) ) - -*Status*: Zheng da has has implemented [[network_virtualization|zhengda]] (an -important prerequisite for unprivileged subhurds) for GSoC 2008, along with -various other interesting bits, including a mechanism to override socket -servers; a proc proxy that allows running processes/subenvironments with a -pseudo device master port; and a mechanism to pass arbitrary virtual devices to -a subhurd. He is still working on running subhurds by normal users. - - -## Namspace-based Translator Selection - -The main idea behind the Hurd is to make (almost) all system functionality -user-modifiable ([[extensible_system|extensibility]]). This includes a -user-modifiable filesystem: the whole filesystem is implemented decentrally, by -a set of filesystem servers forming the directory tree together, a -[[hurd/virtual_file_system]]. These filesystem servers are called -[[translators|hurd/translator]], and are the most visible feature of the Hurd. - -The reason they are called translators is because when you set a translator on -a filesystem node, the underlying node(s) are hidden by the translator, but the -translator itself can access them, and present their contents in a different -format -- translate them. A simple example is a -[[gunzip_translator|hurd/translator/storeio]], which can be set on a gzipped -file, and presents a virtual file with the uncompressed contents. Or the other -way around. Or a translator that presents an -[[XML_file_as_a_directory_tree|hurd/translator/xmlfs]]. Or an mbox as a set of -individual files for each mail ([[hurd/translator/mboxfs]]); or ever further -breaking it down into headers, body, attachements... - -This gets even more powerful when translators are used as building blocks for -larger applications: A mail reader for example doesn't need backends for -understanding various mailbox formats anymore. All formats can be parsed by -special translators, and the mail reader gets the data as a uniform, directly -usable filesystem structure. Translators can also be stacked: If you have a -compressed mailbox for example, first apply a gunzip translator, and then an -mbox translator on top of that. - -There are a few problems with the way translators are set, though. For one, -once a translator is set on a node, you always see the translated content. If -you need the untranslated contents again, to do a backup for example, you first -need to remove the translator again. Also, having to set a translator -explicitely before accessing the contents is pretty cumbersome, making this -feature almost useless. - -A possible solution is implementing a mechanism for selecting translators -through special filename attributes. For example you could use -`index.html.gz,,+` and `index.html.gz,,-` to choose between translated and -untranslated versions of a file. Or you could use `index.html.gz,,u` to get -the contents of the file with a gunzip translator applied automatically. You -could also use attributes on whole directory trees: `.,,0/` would give you a -directory tree corresponding to the current directory, but with any translators -disabled, for doing a backup. And `site,,u/*.html.gz` would present a whole -directory tree of compressed HTML files as uncompressed files. - -One benefit of the Hurd's flexibility is that it should be possible to -implement such a mechanism without touching the existing Hurd components: -Rather, just implement a special proxy, that mirrors the normal filesystem, but -is able to interpret the special extensions and present transformed files in -place of the original ones. - -In the long run it's probably desirable to have the mechanism implemented in -the standard name lookup mechanism, so it will be available globally, and avoid -the overhead of a proxy; but for the beginnig the proxy solution is much more -flexible. - -The goal of this project is implementing a prototype proxy; perhaps also a -first version of the global variant as proof of concept, if time permits. It -requires good understanding of the name lookup mechanism, and translator -programming; but the implementation should not be too hard. Perhaps the hardest -part is finding a convenient, flexible, elegant, hurdish method for mapping the -special extensions to actual translators... - -Possible mentors: Olaf Buddenhagen (antrik) - -Exercise: Try to make some modification to the existing unionfs and/or firmlink -translators. (More specific suggestions welcome... :-) ) - -*Status*: Sergiu Ivanov has been working *voluntarily* on -[[namespace-based_translator_selection|scolobb]], as an inofficial GSoC 2008 -participant! Not all the desired functionality is in place yet; work is -ongoing. - - -## Fix File Locking - -Over the years, [[UNIX]] has aquired a host of different file locking mechanisms. -Some of them work on the Hurd, while others are buggy or only partially -implemented. This breaks many applications. - -The goal is to make all file locking mechanisms work properly. This requires -finding all existing shortcomings (through systematic testing and/or checking -for known issues in the bug tracker and mailing list archives), and fixing -them. - -This task will require digging into parts of the code to understand how file -locking works on the Hurd. Only general programming skills are required. - -Possible mentors: Samuel Thibault (youpi) - -Exercise: Find one of the existing issues, either by looking at the task/bug -trackers on savannah, or by trying things out yourself; and take a go at it. -Probably you wont' be able to fix the problem in a limited amount of time, but -you should be able to do a detailed analysis of the issue at least. - - -## `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 -exising 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. - - -## New Driver Glue Code - -Although a driver framework in userspace 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. - -Using [ddekit](http://demo.tudos.org/dsweeper_tutorial.html) instead of our -own glue code can be explored as a possible alternative approach. - -This is a doable, but pretty involved project. Experience with driver -programming under Linux (or BSD) is a must. (No Hurd-specific knowledge is -required, though.) - -This is [[GNU_Savannah_task 5488]]. - -Possible mentors: Samuel Thibault (youpi) - -Exercise: Try porting one driver from Linux 2.6 to run in the old framework. -The port needn't be elegant or complete; but it would be nice if you could get -it to work at least partially... - - -## Server Overriding Mechanism - -The main idea of the Hurd is that every user can influence almost all system -functionality ([[extensible_system|extensibility]]), by running private Hurd -servers that replace or proxy the global default implementations. - -However, running such a cumstomized subenvironment presently is not easy, -because there is no standard mechanism to easily replace an individual standard -server, keeping everything else. (Presently there is only the [[hurd/subhurd]] -method, which creates a completely new system instance with a completely -independent set of servers.) - -The goal of this project is to provide a simple method for overriding -individual standard servers, using environment variables, or a special -subshell, or something like that. - -Various approaches for such a mechanism has been discussed before. -Probably the easiest (1) would be to modify the Hurd-specific parts of [[hurd/glibc]], -which are contacting various standard servers to implement certain system -calls, so that instead of always looking for the servers in default locations, -they first check for overrides in environment variables, and use these instead -if present. - -A somewhat more generic solution (2) could use some mechanism for arbitrary -client-side namespace overrides. The client-side part of the filename lookup -mechanism would have to check an override table on each lookup, and apply the -desired replacement whenever a match is found. - -Another approach would be server-side overrides. Again there are various -variants. The actual servers themself could provide a mechanism to redirect to -other servers on request. (3) Or we could use some more generic server-side -namespace overrides: Either all filesystem servers could provide a mechanism to -modify the namespace they export to certain clients (4), or proxies could be -used that mirror the default namespace but override certain locations. (5) - -Variants (4) and (5) are the most powerful. They are intimately related to -chroots: (4) is like the current chroot implementation works in the Hurd, and -(5) has been proposed as an alternative. The generic overriding mechanism could -be implemented on top of chroot, or chroot could be implemented on top of the -generic overriding mechanism. But this is out of scope for this project... - -In practice, probably a mix of the different approaches would prove most useful -for various servers and use cases. It is strongly recommended that the student -starts with (1) as the simplest approach, perhaps augmenting it with (3) for -certain servers that don't work with (1) because of indirect invocation. - -This tasks requires some understanding of the Hurd internals, especially a good -understanding of the file name lookup mechanism. It's probably not too heavy on -the coding side. - -This is [[GNU_Savannah_task 6612]]. Also there are quite a bit of emails -discussing this topic, from a last year's GSoC application -- see -<http://lists.gnu.org/archive/html/bug-hurd/2007-03/msg00050.html>, -<http://lists.gnu.org/archive/html/bug-hurd/2007-03/msg00114.html>, -<http://lists.gnu.org/archive/html/bug-hurd/2007-06/msg00082.html>, -<http://lists.gnu.org/archive/html/bug-hurd/2008-03/msg00039.html>. - -Possible mentors: Olaf Buddenhagen (antrik) - -Exercise: Come up with a glibc patch that allows overriding one specific -standard server using method (1). - -*Status*: Overriding of socket servers through environment variables has been -implemented by Zheng Da for GSoC 2008, as part of his -[[network_virtualization|zhengda]] project. - - -## `dtrace` Support - -One of the main problems of the current Hurd implementation is very poor -performance. While we have a bunch of ideas what could cause the performance -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 convieved, 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 -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. - -Possible mentors: Samuel Thibault (youpi) - -Exercise: In lack of a good exercise directly related to this taks, 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. - - -## Hurdish TCP/IP Stack - -The Hurd presently uses a [[TCP/IP_stack|hurd/translator/pfinet]] based on code from an old Linux version. -This works, but lacks some rather important features (like PPP/PPPoE), and the -design is not hurdish at all. - -A true hurdish network stack will use a set of stack of [[hurd/translator]] processes, -each implementing a different protocol layer. This way not only the -implementation gets more modular, but also the network stack can be used way -more flexibly. Rather than just having the standard socket interface, plus some -lower-level hooks for special needs, there are explicit (perhaps -filesystem-based) interfaces at all the individual levels; special application -can just directly access the desired layer. All kinds of packet filtering, -routing, tunneling etc. can be easily achieved by stacking compononts in the -desired constellation. - -While the general architecture is pretty much given by the various network -layers, it's up to the student to design and implement the various interfaces -at each layer. This task requires understanding the Hurd philosophy and -translator programming, as well as good knowledge of TCP/IP. - -This is [[GNU_Savannah_task 5469]]. - -Possible mentors: ? - -Exercise: Make some modification to the existing pfinet implementation. (More -specific suggestions welcome... :-) ) - - -## Improved NFS Implementation - -The Hurd has both NFS server and client implementations, which work, but not -very well: File locking doesn't work properly (at least in conjuction with a -GNU/Linux server), and performance is extremely poor. Part of the problems -could be owed to the fact that only NFSv2 is supported so far. - -This project encompasses implementing NFSv3 support, fixing bugs and -performance problems -- the goal is to have good NFS support. The work done in -a previous unfinished GSoC project can serve as a starting point. - -Both client and server parts need work, though the client is probably much more -important for now, and shall be the major focus of this project. - -This task, [[GNU_Savannah_task 5497]], has no special prerequisites besides general programming skills, and -an interest in file systems and network protocols. - -Possible mentors: ? - -Exercise: Make a go at one of the known issues in the NFS client. You might not -be able to finish this in the limited amount of time, but you should at least -be able to make a detailed analysis of the issue. - - -## Fix `libdiskfs` Locking Issues - -Nowadays the most often encountered cause of Hurd crashes seems to be lockups -in the [[hurd/translator/ext2fs]] server. One of these could be traced -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. - -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 -exmple instrumenting the code to check locking correctness constantly at -runtime. Or implementing a unit testing framework that explicitely checks -locking in various code paths. (The latter could serve as a template for -implementing unit checks in other parts of the Hurd codebase...) - -This task requires experience with debugging locking issues in multithreaded -applications. - -Possible mentors: ? - -Exercise: Hack libdiskfs to keep count of the number of locks currently held. - - -## Convert Hurd Libraries and Servers to pthreads - -The Hurd was originally created at a time when the [pthreads -standard](http://www.opengroup.org/onlinepubs/009695399/basedefs/pthread.h.html) -didn't exist yet. Thus all Hurd servers and libraries are using the old -[[cthreads|hurd/libcthreads]] package that came with [[microkernel/Mach]], -which is not compatible with [[pthreads|hurd/libpthread]]. - -Not only does that mean that people hacking on Hurd internals have to deal with -a non-standard thread package, which nobody is familiar with. Although a -pthreads implementation for the Hurd was created in the meantime, it's not -possible to use both cthreads and pthreads in the same program. Consequently, -pthreads can't presently be used in any Hurd servers -- including translators. - -Some work already has been done once on converting the Hurd servers and -libraries to use pthreads, but that work hasn't been finished. It is available -as [[GNU_Savannah_task 5487]] and can of course be used to base the new work -upon. - -The goal of this project is to have all the Hurd code use pthreads. Should any -limitations in the existing pthreads implementation turn up that hinder this -transition, they will have to be fixed as well. - -One possible option is creating a wrapper that implements the cthreads -interfaces on top of pthreads, to ease the transition -- but it might very well -turn out that it's easier to just change all the existing code to use pthreads -directly. This is up to the student. Such a wrapper has been proposed as -[[GNU_Savannah_task 7895]] and its implementation would be a useful -starting-point. - -This project requires relatively little Hurd-specific knowledge. Experience -with multithreaded programming in general and pthreads in particular is -required, though. - -Possible mentors: Samuel Thibault (youpi) - -Exercise: Take some small piece of code using ctreads and convert it to -pthreads. - - -## Sound Support - -The Hurd presently has no sound support. Fixing this, [[GNU_Savannah_task -5485]], requires two steps: the first is to port some other kernel's drivers to -[[GNU_Mach|microkernel/mach/gnumach]] so we can get access to actual sound -hardware. The second is to implement a userspace server ([[hurd/translator]]), -that implements an interface on top of the kernel device that can be used by -applications -- probably OSS or maybe ALSA. - -Completing this task requires porting at least one driver (e.g. from Linux) for -a popular piece of sound hardware, and the basic userspace server. For the -driver part, previous experience with programming kernel drivers is strongly -advisable. The userspace part requires some knowledge about programming Hurd -translators, but shouldn't be too hard. - -Once the basic support is working, it's up to the student to use the remaining -time for porting more drivers, or implementing a more sophisticated userspace -infrastructure. The latter requires good understanding of the Hurd philosophy, -to come up with an appropriate design. - -Another option would be to evaluate whether a driver that is completely running -in user-space is feasible. <!-- TODO. Elaborate. --> - -Possible mentors: ? - -Exercise: Take a newer driver for a device in one of the subsystems we already -implement (disk or network) from a newer Linux version, or some other operating -system, and try to port it so that it runs in the existing driver framework. -The port needn't be elegant or complete; but it would be nice if you could get -it to work at least partially... - - -## Disk I/O Performance Tuning - -The most obvious reason for the Hurd feeling slow compared to mainstream -systems like GNU/Linux, is very slow harddisk access. - -The reason for this slowness is lack and/or bad implementation of common -optimisation techniques, like scheduling reads and writes to minimalize head -movement; effective block caching; effective reads/writes to partial blocks; -reading/writing multiple blocks at once; and read-ahead. The -[[ext2_filesystem_server|hurd/translator/ext2fs]] might also need some -optimisations at a higher logical level. - -The goal of this project is to analyze the current situation, and implement/fix -various optimisations, to achieve significantly better disk performance. It -requires understanding the data flow through the various layers involved in -disk acces on the Hurd ([[filesystem|hurd/virtual_file_system]], -[[pager|hurd/libpager]], driver), and general experience with -optimising complex systems. That said, the killing feature we are definitely -missing is the read-ahead, and even a very simple implementation would bring -very big performance speedups. - -Possible mentors: ? - -Exercise: Make some modification in at least one of the components involved in -disk I/O. (More specific suggestions welcome... :-) ) - - -## VM Tuning - -Hurd/[[microkernel/Mach]] presently make very bad use of the available physical memory in the -system. Some of the problems are inherent to the system design (the kernel -can't distinguish between important application data and discardable disk -buffers for example), and can't be fixed without fundamental changes. Other -problems however are an ordinary lack of optimisation, like extremely crude -heuristics when to start paging. (See <http://lists.gnu.org/archive/html/bug-hurd/2007-08/msg00034.html> for example.) -Many parameters are based on assumptions from -a time when typical machines had like 16 MiB of RAM, or simply have been set to -arbitrary values and never tuned for actual use. - -The goal of this project is to bring the virtual memory management in Hurd/Mach -closer to that of modern mainstream kernels (Linux, FreeBSD), by comparing the -implementation to other systems, implementing any worthwhile improvements, and -general optimisation/tuning. It requires very good understanding of the Mach -VM, and virtual memory in general. - -This project is related to [[GNU_Savannah_task 5489]]. - -Possible mentors: ? - -Exercise: Make some modification to the existing VM code. You could try to find -a piece of code that can be improved with simple code optimization, for -example. - - -## `mtab` - -In traditional monolithic system, the kernel keeps track of all mounts; the -information is available through `/proc/mounts` (on Linux at least), and in a -very similar form in `/etc/mtab`. - -The Hurd on the other hand has a totally -[[decentralized_file_system|hurd/virtual_file_system]]. There is no single -entity involved in all mounts. Rather, only the parent file system to which a -mountpoint ([[hurd/translator]]) is attached is involved. As a result, there -is no central place keeping track of mounts. - -As a consequence, there is currently no easy way to obtain a listing of all -mounted file systems. This also means that commands like `df` can only work on -explicitely specified mountpoints, instead of displaying the usual listing. - -One possible solution to this would be for the translator startup mechanism to -update the `mtab` on any `mount`/`unmount`, like in traditional systems. -However, there are same problems with this approach. Most notably: what to do -with passive translators, i.e., translators that are not presently running, but -set up to be started automatically whenever the node is accessed? Probably -these should be counted an among the mounted filesystems; but how to handle the -`mtab` updates for a translator that is not started yet? Generally, being -centralized and event-based, this is a pretty unelegant, non-hurdish solution. - -A more promising approach is to have `mtab` exported by a special translator, -which gathers the necessary information on demand. This could work by -traversing the tree of translators, asking each one for mount points attached -to it. (Theoretically, it could also be done by just traversing *all* nodes, -checking each one for attached translators. That would be very inefficient, -though. Thus a special interface is probably required, that allows asking a -translator to list mount points only.) - -There are also some other issues to keep in mind. Traversing arbitrary -translators set by other users can be quite dangerous -- and it's probably not -very interesting anyways what private filesystems some other user has mounted. -But what about the global `/etc/mtab`? Should it list only root-owned -filesystems? Or should it create different listings depending on what user -contacts it?... - -That leads to a more generic question: which translators should be actually -listed? There are different kinds of translators: ranging from traditional -filesystems ([[disks|hurd/libdiskfs]] and other actual -[[stores|hurd/translator/storeio]]), but also purely virtual filesystems like -[[hurd/translator/ftpfs]] or [[hurd/translator/unionfs]], and even things that -have very little to do with a traditional filesystem, like a -[[gzip_translator|hurd/translator/storeio]], -[[mbox_translator|hurd/translator/mboxfs]], -[[xml_translator|hurd/translator/xmlfs]], or various device file translators... -Listing all of these in `/etc/mtab` would be pretty pointless, so some kind of -classification mechanism is necessary. By default it probably should list only -translators that claim to be real filesystems, though alternative views with -other filtering rules might be desirable. - -After taking decisions on the outstanding design questions, the student will -implement both the actual [[mtab_translator|hurd/translator/mtabfs]], and the -necessery interface(s) for gathering the data. It requires getting a good -understanding of the translator mechanism and Hurd interfaces in general. - -Possible mentors: Olaf Buddenhagen (antrik) - -Exercise: Create a simple translator using libnetfs, that only allows creating -directories and attaching other translators. - - -## GNU Mach Code Cleanup - -Although there are some attempts to move to a more modern microkernel -alltogether, the current Hurd implementation is based on -[[GNU_Mach|microkernel/mach/gnumach]], which is only a slightly modified -variant of the original CMU [[microkernel/Mach]]. - -Unfortunately, Mach was created about two decades ago, and is in turn based on -even older BSD code. Parts of the BSD kernel -- file systems, [[UNIX]] [[mechanism]]s -like processes and signals, etc. -- were ripped out (to be implemented in -[[userspace_servers|hurd/translator]] instead); while other mechanisms were -added to allow implementing stuff in userspace. -([[Pager_interface|microkernel/mach/external_pager_mechanism]], -[[microkernel/mach/IPC]], etc.) - -Also, Mach being a research project, many things were tried, adding lots of -optional features not really needed. - -The result of all this is that the current code base is in a pretty bad shape. -It's rather hard to make modifications -- to make better use of modern hardware -for example, or even to fix bugs. The goal of this project is to improve the -situation. - -The task starts out easy, with fixing compiler warnings. Later it moves on to -more tricky things: removing dead or unneeded code paths; restructuring code -for readability and maintainability. - -This task requires good knowledge of C, and experience with working on a large -existing code base. Previous kernel hacking experience is an advantage, but -not really necessary. - -Possible mentors: Samuel Thibault (youpi) - -Exercise: Create a few simple patches that fix some of the compiler warnings, -rework a piece of ugly code etc. - - -## `xmlfs` - -Hurd [[translators|hurd/translator]] allow presenting underlying data in a -different format. This is a very powerful ability: it allows using standard -tools on all kinds of data, and combining existing components in new ways, once -you have the necessary translators. - -A typical example for such a translator would be xmlfs: a translator that -presents the contents of an underlying XML file in the form of a directory -tree, so it can be studied and edited with standard filesystem tools, or using -a graphical file manager, or to easily extract data from an XML file in a -script etc. - -The exported directory tree should represent the DOM structure of the document, -or implement XPath, or both, or some combination thereof (perhaps XPath could -be implemented as a second translator working on top of the DOM one) -- -whatever works well, while sticking to XML standards as much as possible. - -Ideally, the translation should be reversible, so that another, complementary -translator applied on the expanded directory tree would yield the original XML -file again; and also the other way round, applying the complementary translator -on top of some directory tree and xmlfs on top of that would yield the original -directory again. However, with the different semantics of directory trees and -XML files, it might not be possible to create such a universal mapping. Thus -it is a desirable goal, but not a strict requirement. - -The goal of this project is to create a fully usable XML translator, that -allows both reading and writing any XML file. Implementing the complementary -translator also would be nice if time permits, but is not mandatory part of the -task. - -The [[existing_partial_(read-only)_xmlfs_implementation|hurd/translator/xmlfs]] -can serve as a starting point. - -This task requires pretty good designing skills. Good knowledge of XML is also -necessary. Learning translator programming will obviously be necessary to -complete the task. - -Possible mentors: Olaf Buddenhagen (antrik) - -Exercise: Make some modification to the existing xmlfs translator, and write a -shell script that uses xmlfs to extract some interesting information from an -.odt document. (More specific suggestions welcome... :-) ) - - -## Allow Using `unionfs` Early at Boot - -In [[UNIX]] systems, traditionally most software is installed in a common directory -hierachy, where files from various packages live beside each other, grouped by -function: user-invokable executables in `/bin`, system-wide configuration files -in `/etc`, architecture specific static files in `/lib`, variable data in -`/var`, and so on. To allow clean installation, deinstallation, and upgrade of -software packages, GNU/Linux distributions usually come with a package manager, -which keeps track of all files upon installation/removal in some kind of -central database. - -An alternative approach is the one implemented by GNU Stow: each package is -actually installed in a private directory tree. The actual standard directory -structure is then created by collecting the individual files from all the -packages, and presenting them in the common `/bin`, `/lib`, etc. locations. - -While the normal Stow package (for traditional UNIX systems) uses symlinks to -the actual files, updated on installation/deinstallation events, the Hurd -[[hurd/translator]] mechanism allows a much more elegant solution: -[[hurd/translator/stowfs]] (which is actually a special mode of -[[hurd/translator/unionfs]]) creates virtual directories on the fly, composed -of all the files from the individual package directories. - -The problem with this approach is that unionfs presently can be launched only -once the system is booted up, meaning the virtual directories are not available -at boot time. But the boot process itself already needs access to files from -various packages. So to make this design actually usable, it is necessary to -come up with a way to launch unionfs very early at boot time, along with the -root filesystem. - -Completing this task will require gaining a very good understanding of the Hurd -boot process and other parts of the design. It requires some design skills -also to come up with a working mechanism. - -Possible mentors: ? - -Exercise: Try to write a dummy server that is started instead of ext2fs on -system boot, and starts the actual ext2fs in turn. - - -## Fix `tmpfs` - -In some situations it is desirable to have a file system that is not backed by -actual disk storage, but only by anonymous memory, i.e. lives in the RAM (and -possibly swap space). - -A simplistic way to implement such a memory filesystem is literally creating a -ramdisk, i.e. simply allocating a big chunck of RAM (called a memory store in -Hurd terminology), and create a normal filesystem like ext2 on that. However, -this is not very efficient, and not very convenient either (the filesystem -needs to be recreated each time the ramdisk is invoked). A nicer solution is -having a real [[hurd/translator/tmpfs]], which creates all filesystem -structures directly in RAM, allocating memory on demand. - -The Hurd has had such a tmpfs for a long time. However, the existing -implementation doesn't work anymore -- it got broken by changes in other parts -of the Hurd design. - -There are several issues. The most serious known problem seems to be that for -technical reasons it receives [[microkernel/mach/RPC]]s from two different -sources on one [[microkernel/mach/port]], and gets mixed up with them. Fixing -this is non-trivial, and requires a good understanding of the involved -mechanisms. - -The goal of this project to get a fully working, full featured tmpfs -implementation. It requires digging into some parts of the Hurd, incuding the -[[pager_interface|hurd/libpager]] and [[hurd/translator]] programming. This -task probably doesn't require any design work, only good debugging skills. - -Possible mentors: ? - -Exercise: Take a go at one of the existing issues in tmpfs. You may not be able -to finish this in the limited amount of time, but you should at least be able -to do a detailed analysis of the problem. - - -## Lexical `..` Resolution - -For historical reasons, [[UNIX]] filesystems have a real (hard) `..` link from each -directory pointing to its parent. However, this is problematic, because the -meaning of "parent" really depends on context. If you have a symlink for -example, you can reach a certain node in the filesystem by a different path. If -you go to `..` from there, UNIX will traditionally take you to the hard-coded -parent node -- but this is usually not what you want. Usually you want to go -back to the logical parent from which you came. That is called "lexical" -resolution. - -Some application already use lexical resolution internally for that reason. It -is generally agreed that many problems could be avoided if the standard -filesystem lookup calls used lexical resolution as well. The compatibility -problems probably would be negligable. - -The goal of this project is to modify the filename lookup mechanism in the Hurd -to use lexical resolution, and to check that the system is still fully -functional afterwards. This task requires understanding the filename resolution -mechanism. It's probably a relatively easy task. - -See also [[GNU_Savannah_bug 17133]]. - -Possible mentors: ? - -Exercise: Make some modification to the name lookup mechanism. (More specific -suggestions welcome... :-) ) - - -## 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 -good, as it allows easily escaping the `chroot`, for example by use of -[[passive_translators|hurd/translator]]. - -Many solutions have been suggested for this problem -- ranging from simple -workaround changing the behaviour of passive translators in a `chroot`; -changing the context in which passive translators are exectuted; changing the -interpretation of filenames in a chroot; to reworking the whole passive -translator mechanism. Some involving a completely different approch to -`chroot` implementation, using a proxy instead of a special system call in the -filesystem servers. - -The task is to pick and implement one approach for fixing chroot. - -This task is pretty heavy: it requires a very good understanding of file name -lookup and the translator mechanism, as well as of security concerns in general --- the student must prove that he really understands security implications of -the UNIX namespace approach, and how they are affected by the introduction of -new mechanisms. (Translators.) More important than the acualy code is the -documentation of what he did: he must be able to defend why he chose a certain -approach, and explain why he believes this approach really secure. - -Possible mentors: ? - -Exercise: Make some modification to the chroot mechanism. (More specific -suggestions welcome :-) ) - - -## Hurdish Package Manager for the GNU System - -Most GNU/Linux systems use pretty sophisticated package managers, to ease the -management of installed software. These keep track of all installed files, and -various kinds of other necessary information, in special databases. On package -installation, deinstallation, and upgrade, scripts are used that make all kinds -of modifications to other parts of the system, making sure the packages get -properly integrated. - -This approach creates various problems. For one, *all* management has to be -done with the distribution package management tools, or otherwise they would -loose track of the system state. This is reinforced by the fact that the state -information is stored in special databases, that only the special package -management tools can work with. - -Also, as changes to various parts of the system are made on certain events -(installation/deinstallation/update), managing the various possible state -transitions becomes very complex and bug-prone. - -For the official (Hurd-based) GNU system, a different approach is intended: -making use of Hurd [[translators|hurd/translator]] -- more specifically their -ability to present existing data in a different form -- the whole system state -will be created on the fly, directly from the information provided by the -individual packages. The visible system state is always a reflection of the -sum of packages installed at a certain moment; it doesn't matter how this state -came about. There are no global databases of any kind. (Some things might -require caching for better performance, but this must happen transparently.) - -The core of this approach is formed by [[hurd/translator/stowfs]], which -creates a traditional unix directory structure from all the files in the -individual package directories. But this only handles the lowest level of -package management. Additional mechanisms are necessary to handle stuff like -dependencies on other packages. - -The goal of this task is to create these mechanisms. - -Possible mentors: Ben Asselstine (bing) - -Exercise: Write a translator that observes a directory tree using -dir_notify_changes(), and presents a file with a log of changes. - - -## Port the Debian Installer to the Hurd - -The primary means of distributing the Hurd is through Debian GNU/Hurd. -However, the installation CDs presently use an ancient, non-native installer. -The situation could be much improved by making sure that the newer *Debian -Installer* works on the Hurd. - -Some preliminary work has been done, see -<http://wiki.debian.org/DebianInstaller/Hurd>. - -The goal is to have the Debian Installer fully working on the Hurd. It -requires relatively little Hurd-specific knowledge. - -Possible mentors: Samuel Thibault (youpi) - -Exercise: Try to get one piece of the installer running on Hurd. +[[GNU Free Documentation License|/fdl]]."]]"""]] + +We offer a wide range of possible projects to choose from. If you have an idea +not listed here, we'd love to hear about it! + +In either case, we encourage you to contact us (on [[IRC]] and/or our developer +[[mailing lists]]), so we can discuss your idea, or help you pick a suitable +task -- we will gladly explain the tasks in more detail, if the descriptions +are not clear enough. + +In fact, we suggest you discuss your choice with us even if you have no trouble +finding a task that suits you: as explained in the introduction section of the +[[student_application_form]], we ask all students to get into regular +communication with us for the application to be considered complete. Talking +about your project choice is a good start :-) + +(We strongly suggest that you generally take a look at the +[[student_application_form]] right now -- the sooner you know what we expect, +the better you can cater to it :-) ) + +Many of the project descriptions suggest some "exercise". The reason is that +for the application to be complete, we require you to make a change to the Hurd +code, and send us the resulting patch. (This is also explained in the +[[student_application_form]].) If possible, the change should make some +improvement to the code you will be working on during the summer, or to some +related code. + +The "exercise" bit in the project description is trying to give you some ideas +what kind of change this could be. In most cases it is quite obvious, though: +Try to find something to improve in the relevant code, by looking at known +issues in the [Savannah bug tracker](http://savannah.gnu.org/bugs/?group=hurd); +by running the code and testing stuff; and by looking through the code. If you +don't find anything, try with some related code -- if you task involves +translator programming, make some improvement to an existing translator; if it +involves glibc hacking, make an improvement to glibc; if it involves driver +hacking, make an improvement to the driver framework; and so on... Makes sense, +doesn't it? :-) + +Sometimes it's hard to come up with a useful improvement to the code in +question, that isn't too complicated for the purposes of the application. In +this case, we need to find a good alternative. You could for example make an +improvement to some Hurd code that is not directly related to your project: +this way you won't get familiar with working on the code you will actually need +for the task, but at least you can show that you are able to work with the Hurd +code in general. + +Another possible alternative would be making some change to the code in +question, that isn't really a useful improvement, while still making sense in +some way -- this could suffice to prove that you are able to work with the +code. + +Don't despair if you can't come up with anything suitable by yourself. Contact +us, and we will think of something together :-) + +In either case, we strongly suggest that you talk to us about the change you +want to make up front, to be sure that it is something that will get our +approval -- especially if the idea is not directly taken from the project +description. + +Also, don't let this whole patch stuff discourage you from applying! As +explained in the [[student_application_form]], it's not a problem if you do not +yet have all the necessary knowledge to do this alone -- we don't expect that. +After all, the purpose of GSoC is to introduce you to free software development +:-) We only want to see that you are able to obtain the necessary knowledge +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). + +[[!inline pages="community/gsoc/project_ideas/language_bindings" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/virtualization" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/file_locking" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/server_overriding" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/tcp_ip_stack" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/nfs" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/libdiskfs_locking" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/pthreads" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/sound" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/disk_io_performance" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/vm_tuning" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/mtab" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/gnumach_cleanup" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/xmlfs" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/unionfs_boot" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/tmpfs" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/lexical_dot-dot" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/secure_chroot" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/package_manager" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/debian_installer" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/download_backends" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/libgtop" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/maxpath" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/gnat" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/hardware_libs" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/cdparanoia" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/perl_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/libcap" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/xattr" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/valgrind" show=0 feeds=no actions=yes]] diff --git a/community/gsoc/project_ideas/cdparanoia.mdwn b/community/gsoc/project_ideas/cdparanoia.mdwn new file mode 100644 index 00000000..a92329fe --- /dev/null +++ b/community/gsoc/project_ideas/cdparanoia.mdwn @@ -0,0 +1,30 @@ +[[!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="Implement CD Audio Grabbing"]] + +The Hurd presently has only support for CD-ROMs, but not for audio extraction +("grabbing"). As a result, cdparanoia (and other extraction +libraries/utilities) are not available; and many other packages depending on +these can't be built in Debian GNU/Hurd either. + +Adding support for audio extraction shouldn't be too hard. It requires +implementing a number of additional ioctl()s, generating the appropriate ATAPI +commands. + +The goal of this task is fully working cdparanoia in Debian GNU/Hurd. It will +require digging a bit into Hurd internals and ATAPI commands, but should be +quite doable without any previous knowledge about either. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Look at the implementation of the existing ioctl()s, and try to find +something that could be easily added/improved. If you don't see anything +obvious, talk to us about a different exercise task. diff --git a/community/gsoc/project_ideas/debian_installer.mdwn b/community/gsoc/project_ideas/debian_installer.mdwn new file mode 100644 index 00000000..43682e8b --- /dev/null +++ b/community/gsoc/project_ideas/debian_installer.mdwn @@ -0,0 +1,41 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="Port the Debian Installer to the Hurd"]] + +The primary means of distributing the Hurd is through Debian GNU/Hurd. +However, the installation CDs presently use an ancient, non-native installer. +The situation could be much improved by making sure that the newer *Debian +Installer* works on the Hurd. + +Some preliminary work has been done, see +<http://wiki.debian.org/DebianInstaller/Hurd>. + +The goal is to have the Debian Installer fully working on the Hurd. It +requires relatively little Hurd-specific knowledge. + +A lot of the "non-Linux support" part of the project has already been done thanks to a previous GSoC, so at least no ground reason should bar the project. A lot of the required udebs are already in Debian or are pending upload, so that building an image and booting it does already work. A preliminary list of what remains is + + * Add initrd support to GNU Mach, unless youpi does it before :) This should not be very complicated by re-using the iopl driver code. + * hurdify genext2fs to handle 4096 block size by default (see bug #562999) and support translator entries. + * Port busybox. This needs to be synchronized with kfreebsd people, who have probably already done some work, but that seemingly still hasn't been merged. In the meanwhile, youpi has a version with most of it disabled so a d-i image can actually be built. + * Port keyboard-setup to configure the xkb driver of the Hurd console + +As a starting point to get a grasp at how the debian installer is built, students might wish to look at the current Debian installer source and build process on Linux: + + * svn co svn://svn.debian.org/d-i/trunk/installer/ + * cd installer/build + * make build_monolithic + +The same can be done on hurd-i386 but a few non-uploaded packages are needed, see http://people.debian.org/~sthibault/hurd-i386/README-d-i + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Fix a couple of Hurd issues in busybox. diff --git a/community/gsoc/project_ideas/disk_io_performance.mdwn b/community/gsoc/project_ideas/disk_io_performance.mdwn new file mode 100644 index 00000000..b6c857b0 --- /dev/null +++ b/community/gsoc/project_ideas/disk_io_performance.mdwn @@ -0,0 +1,36 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="Disk I/O Performance Tuning"]] + +The most obvious reason for the Hurd feeling slow compared to mainstream +systems like GNU/Linux, is very 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 +[[ext2_filesystem_server|hurd/translator/ext2fs]] might also need some +optimizations at a higher logical level. + +The goal of this project is to analyze the current situation, and implement/fix +various optimizations, to achieve significantly better disk performance. It +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 +very big performance speedups. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Look through all the code involved in disk I/O, and try something +easy to improve. It's quite likely though that you will find nothing obvious -- +in this case, please contact us about a different exercise task. diff --git a/community/gsoc/project_ideas/download_backends.mdwn b/community/gsoc/project_ideas/download_backends.mdwn new file mode 100644 index 00000000..f794e814 --- /dev/null +++ b/community/gsoc/project_ideas/download_backends.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!meta title="Use Internet Protocol Translators (ftpfs etc.) as Backends for Other Programs"]] + +The Hurd design facilitates splitting up large applications into independent, +generic components, which can be easily combined in different contexts, by +moving common functionality into separate Hurd servers (translators), +accessible trough filesystem interfaces and/or specialized RPC interfaces. + +Download protocols like FTP, HTTP, BitTorrent etc. are very good candidates for +this kind of modularization: a program could simply use the download +functionality by accessing FTP, HTTP etc. translators. + +There is already an ftpfs translator in the Hurd tree, as well as an [httpfs +translator on hurdextras](http://www.nongnu.org/hurdextras/#httpfs); however, +these are only suitable for very simple use cases: they just provide the actual +file contents downloaded from the URL, but no additional status information +that are necessary for interactive use. (Progress indication, error codes, HTTP +redirects etc.) + +A new interface providing all this additional information (either as an +extension to the existing translators, or as distinct translators) is required +to make such translators usable as backends for programs like apt-get for +example. + +The goal of this project is to design a suitable interface, implement it for at +least one download protocol, and adapt apt-get (or some other program) to use +this as a backend. + +This task requires some design skills and some knowledge of internet protocols, +to create a suitable interface. Translator programming knowledge will have to +be obtained while implementing it. + +It is not an easy task, but it shouldn't pose any really hard problems either. + +Possible mentors: Olaf Buddenhagen (antrik) + +Exercise: Make some improvement to one of the existing download translators -- +httpfs in particular is known to be buggy. diff --git a/community/gsoc/project_ideas/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn new file mode 100644 index 00000000..9c063e9f --- /dev/null +++ b/community/gsoc/project_ideas/driver_glue_code.mdwn @@ -0,0 +1,49 @@ +[[!meta copyright="Copyright © 2008, 2009, 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="New Driver Glue Code"]] + +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.) + +This is [[!GNU_Savannah_task 5488]]. +[[open issues/user-space device drivers]]. +[[open issues/device drivers and io systems]]. + + +Possible mentors: Samuel Thibault (youpi) + +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... + +*Status*: [[Zheng Da|zhengda]] is working on DDE, and has mostly completed the +initial port. diff --git a/community/gsoc/project_ideas/dtrace.mdwn b/community/gsoc/project_ideas/dtrace.mdwn new file mode 100644 index 00000000..4a46cf38 --- /dev/null +++ b/community/gsoc/project_ideas/dtrace.mdwn @@ -0,0 +1,46 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="dtrace Support"]] + +One of the main problems of the current Hurd implementation is very poor +performance. While we have a bunch of ideas what could cause the performance +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 +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 +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. + +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. diff --git a/community/gsoc/project_ideas/file_locking.mdwn b/community/gsoc/project_ideas/file_locking.mdwn new file mode 100644 index 00000000..0159b091 --- /dev/null +++ b/community/gsoc/project_ideas/file_locking.mdwn @@ -0,0 +1,38 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="Fix and Complete File Locking Support"]] + +Over the years, [[UNIX]] has acquired a host of different file locking mechanisms. +Some of them work on the Hurd, while others are buggy or only partially +implemented. This breaks many applications. + +The goal is to make all file locking mechanisms work properly. This requires +finding all existing shortcomings (through systematic testing and/or checking +for known issues in the bug tracker and mailing list archives), and fixing +them. The biggest missing feature is record locking, i.e. the lockf variant, +which needs a complete implementation. + +This task will require digging into parts of the code to understand how file +locking works on the Hurd. Only general programming skills are required. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Find one of the existing issues, either by looking at the task/bug +trackers on savannah, or by trying things out yourself; and take a go at it. +Note though that most of these issues are probably not trivial -- it's quite +likely that you won't be able to actually fix any of them in the time available +during the application process. However, you might be able to spot something +else that could be improved while looking into this. + +If after trying for a while you haven't found anything easy enough to improve +in the locking-related code, talk to us about some alternative exercise task. +Perhaps you actually find something you could do while looking through the bug +tracker or trying stuff yourself in search of locking issues :-) diff --git a/community/gsoc/project_ideas/gnat.mdwn b/community/gsoc/project_ideas/gnat.mdwn new file mode 100644 index 00000000..97a4a552 --- /dev/null +++ b/community/gsoc/project_ideas/gnat.mdwn @@ -0,0 +1,24 @@ +[[!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="Porting GNAT"]] + +The GNU Ada Translator (GNAT) isn't available for the Hurd so far. There are +also a number of other Debian packages depending on GNAT, and thus not +buildable on the Hurd. + +The goal of this project is getting GNAT fully working in Debian GNU/Hurd. It +requires implementing some explicitly system-specific stuff in GNAT, and maybe +fixing a few other problems. Good knowledge of Ada is a must; some Hurd +knowledge will have to be acquired while working on the project. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Fix one of the problems preventing GNAT from working on the Hurd. diff --git a/community/gsoc/project_ideas/gnumach_cleanup.mdwn b/community/gsoc/project_ideas/gnumach_cleanup.mdwn new file mode 100644 index 00000000..4aef0d1b --- /dev/null +++ b/community/gsoc/project_ideas/gnumach_cleanup.mdwn @@ -0,0 +1,46 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="GNU Mach Code Cleanup"]] + +Although there are some attempts to move to a more modern microkernel +altogether, the current Hurd implementation is based on +[[GNU_Mach|microkernel/mach/gnumach]], which is only a slightly modified +variant of the original CMU [[microkernel/Mach]]. + +Unfortunately, Mach was created about two decades ago, and is in turn based on +even older BSD code. Parts of the BSD kernel -- file systems, [[UNIX]] [[mechanism]]s +like processes and signals, etc. -- were ripped out (to be implemented in +[[userspace_servers|hurd/translator]] instead); while other mechanisms were +added to allow implementing stuff in user space. +([[Pager_interface|microkernel/mach/external_pager_mechanism]], +[[microkernel/mach/IPC]], etc.) + +Also, Mach being a research project, many things were tried, adding lots of +optional features not really needed. + +The result of all this is that the current code base is in a pretty bad shape. +It's rather hard to make modifications -- to make better use of modern hardware +for example, or even to fix bugs. The goal of this project is to improve the +situation. + +There are various things you can do here: Fixing compiler warnings; removing +dead or unneeded code paths; restructuring code for readability and +maintainability etc. -- a glance at the source code should quickly give you +some ideas. + +This task requires good knowledge of C, and experience with working on a large +existing code base. Previous kernel hacking experience is an advantage, but +not really necessary. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: You should have no trouble finding something to improve when looking +at the gnumach code, or even just at compiler warnings. diff --git a/community/gsoc/project_ideas/hardware_libs.mdwn b/community/gsoc/project_ideas/hardware_libs.mdwn new file mode 100644 index 00000000..c30505cb --- /dev/null +++ b/community/gsoc/project_ideas/hardware_libs.mdwn @@ -0,0 +1,42 @@ +[[!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="Stub Implementations of Hardware Specific Libraries"]] + +Many programs use special libraries to access certain hardware devices, +like libusb, libbluetooth, libraw1394, libiw-dev (though there already is a +wireless-tools-gnumach package), etc. + +The Hurd presently doesn't support these devices. Nevertheless, all of these +programs could still be built -- and most of them would indeed be useful -- +without actual support of these hardware devices, kdebase for instance. However, +as the libraries are presently not available for Hurd, the programs can't be +easily built in Debian GNU/Hurd due to missing dependencies. + +This could be avoided by providing dummy libraries, which the programs could +link against, but which wouldn't actually do any hardware access: instead, they +would simply return appropriate error codes, reporting that no devices were +found. + +There are two possible approaches for providing such stub libraries: Either +implement replacement libraries providing the same API as the real ones; or +implement dummy backends for the Hurd in the proper libraries. Which approach +to prefer probably depends on the structure of the various libraries. + +The goal of this project is to create working dummy libraries/backends for the +mentioned devices, and get them into Debian GNU/Hurd. It shouldn't require any +special previous knowledge, though some experience with build systems would be +helpful. Finishing this task will probably require learning a bit about the +hardware devices in question, and about Debian packaging. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Get one of the libraries to compile on Debian GNU/Hurd. It doesn't +need to report reasonable error codes yet -- just make it build at all for now. diff --git a/community/gsoc/project_ideas/language_bindings.mdwn b/community/gsoc/project_ideas/language_bindings.mdwn new file mode 100644 index 00000000..a27b0d30 --- /dev/null +++ b/community/gsoc/project_ideas/language_bindings.mdwn @@ -0,0 +1,67 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="Bindings to Other Programming Languages"]] + +The main idea of the Hurd design is giving users the ability to easily +modify/extend the system's functionality ([[extensible_system|extensibility]]). +This is done by creating [[filesystem_translators|hurd/translator]] and other +kinds of Hurd servers. + +However, in practice this is not as easy as it should, because creating +translators and other servers is quite involved -- the interfaces for doing +that are not exactly simple, and available only for C programs. Being able to +easily create simple translators in RAD languages is highly desirable, to +really be able to reap the advantages of the Hurd architecture. + +Originally Lisp was meant to be the second system language besides C in the GNU +system; but that doesn't mean we are bound to Lisp. Bindings for any popular +high-level language, that helps quickly creating simple programs, are highly +welcome. + +Several approaches are possible when creating such bindings. One way is simply +to provide wrappers to all the available C libraries ([[hurd/libtrivfs]], [[hurd/libnetfs]] +etc.). While this is easy (it requires relatively little consideration), it may +not be the optimal solution. It is preferable to hook in at a lower level, thus +being able to create interfaces that are specially adapted to make good use of +the features available in the respective language. + +These more specialized bindings could hook in at some of the lower level +library interfaces ([[hurd/libports]], [[hurd/glibc]], etc.); use the +[[microkernel/mach/MIG]]-provided [[microkernel/mach/RPC]] stubs directly; or +even create native stubs directly from the interface definitions. The +[[lisp_bindings_created_by_Flavio_Cruz|flaviocruz]] in last year's GSoC mostly +use the latter approach, and can serve as a good example. + +There is another possible reason for preferring lower-level bindings: +Presently, the Hurd server libraries use the cthreads threading library, which +predates the pthread standard prevalent today. There is a pthread library for +the Hurd as well, but it's not possible to use both cthreads and pthreads in +the same executable. Thus, until +[[porting_the_Hurd_libraries_to_pthreads|community/gsoc/project_ideas/pthreads]] +is finished, implementing bindings for any language that uses pthreads (in the +runtime environment or the actual programs) is only possible when not using the +standard Hurd server libraries at all -- i.e. when binding at MIG stub level or +interface definition level. + +The task is to create easy to use Hurd bindings for a language of the student's +choice, and some example servers to prove that it works well in practice. This +project will require gaining a very good understanding of the various Hurd +interfaces. Skills in designing nice programming interfaces are a must. + +Anatoly A. Kazantsev has started working on [Python +bindings](http://savannah.nongnu.org/projects/pyhurd/) last year -- if Python +is your language of choice, you probably should take his work and complete it. + +There was also some previous work on [Perl +bindings](http://www.nongnu.org/hurdextras/#pith), which might serve as a +reference if you want to work on Perl. + +Possible mentors: Anatoly A. Kazantsev (anatoly) for Python diff --git a/community/gsoc/project_ideas/lexical_dot-dot.mdwn b/community/gsoc/project_ideas/lexical_dot-dot.mdwn new file mode 100644 index 00000000..e0dabc01 --- /dev/null +++ b/community/gsoc/project_ideas/lexical_dot-dot.mdwn @@ -0,0 +1,40 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="Lexical .. Resolution"]] + +For historical reasons, [[UNIX]] filesystems have a real (hard) `..` link from each +directory pointing to its parent. However, this is problematic, because the +meaning of "parent" really depends on context. If you have a symlink for +example, you can reach a certain node in the filesystem by a different path. If +you go to `..` from there, UNIX will traditionally take you to the hard-coded +parent node -- but this is usually not what you want. Usually you want to go +back to the logical parent from which you came. That is called "lexical" +resolution. + +Some application already use lexical resolution internally for that reason. It +is generally agreed that many problems could be avoided if the standard +filesystem lookup calls used lexical resolution as well. The compatibility +problems probably would be negligible. + +The goal of this project is to modify the filename lookup mechanism in the Hurd +to use lexical resolution, and to check that the system is still fully +functional afterwards. This task requires understanding the filename resolution +mechanism. + +See also [[!GNU_Savannah_bug 17133]]. + +Possible mentors: Carl Fredrik Hammar (cfhammar) + +Exercise: This project requires changes to the name lookup mechanism in the +Hurd-related glibc parts, as well as the Hurd servers. Thus, the exercise task +should involve hacking glibc or Hurd servers, or even both. Fixing the bug in +the client-side nfs translator (/hurd/nfs) that makes "rmdir foo/" fail while +"rmdir foo" works, seems a good candidate. diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn new file mode 100644 index 00000000..1346203d --- /dev/null +++ b/community/gsoc/project_ideas/libcap.mdwn @@ -0,0 +1,41 @@ +[[!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="Implementing libcap"]] + +libcap is a library providing the API to access POSIX capabilities. These allow +giving various kinds of specific privileges to individual users, without giving +them full root permissions. + +Although the Hurd design should facilitate implementing such features in a quite +natural fashion, there is no support for POSIX capabilities yet. As a +consequence, libcap is not available on the Hurd, and thus various packages +using it can not be easily built in Debian GNU/Hurd. + +The first goal of this project is implementing a dummy libcap, which doesn't +actually do anything useful yet, but returns appropriate status messages, so +program using the library can be built and run on Debian GNU/Hurd. + +Having this, actual support for at least some of the capabilities should be +implemented, as time permits. This will require some digging into Hurd +internals. + +Some knowledge of POSIX capabilities will need to be obtained, and for the +latter part also some knowledge about the Hurd architecture. This project is +probably doable without previous experience with either, though. + +David Hedberg applied for this project in 2010, +and though he didn't go through with it, +he fleshed out many [[libcap/details]]. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Make libcap compile on Debian GNU/Hurd. It doesn't need to actually +do anything yet -- just make it build at all for now. diff --git a/community/gsoc/project_ideas/libcap/details.mdwn b/community/gsoc/project_ideas/libcap/details.mdwn new file mode 100644 index 00000000..aa27a84e --- /dev/null +++ b/community/gsoc/project_ideas/libcap/details.mdwn @@ -0,0 +1,766 @@ +[[!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="Details on implementing libcap"]] + + +This is the proposal submitted by David Hedberg for GSoC 2010 (who opted +to go with another mentoring organization), adapted from an initial +proposal and several amendments into a single document, but the idea +is to further adapt it to a more neutral design document over time. + + +# The proposal + +### Quick description of POSIX capabilities + +The original suggestion can be found [[here|libcap]]. +POSIX capabilities never actually entered the POSIX standard but was +left as a draft. Linux has nevertheless implemented this draft, and +there are reasons for doing the same in the Hurd - a more fine grained +control of rights leading to increased security being one of them. + +POSIX capabilities are give on a per-process basis, and basically allows +splitting up those rights usually granted to root into smaller and more +specific rights. Examples of capabilities are CAP_CHOWN and CAP_KILL, +overriding certain restrictions on chown and allowing the process to +kill processes with different UID's, respectively. + +Each process is given three sets with capabilities: the Permitted set +(P), the Effective set (E) and the Inheritable set (I). The effective +set contains the capabilities that are currently active. The permitted +set contains the capabilities that the process has the right to use. +The inheritable set contains the capabilities that can be inherited +by children to the process. A process can drop capabilities from its +permitted set, but not set them. The effective set and the inheritable +set can be changed freely as long as they stay subsets of the permitted +set. + +Capabilities can also be set on executables. When executed, the resulting +process is given the capabilities both as defined by the parent process +and by the capabilities set on the file (formula below), resulting in +what might be explained as a fine-grained setuid. Implementing this +requires support for *xattr* or similar. + +Some applications that are currently using capabilities are samba, ntp, +vsftp, pure-ftpd, proftpd, squid, asterisk and dovecot. + + +### A quick description of capabilities in Linux + +Each process has a three bit fields representing each of the three +sets (P, E and I). Each bit field is currently built up of two (32 +bit) integers to be able to hold the 33 currently defined capabilities +(see linux/capability.h). Each process further has a bounding set which +bounds the permitted set. Two syscalls handles the setting and getting +of capabilities; *capset* and *capget*. Some related functionality +can also be controlled by calling *prctl*: the right to read/drop the +bounding capabilities (PR_CAPBSET_READ/PR_CAPBSET_DROP) and whether +or not the process should keep its capabilities when a change is made +to the threads UID's (PR_SET_KEEPCAPS/PR_GET_KEEPCAPS). User space +applications are expected(recommended?) to use libcap to take advantage +of the functionality provided. Some applications also use libcap-ng +which is "intended to make programming with POSIX capabilities much +easier than the traditional libcap library". Most applications seem +to be using the original libcap, however. + + +## Implementing libcap + +The exercise for this assignment was to get the libcap used in +Linux to compile under the Hurd. This was accomplished using the +latest git version of libcap from (..), corresponding to libcap +2.19. The changes were simple and amounted to simply removing the +dependency on some Linux-specific headers and creating stubs for +capset, capget and prctl described above. This suggests that porting +this library to the Hurd once the proper functionality is in place +could be relatively simple. The patch is available +[here](https://alioth.debian.org/tracker/index.php?func=detail&aid=312442&group_id=30628&atid=410472 "Alioth"). +One could also consider implementing the three missing functions in the +Hurd (or Hurd glibc) which would allow the usage of the Linux libcap +without modifications. As the Linux libcap maintainer might or might +not be interested in making libcap multi platform, this approach might +be preferable. + + +## Implementing POSIX capabilities in the Hurd + +As I am still reading up on how things fit together in the Hurd this is +very likely to contain some misunderstandings and be at least partly off +the mark. I intend to have grasped this by the time I start working on +it however, if I were to be given the chance. Below are two possible +approaches as I have understood them after some reading and discussions +on #hurd@freenode. + + +### The basics, Approach 1: Special UID's + +Let each capability be represented by a specific UID. One could imagine +reserving a range of the possible uid_t's for this purpose. The euids +vector in the authhandle struct could perhaps hold the effective set while +the auids vector could hold the permitted set as these seem to roughly +correspond to eachother in intent. This leaves the Inheritable set. +One solution could be to store the inheritable set in the agids vector, +but that does not seem to be a very natural nor nice solution. One could +extend the authhandle struct with an additional vector, but one would then +need to also extend the auth interface with RPC's to be able to modify +and access it. Another possibility is to store all the capabilities +in the same idvec and use separate defines for the the different sets +(CAP_P_CHMOD, CAP_E_CHMOD, CAP_I_CHMOD). This does not seem like a +good solution. + +Storing each capability in its own uid_t might also arguably be somewhat +wasteful, although this is probably of secondary concern (if at all). +One could also imagine that legacy applications might be confused, +although I am not sure I can see any obvious problems. What happens +when a process have only capability id's? + + +### The basics, Approach 2: Extend the auth interface + +This approach would expand the auth interface and extend +the auth server with another set of RPC's for capabilities +(*auth_getcaps*, *auth_makecaps*, *auth_user_authenticate* and +*auth_server_authenticate*), mirroring those currently declared for id's. +This would obviously require changes to more parts of the Hurd for +processes to be able to take advantage of capabilities, but as the logic +behind handling capabilities and that behind handling user id's might +not be completely comparable, this might make for a cleaner solution. +It would also remove the problem of having to sensibly map all the +three capability sets onto semantically differing sets of user/group +ids, something that might be even more important if we were to also +implement something like the bounding sets used in Linux or perhaps +other related functionality. We are also not limited to having to store +the capabilities as id vectors, although doing so would perhaps still +make sense. + + +### The individual capabilities + +Implementing the individual capabilities will probably have to be thought +of on a case-by-case basis. Taking chown (in *libdiskfs*) as an example, +the exact approach would differ slightly depending on how the approach +taken to implement capabilities. If the first approach were to be taken, +the UID's (and thus the capabilities) of the caller would already be +available to the function through the *iouser* struct contained in the +*protid* struct given as the first argument. Implementing capabilities +would then simply be a matter of checking for the special UID's. If the +second approach were to be taken, one would need to perhaps expand the +iouser struct to contain information about the capabilities. + +Just like Linux has defined many Linux-specific capabilities - some of +which could certainly be useful also applied to the Hurd - one could +also imagine extending the POSIX capability system also for Hurd specific +purposes. + + +## Some applications using capabilities + +#### Samba 3 + +Uses CAP_MKNOD and CAP_LEASE in smbd to only keep the necessary abilities. +Documentation mentions CAP_LINUX_IMMUTABLE as a way to protect files +from being deleted. Can also use a couple of IRIX specific capabilities +(CAP_NETWORK_MGT and CAP_DEVICE_MGT) as alternatives to the Linux-specific +ones if running on IRIX. + + +#### ntpd + +Checks if capabilities are supported, more precisely if CAP_SYS_TIME, +CAP_SETUID, CAP_SETGID, CAP_SYS_CHROOT and CAP_NET_BIND_SERVICE are +supported. If they are supported, it uses prctl with PR_SET_KEEPCAPS +to keep privileges across setuid() and then drops root. After done with +CAP_SETUID, CAP_SETGID, CAP_SYS_CHROOT it drops every capability except +CAP_SYS_TIME and, if needed, CAP_NET_BIND_SERVICE. + + +#### vsftpd + +Uses CAP_CHOWN, CAP_NET_BIND_SERVICE when using the "one process" +security model (typically disabled by default). + + +#### proftpd-basic + +Provides support for capabilities from mod_cap. Uses CAP_USE_CHOWN, +CAP_USE_DAC_OVERRIDE, CAP_USE_DAC_READ_SEARCH and CAP_USE_AUDIT_WRITE. +Distribution contains README.capabilities with some explanations. +Also ships with their own libcap for some reason, based on libcap 1.10. + + +#### dovecot + +Keeps CAP_CHOWN, CAP_SYS_CHROOT, CAP_SETUID, CAP_SETGID, +CAP_NET_BIND_SERVICE, CAP_DAC_OVERRIDE for proper operations, drops +the rest. + + +#### bind9 + +Reasons for each capability are clearly noted in comments in update.c +in linux_initialprivs() and linux_minprivs(). initialprivs drops all +capabilities and proceeds to set CAP_NET_BIND_SERVICE, CAP_SYS_CHROOT, +CAP_SETUID, CAP_SETGID, CAP_DAC_READ_SEARCH and CAP_CHOWN. minprivs only +sets CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE. + + +#### pulseaudio + +Mentions CAP_NICE (CAP_SYS_NICE), but does not appear to be using it +(anymore?). Seems to use libcap to drop caps, however. + + +#### pinentry + +Checks if CAP_IPC_LOCK is available and "uses it" to gain only the +ability to lock memory when needed. + + +#### zsh + +Comes with a module "caps" which contains "[b]uiltins for manipulating +POSIX.1e (POSIX.6) capability (privilege) sets." Most useful here is the +"cap" builtin, which makes it possible to change the shell's process +capability sets. This might be useful for testing. + + +#### inetutils (ping,traceroute) + +Does not use capabilities explicitly, but is nevertheless a useful +example of how file capabilities could be used. ping and traceroute +are currently installed suid root since they need to be able to open +raw sockets. With file capabilities, this could be accomplished by +instead setting the capability CAP_NET_RAW on the two executables, +thus giving the utilities almost only the specific rights they need. + + +## The capabilities + +The above might give some hint as to what capabilities should be +prioritized. One assumption I have made is that the goal of this project +is to implement, as far as possible, the same functionality as what is +present in Linux. No effort has (so far) been made to look into possible +applications specific to the Hurd. + +A few of the above mentioned applications also explicitly uses +PR_SET_KEEPCAPS (through prctl()) to specify that capabilities should +be passed on to children. This means that the implementation in the +Hurd should take this into account. + +I have below done a preliminary classification of the capabilities +as defined in Linux capability.h into four "classes": Network, File +management, "glibc -> mach" and Other. There are also some capabilities +that either depend on functionality not implemented or are too Linux +specific. I have not described each capability in detail as looking +at the comments in capability.h and reading in capabilities(7) are +better sources. + + +### The Networking Class + +These would mostly affect pfinet. The general picture seem to be that +pfinet currently uses a boolean (int) isroot in struct sock_user to keep +track of the credentials of the caller. This would need to be expanded +somehow to keep track of the separate capabilities. + +CAP_NET_BIND_SERVICE: Allow binding to TCP/UDP sockets below 1024 +CAP_NET_RAW: Allow use of RAW and PACKET sockets. +CAP_NET_BROADCAST: "Allow broadcasting, listen to multicast" +CAP_NET_ADMIN: This seem to be a bit of a "catch-all" for network-related +administration. + + +### The Files Management Class + +The description of CAP_CHOWN in the original proposal should apply to +(most of?) these. That is, modify the iouser struct. At least libdiskfs +should be modified, but the same or similar modifications might need to +be made to several servers (libnetfs..? The actual servers implementing +the filesystem?) + +CAP_CHOWN: "Make arbitrary changes to file UIDs and GIDs" +CAP_FOWNER: allow chmod, utime, .. for files not owned. +CAP_FSETID: Don't clear setuid/setgid when a file is modified. +CAP_DAC_OVERRIDE and +CAP_DAC_READ_SEARCH: Bypasses file/directory read/write/execute permission +checks. ( hurdexec.c, file-access.c, .. ? ) +CAP_MKNOD: allows usage of "the privileged aspects of mknod()". Does this +one make sense in the Hurd? + + +### The (glibc -> gnumach) Class + +These seem to be implemented in glibc by direct calls to gnumach. +If they should be implemented, maybe a proxy in the Hurd is needed? + +CAP_SYS_TIME: manipulate the system clock, set real-time clock. +CAP_IPC_LOCK: mlock, mlockall, mmap, shmctl +CAP_KILL: No permission checks for killing processes +CAP_SYS_NICE: setpriority/getpriority for arbitrary processes. + + +### The Rest Class + +CAP_SYS_CHROOT: Allows usage of chroot(). +It's either really simple (not needed in the case of the Hurd) or really +difficult. Needs some figuring out. One of the calls that should be +high-priority. +CAP_SYS_ADMIN: General administration rights. Seemingly sprinkled out +into just about everything. Quick grep through the Linux sources gives +440 hits in .c-files. +CAP_SYS_BOOT: Allow use of reboot(). +glibc calls init:startup_reboot.. +CAP_SETGID: Allows usage of setgid,setgroups and "forged gids on socket +credentials passing" +CAP_SETUID: Allows usage of set*uid and "forged pids on socket credentials +passing" +CAP_SYS_TTY_CONFIG: vhangup, some other places. vhangup() is a stub in +the Hurd, but maybe the console server is otherwise affected? +CAP_SYS_RESOURCE: Override various limits. (quota, reserved space etc. +on ext2, interrupt frequencies, consoles,...). According to "The Critique" +mach performs no resource accounting so some of these might be moot to +implement, while others still apply. +CAP_SYS_RAWIO Allow raw input/output. Sprinkled in many places, +device drivers among others. Many of these will probably be difficult +to implement. +CAP_SETPCAP: This one has (or had?) two different usages in Linux: +If file capabilities are not supported it gives the right to grant +or remove capabilities from the permitted set of arbitrary processes. +If file capabilities are supported, it allows for removing capabilities +from the bounding set of the current process. As the Hurd implementation +won't have file capabilities initially it might make sense to implement +this if possible. If bounding sets are implemented this should probably +be the way provided to modify them. + + +### Unimplementable + +*(At this point in time, as far as I can determine)* + +CAP_LINUX_IMMUTABLE: depends on chattr etc. working. +CAP_SETFCAP: depends on xattr's +CAP_SYS_PACCT: acct() missing in the Hurd. +CAP_SYS_MODULE, CAP_SYS_PTRACE, CAP_MAC_OVERRIDE, CAP_MAC_ADMIN, +CAP_AUDIT_WRITE, CAP_AUDIT_CONTROL, CAP_LEASE + + +## Priority when implementing + +The two most used capabilities as unscientifically judged from +the selection of applications above are CAP_NET_BIND_SERVICE and +CAP_CHOWN, suggesting that implementing the "network class" and the +"file management" class of capabilities as classified above might be a +good start. These also, to me, seem to be easier classes to implement. +CAP_NET_ADMIN might need some extra work. + +Second most common were CAP_SYS_CHROOT, CAP_SETGID and CAP_SETUID. I am +not completely clear on how these should be handled. + +Assuming those are out of the way, CAP_IPC_LOCK, CAP_SYS_TIME, CAP_KILL +and CAP_SYS_NICE might be a good choice to tackle if possible. This +might, if I have understood things correctly, involve writing a proxy +Hurd server for these calls in mach. + +CAP_SYS_ADMIN, CAP_SYS_RESOURCE and CAP_SYS_RAWIO. These contains a bit +of "everything" (ADMIN being the worse one), meaning that experience +and infrastructure gained from implementing the previous capabilities +might come in handy. CAP_SYS_RAWIO might be difficult; it can be found +inside many drivers in the Linux source. + + +## Additional general details + +[This article](http://www.ibm.com/developerworks/library/l-posixcap.html) +contains a good general description of how capabilities in Linux +works. As there will be no file capabilities in the Hurd initially, +an approach emulating the behavior Linux exhibits when SECURE_NOROOT +and SECURE_NO_SETUID_FIXUP are *not* set seems to be a good start. +This is called the "root-user-is-privileged" model in the article, +and somewhat simplified it means that processes started by root, or +setuid-root, is given all capabilities no matter what capabilities the +parent might or might not hold at the time of execution. Quoting verbatim +from the article: + +> * When SECURE_NOROOT is not set, then when a process executes a file, +> the new capability sets may be calculated as though the file had some +> file capability sets set fully populated. In particular: +> +> * The file inheritable and permitted sets will be full on if the +> process's real or effective uid is 0 (root) or the file is setuid +> root. +> +> * The file effective set will be full on if the process's effective +> uid is root or the file is setuid root. +> +> +> * When SECURE_NO_SETUID_FIXUP is not set, then when a process switches +> its real or effective uids to or from 0, capability sets are further +> shifted around: +> +> * If a process switches its effective uid from 0 to non-0, then its +> effective capability set is cleared. +> +> * If a process switches its real, effective, or saved uids from at +> least one being 0 to all being non-zero, then both the permitted +> and effective capabilities are cleared. +> +> * If a process sets its effective uid from non-zero to 0, then the +> effective capabilities are set equal to the permitted capabilities. + +The capabilities of the resulting process are determined by the following +formulas, again taken from the article, with p for Process and f for file: + +> pI' = pI +> pP' = fP | (fI & pI) +> pE' = pP' & fE + +The security under the above described model, being what at least some +of the applications I listed in my last comment employs, is basically +the following (also detailed somewhat in the same article): + +* Execute process as root (or setuid) to gain all capabilities. + +* Use the prctl system call to enable keepcaps for the process + (same(?) effect as enabling SECURE_NO_SETUID_FIXUP for the process). + keepcaps should be off by default. + +* setuid to a non-root user, and by doing so losing the possibility to + regain capabilities by simply starting a new process. + +* Drop all the capabilities except those few actually needed. + + +## Infrastructure details - Special UIDs approach + +The auth server must somehow keep track of three sets of capabilities. +I suggest keeping these three sets in three additional idvec's in the +authhandle struct, and will for the purpose of this description name +these pcaps (permitted), ecaps (effective) and icaps (inheritable). +This will simplify keeping track of the internal logic somewhat. +In addition to this, there is a need to keep track of the "keepcaps" flag +as described above. I suggest representing this with an int keepcaps +in the same struct. + +1. Expand authhandle struct with three additional idvecs and one integer. +Fix static functions handling the struct, such as destroy_authhandle. + +2. Implement the necessary logic in auth_makeauth to handle capabilities. + +Problems: +Assume that all capabilities are mapped onto uids, given names on the form +uid_<capability>, for example uid_cap_net_raw. Assume that the presence +of an uid in euids suggest that the capability is in the effective set +of the process, that the presence of this uid in auids suggests that it +is in the permitted set of the process, and that the presence of this +uid in aguids suggest that it is in the inheritable set of the process. +That they are internally stored in separate idvec's can be ignored as +an implementation detail. + +* The UID's have as it is different meanings depending on where in the + array they are positioned, and certain clients seem to rely on this. + The first UID in euids is the effective uid, and the first and second + UIDs in auids are the real and saved UIDS respectively. At least + some users of makeauth would need to made aware of capabilities, + for example setuid in glibc. + +* Setting/getting the keepcaps-flag is also a bit of a problem. To avoid + changing the auth interface yet another special UID could be used + for this purpose, although that seems to be really stretching it. + The cleaner solution would probably be to expand the interface with + something along the lines of auth_setkeepcaps/auth_getkeepcaps. + This interface would only be used by prctl. + +Another problem with this approach is that it seems a bit difficult +to oversee the affects that using other RPC's like fsys_getroot and +io_restrict_auth might have on capabilities. + + +## Infrastructure details - "extend-interfaces" approach + +This approach has started to seem like the better way to me, as the +usage of capabilities becomes more explicit through the entire "chain", +perhaps making it somewhat more easy to understand all the interactions. + +I suggest something like the following new interface methods: + +*** + + +### The auth interface + + routine auth_getauth_caps ( + handle: auth_t; + out euids: idarray_t; + out auids: idarray_t; + out egids: idarray_t; + out agids: idarray_t; + out ecaps: idarray_t; + out pcaps: idarray_t; + out icaps: idarray_t); + + routine auth_makeauth_caps ( + handle: auth_t; + other_handles: portarray_t; + euids: idarray_t; + auids: idarray_t; + egids: idarray_t; + agids: idarray_t; + ecaps: idarray_t; + pcaps: idarray_t; + icaps: idarray_t; + flags: int; /* keepcaps.. ? */ + out newhandle: mach_port_make_send_t); + + routine auth_server_authenticate_caps ( + handle: auth_t; + sreplyport reply: mach_port_poly_t; + rendezvous: mach_port_send_t; + newport: mach_port_poly_t; + out euids: idarray_t; + out auids: idarray_t; + out egids: idarray_t; + out agids: idarray_t; + out ecaps: idarray_t; + out pcaps: idarray_t; + out icaps: idarray_t); + + +### The io interface + + routine io_restrict_auth_caps ( + io_object: io_t; + RPT + out new_object: mach_port_send_t; + uids: idarray_t SCP; + gids: idarray_t SCP; + ecaps: idarray_t SCP); + + +### The fsys interface + + routine fsys_getroot_caps ( + fsys: fsys_t; + RPT + #ifdef FSYS_GETROOT_UREPLY + ureplyport ureply: mig_reply_port_t; + #endif + dotdot_node: mach_port_send_t; + gen_uids: idarray_t; + gen_gids: idarray_t; + out ecaps: idarray_t; + out pcaps: idarray_t; + out icaps: idarray_t; + flags: int; + out do_retry: retry_type; + out retry_name: string_t; + out file: mach_port_send_t); + +*** + +These are meant to be able to replace the old methods with +capability-aware methods, instead of merely complementing them. +The replacing work could then be made a more gradual process. Steps: + +* Extend authhandle with the same data members as in the UID-case. + +* Implement new _caps-functions according to described interface + extensions above, refactor code a bit to share common uid-handling + logic. Both makeauth's should drop all capabilities if switching from + uid 0 without having keepcaps. For example, keepcaps should be unset + by default. + +* Fix glibc. Extend hurd_id_data in hurd/id.h to store capabilities, + switch to capability aware functions where necessary. + +* io-reauthenticate. Fix implementations to use + auth_server_authenticate_caps instead. For this we also need somewhere + to save the caps, so it ties in with for example the extension of + iouser as mentioned in the details. + +* fsys_getroot. Implement fsys_getroot_caps in libdiskfs, trans, + libtreefs, libtrivs, libnetfs. Fix users of function in libdiskfs, + libfshelp, settrans, libtreefs, clookup. + +* io_restrict_auth. Implement io_restrict_auth_caps in libdiskfs, + libtreefs, libtrivfs, libnetfs, boot. Fix users in utils(symlink, + firmlink), libtrivs, term, clookup + +Among the problems might be that there are a lot of arguments that +needs to be passed around, and that it seems somewhat ugly to end up +with function names referencing caps in particular. + +Below some more about the specific capabilities. This should in large +be common to the two approaches above. + + +## Actually handing out the capabilities to process + +This seems like a good job for the file_exec route in the fs interface. +Quoting from the comments above the definition in fs.defs: "*Necessary +initialization, including authentication changes associated with set[ug]id +execution must be handled by the filesystem*". The capability-granting +functionality should to be added in at least the implementations in +libdiskfs and libnetfs as far as I can determine, and should be "easy +enough" once the infrastructure for implementing the file-related +capabilities (CAP_CHOWN etc.) are in place. This also seem to make +sense considering the future possibility for file capabilities. + + +## Some implementation details of individual capabilities. + +### Net-related capabilities. + +This turned out to be a bit less work than I had thought, as the +imported Linux code already seem to contain all the necessary checks. +What remains to do to implement all of these capabilities is mostly a +matter of putting some infrastructure in place. + +* In struct sock_user (pfinet.h), change isroot for idvec + caps. Alternatively, add idvec caps. + +* Change the function make_sock_user in socket.c to take an idvec caps + as a parameter and properly set the given caps to the corresponding + idvec in sock_user. + +* Fix users of make_sock_user: S_io_reauthenticate, S_io_restrict_auth, + S_socket_create, S_socket_accept. This should be doable with the + current infrastructure. For example, S_socket_create currently + sets isroot in the new sock_user from the corresponding member in + the trivfs_protid struct. This does not present a problem however, + as the latter struct also provides access to an iouser (iohelp.h) + from which the needed uids of the user should be available. + +* Fix up parts of source from Linux, modify task_struct add idvec, + modify prepare_current to take the caps idvec instead of isroot. + Re-implement the existing function capable(int cap) to actually check + for the capability passed as an argument instead of just return isroot. + +* Change a few isroot's at 3 other places in the code to check for + capabilities. Since these places all have access to isroot and thus by + implication the sock_user, they also have access to the new capability + information; no restructuring necessary. + + +### File-related capabilities + +While there are a lot of servers in the Hurd, I am not sure all of these +capabilities actually make sense to implement in all of them. + + +#### CAP_CHOWN + +Implementing this in libdiskfs should take care of it where it makes +sense. Servers using libdiskfs uses iouser from libiohelp to hold +user credentials. As noted above, this struct is already capable of +holding our capabilities as uid's or is otherwise extended to contain +the necessary idvecs if using the second general approach. Adding a +check along the lines of *idvec_contains(uid_cap_chown)* in function +diskfs_S_file_chown (file-chown.c) should be all that's needed. + +In libnetfs, netfs_attempt_chown is declared as a function that the +server using the library must implement. Any checks for chown rights +are however most likely performed on the server side, suggesting that +there is nothing we can do here to implement CAP_CHOWN. Even if we do +need to add something, an iouser containing the necessary information +to implement the checks in a manner analogous to that in libdiskfs seems +to be passed to each important function. + + +#### CAP_DAC_* + +These might actually make sense to implement in more servers, and the +logic seems somewhat involved. Need to add the necessary checks to +at least file_check_access, file_exec in libdiskfs. file_exec also in +libnetfs, probably. Possibly changes also in other places. + +The main difficulties overall seem to lie in getting the infrastructure +properly in place rather than implementing most of the individual +capabilities, and I have updated the schedule a bit in an attempt to +reflect this. + + +## Schedule updating + +The more I look into this the less time it seems likely to take to +do the work. Below is my best estimation at the moment, and I have +basically adjusted everything to what I think is more likely estimations. +If this is correct I would be more or less around midterm. I haven't +gone completely to the individual level as that doesn't seem to make +sense, but what is clustered together are either related capabilities +or a collection of capabilities classified roughly with regards to how +much I know about the area and how many different rights they control. +It's not my intention to "slack off" or anything, so if this estimation +were to be correct I could perhaps take a look at the xattrs-patch, +or spend the rest of my time fixing PATH_MAX-issues. Then again, maybe +there is some great difficulty hidden somewhere. + + +#### Some justifications: + +Dummy libcap, more or less done. +*1 day* (making sure it "fails gracefully" shouldn't really take longer than this) + +Application for testing, the beginnings of a fairly extensive "test suit" on Linux. +*2 days* + +Basic infrastructure. +*5 days*, depends on the chosen approach, but it is probably wise to +reserve at least a bunch of days for this. + +Implementations of prctl/capset/capget in libshouldbeinlibc, +or a port of libcap to the Hurd in any other way. +*5 days* + +CAP_NET_BIND_SERVICE, CAP_NET_RAW, CAP_NET_BROADCAST, CAP_NET_ADMIN +*4 days*, as noted above this should be easy, but it might uncover bugs +in the newly implemented infrastructure for example. + +CAP_CHOWN,CAP_FOWNER,CAP_FSETID +*2 days*, I think these only needs to be done in libdiskfs + +CAP_DAC_OVERRIDE,CAP_DAC_READ_SEARCH +*4 days*, these might need changes to various servers + +CAP_SYS_TIME,CAP_IPC_LOCK,CAP_KILL +CAP_SYS_NICE,CAP_SYS_CHROOT,CAP_SYS_BOOT +*2 weeks*, these are varied and I'm not that sure exactly how each should +be tackled so some research is needed. + +CAP_SETGID,CAP_SETUID,CAP_SYS_TTY_CONFIG +*4 days* + +CAP_SYS_ADMIN,CAP_SYS_RESOURCE,CAP_SYS_RAWIO +*2 weeks*, these too are pretty varied and some might need some individual +researching + +CAP_SETPCAP +*1 day* + + +## Schedule + +24/5 Start coding +25/5 Dummy libcap ready for use. +27/5 The beginnings of a "test suite", written on Linux. + 1/6 Basic infrastructure in place + 6/6 Dummy libcap extended with real functionality to make use of + implemented capability and infrastructure, or the Hurd adapted for + compatibility with Linux libcap. +10/6 The "network class" of capabilities implemented. +12/6 CAP_CHOWN, CAP_FOWNER, CAP_FSETID +16/6 CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH +30/6 CAP_SYS_TIME, CAP_IPC_LOCK, CAP_KILL, CAP_SYS_NICE, + CAP_SYS_CHROOT, CAP_SYS_BOOT + 4/7 CAP_SETGID,CAP_SETUID,CAP_SYS_TTY_CONFIG +12/7 "Mentors and students can begin submitting mid-term evaluations" +16/7 GSoC Mid-term evaluations deadline. +18/7 CAP_SYS_ADMIN, CAP_SYS_RESOURCE, CAP_SYS_RAWIO +19/7 CAP_SETPCAP diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn new file mode 100644 index 00000000..0618bbe6 --- /dev/null +++ b/community/gsoc/project_ideas/libdiskfs_locking.mdwn @@ -0,0 +1,41 @@ +[[!meta copyright="Copyright © 2008, 2009, 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="Fix libdiskfs Locking Issues"]] + +Nowadays the most often encountered cause of Hurd crashes seems to be lockups +in the [[hurd/translator/ext2fs]] server. One of these could be traced +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. + +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 +locking in various code paths. (The latter could serve as a template for +implementing unit checks in other parts of the Hurd codebase...) + +(A systematic code review 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...) + +[Linux' *sparse*](https://sparse.wiki.kernel.org/) could be worth looking at. + +This task requires experience with debugging locking issues in multithreaded +applications. + +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/libgtop.mdwn b/community/gsoc/project_ideas/libgtop.mdwn new file mode 100644 index 00000000..14304de2 --- /dev/null +++ b/community/gsoc/project_ideas/libgtop.mdwn @@ -0,0 +1,34 @@ +[[!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="Porting libgtop"]] + +libgtop is a library used by many applications (especially GNOME applications) +to abstract the system-specific methods for obtaining information about the +current state of the system -- processes running, system load etc. + +A [[Linux-compatible_procfs|madhusudancs]] implementation has been created +during GSoC 2008, and should cover a large part of the functionality of +libgtop. However, not all necessary information is exported via /proc (even on +Linux); there are some bits still missing in the Hurd procfs implementation; +and there are a couple of bugs that need to be fixed to make it fully usable. + +The goal of this project is a fully functional libgtop in Debian GNU/Hurd. Some +application(s) using it also need to be ported, e.g. gnome-system-monitor. + +Some bits of this work are easy, others need some digging into Hurd internals. +This task doesn't require any specific previous knowledge (besides of general +C/UNIX programming skills of course); but during the course of the project, +some knowledge about Hurd internals will have to be obtained, along with a bit +of Debian stuff. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Fix one of the shortcomings in the existing procfs implementation. diff --git a/community/gsoc/project_ideas/maxpath.mdwn b/community/gsoc/project_ideas/maxpath.mdwn new file mode 100644 index 00000000..5be8917f --- /dev/null +++ b/community/gsoc/project_ideas/maxpath.mdwn @@ -0,0 +1,46 @@ +[[!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="Fixing Programs Using PATH_MAX et al Unconditionally"]] + +POSIX describes some constants (or rather macros) like PATH_MAX/MAXPATHLEN and +similar, which may be defined by the system to indicate certain limits. Many +people overlook the *may* though: Systems only should define them if they +actually have such fixed limits. The Hurd, following the GNU Coding Standards, +tries to avoid this kind of arbitrary limits, and consequently doesn't define +the macros. + +Many programs however just assume their presence, and use them unconditionally. +This is simply sloppy coding: not only does it violate POSIX and fails on +systems not defining the macros, but in fact most common use cases of these +macros are simply wrong! (See +<http://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html> for some +hints as to why this is so.) + +There are a few hundred packages in Debian GNU/Hurd failing to build because of +this -- simply grep for the offending macros in the +[list_of_build_failures](http://unstable.buildd.net/buildd/hurd-i386_Failed.html). + +Fixing these issues usually boils down to replacing `char foo[PATH_MAX]` +by `char *foo`, and using dynamic memory allocation, i.e. e.g. a loop +that tries geometrically growing sizes. Sometimes this is tricky, but +more often not very hard. Sometimes it is even trivial because the GNU +system has proper replacements. See the corresponding section of the +[[porting_guidelines_page|hurd/porting/guidelines]] for more details. With a bit of +practice, it should be easily possible to fix several programs per day. + +The goal of this project is to fix the PATH_MAX and related problems in a +significant number of packages, and make the fixes ready for inclusion in +Debian and (where possible) upstream. No Hurd-specific knowledge is needed, nor +any other special knowledge aside from general C programming skills. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Fix the PATH_MAX issues in some Debian package. diff --git a/community/gsoc/project_ideas/mtab.mdwn b/community/gsoc/project_ideas/mtab.mdwn new file mode 100644 index 00000000..a60a8038 --- /dev/null +++ b/community/gsoc/project_ideas/mtab.mdwn @@ -0,0 +1,74 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="mtab"]] + +In traditional monolithic system, the kernel keeps track of all mounts; the +information is available through `/proc/mounts` (on Linux at least), and in a +very similar form in `/etc/mtab`. + +The Hurd on the other hand has a totally +[[decentralized_file_system|hurd/virtual_file_system]]. There is no single +entity involved in all mounts. Rather, only the parent file system to which a +mountpoint ([[hurd/translator]]) is attached is involved. As a result, there +is no central place keeping track of mounts. + +As a consequence, there is currently no easy way to obtain a listing of all +mounted file systems. This also means that commands like `df` can only work on +explicitly specified mountpoints, instead of displaying the usual listing. + +One possible solution to this would be for the translator startup mechanism to +update the `mtab` on any `mount`/`unmount`, like in traditional systems. +However, there are some problems with this approach. Most notably: what to do +with passive translators, i.e., translators that are not presently running, but +set up to be started automatically whenever the node is accessed? Probably +these should be counted among the mounted filesystems; but how to handle the +`mtab` updates for a translator that is not started yet? Generally, being +centralized and event-based, this is a pretty inelegant, non-hurdish solution. + +A more promising approach is to have `mtab` exported by a special translator, +which gathers the necessary information on demand. This could work by +traversing the tree of translators, asking each one for mount points attached +to it. (Theoretically, it could also be done by just traversing *all* nodes, +checking each one for attached translators. That would be very inefficient, +though. Thus a special interface is probably required, that allows asking a +translator to list mount points only.) + +There are also some other issues to keep in mind. Traversing arbitrary +translators set by other users can be quite dangerous -- and it's probably not +very interesting anyways what private filesystems some other user has mounted. +But what about the global `/etc/mtab`? Should it list only root-owned +filesystems? Or should it create different listings depending on what user +contacts it?... + +That leads to a more generic question: which translators should be actually +listed? There are different kinds of translators: ranging from traditional +filesystems ([[disks|hurd/libdiskfs]] and other actual +[[stores|hurd/translator/storeio]]), but also purely virtual filesystems like +[[hurd/translator/ftpfs]] or [[hurd/translator/unionfs]], and even things that +have very little to do with a traditional filesystem, like a +[[gzip_translator|hurd/translator/storeio]], +[[mbox_translator|hurd/translator/mboxfs]], +[[xml_translator|hurd/translator/xmlfs]], or various device file translators... +Listing all of these in `/etc/mtab` would be pretty pointless, so some kind of +classification mechanism is necessary. By default it probably should list only +translators that claim to be real filesystems, though alternative views with +other filtering rules might be desirable. + +After taking decisions on the outstanding design questions, the student will +implement both the actual [[mtab_translator|hurd/translator/mtabfs]], and the +necessary interface(s) for gathering the data. It requires getting a good +understanding of the translator mechanism and Hurd interfaces in general. + +Possible mentors: Olaf Buddenhagen (antrik), Carl Fredrik Hammar (cfhammar) + +Exercise: Make some improvement to any of the existing Hurd translators. +Especially those in [hurdextras](http://www.nongnu.org/hurdextras/) are often +quite rudimentary, and it shouldn't be hard to find something to improve. diff --git a/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn b/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn new file mode 100644 index 00000000..67e3fc28 --- /dev/null +++ b/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn @@ -0,0 +1,82 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="Namespace-based Translator Selection"]] + +The main idea behind the Hurd is to make (almost) all system functionality +user-modifiable ([[extensible_system|extensibility]]). This includes a +user-modifiable filesystem: the whole filesystem is implemented decentrally, by +a set of filesystem servers forming the directory tree together, a +[[hurd/virtual_file_system]]. These filesystem servers are called +[[translators|hurd/translator]], and are the most visible feature of the Hurd. + +The reason they are called translators is because when you set a translator on +a filesystem node, the underlying node(s) are hidden by the translator, but the +translator itself can access them, and present their contents in a different +format -- translate them. A simple example is a +[[gunzip_translator|hurd/translator/storeio]], which can be set on a gzipped +file, and presents a virtual file with the uncompressed contents. Or the other +way around. Or a translator that presents an +[[XML_file_as_a_directory_tree|hurd/translator/xmlfs]]. Or an mbox as a set of +individual files for each mail ([[hurd/translator/mboxfs]]); or ever further +breaking it down into headers, body, attachments... + +This gets even more powerful when translators are used as building blocks for +larger applications: A mail reader for example doesn't need backends for +understanding various mailbox formats anymore. All formats can be parsed by +special translators, and the mail reader gets the data as a uniform, directly +usable filesystem structure. Translators can also be stacked: If you have a +compressed mailbox for example, first apply a gunzip translator, and then an +mbox translator on top of that. + +There are a few problems with the way translators are set, though. For one, +once a translator is set on a node, you always see the translated content. If +you need the untranslated contents again, to do a backup for example, you first +need to remove the translator again. Also, having to set a translator +explicitly before accessing the contents is pretty cumbersome, making this +feature almost useless. + +A possible solution is implementing a mechanism for selecting translators +through special filename attributes. For example you could use +`index.html.gz,,+` and `index.html.gz,,-` to choose between translated and +untranslated versions of a file. Or you could use `index.html.gz,,u` to get +the contents of the file with a gunzip translator applied automatically. You +could also use attributes on whole directory trees: `.,,0/` would give you a +directory tree corresponding to the current directory, but with any translators +disabled, for doing a backup. And `site,,u/*.html.gz` would present a whole +directory tree of compressed HTML files as uncompressed files. + +One benefit of the Hurd's flexibility is that it should be possible to +implement such a mechanism without touching the existing Hurd components: +Rather, just implement a special proxy, that mirrors the normal filesystem, but +is able to interpret the special extensions and present transformed files in +place of the original ones. + +In the long run it's probably desirable to have the mechanism implemented in +the standard name lookup mechanism, so it will be available globally, and avoid +the overhead of a proxy; but for the beginning the proxy solution is much more +flexible. + +The goal of this project is implementing a prototype proxy; perhaps also a +first version of the global variant as proof of concept, if time permits. It +requires good understanding of the name lookup mechanism, and translator +programming; but the implementation should not be too hard. Perhaps the hardest +part is finding a convenient, flexible, elegant, hurdish method for mapping the +special extensions to actual translators... + +Possible mentors: Olaf Buddenhagen (antrik) + +Exercise: Try to make some modification to the existing unionfs and/or firmlink +translators. (More specific suggestions welcome... :-) ) + +*Status*: Sergiu Ivanov has been working *voluntarily* on +[[namespace-based_translator_selection|scolobb]], as an inofficial GSoC 2008 +participant! Not all the desired functionality is in place yet; work is +ongoing. diff --git a/community/gsoc/project_ideas/nfs.mdwn b/community/gsoc/project_ideas/nfs.mdwn new file mode 100644 index 00000000..e7c18324 --- /dev/null +++ b/community/gsoc/project_ideas/nfs.mdwn @@ -0,0 +1,45 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="Improved NFS Implementation"]] + +The Hurd has both NFS server and client implementations, which work, but not +very well: File locking doesn't work properly (at least in conjunction with a +GNU/Linux server), and performance is extremely poor. Part of the problems +could be owed to the fact that only NFSv2 is supported so far. + +(Note though that locking on the Hurd is problematic in general, not only in +conjunction with NFS -- see the [[file_locking]] task.) + +This project encompasses implementing NFSv3 support, fixing bugs and +performance problems -- the goal is to have good NFS support. The work done in +a previous unfinished GSoC project can serve as a starting point. + +Both client and server parts need work, though the client is probably much more +important for now, and shall be the major focus of this project. + +Some [discussion of NFS +improvements](http://lists.gnu.org/archive/html/bug-hurd/2008-04/msg00035.html) +has been done for a former GSoC application -- it might give you some pointers. +But don't take any of the statements made there for granted -- check the facts +yourself! + +This task, [[!GNU_Savannah_task 5497]], has no special prerequisites besides general programming skills, and +an interest in file systems and network protocols. + +Possible mentors: ? + +Exercise: Look into one of the existing issues in the NFS code. It's quite +possible that you will not be able to fix any of the visible problems before +the end of the application process; but you might discover something else you +could improve in the code while working on it :-) + +If you can't find anything suitable, talk to us about possible other exercise +tasks. diff --git a/community/gsoc/project_ideas/package_manager.mdwn b/community/gsoc/project_ideas/package_manager.mdwn new file mode 100644 index 00000000..23304f6b --- /dev/null +++ b/community/gsoc/project_ideas/package_manager.mdwn @@ -0,0 +1,51 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="Hurdish Package Manager for the GNU System"]] + +Most GNU/Linux systems use pretty sophisticated package managers, to ease the +management of installed software. These keep track of all installed files, and +various kinds of other necessary information, in special databases. On package +installation, deinstallation, and upgrade, scripts are used that make all kinds +of modifications to other parts of the system, making sure the packages get +properly integrated. + +This approach creates various problems. For one, *all* management has to be +done with the distribution package management tools, or otherwise they would +loose track of the system state. This is reinforced by the fact that the state +information is stored in special databases, that only the special package +management tools can work with. + +Also, as changes to various parts of the system are made on certain events +(installation/deinstallation/update), managing the various possible state +transitions becomes very complex and bug-prone. + +For the official (Hurd-based) GNU system, a different approach is intended: +making use of Hurd [[translators|hurd/translator]] -- more specifically their +ability to present existing data in a different form -- the whole system state +will be created on the fly, directly from the information provided by the +individual packages. The visible system state is always a reflection of the +sum of packages installed at a certain moment; it doesn't matter how this state +came about. There are no global databases of any kind. (Some things might +require caching for better performance, but this must happen transparently.) + +The core of this approach is formed by [[hurd/translator/stowfs]], which +creates a traditional Unix directory structure from all the files in the +individual package directories. But this only handles the lowest level of +package management. Additional mechanisms are necessary to handle stuff like +dependencies on other packages. + +The goal of this task is to create these mechanisms. + +Possible mentors: Ben Asselstine (bing) + +Exercise: Make some improvement to any of the existing Hurd translators. +Especially those in [hurdextras](http://www.nongnu.org/hurdextras/) are often +quite rudimentary, and it shouldn't be hard to find something to improve. diff --git a/community/gsoc/project_ideas/perl_python.mdwn b/community/gsoc/project_ideas/perl_python.mdwn new file mode 100644 index 00000000..34e877ab --- /dev/null +++ b/community/gsoc/project_ideas/perl_python.mdwn @@ -0,0 +1,38 @@ +[[!meta copyright="Copyright © 2009, 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="Improving Perl or Python Support"]] + +Perl and Python are available on the Hurd, but there are quite a lot of test suite +failures. These could be caused by problems in the system-specific +implementation bits of Perl/Python, and/or shortcomings in the actual system +functionality which Perl/Python depends on. + +The student applying for this project can pick either Perl or Python, +whichever he is more comfortable with. +(Perl is higher priority though; and there are more failures too.) + +The goal then is to fix all of the problems with the chosen language if possible, or at +least some of them. Some issues might require digging quite deep into Hurd +internals, while others are probably easy to fix. + +Note that while some Perl/Python knowledge is probably necessary to understand what +the test suite failures are about, the actual work necessary to fix these +issues is mostly C programming -- in the implementation of Perl/Python and/or the +Hurd. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Take a stab at one of the testsuite failures, +and write a minimal testcase exposing the underlying problem. +Actually fixing it would be a bonus of course -- +but as it's hard to predict which issues will be easy and which will be tricky, +we will already be satisfied if the student makes a good effort. +(We hope to see some discussion of the problems in this case though :-) ) diff --git a/community/gsoc/project_ideas/procfs.mdwn b/community/gsoc/project_ideas/procfs.mdwn new file mode 100644 index 00000000..d4760aae --- /dev/null +++ b/community/gsoc/project_ideas/procfs.mdwn @@ -0,0 +1,45 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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. diff --git a/community/gsoc/project_ideas/pthreads.mdwn b/community/gsoc/project_ideas/pthreads.mdwn new file mode 100644 index 00000000..61c8c079 --- /dev/null +++ b/community/gsoc/project_ideas/pthreads.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="Convert Hurd Libraries and Servers to pthreads"]] + +[[!tag open_issue_pthread]] + +The Hurd was originally created at a time when the [pthreads +standard](http://www.opengroup.org/onlinepubs/009695399/basedefs/pthread.h.html) +didn't exist yet. Thus all Hurd servers and libraries are using the old +[[cthreads|hurd/libcthreads]] package that came with [[microkernel/Mach]], +which is not compatible with [[pthreads|hurd/libpthread]]. + +Not only does that mean that people hacking on Hurd internals have to deal with +a non-standard thread package, which nobody is familiar with. Although a +pthreads implementation for the Hurd was created in the meantime, it's not +possible to use both cthreads and pthreads in the same program. Consequently, +pthreads can't presently be used in any Hurd servers -- including translators. + +(Thus it's impossible to use the [Hurd +libfuse](http://www.nongnu.org/hurdextras/#libfuse) with any FUSE modules +depending on pthreads for example.) + +Most of the conversion has already been done in previous efforts (see +[[!GNU_Savannah_task 5487]]) -- but the tricky parts are still missing. + +The goal of this project is to have all the Hurd code use pthreads. Should any +limitations in the existing pthreads implementation turn up that hinder this +transition, they will have to be fixed as well. + +This project requires relatively little Hurd-specific knowledge. Experience +with multithreaded programming in general and pthreads in particular is +required, though. + +Possible mentors: Barry deFreese (bddebian), Samuel Thibault (youpi) + +Exercise: Try to fix one of the outstanding issues with the work done so far. +It's not yet complete, and there hasn't been much debugging yet, so it should +not be too hard to find something needing improvement -- but if you don't see +anything obvious, feel free to talk to us about an alternative exercise task. diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn new file mode 100644 index 00000000..feb30a7c --- /dev/null +++ b/community/gsoc/project_ideas/secure_chroot.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="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 +good, as it allows easily escaping the `chroot`, for example by use of +[[passive_translators|hurd/translator]]. + +Many solutions have been suggested for this problem -- ranging from simple +workaround changing the behavior of passive translators in a `chroot`; +changing the context in which passive translators are executed; changing the +interpretation of filenames in a chroot; to reworking the whole passive +translator mechanism. Some involving a completely different approach to +`chroot` implementation, using a proxy instead of a special system call in the +filesystem servers. + +See <http://tri-ceps.blogspot.com/2007/07/theory-of-filesystem-relativity.html> +for some suggestions, as well as the followup discussions on +<http://lists.gnu.org/archive/html/gnu-system-discuss/2007-09/msg00118.html> +and <http://lists.gnu.org/archive/html/bug-hurd/2008-03/msg00089.html>. + +The task is to pick and implement one approach for fixing chroot. + +This task is pretty heavy: it requires a very good understanding of file name +lookup and the translator mechanism, as well as of security concerns in general +-- the student must prove that he really understands security implications of +the UNIX namespace approach, and how they are affected by the introduction of +new mechanisms. (Translators.) More important than the actual code is the +documentation of what he did: he must be able to defend why he chose a certain +approach, and explain why he believes this approach really secure. + +Possible mentors: Carl Fredrik Hammar (cfhammar) + +Exercise: It's hard to come up with a relevant exercise, as there are so many +possible solutions... Probably best to make an improvement to one of the +existing translators -- if possible, something touching name resolution or and +such, e.g. implementing file_reparent() in a translator that doesn't support it +yet. diff --git a/community/gsoc/project_ideas/server_overriding.mdwn b/community/gsoc/project_ideas/server_overriding.mdwn new file mode 100644 index 00000000..c35d88de --- /dev/null +++ b/community/gsoc/project_ideas/server_overriding.mdwn @@ -0,0 +1,74 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!meta title="Server Overriding Mechanism"]] + +The main idea of the Hurd is that every user can influence almost all system +functionality ([[extensible_system|extensibility]]), by running private Hurd +servers that replace or proxy the global default implementations. + +However, running such a customized subenvironment presently is not easy, +because there is no standard mechanism to easily replace an individual standard +server, keeping everything else. (Presently there is only the [[hurd/subhurd]] +method, which creates a completely new system instance with a completely +independent set of servers.) + +The goal of this project is to provide a simple method for overriding +individual standard servers, using environment variables, or a special +subshell, or something like that. It is closely related to the +[[virtualization]] task. + +Various approaches for such a mechanism has been discussed before. +Probably the easiest (1) would be to modify the Hurd-specific parts of [[hurd/glibc]], +which are contacting various standard servers to implement certain system +calls, so that instead of always looking for the servers in default locations, +they first check for overrides in environment variables, and use these instead +if present. Take a look at the [socket server overriding +patch](http://www.assembla.com/spaces/VNetHurd/documents/aJidqKp6ur3z-Nab7jnrAJ/download/A%20patch%20of%20glibc) +for an example. + +A somewhat more generic solution (2) could use some mechanism for arbitrary +client-side namespace overrides. The client-side part of the filename lookup +mechanism would have to check an override table on each lookup, and apply the +desired replacement whenever a match is found. + +Another approach would be server-side overrides. Again there are various +variants. The actual servers themselves could provide a mechanism to redirect to +other servers on request. (3) Or we could use some more generic server-side +namespace overrides: Either all filesystem servers could provide a mechanism to +modify the namespace they export to certain clients (4), or proxies could be +used that mirror the default namespace but override certain locations. (5) + +Variants (4) and (5) are the most powerful. They are intimately related to +chroots: (4) is like the current chroot implementation works in the Hurd, and +(5) has been proposed as an alternative. The generic overriding mechanism could +be implemented on top of chroot, or chroot could be implemented on top of the +generic overriding mechanism. But this is out of scope for this project... + +In practice, probably a mix of the different approaches would prove most useful +for various servers and use cases. It is strongly recommended that the student +starts with (1) as the simplest approach, perhaps augmenting it with (3) for +certain servers that don't work with (1) because of indirect invocation. + +This tasks requires some understanding of the Hurd internals, especially a good +understanding of the file name lookup mechanism. It's probably not too heavy on +the coding side. + +This is [[!GNU_Savannah_task 6612]]. Also there are quite a bit of emails +discussing this topic, from a previous year's GSoC application -- see +<http://lists.gnu.org/archive/html/bug-hurd/2007-03/msg00050.html>, +<http://lists.gnu.org/archive/html/bug-hurd/2007-03/msg00114.html>, +<http://lists.gnu.org/archive/html/bug-hurd/2007-06/msg00082.html>, +<http://lists.gnu.org/archive/html/bug-hurd/2008-03/msg00039.html>. + +Possible mentors: Olaf Buddenhagen (antrik), Carl Fredrik Hammar (cfhammar) + +Exercise: Come up with a glibc patch that allows overriding one specific +standard server using method (1). diff --git a/community/gsoc/project_ideas/sound.mdwn b/community/gsoc/project_ideas/sound.mdwn new file mode 100644 index 00000000..8411831b --- /dev/null +++ b/community/gsoc/project_ideas/sound.mdwn @@ -0,0 +1,42 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="Sound Support"]] + +The Hurd presently has no sound support. Fixing this, [[!GNU_Savannah_task +5485]], requires two steps: the first is to port some other kernel's drivers to +[[GNU_Mach|microkernel/mach/gnumach]] so we can get access to actual sound +hardware. The second is to implement a userspace server ([[hurd/translator]]), +that implements an interface on top of the kernel device that can be used by +applications -- probably OSS or maybe ALSA. + +Completing this task requires porting at least one driver (e.g. from Linux) for +a popular piece of sound hardware, and the basic userspace server. For the +driver part, previous experience with programming kernel drivers is strongly +advisable. The userspace part requires some knowledge about programming Hurd +translators, but shouldn't be too hard. + +Once the basic support is working, it's up to the student to use the remaining +time for porting more drivers, or implementing a more sophisticated userspace +infrastructure. The latter requires good understanding of the Hurd philosophy, +to come up with an appropriate design. + +Another option would be to evaluate whether a driver that is completely running +in user-space is feasible. <!-- TODO. Elaborate. --> + +Possible mentors: Samuel Thibault (youpi) + +Exercise: This project requires kernel (driver framework) hacking as well as +some Hurd server hacking; so the exercise should involve either of these, or +even both. You could for example port some newer driver to run in the existing +framework (see the [[device_driver|driver_glue_code]] project description), or +try to make some fix(es) to the [unfinished random device +implementation](http://savannah.gnu.org/patch/?6088) created by Michael +Casadevall. diff --git a/community/gsoc/project_ideas/tcp_ip_stack.mdwn b/community/gsoc/project_ideas/tcp_ip_stack.mdwn new file mode 100644 index 00000000..331336ac --- /dev/null +++ b/community/gsoc/project_ideas/tcp_ip_stack.mdwn @@ -0,0 +1,42 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="Hurdish TCP/IP Stack"]] + +The Hurd presently uses a [[TCP/IP_stack|hurd/translator/pfinet]] based on code from an old Linux version. +This works, but lacks some rather important features (like PPP/PPPoE), and the +design is not hurdish at all. + +A true hurdish network stack will use a set of [[hurd/translator]] processes, +each implementing a different protocol layer. This way not only the +implementation gets more modular, but also the network stack can be used way +more flexibly. Rather than just having the standard socket interface, plus some +lower-level hooks for special needs, there are explicit (perhaps +filesystem-based) interfaces at all the individual levels; special application +can just directly access the desired layer. All kinds of packet filtering, +routing, tunneling etc. can be easily achieved by stacking components in the +desired constellation. + +Implementing a complete modular network stack is not feasible as a GSoC +project, though. Instead, the task is to take some existing user space TCP/IP +implementation, and make it run as a single Hurd server for now, so it can be +used in place of the existing pfinet. The idea is to split it up into +individual layers later. The initial implementation, and the choice of a TCP/IP +stack, should be done with this in mind -- it needs to be modular enough to +make such a split later on feasible. + +This is [[!GNU_Savannah_task 5469]]. + +Possible mentors: zhengda + +Exercise: You could try making some improvement to the existing pfinet +implementation; or you could work towards running some existing userspace +TCP/IP stack on Hurd. (As a normal program for now, not a proper Hurd server +yet.) diff --git a/community/gsoc/project_ideas/testsuites.mdwn b/community/gsoc/project_ideas/testsuites.mdwn new file mode 100644 index 00000000..4f8d43fc --- /dev/null +++ b/community/gsoc/project_ideas/testsuites.mdwn @@ -0,0 +1,52 @@ +[[!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="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. +While these testsuites were written mostly to track regressions in the respective packages, +some of the tests fail on the Hurd in general. + +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, +but can be directly or indirectly responsible for all kinds of failures. +The testsuites help in isolating such problems, +so they can be tracked down and fixed. + +This task thus consists in running some of the mentioned testsuites +(and/or any other ones that come to mind), +and looking into the causes of failures. +The goal is to analyze all failures in one or more of the listed testsuites, +to find out what shortcomings in the Hurd implementation cause them (if any), +and to fix at least some of these shortcomings. + +Note that this task somewhat overlaps with the [[Perl/Python task|perl_python]] listed above. +Here the focus however is not on improving the support for any particular program, +but on fixing general problems in the Hurd. + +This is a very flexible task: +while less experienced students should be able to tackle at least a few of the easier problems, +other issues will be challenging even for experienced hackers. +No specific previous knowledge is required for this task; +only fairly decent C programming skills. +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. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Take a stab at one of the testsuite failures, +and write a minimal testcase exposing the underlying problem. +Actually fixing it would be a bonus of course -- +but as it's hard to predict which issues will be easy and which will be tricky, +we will already be satisfied if the student makes a good effort. +(We hope to see some discussion of the problems in this case though :-) ) diff --git a/community/gsoc/project_ideas/tmpfs.mdwn b/community/gsoc/project_ideas/tmpfs.mdwn new file mode 100644 index 00000000..63b4effe --- /dev/null +++ b/community/gsoc/project_ideas/tmpfs.mdwn @@ -0,0 +1,45 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="Fix tmpfs"]] + +In some situations it is desirable to have a file system that is not backed by +actual disk storage, but only by anonymous memory, i.e. lives in the RAM (and +possibly swap space). + +A simplistic way to implement such a memory filesystem is literally creating a +ramdisk, i.e. simply allocating a big chunk of RAM (called a memory store in +Hurd terminology), and create a normal filesystem like ext2 on that. However, +this is not very efficient, and not very convenient either (the filesystem +needs to be recreated each time the ramdisk is invoked). A nicer solution is +having a real [[hurd/translator/tmpfs]], which creates all filesystem +structures directly in RAM, allocating memory on demand. + +The Hurd has had such a tmpfs for a long time. However, the existing +implementation doesn't work anymore -- it got broken by changes in other parts +of the Hurd design. + +There are several issues. The most serious known problem seems to be that for +technical reasons it receives [[microkernel/mach/RPC]]s from two different +sources on one [[microkernel/mach/port]], and gets mixed up with them. Fixing +this is non-trivial, and requires a good understanding of the involved +mechanisms. + +The goal of this project is to get a fully working, full featured tmpfs +implementation. It requires digging into some parts of the Hurd, including the +[[pager_interface|hurd/libpager]] and [[hurd/translator]] programming. This +task probably doesn't require any design work, only good debugging skills. + +Possible mentors: Carl Fredrik Hammar (cfhammar) + +Exercise: Take a look at tmpfs and try to fix one of the existing issues. Some +of them are probably not too tricky; or you might discover something else you +could improve while working on it. If you don't find anything obvious, contact +us about a different exercise task. diff --git a/community/gsoc/project_ideas/unionfs_boot.mdwn b/community/gsoc/project_ideas/unionfs_boot.mdwn new file mode 100644 index 00000000..d9f1a9e1 --- /dev/null +++ b/community/gsoc/project_ideas/unionfs_boot.mdwn @@ -0,0 +1,45 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="Allow Using unionfs Early at Boot"]] + +In [[UNIX]] systems, traditionally most software is installed in a common directory +hierarchy, where files from various packages live beside each other, grouped by +function: user-invokable executables in `/bin`, system-wide configuration files +in `/etc`, architecture specific static files in `/lib`, variable data in +`/var`, and so on. To allow clean installation, deinstallation, and upgrade of +software packages, GNU/Linux distributions usually come with a package manager, +which keeps track of all files upon installation/removal in some kind of +central database. + +An alternative approach is the one implemented by GNU Stow: each package is +actually installed in a private directory tree. The actual standard directory +structure is then created by collecting the individual files from all the +packages, and presenting them in the common `/bin`, `/lib`, etc. locations. + +While the normal Stow package (for traditional UNIX systems) uses symlinks to +the actual files, updated on installation/deinstallation events, the Hurd +[[hurd/translator]] mechanism allows a much more elegant solution: +[[hurd/translator/stowfs]] (which is actually a special mode of +[[hurd/translator/unionfs]]) creates virtual directories on the fly, composed +of all the files from the individual package directories. + +The problem with this approach is that unionfs presently can be launched only +once the system is booted up, meaning the virtual directories are not available +at boot time. But the boot process itself already needs access to files from +various packages. So to make this design actually usable, it is necessary to +come up with a way to launch unionfs very early at boot time, along with the +root filesystem. + +Completing this task will require gaining a very good understanding of the Hurd +boot process and other parts of the design. It requires some design skills +also to come up with a working mechanism. + +Possible mentors: Carl Fredrik Hammar (cfhammar) diff --git a/community/gsoc/project_ideas/unionmount.mdwn b/community/gsoc/project_ideas/unionmount.mdwn new file mode 100644 index 00000000..86ef96c7 --- /dev/null +++ b/community/gsoc/project_ideas/unionmount.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta redir=hurd/translator/unionmount]] diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn new file mode 100644 index 00000000..c6fc7459 --- /dev/null +++ b/community/gsoc/project_ideas/valgrind.mdwn @@ -0,0 +1,80 @@ +[[!meta copyright="Copyright © 2009, 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="Porting Valgrind to the 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, +a Hurd port will help finding out why certain programs segfault on the Hurd, +although they work on Linux. +Even more importantly, it will help finding bugs in the Hurd servers themselfs. + +To keep track of memory use, +Valgrind however needs to know how each system call affects the validity of memory regions. +This knowledge is highly kernel-specific, +and thus Valgrind needs to be explicitely ported for every system. + +Such a port involves two major steps: +making Valgrind understand how kernel traps work in general on the system in question; +and how all the individual kernel calls affect memory. +The latter step is where most of the work is, +as the behaviour of each single system call needs to be described. + +Compared to Linux, +Mach (the microkernel used by the Hurd) has very few kernel traps. +Almost all system calls are implemented as RPCs instead -- +either handled by Mach itself, or by the various Hurd servers. +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, +the actual effect of the call varies greatly depending on which RPC is invoked -- +similar to the ioctl() call on Linux. +Each request thus must be handled individually. + +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, +Valgrind can know exactly which memory regions are affected by that call, +even without specific knowledge of the RPC in question. +Thus implementing a general parser for the reply messages +will already give Valgrind a fairly good approximation of memory validity -- +without having to specify the exact semantic of each RPC by hand. + +While this should make Valgrind quite usable on the Hurd already, it's not perfect: +some RPCs might return a buffer that is only partially filled with valid data; +or some reply parameters might be optional, +and only contain valid data under certain conditions. +Such specific semantics can't be deduced from the message headers alone. +Thus for a complete port, +it will still be necessary to go through the list of all known RPCs, +and implement special handling in Valgrind for those RPCs that need it. + +The goal of this task is at minimum to make Valgrind grok Mach traps, +and to implement the generic RPC handler. +Ideally, specific handling for RPCs needing it should also be implemented. + +Completing this project will require digging into Valgrind's handling of system calls, +and into Hurd RPCs. +It is not an easy task, but a fairly predictable one -- +there shouldn't be any unexpected difficulties, +and no major design work is necessary. +It doesn't require any specific previous knowledge: +only good programming skills in general. +On the other hand, +the student will obtain a good understanding of Hurd RPCs while working on this task, +and thus perfect qualifications for Hurd development in general :-) + +Possible mentors: Samuel Thibault (youpi) + +Exercise: As a starter, +students can try to teach valgrind a couple of Linux ioctls, +as this will make them learn how to use the read/write primitives of valgrind. diff --git a/community/gsoc/project_ideas/virtualization.mdwn b/community/gsoc/project_ideas/virtualization.mdwn new file mode 100644 index 00000000..822b8d99 --- /dev/null +++ b/community/gsoc/project_ideas/virtualization.mdwn @@ -0,0 +1,76 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="Virtualization Using Hurd Mechanisms"]] + +The main idea behind the Hurd design is to allow users to replace almost any +system functionality ([[extensible_system|extensibility]]). Any user can easily +create a subenvironment using some custom [[servers|hurd/translator]] instead +of the default system servers. This can be seen as an +[[advanced_lightweight_virtualization|hurd/virtualization]] mechanism, which +allows implementing all kinds of standard and nonstandard virtualization +scenarios. + +However, though the basic mechanisms are there, currently it's not easy to make +use of these possibilities, because we lack tools to automatically launch the +desired constellations. + +The goal is to create a set of powerful tools for managing at least one +desirable virtualization scenario. One possible starting point could be the +[[hurd/subhurd]]/[[hurd/neighborhurd]] mechanism, which allows a second almost totally +independent instance of the Hurd in parallel to the main one. + +While subhurd allow creating a complete second system instance, with an own set +of Hurd servers and [[UNIX]] daemons and all, there are also situations where it is +desirable to have a smaller subenvironment, living withing the main system and +using most of its facilities -- similar to a chroot environment. A simple way +to create such a subenvironment with a single command would be very helpful. + +It might be possible to implement (perhaps as a prototype) a wrapper using +existing tools (chroot and [[hurd/translator/unionfs]]); or it might require more specific tools, +like some kind of unionfs-like filesystem proxy that mirrors other parts of the +filesystem, but allows overriding individual locations, in conjunction with +either chroot or some similar mechanism to create a subenvironment with a +different root filesystem. + +It's also desirable to have a mechanism allowing a user to set up such a custom +environment in a way that it will automatically get launched on login -- +practically allowing the user to run a customized operating system in his own +account. + +Yet another interesting scenario would be a subenvironment -- using some kind +of special filesystem proxy again -- in which the user serves as root, being +able to create local sub-users and/or sub-groups. + +This would allow the user to run "dangerous" applications (webbrowser, chat +client etc.) in a confined fashion, allowing it access to only a subset of the +user's files and other resources. (This could be done either using a lot of +groups for individual resources, and lots of users for individual applications; +adding a user to a group would give the corresponding application access to the +corresponding resource -- an advanced [[ACL]] mechanism. Or leave out the groups, +assigning the resources to users instead, and use the Hurd's ability for a +process to have multiple user IDs, to equip individual applications with sets +of user IDs giving them access to the necessary resources -- basically a +[[capability]] mechanism.) + +The student will have to pick (at least) one of the described scenarios -- or +come up with some other one in a similar spirit -- and implement all the tools +(scripts, translators) necessary to make it available to users in an +easy-to-use fashion. While the Hurd by default already offers the necessary +mechanisms for that, these are not perfect and could be further refined for +even better virtualization capabilities. Should need or desire for specific +improvements in that regard come up in the course of this project, implementing +these improvements can be considered part of the task. + +Completing this project will require gaining a very good understanding of the +Hurd architecture and spirit. Previous experience with other virtualization +solutions would be very helpful. + +Possible mentors: Olaf Buddenhagen (antrik), Carl Fredrik Hammar (cfhammar) diff --git a/community/gsoc/project_ideas/vm_tuning.mdwn b/community/gsoc/project_ideas/vm_tuning.mdwn new file mode 100644 index 00000000..ecc5f9f4 --- /dev/null +++ b/community/gsoc/project_ideas/vm_tuning.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="VM Tuning"]] + +Hurd/[[microkernel/Mach]] presently make very bad use of the available physical memory in the +system. Some of the problems are inherent to the system design (the kernel +can't distinguish between important application data and discardable disk +buffers for example), and can't be fixed without fundamental changes. Other +problems however are an ordinary lack of optimization, like extremely crude +heuristics when to start paging. (See <http://lists.gnu.org/archive/html/bug-hurd/2007-08/msg00034.html> for example.) +Many parameters are based on assumptions from +a time when typical machines had like 16 MiB of RAM, or simply have been set to +arbitrary values and never tuned for actual use. + +The goal of this project is to bring the virtual memory management in Hurd/Mach +closer to that of modern mainstream kernels (Linux, FreeBSD), by comparing the +implementation to other systems, implementing any worthwhile improvements, and +general optimization/tuning. It requires very good understanding of the Mach +VM, and virtual memory in general. + +This project is related to [[!GNU_Savannah_task 5489]]. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Make some modification to the existing VM code. You could try to find +a piece of code that can be improved with simple code optimization, for +example. diff --git a/community/gsoc/project_ideas/xattr.mdwn b/community/gsoc/project_ideas/xattr.mdwn new file mode 100644 index 00000000..7178d826 --- /dev/null +++ b/community/gsoc/project_ideas/xattr.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!meta title="Implement xattr Support"]] + +Extended attributes (xattr) are a standardized, generic method for storing +additional metadata along with a file (inode). Most modern UNIX filesystems +support xattrs. + +In general, xattrs should be used sparingly, as they are less transparent than +data stored as explicit file contents; however, there are some cases where they +really make sense. The Hurd's variant of ext2 presently uses some additional +fields in the inode to store Hurd-specific metadata: most notable passive +translator settings. As these fields are Hurd-specific, they can't be accessed +by the standard methods from Linux for example, so it's not possible to fully +work with a Hurd filesystem on GNU/Linux (copy, backup etc.); and also, even +when on Hurd, only tools that explicitly support the Hurd-specific information +can handle them. + +Using extended attributes instead of custom fields for the Hurd-specific +information would be very helpful. + +The most important goal of this project thus is to make the Hurd ext2fs server +able to store and read the Hurd-specific information with extended attributes +instead of the custom fields, so it become accessible from other systems. Being +able to access the information through the standard xattr API instead of +Hurd-specific calls is also desirable. (And in turn requires implementing the +generic xattr API first, which can be useful for other purposes as well.) + +Completing this project will require digging into some parts of the Hurd, but +it should be quite doable without previous Hurd experience. Some experience +with xattrs might help a bit, but shouldn't be really necessary either. + +Some previous work on xattr support is available in [[!GNU_Savannah_patch +5126]], and might serve as a starting point. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Implement support for different inode sizes (other than 128 bytes) in +Hurd's ext2fs. diff --git a/community/gsoc/project_ideas/xmlfs.mdwn b/community/gsoc/project_ideas/xmlfs.mdwn new file mode 100644 index 00000000..5e5eaa13 --- /dev/null +++ b/community/gsoc/project_ideas/xmlfs.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under 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="xmlfs"]] + +Hurd [[translators|hurd/translator]] allow presenting underlying data in a +different format. This is a very powerful ability: it allows using standard +tools on all kinds of data, and combining existing components in new ways, once +you have the necessary translators. + +A typical example for such a translator would be xmlfs: a translator that +presents the contents of an underlying XML file in the form of a directory +tree, so it can be studied and edited with standard filesystem tools, or using +a graphical file manager, or to easily extract data from an XML file in a +script etc. + +The exported directory tree should represent the DOM structure of the document, +or implement XPath/XQuery, or both, or some combination thereof (perhaps XPath/XQuery could +be implemented as a second translator working on top of the DOM one) -- +whatever works well, while sticking to XML standards as much as possible. + +Ideally, the translation should be reversible, so that another, complementary +translator applied on the expanded directory tree would yield the original XML +file again; and also the other way round, applying the complementary translator +on top of some directory tree and xmlfs on top of that would yield the original +directory again. However, with the different semantics of directory trees and +XML files, it might not be possible to create such a universal mapping. Thus +it is a desirable goal, but not a strict requirement. + +The goal of this project is to create a fully usable XML translator, that +allows both reading and writing any XML file. Implementing the complementary +translator also would be nice if time permits, but is not mandatory part of the +task. + +The [[existing_partial_(read-only)_xmlfs_implementation|hurd/translator/xmlfs]] +can serve as a starting point. + +This task requires pretty good designing skills. Very good knowledge of XML is also +necessary. Learning translator programming will obviously be necessary to +complete the task. + +Possible mentors: Olaf Buddenhagen (antrik) + +Exercise: Make some improvement to the existing xmlfs, or some other existing +Hurd translator. (Especially those in +[hurdextras](http://www.nongnu.org/hurdextras/) are often quite rudimental -- +it shouldn't be hard to find something to improve...) diff --git a/community/gsoc/student_application_form.mdwn b/community/gsoc/student_application_form.mdwn index e5639f9e..ba339dc9 100644 --- a/community/gsoc/student_application_form.mdwn +++ b/community/gsoc/student_application_form.mdwn @@ -1,61 +1,74 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] Before we get to the actual application form, some important remarks about the application process -- please read them carefully. +First of all, please give your application a useful title. In many cases, you +can simply copy it from the project ideas list. Some ideas -- like language +bindings for example -- are rather broad, and require an additional specifier. +(e.g. "Python Bindings") + +If you are proposing a project not on the ideas list, you have to find a useful +title yourself of course -- but surely this isn't hard, if you were able to +come up with your own project idea :-) + Submitting the application form is only part of the deal: we expect a few other -things on top of that. Lacking these, the application is not complete, and we +things on top of that, as explained below. This is important, so please take +it seriously -- without these things, the application is not complete, and we won't consider it. One of the things we expect is that you contact us directly as soon as possible (preferably even before you send the application form), on our developer -[[mailing_lists]] and [[IRC]] channel. Don't be afraid -- we won't bite :-) IRC +[[mailing lists]] and [[IRC]] channel. Don't be afraid -- we won't bite :-) IRC in particular allows for very informal conversations. (Note though that we are not all in the same time zone, and people generally -don't stare at the IRC screen all the time -- it can take quite a long time -until somebody replies: even several hours. Don't get discouraged by that: Just +don't stare at the IRC screen all the time: it can take quite a long time +until somebody replies -- even several hours. Don't get discouraged by that. Just be patient and hang on, or try again later.) Contacting us as soon as possible is crucial, as regular communication is the single most important factor for a successful GSoC project. We need to see that -you are able and willing to talk to us regularily. Also it allows us getting to -know you much better than the application form alone could. +you are able and willing to talk to us regularly. Also, we get to +know you much better this way than what the application form alone would allow us to. -You shouldn't be at a loss for reason to contact us. You ought to discuss your -project and application with us for exmple: You will gain a much better idea -about the project, our expectations etc. -- in short, you will be able to -submit a better application right from the beginnig, saving both yourself and -us some tedious roundtrips :-) +You shouldn't be at a loss for reasons to contact us. You ought to discuss your +project and application with us for example -- you will gain a much better idea +about the project, our expectations etc. In short, you will be able to +submit a better application right from the beginning, saving both yourself and +us some tedious round trips :-) Also, if you really want to get involved with the Hurd project, there are -surely many things you will want to know :-) All in all, you should have ample +surely many things you will want to know -- after all, it's a fascinating +project, with a fascinating architecture etc., right? :-) + +All in all, you should have ample causes to get in touch during the application period. Bonus points if you also participate in discussions not directly related to your project. The other thing necessary to complete your application is making a change to -some part of the Hurd code, and submitting a patch with the change. (If you are +some part of the Hurd code, and submitting a patch implementing that change. (If you are not sure what that means, ask us!) This is important, as it shows that you have everything set up to start hacking -on the project (source code, tool chain, testing environment etc.), and that -you have all kinds of qualifications necessary to successfully finish the -project: general programming abilities; working in the Hurd environment; +on the project (source code, tool chain, testing environment etc.); and that +you have all kinds of qualifications necessary to successfully finish your +project: general programming skills; working in the Hurd environment; submitting patches and reacting to feedback; finding and/or asking for any information you need; and so on. Don't get us wrong: We absolutely do *not* demand that you have and know all this up front. After all, the idea of GSoC is to *introduce* you to free software development in general, and to our project specifically :-) We are -willing to help you with anything you will need to create the patch -- you just +eager to help you with anything you will need to create the patch -- you just need to ask! We actively encourage you to contact us whenever you have any doubts. Don't be @@ -63,7 +76,7 @@ afraid that we will think worse of you when you ask too much. On the contrary: this is an occasion for you to show us that whenever there is something you don't know yet, you are able to learn quickly, and know how to ask for help :-) -As for the kind of change we want: Ideally, it would be some real improvement +As for the kind of change we want: ideally, it would be some real improvement (bug fix or new feature) in a part of the Hurd related to the specific project you want to work on. (This is not always possible though -- in that case, a useful change to some unrelated part of the Hurd would also do, or perhaps some @@ -92,9 +105,17 @@ you are unsure about something. And now that you are prepared to face the enemy, here we go :-) +* Please supply your contact information here: full name, email address, IRC +nick, Jabber ID, phone number, etc. -- anything we might need to recognize you +and to keep in touch. + +* Introduce yourself: who are you, where are you from, what do you do, how did +you get here... Don't write a long essay here -- just a bunch of basic facts +you think we should know, so we get some idea whom we are talking to :-) + * Please describe the task of the project you want to work on, in your own words. Be as specific as possible. It's not sufficient to rephrase the -description from the project ideas page; show us that you actually understand +description from the project ideas page -- show us that you actually understand what this task involves! Read the available documentation (and possibly code) if necessary. And don't hesitate to ask us if you have any doubts :-) @@ -107,7 +128,7 @@ ready to be merged to mainline. Experience shows that adding the "final touches" necessary for that, tends to take up quite a lot of time -- there are always some bugs here and there, some misunderstandings about how things are supposed to work, build system issues, missing documentation, forgotten bits, -and so on. Thus, the schedule should suppose that a larger part of the main +and so on. Thus, the schedule should assume that a larger part of the main implementation work will be done by midterm! Also note that by the beginning of the summer session, you need to be able to @@ -153,12 +174,12 @@ the application process. * Do you have a permanent internet connection, especially during the time of the summer session? Are you able and willing to hang out on the Hurd IRC -channel regularily? (As in: Running the IRC client more or less permanently and +channel regularly? (As in: Running the IRC client more or less permanently and checking for activity now and then.) If it turns out that your mentor lives in a different time zone, could you shift your day/night rhythm to better match that of your mentor and other Hurd developers? -Hint: Hanging out on the channel regularily during the application process +Hint: Hanging out on the channel regularly during the application process would be a good start :-) * When does your university term end, when are your exams, and when does the @@ -181,8 +202,8 @@ intend to make sure you will be able to dedicate sufficient time to your project nevertheless? Please be open about this, and also mention things you are not yet sure about. -We can be flexible about time arrangements; but we need to know about any -possible obstacles up front. +We can be flexible about time arrangements; but we absolutely need to know about any +possible obstacles up front. Surprises on that score are not acceptable. * How do you intend to make sure that your code will keep on being maintained and supported properly after the end of the GSoC program? diff --git a/community/gsoc/xorg_ideas.mdwn b/community/gsoc/xorg_ideas.mdwn new file mode 100644 index 00000000..26177345 --- /dev/null +++ b/community/gsoc/xorg_ideas.mdwn @@ -0,0 +1,67 @@ +[[!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]]."]]"""]] + +## VT Switching for GNU Hurd + +While XFree86 was first ported to the Hurd more than a decade ago, and there +are updates now and then to make newer versions of Xorg run as well, +the support is quite rudimentary: in particular, there +is no support for switching back to the text console while X is running. + +Implementing this requires creating an interface between the X server and the +Hurd console, and implementing the necessary code on both sides. + +The goal of this project is to get console switching fully working on the Hurd. +Some Hurd-specific and X-specific knowlegde will need to be obtained, but the +task should be quite doable without previous experience with either. It +requires implementing some pieces of code that are not quite trivial, but +shouldn't be terribly hard either. + +Exercise: Try fixing <http://savannah.gnu.org/bugs/?21000>, or perhaps some +other minor issue with X on the Hurd. + + +## Initial work on porting DRM to GNU Hurd + +The Direct Rendering Manager (DRM) is a kernel driver component taking care of +graphics hardware access. Originally, it only took care of the 3D acceleration +unit, and was used mostly by the DRI (Direct Rendering Infrastructure) in Mesa. + +A few years ago, the developers came to the conclusion that a more robust +and functional graphics stack requires the kernel driver to take care of other +graphics access as well: mode setting in particular. (Essentially what the old +KGI project proposed, see <http://www.kgi-project.org>.) Also, with the new GEM +interface, the DRM now takes care of graphics memory management as well. + +With the new responsibilities, the DRM is no longer an optional addon for fast +3D support, but a central component of the graphics stack. It needs to be +implemented by any operating system that wants good Xorg driver support in the +future. (Moreover, it is now also useful outside the context of Xorg.) + +The Hurd implementation of DRM will be somewhat special, as -- following the +microkernel idea -- we want to run the drivers as priviledged user space server +processes, rather than actual kernel modules. + +This task is about doing the first steps for porting the DRM to the Hurd. This +can be done by taking one of the existing DRM modesetting drivers (Intel, Nouveau (Nvidia), or +Radeon), trying to get parts of it running as a Hurd server, and +porting/implementing necessary pieces of the general DRM framework as needed +along the way. + +It is probably not realistic to get the driver fully working over the summer. +The goal however is to get at least some parts going. + +This task will require obtaining a considerable amount of knowledge about the +Hurd and Mach (especially things like virtual memory management) -- it goes +deep into system internals. Previous experience with operating system and/or +graphics driver development would definitely be helpful. + +Exercise: Try to get some part of the driver compiling on the Hurd, using stubs +for any system-specific functionality. diff --git a/community/meetings.mdwn b/community/meetings.mdwn index f3f66420..c7ed664d 100644 --- a/community/meetings.mdwn +++ b/community/meetings.mdwn @@ -1,25 +1,24 @@ -[[meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] -[[meta title="Meetings with Hurd developer attendance"]] +[[!meta title="Meetings with Hurd developer attendance"]] # Upcoming - * [[25C3]] - * [[Self-organised_2008]] - * [[EuroSys_2009]] - * [[FOSDEM_2009]] + * [[Self-organised]] # Past + * [[FOSDEM 2010]] + * [[EuroSys_2009]] * [[FOSDEM_2008]] * [[Weekend_at_stesie's|stesie_2007-10-12]] * [[FOSDEM_2007]] diff --git a/community/meetings/25c3.mdwn b/community/meetings/25c3.mdwn deleted file mode 100644 index 59e7b22a..00000000 --- a/community/meetings/25c3.mdwn +++ /dev/null @@ -1,60 +0,0 @@ -[[meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, -Inc."]] - -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU_Free_Documentation_License|/fdl]]."]]"""]] - -[[meta title=25C3]] - -<http://events.ccc.de/congress/2008/> - -The 25th Chaos Communication Congress will take place from Dezember 27th to -30th at the bcc (Berliner Congress Center) in Berlin, Germany. - - -# Who and When - -[[table class="table_style_1" data=""" -"Name","Attending","Arrival","Return","Share room with us" -"Jeroen Dekkers","yes","?","?","?" -"Marcus Brinkmann","yes","?","?","?" -"Michael Banck","intends to go","?","?","?" -"Neal Walfield","no","?","?","?" -"Olaf Buddenhagen","yes","?","?","?" -"[[Thomas_Schwinge|tschwinge]]","no","?","?","?" -"Wouter van Heyst","yes","?","?","?" -"""]] - - -<!-- -# Accommodation ---> - -<!-- -(Large) evening counts: - -[[table class="table_style_1" data=""" - , Bas, Gianluca, Marcus, Michael, Neal, Olaf, Samuel, Soeren, Thomas, Total -Thu 21, , 1? , *<strike>1</strike>*, , , , 1 , , *<strike>1</strike>*, *<strike>4</strike>* 2 -Fri 22, 2 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 ,10 -Sat 23, 2 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 ,10 -Sun 24, 2 , 1 , 1 , 1 , 1 , 1 , 1 , *<strike>1</strike>*, 1 , *<strike>10</strike>* 9 -"""]] ---> - - -<!-- -# What ---> - - -<!-- -# Photos - -Put links to your photos here. ---> diff --git a/community/meetings/eurosys_2009.mdwn b/community/meetings/eurosys_2009.mdwn index 30230a26..24c2b112 100644 --- a/community/meetings/eurosys_2009.mdwn +++ b/community/meetings/eurosys_2009.mdwn @@ -1,55 +1,25 @@ -[[meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, +[[!meta copyright="Copyright © 2006, 2007, 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] -[[meta title="EuroSys 2009"]] +[[!meta title="EuroSys 2009"]] <http://eurosys2009.informatik.uni-erlangen.de/> EuroSys will take place on March 30th to April 3rd in Nuremberg, Germany. -# Who And When +# Who and When -[[table class="table_style_1" data=""" -"Name","Attending","Arrival","Return","Share room with us" -"Neal Walfield","intends to go","?","?","?" -"[[Samuel_Thibault|SamuelThibault]]","intends to go","?","?","?" -"[[Thomas_Schwinge|tschwinge]]","intends to go","?","?","?" +[[!table class="table_style_1" data=""" +"Name","Attending","Arrival","Return" +"Neal Walfield","yes","Monday evening","Friday" +"[[Thomas_Schwinge|tschwinge]]","yes","Monday evening","Friday" """]] - - -<!-- -# Accommodation ---> - -<!-- -(Large) evening counts: - -[[table class="table_style_1" data=""" - , Bas, Gianluca, Marcus, Michael, Neal, Olaf, Samuel, Soeren, Thomas, Total -Thu 21, , 1? , *<strike>1</strike>*, , , , 1 , , *<strike>1</strike>*, *<strike>4</strike>* 2 -Fri 22, 2 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 ,10 -Sat 23, 2 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 ,10 -Sun 24, 2 , 1 , 1 , 1 , 1 , 1 , 1 , *<strike>1</strike>*, 1 , *<strike>10</strike>* 9 -"""]] ---> - - -<!-- -# What ---> - - -<!-- -# Photos - -Put links to your photos here. ---> diff --git a/community/meetings/fosdem_2005.mdwn b/community/meetings/fosdem_2005.mdwn index c34319fb..8d7f459d 100644 --- a/community/meetings/fosdem_2005.mdwn +++ b/community/meetings/fosdem_2005.mdwn @@ -1,14 +1,14 @@ -[[meta copyright="Copyright © 2006, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2006, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] -[[meta title="FOSDEM 2005"]] +[[!meta title="FOSDEM 2005"]] <http://fosdem.org/2005> diff --git a/community/meetings/fosdem_2006.mdwn b/community/meetings/fosdem_2006.mdwn index 8bf9967f..a869f262 100644 --- a/community/meetings/fosdem_2006.mdwn +++ b/community/meetings/fosdem_2006.mdwn @@ -1,15 +1,15 @@ -[[meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, +[[!meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] -[[meta title="FOSDEM 2006"]] +[[!meta title="FOSDEM 2006"]] <http://fosdem.org/2006> diff --git a/community/meetings/fosdem_2007.mdwn b/community/meetings/fosdem_2007.mdwn index 55d346fd..ab9fa413 100644 --- a/community/meetings/fosdem_2007.mdwn +++ b/community/meetings/fosdem_2007.mdwn @@ -1,15 +1,15 @@ -[[meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, +[[!meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] -[[meta title="FOSDEM 2007"]] +[[!meta title="FOSDEM 2007"]] <http://fosdem.org/2007> @@ -18,7 +18,7 @@ Bruxelles. # Who And When -[[table class="table_style_1" data=""" +[[!table class="table_style_1" data=""" "Name","Attending","Arrival","Return","Share room with us" "[[AlfredoBeaumont]]","no","n/a","n/a","n/a" "[[AndrewResch]]","no","n/a","n/a","n/a" @@ -88,7 +88,7 @@ Been there in 2006. It was okay. [[SamuelThibault]] booked rooms at ~ 18.60€ there: -[[table class="table_style_1" data=""" +[[!table class="table_style_1" data=""" "Night of...","Persons" "2007-02-22","<strike>7</strike>**6**" "2007-02-23","10" diff --git a/community/meetings/fosdem_2008.mdwn b/community/meetings/fosdem_2008.mdwn index fb4a3ae9..e9625fdf 100644 --- a/community/meetings/fosdem_2008.mdwn +++ b/community/meetings/fosdem_2008.mdwn @@ -1,15 +1,15 @@ -[[meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, +[[!meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] -[[meta title="FOSDEM 2008"]] +[[!meta title="FOSDEM 2008"]] <http://fosdem.org/2008> @@ -19,7 +19,7 @@ Bruxelles. # Who And When -[[table class="table_style_1" data=""" +[[!table class="table_style_1" data=""" "Name","Attending","Arrival","Return","Share room with us" "[[Bas_Wijnen|baswijnen]] and girlfriend","yes","Friday","Monday","yes (two)" "Christian Dietrich","no","n/a","n/a","n/a" @@ -42,7 +42,7 @@ Bruxelles. (Large) evening counts: -[[table class="table_style_1" data=""" +[[!table class="table_style_1" data=""" , Bas, Gianluca, Marcus, Michael, Neal, Olaf, Samuel, Soeren, Thomas, Total Thu 21, , 1? , *<strike>1</strike>*, , , , 1 , , *<strike>1</strike>*, *<strike>4</strike>* 2 Fri 22, 2 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 ,10 @@ -94,7 +94,7 @@ gaah, Full! <!-- [[SamuelThibault]] booked rooms at ~ 18.60€ there: -[[table class="table_style_1" data=""" +[[!table class="table_style_1" data=""" "Night of...","Persons" "2007-02-22","<strike>7</strike>**6**" "2007-02-23","10" diff --git a/community/meetings/fosdem_2009.mdwn b/community/meetings/fosdem_2009.mdwn deleted file mode 100644 index abeb74db..00000000 --- a/community/meetings/fosdem_2009.mdwn +++ /dev/null @@ -1,128 +0,0 @@ -[[meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, -Inc."]] - -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU_Free_Documentation_License|/fdl]]."]]"""]] - -[[meta title="FOSDEM 2009"]] - -<http://fosdem.org/2009> - -FOSDEM will take place on February 7th/8th at the Université Libre de -Bruxelles. - - -# Who And When - -[[table class="table_style_1" data=""" -"Name","Attending","Arrival","Return","Share room with us" -"Neal Walfield","no","n/a","n/a","n/a" -"[[Thomas_Schwinge|tschwinge]]","no","n/a","n/a","n/a" -"""]] - - -# Accommodation - -<!-- -(Large) evening counts: - -[[table class="table_style_1" data=""" - , Bas, Gianluca, Marcus, Michael, Neal, Olaf, Samuel, Soeren, Thomas, Total -Thu 21, , 1? , *<strike>1</strike>*, , , , 1 , , *<strike>1</strike>*, *<strike>4</strike>* 2 -Fri 22, 2 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 ,10 -Sat 23, 2 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 ,10 -Sun 24, 2 , 1 , 1 , 1 , 1 , 1 , 1 , *<strike>1</strike>*, 1 , *<strike>10</strike>* 9 -"""]] ---> - - -## The Moon Hotel - -Rue de la Montagne 4B. - -EUR 33.5 per night. - -Breakfast is included, there is hotspot wifi - -check-in can be between 13:00 and 00:00, departure is before 11:00 - -Been there in 2008. It was okay. - - -## A-XL flathotel - -<http://www.axlflathotel.be/fr/tarifs.html> - - -## Youth hostel _Bruegel_ - -<http://www.vjh.be/jeugdherbergen/brussel/mainE.htm> - -Heilige Geeststraat 2 -1000 Brussels -Phone: +32(0)2 511 04 36 -Fax: +32(0)2 512 07 11 -<brussel@vjh.be> - -[Map via Google maps](http://maps.google.com/maps?f=q&hl=en&q=Heilige+Geeststraat+2,+1000+Brussels,+Belgium&sll=50.846056,4.344578&sspn=0.022599,0.086517&ie=UTF8&om=1&z=15&ll=50.843942,4.351444&spn=0.0113,0.043259&iwloc=cent). -[Map via Map24](http://link2.map24.com/?street0=Heilige%20Geeststraat&zip0=1000&city0=Br%FCssel&state0=&country0=be&name0=&lid=43c26f81&ol=de-de). - -Been there in 2006 and 2007. It was okay. - -Rooms at ~ 18.60€ - -We need someone to get the keys before -20:00. Reservations last until 16:00, so either he gets the keys before 16:00, -or we just need to call for confirming the reservation - -[[I|tschwinge]] seem to remember something that in 2007 the Madame at the -reception wasn't really happy with us arriving later than 16:00 even with -having had confirmed that via a phone call. - - -## Sleep Well Youth Hostel - -<http://www.sleepwell.be/> - - -## Youth Hostel Can Gogh - -<http://chab.be/> - -No under 18-ers and over 35-ers allowed. - - -## Auberge de Jeunesse Jacques Brel - -<http://www.laj.be/html/fr/auberges/brel/aubergesbrel_01.htm>. - -Samuel knows that one and liked it. antrik too :-) - - -<!-- -# What ---> - -<!-- -There will be a keysigning party, see <http://fosdem.org/2008/keysigning>. ---> - -<!-- -We don't have a Developers Room at FOSDEM. ---> - -<!-- -There is again a pre-FOSDEM meeting on Friday night, see <http://fosdem.org/2008/beerevent>. ---> - - -<!-- -# Photos - -Put links to your photos here. ---> diff --git a/community/meetings/fosdem_2010.mdwn b/community/meetings/fosdem_2010.mdwn new file mode 100644 index 00000000..9def3c1c --- /dev/null +++ b/community/meetings/fosdem_2010.mdwn @@ -0,0 +1,86 @@ +[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 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="FOSDEM 2010"]] + +<http://fosdem.org/2010> + +FOSDEM will take place on February 6th/7th at the Université Libre de +Bruxelles. + + +# Who And When + +[[!table class="table_style_1" data=""" +"Name","Attending","Arrival","Return","Share room with us" +"Anatoly A. Kazantsev","no","","","" +"Andrei Barbu","no","","","" +"Arne Babenhauserheide","no","","","" +"[[Bas Wijnen|baswijnen]]","Yes","Friday evening","Sunday afternoon","no" +"Ben Asselstine","yes","?","?","yes (but no dates confirmed)" +"Carl Fredrik Hammar","no","","","" +"Colin Leitner","no","","","" +"Emilio Pozuelo Monfort","probably not","","","" +"Flavio Cruz","no","","","" +"[[Gianluca Guida|GianlucaGuida]]","yes","Fr.","Mo.","yes" +"Guillem Jover","no","","","" +"Madhusudan C.S.","?","","","" +"Marcus Brinkmann","yes","fr","mo","yes" +"[[Michael Banck|MichaelBanck]]","yes","Fr., early afternoon","Su., night","yes" +"Neal Walfield","yes","Fr","Mo","yes" +"Olaf Buddenhagen","yes","fr","mo","yes" +"Pino Toscano","no","","","" +"[[Samuel Thibault|SamuelThibault]]","no","","","" +"Sergiu Ivanov","no","","","" +"[[Soeren Schulze|SoerenSchulze]]","yes","Fr","Mo","yes" +"[[Stefan Siegl|stesie]]","no","","","" +"[[Thomas Schwinge|tschwinge]]","yes","Fr., 10:35","Mo., 18:25","yes" +"Vasily Sartakov","maybe","","","" +"Zheng Da","no","","","" +"""]] + + +# Where (Accommodation) + +This year, we'll stay in the [Hotel Astrid](http://www.astridhotel.be/), +together with the FSFE folks. The following data (without Ben's) has been +forwarded to them: + +[[!table class="table_style_1" data=""" + , Ben , Gianluca, Marcus, Michael, Neal, Olaf, Thomas, Total +Fri 5, **?**, 1 , 1 , 1 , 1 , 1 , 1 , 6 +Sat 6, **?**, 1 , 1 , 1 , 1 , 1 , 1 , 6 +Sun 7, **?**, 1 , 1 , , 1 , 1 , 1 , 5 +"""]] + + +# What + +On Saturday, Bas will be giving a [talk about *Iris*, his new +kernel](http://fosdem.org/2010/schedule/events/emb_iris) (Sat., 18:00, Embedded +Developer Room). + +On Sunday, one can join the other folks at the [Alt-OS Developer +Room](http://fosdem.org/2010/schedule/devrooms/altos) (also see the [Haiku +FOSDEM2010AltOSDevroomSchedule +page](http://dev.haiku-os.org/wiki/FOSDEM2010AltOSDevroomSchedule)) where at +least some of us will [spend their +time](http://lists.gnu.org/archive/html/bug-hurd/2009-12/msg00080.html). + +At this very place, Olaf will be giving two presentations: [*Why is Anyone +Still Working on the GNU +Hurd?*](http://fosdem.org/2010/schedule/events/altos_hurd) (Sun., 10:30, Alt-OS +Developer Room), and [*Porting KGI graphics drivers from Linux to GNU +Hurd*](http://fosdem.org/2010/schedule/events/altos_kgi_hurd) (Sun., 13:00, +Alt-OS Developer Room). + +There'll be further GNU folks around; [Mini GNU Hackers Meeting at FOSDEM +Brussels 2010](http://www.gnu.org/ghm/2010/fosdem/). diff --git a/community/meetings/rmll_2006.mdwn b/community/meetings/rmll_2006.mdwn index cb0ddd7e..0d82a2b1 100644 --- a/community/meetings/rmll_2006.mdwn +++ b/community/meetings/rmll_2006.mdwn @@ -1,15 +1,15 @@ -[[meta copyright="Copyright © 2006, 2007, 2008 +[[!meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] -[[meta title="RMLL 2006"]] +[[!meta title="RMLL 2006"]] The 7th Rencontres Mondiales du Logiciel Libre (also known as Libre Software Meeting) will be held on July 4th-8th 2006 in Vandoeuvre-les-Nancy. diff --git a/community/meetings/self-organised_2008.mdwn b/community/meetings/self-organised.mdwn index 10d746fc..1403c115 100644 --- a/community/meetings/self-organised_2008.mdwn +++ b/community/meetings/self-organised.mdwn @@ -1,14 +1,14 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] -[[meta title="Self-organised meeting, somewhere in 2008"]] +[[!meta title="Self-organised meeting"]] This meeting will be held in a to-be-determined place, at a to-be-determined time. This page hopes to help finding a good time and place, and finding out who wants to come. @@ -36,6 +36,9 @@ Please add any suggestions here, and add to your name above if that time is good This likely has the benefit of being relatively close to most people +<http://www.linuxhotel.de/community.html> might be a suitable venue at very +reasonable pricing. + ## Somewhere in Italy This likely has the benefit of better weather. ;-) diff --git a/community/meetings/stesie_2007-10-12.mdwn b/community/meetings/stesie_2007-10-12.mdwn index 8559c662..d59ceded 100644 --- a/community/meetings/stesie_2007-10-12.mdwn +++ b/community/meetings/stesie_2007-10-12.mdwn @@ -1,12 +1,12 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] On the weekend 2007-10-12 to 14 [[Stefan_Siegl|stesie]] invited Hurd people. Colin Leitner and [[Thomas_Schwinge|tschwinge]] came, as well as novice diff --git a/community/weblogs.mdwn b/community/weblogs.mdwn index 016c483f..8df216ba 100644 --- a/community/weblogs.mdwn +++ b/community/weblogs.mdwn @@ -1,17 +1,17 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] Weblogs from Hurd programmers and enthusiasts. -[[inline -pages="community/weblogs/*/* and !*/discussion" +[[!inline +pages="community/weblogs/*/* and !community/weblogs/*/*/*" show=0 actions=no rootpage="community/weblogs" postformtext="Add a new user named:"]] diff --git a/community/weblogs/ArneBab.mdwn b/community/weblogs/ArneBab.mdwn index 8c7b377a..1e80e5a8 100644 --- a/community/weblogs/ArneBab.mdwn +++ b/community/weblogs/ArneBab.mdwn @@ -1,12 +1,12 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] I'm just a Hurd dabbler who likes the ideas behind the Hurd: @@ -38,8 +38,8 @@ See you in the Hurd! ----- My Blog ----- -[[inline -pages="community/weblogs/ArneBab/* and !*/discussion" +[[!inline +pages="community/weblogs/ArneBab/* and !community/weblogs/ArneBab/*/*" show=0 actions=no rootpage="community/weblogs/ArneBab" postformtext="Add a new entry named:"]] diff --git a/community/weblogs/ArneBab/What_a_Hurd_release_should_be_able_to_do_for_me.mdwn b/community/weblogs/ArneBab/What_a_Hurd_release_should_be_able_to_do_for_me.mdwn new file mode 100644 index 00000000..51ef2a85 --- /dev/null +++ b/community/weblogs/ArneBab/What_a_Hurd_release_should_be_able_to_do_for_me.mdwn @@ -0,0 +1,40 @@ +I thought a bit about what I’d need from Hurd to use it for some of my real life tasks. + +My desktop has to be able to do everything it does now, and that under high load, so it currently is no useful target for the Hurd. + +But then I have an OLPC XO sitting here, and I use it mostly for work and for clearly defined tasks. As such it seems natural to me to check, what the Hurd would have to be able to do to support my workflow on the OLPC. + +### What I need + +* Writing text and programming Python with emacs. - *works*. +* Use Mercurial for my versiontracked stuff. - *works*. +* Reading websites with emacs and w3m or with lynx. - *works*. +* Use SSH to go on my desktop and on the university machine. - *should work*. +* Run X11 with dwm and emacs. - *should work*. +* Boot Hurd on the OLPC from a USB stick. - *not yet*? +* Support networking over wlan and wpa_supplicant. - *not yet*? Might DDE kit help? +* Listen to music with Quod Libet in X11. - *not yet*. Needs audio support. + +### What would be nice + +* Run a Gentoo system. - not *really* needed, but nice to update my system with the same tools. +* Watch videos with mplayer. - unlikely. Even with Linux as kernel watching videos pushes my XO to the limit. But this is not essential. + + +So, as soon as Debian GNU/Hurd (or Arch Hurd) supports the things I need, I’ll put it on a USB-stick and use it for coding and writing. + +To be frank: I’d likely even use it without audio-support. I have an mp3 player and can feed it via USB. So the essential features for me are: + +### Essential features + +* Writing text and programming Python with emacs. - works. +* Use Mercurial for my versiontracked stuff. - works. +* Use SSH to go on my desktop and on the university machine. - should work. +* Boot Hurd on the OLPC from a USB stick. - not yet? +* Support networking over wlan and wpa_supplicant. - not yet? Might DDE kit help? + +### Conclusion + +The Hurd doesn’t yet do everything I need for my OLPC, but it isn’t that far away either. Grub already gets [ported to OLPC](http://grub.enbug.org/OLPC), so what’s missing to make the Hurd a work system for me are just *booting on OLPC from USB stick* and *wlan-support on OLPC*. + +All the rest I need for work is already in place. diff --git a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn index 8b6c4226..6f0af07e 100644 --- a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn +++ b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn @@ -94,16 +94,16 @@ sounds like an interesting option.*" *"While I believe this can be applied to any kind of applications, I'm personally most interested in more efficient and powerful desktop environments -- these considerations are in fact what got me seriously -interested in the Hurd. +interested in the Hurd.* -Even more specifically, I've done most considerations (though by far not +*Even more specifically, I've done most considerations (though by far not all) on modular web browsing environments. Those interested can read up -some of my thoughts on this: +some of my thoughts on this:* http://sourceforge.net/mailarchive/message.php?msg_name=20080909073154.GB821%40alien.local -(Just skip the text mode browsing stuff -- the relevant part is the long +*(Just skip the text mode browsing stuff -- the relevant part is the long monologue at the end... I really should put these ideas into my blog.)"* @@ -112,7 +112,13 @@ monologue at the end... I really should put these ideas into my blog.)"* Another example of features which would be easily possible with the Hurd: -* media-player translator: +* transparent ftp (already possible!): + - settrans -c ftp: /hurd/hostmux /hurd/ftpfs / + - ls ftp://ftp.gnu.org/ + - # -> list the files on the FTP server. + + +* media-player translator: - settrans play /hurd/mediaplayer_play - cp song1.ogg song2.ogg play - # -> files get buffered and played. @@ -121,7 +127,15 @@ or even: * cp ftp://foo/bar/ogg play -that's KDEs fabled network transparency on the filesystem / shell level. +that's KDEs fabled network transparency on the filesystem / shell level (where it belongs to be desktop agnostic). + +* add temporary filesystems anywhere via `settrans -a NODE /hurd/ext2fs` + +* make everything temporarily writeable without really changing it via [[hurd/translator/unionfs]]. + +* Read tar archives and mbox files via `ls foo.tar.gz,,tarfs` and `ls foo.mbox,,mboxfs`, respectively → [[hurd/translator/nsmux]]. + +* Use stuff like the new akonady (personal information) framework in KDE more efficiently from the shell. Reality check @@ -246,8 +260,8 @@ Applications A minor phase, which will surely be interleaved with the others: Making the ideas tangible to turn them into ways how people can use the Hurd. -"Hey, look, this is the Hurd. You can use it like this to do that which you can't do -as well/easily/elegantly in any other way." +*"Hey, look, this is the Hurd. You can use it like this to do that which you can't do +as well/easily/elegantly in any other way."* ### Applications for private use @@ -264,18 +278,18 @@ it's too hard. From what I see, each direct cool application must be about as simple as -$ qemu hurd-is-cool.img -$ login root -$ settrans cool /hurd/cool +$ qemu hurd-is-cool.img +$ login root +$ settrans cool /hurd/cool $ ls cool One main focus in this example is: No command line parameters but the ones we really need. No "-a", if the example is also cool without it. No "--console" if it works otherwise. -Especially no "qemu --cd livecd --hda hurd.img ..." - that one is great for -specialists, but the goal here isn't to teach people better usage of qemu, -but to show them that the Hurd is cool, and only that. +Especially no *"qemu --cd livecd --hda hurd.img ..."* - that one is great for +people who already know qemu or want to learn it, but the goal here isn't to teach people +better usage of qemu, but to show them that the Hurd is cool, and only that. All that interesting advanced stuff just gets newcomers confused. diff --git a/community/weblogs/ArneBab/xkb-woes-trying-to-get-a-german-keyboard-layout.mdwn b/community/weblogs/ArneBab/xkb-woes-trying-to-get-a-german-keyboard-layout.mdwn index fef628bc..693168a4 100644 --- a/community/weblogs/ArneBab/xkb-woes-trying-to-get-a-german-keyboard-layout.mdwn +++ b/community/weblogs/ArneBab/xkb-woes-trying-to-get-a-german-keyboard-layout.mdwn @@ -1,12 +1,12 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant 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]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] Yesterday I spent a few hours trying to get my german keyboard to let me use my umlauts (and to let me type without having to hunt down the right keys), but without much luck. diff --git a/community/weblogs/antrik/hurd-mission-statement.mdwn b/community/weblogs/antrik/hurd-mission-statement.mdwn new file mode 100644 index 00000000..592e176a --- /dev/null +++ b/community/weblogs/antrik/hurd-mission-statement.mdwn @@ -0,0 +1,39 @@ +For a while I have been thinking about the lack of a roadmap for the +Hurd; but now I realized that we lack something even more fundamental: a +simple mission statement -- i.e. saying where we want to go, rather +than how we want to get there. I think many of the problems we have are +directly or indirectly related to that. + +As we didn't have such a mission statement so far, the people currently +involved have vastly different ideas about the mission, which of course +makes it a bit hard to come up with a suitable one now. However, I +managed to come up with something that I believe is generic enough so +all contributors can subscribe to it: + +> *The mission of the Hurd project is: to create a general-purpose +> kernel suitable for the GNU operating system, which is viable for +> everyday use, and gives users and programs as much control over their +> computing environment as possible.* + +*"Suitable for GNU"* in the first part implies a number of things. I +explicitely mentioned *"general-purpose"*, because this an important +feature that sets the Hurd apart from many other microkernel projects, +but isn't immediately obvious. + +I didn't mention that it must be entirely free software, as this should +be obvious to anyone familiar with GNU. + +Another thing I did not mention, because it's too controversial: how +much UNIX do we need? I think that being suitable for GNU requires a +pretty high degree of UNIX compatibility, and also that the default +environment looks to the user more or less like UNIX. However, some +people claimed in the past that GNU could do without UNIX -- the wording +used here doesn't totally preclude such views. + +The second part also leaves a lot of slack: I for my part still believe +that a Mach-based Hurd can be viable for everyday use; but those who +think that a microkernel change is required, should be happy with this +wording as well. + +The third part tries to express the major idea behind the Hurd design in +the most compact and generic way possible. diff --git a/community/weblogs/antrik/plan9-and-the-hurd-major-differences.mdwn b/community/weblogs/antrik/plan9-and-the-hurd-major-differences.mdwn new file mode 100644 index 00000000..9e6143bf --- /dev/null +++ b/community/weblogs/antrik/plan9-and-the-hurd-major-differences.mdwn @@ -0,0 +1,50 @@ +[[!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="Major differences between Plan9 and the Hurd"]] + +There are some similarities between the Hurd and Plan 9 regarding the file +system handling -- but there are also very fundamental differences which go +far beyond monolithic vs. microkernel design: + +- The Hurd is UNIX (POSIX) compatible + +- While (almost) all services are attached to the file system tree, not + all services actually export a file system interface! + + Personally, I advocate using FS-based interfaces as much as possible. + Yet, there are some cases where they get very awkward and/or + inefficient, and domain-specific interfaces simply make a lot more + sense. + + Also, some Hurd services are indeed used to implement the file systems + in the first place -- they work below the FS level, and obviously + can't use an FS interface! + +- File systems are completely decentralized -- clients always talk to + the FS servers directly, without any central VFS layer. (I don't think + that's the case in Plan 9?) + + This offers much more flexibility -- the way the FS interfaces + themselves work can be modified. Many things can be implemented as + normal translators, that would require special VFS support on other + systems. (Extended attributes, VFS-based union mounts, local + namespaces, firmlink, magic file name suffixes etc.) + +- The system design allows users and applications to change almost all + aspects of the system functionality in the local environment easily + and without affecting other parts of the system. + + (This is possible with Plan 9 to some extent; but the Hurd allows it + at a much lower level -- including stuff like the filesystem + interfaces, access control mechanisms, program execution and process + management, and so on.) + +I hope I didn't forget any major differences... diff --git a/community/weblogs/tschwinge/2009-06-23_split_patch_and_git_rebase_--interactive.mdwn b/community/weblogs/tschwinge/2009-06-23_split_patch_and_git_rebase_--interactive.mdwn new file mode 100644 index 00000000..bd08060e --- /dev/null +++ b/community/weblogs/tschwinge/2009-06-23_split_patch_and_git_rebase_--interactive.mdwn @@ -0,0 +1,545 @@ +[[!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="splitting a patch into three, and then some git rebase +--interactive"]] + +I was revisiting the issue of getting the Hurd's code base compiled with recent +versions of GCC. Specifically, there were a lot of duplicate symbols shown at +linking time, and all these were related to `inline` functions. Originally, in +2007, we had solved this problem already (or rather, shifted it) by using GCC's +`-fgnu89-inline` option, but as we [[!GNU_Savannah_patch 6840 desc="saw now"]], +that one obviously doesn't help anymore if third-party code is using the Hurd's +unfixed header files. + +So I was revisiting this issue. I was already prepared that this would take +some hours, with lots of editing, compiling cycles, plus some analyzing of the +binaries. So I made up a fresh repository for this work. + + $ mkdir hurd-ei + $ cd hurd-ei/ + $ git init + [...] + $ git remote add savannah git://git.savannah.gnu.org/hurd/hurd.git + $ git fetch + [...] + +Switch to a new topic-branch. + + $ git checkout -b master-ei savannah/master + Branch master-ei set up to track remote branch master from savannah. + Switched to a new branch 'master-ei' + +(*`ei`* is short for `extern inline`.) + +The first thing to do was to disable that `-fgnu89-inline` option, so I edited +`Makeconf` where it was added to `CFLAGS`. + +I started editing, compiling, editing, compiling, and so on. + +Finally, the tree was in a shape where everything was building fine and the +resulting libraries contained the symbols they should, etc. + +I committed the whole junk as one *big blob* commit, to store it in a safe +place (you never know with these Hurd machines...), and to continue working on +it the next day. + + $ git commit -a + +For the commit message, I already mostly assembled a `ChangeLog`-style log. +Then: + + $ git format-patch savannah/master.. + 0001-Bla.patch + +... and here is [[0001-Bla.patch.bz2]] (compressed). + + +The next day, a.k.a. today, in a different Git repository. + + $ git checkout -b master-fix_inline savannah/master + Branch master-fix_inline set up to track remote branch master from savannah. + Switched to a new branch 'master-fix_inline' + $ bunzip2 < ../some/where/0001-Bla.patch.bz2 | git am + Applying: Bla. + +The *big blob* is now on top of savannah/master (which was +`2772f5c6a6a51cf946fd95bf6ffe254273157a21`, by the way -- in case that you want +to reproduce this tutorial later, simply substitute `savannah/master` with +`2772...`). + +By then, I had come to the conclusion that the commit essentially was fine, but +should be split into two, and the `configure` hunk shouldn't be in there. So +be it. + +So, the `HEAD` of the active branch is our *big blob* commit that we want to +work on. Check with `git show HEAD`: + + $ git show HEAD + commit 93e97f3351337c349e2926f4041e61bc487ef9e6 + Author: Thomas Schwinge <tschwinge@gnu.org> + Date: Tue Jun 23 00:27:28 2009 +0200 + + Bla. + + * console-client/timer.h (fetch_jiffies): Use static inline instead of extern + inline. + * ext2fs/ext2fs.h (test_bit, set_bit, clear_bit, dino, global_block_modified) + (record_global_poke, sync_global_ptr, record_indir_poke, sync_global) + (alloc_sync): Likewise. + * libftpconn/priv.h (unexpected_reply): Likewise. + * term/term.h (qsize, qavail, clear_queue, dequeue_quote, dequeue) + (enqueue_internal, enqueue, enqueue_quote, unquote_char, char_quoted_p) + (queue_erase): Likewise. + * ufs/ufs.h (dino, indir_block, cg_locate, sync_disk_blocks, sync_dinode) + (swab_short, swab_long, swab_long_long): Likewise. + * term/munge.c (poutput): Use static inline instead of inline. + + * libdiskfs/diskfs.h: Apply inline optimization only ifdef + [__USE_EXTERN_INLINES]. Use __extern_inline instead of extern inline. + * libftpconn/ftpconn.h: Likewise. + * libpipe/pipe.h: Likewise. + * libpipe/pq.h: Likewise. + * libshouldbeinlibc/idvec.h: Likewise. + * libshouldbeinlibc/maptime.h: Likewise. + * libshouldbeinlibc/ugids.h: Likewise. + * libstore/store.h: Likewise. + * libthreads/rwlock.h: Likewise. + * libdiskfs/extern-inline.c: Adapt to these changes. + * libftpconn/xinl.c: Likewise. And don't #include "priv.h". + * libpipe/pipe-funcs.c: Likewise. + * libpipe/pq-funcs.c: Likewise. + * libshouldbeinlibc/maptime-funcs.c: Likewise. And remove superfluous + includes. + * libstore/xinl.c: Likewise. + * libthreads/rwlock.c: Likewise. + + * Makeconf (CFLAGS): Don't append $(gnu89-inline-CFLAGS). + * pfinet/Makefile (CFLAGS): Append $(gnu89-inline-CFLAGS). + + diff --git a/Makeconf b/Makeconf + index e9b2045..236f1ec 100644 + --- a/Makeconf + +++ b/Makeconf + @@ -65,7 +65,7 @@ INCLUDES += -I$(..)include -I$(top_srcdir)/include + CPPFLAGS += $(INCLUDES) \ + -D_GNU_SOURCE -D_IO_MTSAFE_IO -D_FILE_OFFSET_BITS=64 \ + $($*-CPPFLAGS) + -CFLAGS += -std=gnu99 $(gnu89-inline-CFLAGS) -Wall -g -O3 \ + +CFLAGS += -std=gnu99 -Wall -g -O3 \ + [...] + +We want to undo this one commit, but preserve its changes in the working +directory. + + $ git reset HEAD^ + Makeconf: locally modified + configure: locally modified + console-client/timer.h: locally modified + ext2fs/ext2fs.h: locally modified + libdiskfs/diskfs.h: locally modified + libdiskfs/extern-inline.c: locally modified + libftpconn/ftpconn.h: locally modified + libftpconn/priv.h: locally modified + libftpconn/xinl.c: locally modified + libpipe/pipe-funcs.c: locally modified + libpipe/pipe.h: locally modified + libpipe/pq-funcs.c: locally modified + libpipe/pq.h: locally modified + libshouldbeinlibc/idvec.h: locally modified + libshouldbeinlibc/maptime-funcs.c: locally modified + libshouldbeinlibc/maptime.h: locally modified + libshouldbeinlibc/ugids.h: locally modified + libstore/store.h: locally modified + libstore/xinl.c: locally modified + libthreads/rwlock.c: locally modified + libthreads/rwlock.h: locally modified + pfinet/Makefile: locally modified + term/munge.c: locally modified + term/term.h: locally modified + ufs/ufs.h: locally modified + +Now, `HEAD` points to the commit before the previous `HEAD`, i.e. `HEAD^`. +Again, check with `git show HEAD`: + + $ git show HEAD + commit 2772f5c6a6a51cf946fd95bf6ffe254273157a21 + Author: Samuel Thibault <samuel.thibault@ens-lyon.org> + Date: Thu Apr 2 23:06:37 2009 +0000 + + 2009-04-03 Samuel Thibault <samuel.thibault@ens-lyon.org> + + * exec.c (prepare): Call PREPARE_STREAM earlier to permit calling + finish_mapping on E even after errors, as is already done in do_exec. + + diff --git a/exec/ChangeLog b/exec/ChangeLog + index 5a0ad1d..a9300bf 100644 + --- a/exec/ChangeLog + +++ b/exec/ChangeLog + @@ -1,3 +1,8 @@ + +2009-04-03 Samuel Thibault <samuel.thibault@ens-lyon.org> + + + + * exec.c (prepare): Call PREPARE_STREAM earlier to permit calling + + finish_mapping on E even after errors, as is already done in do_exec. + + + 2008-06-10 Samuel Thibault <samuel.thibault@ens-lyon.org> + + * elfcore.c (TIME_VALUE_TO_TIMESPEC): Completely implement instead of + diff --git a/exec/exec.c b/exec/exec.c + index 05dc883..cb3d741 100644 + --- a/exec/exec.c + +++ b/exec/exec.c + @@ -726,6 +726,9 @@ prepare (file_t file, struct execdata *e) + + e->interp.section = NULL; + + + /* Initialize E's stdio stream. */ + + prepare_stream (e); + [...] + +Luckily, Git saves the previous (i.e. before the `git reset`) `HEAD` reference +as `ORIG_HEAD`. Have a look at it with `git show ORIG_HEAD` -- it contains the +*big blob* commit, including the preliminary commit message -- just what HEAD +was before: + + $ git show ORIG_HEAD + commit 93e97f3351337c349e2926f4041e61bc487ef9e6 + Author: Thomas Schwinge <tschwinge@gnu.org> + Date: Tue Jun 23 00:27:28 2009 +0200 + + Bla. + + * console-client/timer.h (fetch_jiffies): Use static inline instead of extern + inline. + [...] + + diff --git a/Makeconf b/Makeconf + index e9b2045..236f1ec 100644 + --- a/Makeconf + +++ b/Makeconf + @@ -65,7 +65,7 @@ INCLUDES += -I$(..)include -I$(top_srcdir)/include + CPPFLAGS += $(INCLUDES) \ + -D_GNU_SOURCE -D_IO_MTSAFE_IO -D_FILE_OFFSET_BITS=64 \ + $($*-CPPFLAGS) + -CFLAGS += -std=gnu99 $(gnu89-inline-CFLAGS) -Wall -g -O3 \ + +CFLAGS += -std=gnu99 -Wall -g -O3 \ + [...] + +OK, now let's pick the files that we want to have in the first of the +envisioned two commits: these are the *static inline instead of extern inline* +and *apply inline optimization only...* sections. + + $ git add console-client/timer.h ext2fs/ext2fs.h [...] libthreads/rwlock.c + +Oh, we forgot something: now that we're preparing this stuff to go into the +*master* repository, update the copyright years. Edit, edit, edit, and then, +again: + + $ git add console-client/timer.h ext2fs/ext2fs.h [...] libthreads/rwlock.c + +Now Git's staging area contains the changes that we want to commit (and the +working directory contains the rest of the *big blob*). Commit these `add`ed +files, and use *big blob*'s commit message as a template for the new one, as it +already contains most of what we want (don't forget to chop off the unneeded +parts). + + $ git commit -c ORIG_HEAD + Waiting for Emacs... + [master-fix_inline 51c15bc] Use static inline where appropriate. + 6 files changed, 50 insertions(+), 51 deletions(-) + $ git show HEAD + commit c6c9d7a69dea26e04bba7010582e7bcd612e710c + Author: Thomas Schwinge <tschwinge@gnu.org> + Date: Tue Jun 23 00:27:28 2009 +0200 + + Use static inline where appropriate and use glibc's __extern_inline machinery. + + * console-client/timer.h (fetch_jiffies): Use static inline instead of extern + inline. + * ext2fs/ext2fs.h (test_bit, set_bit, clear_bit, dino, global_block_modified) + (record_global_poke, sync_global_ptr, record_indir_poke, sync_global) + (alloc_sync): Likewise. + * libftpconn/priv.h (unexpected_reply): Likewise. + * term/term.h (qsize, qavail, clear_queue, dequeue_quote, dequeue) + (enqueue_internal, enqueue, enqueue_quote, unquote_char, char_quoted_p) + (queue_erase): Likewise. + * ufs/ufs.h (dino, indir_block, cg_locate, sync_disk_blocks, sync_dinode) + (swab_short, swab_long, swab_long_long): Likewise. + * term/munge.c (poutput): Use static inline instead of inline. + + * libdiskfs/diskfs.h: Apply inline optimization only ifdef + [__USE_EXTERN_INLINES]. Use __extern_inline instead of extern inline. + * libftpconn/ftpconn.h: Likewise. + * libpipe/pipe.h: Likewise. + * libpipe/pq.h: Likewise. + * libshouldbeinlibc/idvec.h: Likewise. + * libshouldbeinlibc/maptime.h: Likewise. + * libshouldbeinlibc/ugids.h: Likewise. + * libstore/store.h: Likewise. + * libthreads/rwlock.h: Likewise. + * libdiskfs/extern-inline.c: Adapt to these changes. + * libftpconn/xinl.c: Likewise. And don't #include "priv.h". + * libpipe/pipe-funcs.c: Likewise. + * libpipe/pq-funcs.c: Likewise. + * libshouldbeinlibc/maptime-funcs.c: Likewise. And remove superfluous + includes. + * libstore/xinl.c: Likewise. + * libthreads/rwlock.c: Likewise. + + diff --git a/console-client/timer.h b/console-client/timer.h + index 4204192..5e64e97 100644 + --- a/console-client/timer.h + +++ b/console-client/timer.h + @@ -1,5 +1,7 @@ + /* timer.h - Interface to a timer module for Mach. + - Copyright (C) 1995,96,2000,02 Free Software Foundation, Inc. + + + + Copyright (C) 1995, 1996, 2000, 2002, 2009 Free Software Foundation, Inc. + + + Written by Michael I. Bushnell, p/BSG and Marcus Brinkmann. + + This file is part of the GNU Hurd. + @@ -54,7 +56,7 @@ int timer_remove (struct timer_list *timer); + /* Change the expiration time of the timer TIMER to EXPIRES. */ + void timer_change (struct timer_list *timer, long long expires); + + -extern inline long long + +static inline long long + [...] + +As you can see, `HEAD` now points to the new commit on top of the current +branch. (`ORIG_HEAD` doesn't change.) + +On to the next, and last one, only two changes should be left: the `Makeconf` +and `pfinet/Makefile` ones. + + $ git status + # On branch master-fix_inline + # Your branch is ahead of 'savannah/master' by 1 commit. + # + # Changed but not updated: + # (use "git add <file>..." to update what will be committed) + # (use "git checkout -- <file>..." to discard changes in working directory) + # + # modified: Makeconf + # modified: configure + # modified: pfinet/Makefile + # + # Untracked files: + # (use "git add <file>..." to include in what will be committed) + # + # 0001-Bla.patch + # autom4te.cache/ + # hurd_extern_inline_fix.patch?file_id=18191 + no changes added to commit (use "git add" and/or "git commit -a") + +Alright, there is as well still the `configure` hunk that we want to get rid +of. But first for the real second commit, after editing for again adding the +copyright year update: + + $ git add Makeconf pfinet/Makefile + $ git commit -c ORIG_HEAD + Waiting for Emacs... + [master-fix_inline 6a967d1] We're now C99 inline safe -- apart from the Linux code in pfinet. + 2 files changed, 6 insertions(+), 3 deletions(-) + +Check that we're in a clean state now: + + $ git status + # On branch master-fix_inline + # Your branch is ahead of 'savannah/master' by 2 commits. + # + # Changed but not updated: + # (use "git add <file>..." to update what will be committed) + # (use "git checkout -- <file>..." to discard changes in working directory) + # + # modified: configure + # + # Untracked files: + # (use "git add <file>..." to include in what will be committed) + # + # 0001-Bla.patch + # autom4te.cache/ + # hurd_extern_inline_fix.patch?file_id=18191 + no changes added to commit (use "git add" and/or "git commit -a") + +Oops, we forgot something... + + $ git checkout -- configure + +Now, our tree is clean again. (Check with `git status`.) + +By now, we came to the conclusion that the first of the two commits should have +been further split into two separate ones. Of course, essentially we would do +the same splitting again that we've done just now -- but how to easily modify +the first commit, now that we have another one on top of it? + +Alright, `git rebase --interactive` to the rescue -- let's interactively +*`rebase`* the last two commits, to modify them as wanted. + + $ git rebase --interactive HEAD~2 + Waiting for Emacs... + +Emacs wants us to tell which commits we want to keep as they are (`pick`), +which should be merged into others (`squash`), and which we want to `edit`. In +our scenario, we want to `edit` the first one and `pick` the second one. +Change the file thusly and close it. + + Stopped at 5becbb5... Use static inline where appropriate and use... + You can amend the commit now, with + + git commit --amend + + Once you are satisfied with your changes, run + + git rebase --continue + +We want to undo this first commit to split it into two. Again, use `git reset` +for that, while preserving the commit's changes in the working directory. + + $ git reset HEAD^ + console-client/timer.h: locally modified + [...] + +Pick the set of files that we want to have in the first of the envisioned two +commits: the *static inline instead of extern inline* section, and commit them, +again using the previous commit message as a template for the new one: + + $ git add console-client/timer.h ext2fs/ext2fs.h [...] term/munge.c + $ git commit -c ORIG_HEAD + Waiting for Emacs... + [detached HEAD 51c15bc] Use static inline where appropriate. + 6 files changed, 50 insertions(+), 51 deletions(-) + +Next part: *apply inline optimization only...*. Again, `git add` those files +that shall be part of the next commit, i.e. all remaining ones. As before, use +the previous commit message as a template. + + $ git add libdiskfs/diskfs.h [...] libthreads/rwlock.c + $ git commit -c ORIG_HEAD + Waiting for Emacs... + [detached HEAD 8ac30ea] [__USE_EXTERN_INLINES]: Use glibc's __extern_inline machinery. + 16 files changed, 508 insertions(+), 356 deletions(-) + +Now we're done with splitting that commit into two. (Check with `git status` +that we didn't forget anything.) What's missing is getting back the other +commit on top of the two now-split ones: + + $ git rebase --continue + Successfully rebased and updated refs/heads/master-fix_inline. + +Here we go. The other commit has been applied on top of the two new ones. + +Due to time-honored tradition, I always double-check what I have just +committed, before distributing it to the world: + + $ git log --reverse -p -C --cc savannah/master.. + +... and promptly, I recognize some changes that shouldn't be in there: when +using it on some files, Emacs' `copyright-fix-years`, aside from indeed fixing +the list of copyright years, and adding the current year, also changed *GPL +... version 2* into *version 3*, which would be nice, but which we can't do for +the moment. The error is present only in the first and second commit. If it +were in only in the third (the last) one, simply editing the files, and then +using `git commit --amend` would be the solution. But again there is the +problem about how to modify the first (`HEAD~2`) and second (`HEAD~1`, or +`HEAD^`) commit now that there is another one on top of it. By now, we know +the solution: + + $ git rebase --interactive HEAD~3 + Waiting for Emacs... + +This time, we need to `edit` the first and second commits, and `pick` the third +one. + + Stopped at ffd215b... Use static inline where appropriate. + You can amend the commit now, with + + git commit --amend + + Once you are satisfied with your changes, run + + git rebase --continue + +`git show` (which defaults to showing `HEAD`, by the way) can again be used to +have a look at the current `HEAD` (which is the first of the three commits), +and then we revert the unwanted changes in the editor, resulting with the +following changed files: + + $ git status + # Not currently on any branch. + # Changed but not updated: + # (use "git add <file>..." to update what will be committed) + # (use "git checkout -- <file>..." to discard changes in working directory) + # + # modified: ext2fs/ext2fs.h + # modified: libftpconn/priv.h + # modified: term/munge.c + # modified: term/term.h + # modified: ufs/ufs.h + # + # Untracked files: + # (use "git add <file>..." to include in what will be committed) + # + # 0001-Bla.patch + # autom4te.cache/ + # hurd_extern_inline_fix.patch?file_id=18191 + no changes added to commit (use "git add" and/or "git commit -a") + +Then, we can -- as `git rebase` suggested above -- *amend* the existing `HEAD` +commit with these changes (`--amend` and `--all`), reusing `HEAD`'s commit +message without spawning an editor (`-C HEAD`): + + $ git commit --amend -C HEAD --all + [detached HEAD c6c9d7a] Use static inline where appropriate. + 6 files changed, 45 insertions(+), 46 deletions(-) + +Continue with the next commit: + + $ git rebase --continue + Stopped at 8ac30ea... [__USE_EXTERN_INLINES]: Use glibc's __extern_inline machinery. + You can amend the commit now, with + + git commit --amend + + Once you are satisfied with your changes, run + + git rebase --continue + +Again, have a look at the commit (`git show`), revert the unwanted changes, +*amend* `HEAD`, and continue to the next commit: + + $ git commit --amend -C HEAD --all + [detached HEAD 9990dc6] [__USE_EXTERN_INLINES]: Use glibc's __extern_inline machinery. + 16 files changed, 500 insertions(+), 348 deletions(-) + $ git rebase --continue + Stopped at 6a967d1... We're now C99 inline safe -- apart from the Linux code in pfinet. + You can amend the commit now, with + + git commit --amend + + Once you are satisfied with your changes, run + + git rebase --continue + +Two files are left to be edited (`git show`, etc., again), and finally: + + $ git commit --amend -C HEAD --all + [detached HEAD 241c605] We're now C99 inline safe -- apart from the Linux code in pfinet. + 2 files changed, 5 insertions(+), 2 deletions(-) + $ git rebase --continue + Successfully rebased and updated refs/heads/master-fix_inline. + +That's it. `git log --reverse -p -C --cc savannah/master..` now looks as nice +as can be. + + +Of course, this is only a small insight of what is possible to do with `git +rebase` and friends -- see the manual for further explanations. diff --git a/community/weblogs/tschwinge/2009-06-23_split_patch_and_git_rebase_--interactive/0001-Bla.patch.bz2 b/community/weblogs/tschwinge/2009-06-23_split_patch_and_git_rebase_--interactive/0001-Bla.patch.bz2 Binary files differnew file mode 100644 index 00000000..4a682c86 --- /dev/null +++ b/community/weblogs/tschwinge/2009-06-23_split_patch_and_git_rebase_--interactive/0001-Bla.patch.bz2 diff --git a/community/weblogs/tschwinge/2009-06-24_importing_from_gnu_arch_into_git.mdwn b/community/weblogs/tschwinge/2009-06-24_importing_from_gnu_arch_into_git.mdwn new file mode 100644 index 00000000..f397e75b --- /dev/null +++ b/community/weblogs/tschwinge/2009-06-24_importing_from_gnu_arch_into_git.mdwn @@ -0,0 +1,104 @@ +[[!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="converting from GNU arch to Git -- without direct repository +access"]] + +I wanted to import an old GNU arch repository into Git, but only had HTTP +access via ArchZoom. I spent quite some time to try teaching `git archimport` +to use HTTP access to that repository, but this didn't work out. Too bad -- +but at least, using ArchZoom, I was able to get the individual revisions' +tarballs: + + $ ls -1 *.tar.gz + bpf--devel--0.0--base-0.tar.gz + bpf--devel--0.0--patch-1.tar.gz + bpf--devel--0.0--patch-10.tar.gz + bpf--devel--0.0--patch-11.tar.gz + bpf--devel--0.0--patch-12.tar.gz + bpf--devel--0.0--patch-2.tar.gz + bpf--devel--0.0--patch-3.tar.gz + [...] + bpf--devel--0.0--patch-9.tar.gz + bpf--release--0.1--base-0.tar.gz + bpf--release--0.1--patch-1.tar.gz + bpf--release--0.1--patch-2.tar.gz + [...] + bpf--release--0.1--patch-8.tar.gz + +I unpacked these: + + $ for f in *.tar.gz; do tar -xz < "$f" || echo >&2 "$f" failed; done + +The last revision's tree apparently contains all previous revisions' commit +information (author, date, message), so use that: + + $ cp -a ↩ + bpf--release--0.1--patch-8/{arch}/bpf/bpf--devel/bpf--devel--0.0/info@hurdfr.org--hurdfr/patch-log ↩ + d-patch-log + $ cp -a ↩ + bpf--release--0.1--patch-8/{arch}/bpf/bpf--release/bpf--release--0.1/info@hurdfr.org--hurdfr/patch-log ↩ + r-patch-log + +... and extract the information that we need: + + $ base=bpf--devel--0.0-- && ↩ + for f in d-patch-log/*; do ↩ + grep < "$f" ^Creator: | head -n 1 ↩ + | { read j c && ↩ + echo "$c" | sed s%' <.*'%% ↩ + > "$base""$(basename "$f")".author_name && ↩ + echo "$c" | sed -e 's%.*<%%' -e 's%>.*%%' ↩ + > "$base""$(basename "$f")".author_email; } && ↩ + grep < "$f" ^Standard-date: | head -n 1 | { read j d && echo "$d" ↩ + > "$base""$(basename "$f")".author_date; } && ↩ + { grep < "$f" ^Summary: | head -n 1 | { read j m && echo "$m"; } && ↩ + echo && sed < "$f" '1,/^$/d'; } ↩ + > "$base""$(basename "$f")".log ↩ + || echo >&2 "$f" failed; ↩ + done + $ base=bpf--release--0.1-- && ↩ + for f in r-patch-log/*; [...] + +(Of course, I could have used something more elaborate than shell scripting...) + +Remove the GNU arch stuff that we don't need anymore: + + $ find bpf--*/ -type d \( -name {arch} -o -name .arch-ids \) -print0 ↩ + | xargs -0 rm -r + +The `base-0` revisions are actually either empty (the `devel` one) or +equivalent to the previous revision (the `release` one), so remove these: + + $ rm -rf bpf--devel--0.0--base-0 bpf--release--0.1--base-0 + +Finally, import all the other ones: + + $ mkdir g && ( cd g/ && git init ) + $ for d in bpf--d*-? bpf--d*-?? bpf--r*; do ↩ + test -d "$d"/ || continue && ↩ + ( cd g/ && ↩ + rsync -a --delete --exclude=/.git ../"$d"/ ./ && ↩ + git add . && ↩ + GIT_AUTHOR_NAME="$(cat ../"$d".author_name)" ↩ + GIT_AUTHOR_EMAIL="$(cat ../"$d".author_email)" ↩ + GIT_AUTHOR_DATE="$(cat ../"$d".author_date)" ↩ + git commit -F ../"$d".log -a ); ↩ + done + +Voilà! + + +**Update 2009-06-25:** + +Half a day later, [[HurdFr]] published a `git archimport`-converted repository +-- which was *identical* to my hand-crafted one (apart from having +`git-archimport-id:` tags in the commit messages, and the first (empty) commit +not being stripped off). :-) |