From f93aada69b0c8e147363ac317866d78a24eb9bfc Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 25 May 2018 16:15:38 +0200 Subject: Revert page removals of "Update gsoc ideas" ..., to avoid breaking existing links. Instead, mark as obsolete. This reverts parts of commit 4f15828febdea054993b2c21f62530c17ce3adea. --- community/gsoc/project_ideas.mdwn | 4 +- community/gsoc/project_ideas/dtrace.mdwn | 67 ++++++++++++++++++++++ community/gsoc/project_ideas/file_locking.mdwn | 47 +++++++++++++++ community/gsoc/project_ideas/sound.mdwn | 48 ++++++++++++++++ community/gsoc/project_ideas/sound/discussion.mdwn | 47 +++++++++++++++ 5 files changed, 210 insertions(+), 3 deletions(-) create mode 100644 community/gsoc/project_ideas/dtrace.mdwn create mode 100644 community/gsoc/project_ideas/file_locking.mdwn create mode 100644 community/gsoc/project_ideas/sound.mdwn create mode 100644 community/gsoc/project_ideas/sound/discussion.mdwn (limited to 'community/gsoc') diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index 6ab38823..714f37da 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -1,5 +1,5 @@ [[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, -2016 Free Software Foundation, Inc."]] +2016, 2018 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 @@ -105,7 +105,6 @@ project_ideas: community/gsoc/project_ideas/gdb community/gsoc/project_ideas/tcp_ip_stack community/gsoc/project_ideas/nfs - community/gsoc/project_ideas/sound community/gsoc/project_ideas/disk_io_performance community/gsoc/project_ideas/gnumach_cleanup community/gsoc/project_ideas/xmlfs @@ -122,7 +121,6 @@ project_ideas: community/gsoc/project_ideas/testing_framework community/gsoc/project_ideas/libcap community/gsoc/project_ideas/valgrind - community/gsoc/project_ideas/dtrace community/gsoc/project_ideas/libdiskfs_locking" """]] diff --git a/community/gsoc/project_ideas/dtrace.mdwn b/community/gsoc/project_ideas/dtrace.mdwn new file mode 100644 index 00000000..f7aeb6e8 --- /dev/null +++ b/community/gsoc/project_ideas/dtrace.mdwn @@ -0,0 +1,67 @@ +[[!meta copyright="Copyright © 2008, 2009, 2011, 2018 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="Kernel Instrumentation"]] + +[[!tag open_issue_gnumach]] + +[[!template id=highlight text="""/!\ Obsolete /!\ + +--- + +This is no longer valid as a Google Summer of Code project."""]] + + +One of the main problems of the current Hurd implementation is very poor +[[open_issues/performance]]. While we have a bunch of ideas what could cause the performance +problems, these are mostly just guesses. Better understanding what really +causes bad performance is necessary to improve the situation. + +For that, we need tools for performance measurements. While all kinds of more +or less specific [[open_issues/profiling]] tools could be conceived, the most promising and +generic approach seems to be a framework for logging certain events in the +running system (both in the microkernel and in the Hurd servers). This would +allow checking how much time is spent in certain modules, how often certain +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 kernel instrumentation framework is Sun's dtrace, +originally written for Solaris, +but also adopted by some other systems. +However, the GPL-incompatible license means it can't be used in Linux, +and thus Linux developers created their own frameworks instead: +first [[SystemTap]], and now [[LTTng]]. + +In 2008, Andrei Barbu did initial work on kernel probes for the Hurd. +However, not all of his patches got merged, +because some turned out not to be fully functional. +Also, he didn't get around to work on userspace probes, +nor on a nice frontend for writing test scripts employing the probes. + +The goal of this project is to make the instrumentation framework +more usable and complete, +and to better integrate it in the Hurd. +For that, the student will have to work +on some real profiling and/or debugging tasks, +and fix any shortcomings he encounters in the framework. + +This is a pretty involved task. +Previous experience with low-level programming is a must; +and it also requires a good grasp on interactions in complex systems. + +To work on this project, +the student will have to get familiar with GNU Mach. +(The microkernel employed by the Hurd.) +Some understanding of other aspects of the Hurd will also be required, +depending on the exact nature of the profiling/debugging performed. + +Exercise: Use the existing probes to perform some simple measurement. diff --git a/community/gsoc/project_ideas/file_locking.mdwn b/community/gsoc/project_ideas/file_locking.mdwn new file mode 100644 index 00000000..a368a7a8 --- /dev/null +++ b/community/gsoc/project_ideas/file_locking.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2008, 2009, 2012, 2014, 2018 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"]] + +[[!template id=highlight text="""/!\ Obsolete /!\ + +--- + +This is no longer valid as a Google Summer of Code project."""]] + + +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. + +A preliminary patch is [[!GNU_Savannah_patch 332 desc="available"]]. + +Exercise: Find one of the existing issues, either by looking at the task/bug +filed on [[open_issues/file_locking]], on +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/sound.mdwn b/community/gsoc/project_ideas/sound.mdwn new file mode 100644 index 00000000..1a33ae2c --- /dev/null +++ b/community/gsoc/project_ideas/sound.mdwn @@ -0,0 +1,48 @@ +[[!meta copyright="Copyright © 2008, 2009, 2018 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"]] + +[[!template id=highlight text="""/!\ Obsolete /!\ + +--- + +This is no longer valid as a Google Summer of Code project."""]] + + +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. + +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/sound/discussion.mdwn b/community/gsoc/project_ideas/sound/discussion.mdwn new file mode 100644 index 00000000..4a95eb62 --- /dev/null +++ b/community/gsoc/project_ideas/sound/discussion.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!taglink open_issue_documentation]]: update [[sound]] page. + + +# IRC, freenode, #hurd, 2013-09-01 + + I'm new to the hurd but I'd love to learn enough to work on sound + support. + + http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/sound/ + says drivers should be ported to GNU Mach as a first step. + Is this information still current or should the existing Linux + driver be wrapped with DDE instead? + if i recall correctly dde is currently only being used for + network drivers. i'm not sure how much work would be involved for sound + or usb + + +## IRC, freenode, #hurd, 2013-09-02 + + The sound support proposal + (http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/sound/) + recommends porting some other kernel's sound driver to GNU Mach. Is this + still current or should DDE be used instead? + rekado: dde or anything userspace-based is generally preferred + rekado: both are about porting some other kernel's sound driver + dde is preferred yes + This email says that sound drivers are already partly working with + DDE: http://os.inf.tu-dresden.de/pipermail/l4-hackers/2009/004291.html + So, should I just try to get some ALSA kernel parts to compile + with DDE? + well, what is missing is also the dde←→hurd glue + rekado: there is also a problem with pci arbitration + pinotree: I assumed DDEKit works with the hurd and we could use + any DDE/ glue code with it + * rekado looks up pci arbitration + only for networking atm + ah, I see. -- cgit v1.2.3