summaryrefslogtreecommitdiff
path: root/community/gsoc
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@codesourcery.com>2018-05-25 16:15:38 +0200
committerThomas Schwinge <thomas@codesourcery.com>2018-05-25 16:15:38 +0200
commitf93aada69b0c8e147363ac317866d78a24eb9bfc (patch)
tree582f1dbcfcbec5f80bfa507bedd239bc9a1f5a5b /community/gsoc
parent4f15828febdea054993b2c21f62530c17ce3adea (diff)
Revert page removals of "Update gsoc ideas"
..., to avoid breaking existing links. Instead, mark as obsolete. This reverts parts of commit 4f15828febdea054993b2c21f62530c17ce3adea.
Diffstat (limited to 'community/gsoc')
-rw-r--r--community/gsoc/project_ideas.mdwn4
-rw-r--r--community/gsoc/project_ideas/dtrace.mdwn67
-rw-r--r--community/gsoc/project_ideas/file_locking.mdwn47
-rw-r--r--community/gsoc/project_ideas/sound.mdwn48
-rw-r--r--community/gsoc/project_ideas/sound/discussion.mdwn47
5 files changed, 210 insertions, 3 deletions
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. <!-- TODO. Elaborate. -->
+
+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
+
+ <rekado> I'm new to the hurd but I'd love to learn enough to work on sound
+ support.
+ <rekado>
+ http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/sound/
+ says drivers should be ported to GNU Mach as a first step.
+ <rekado> Is this information still current or should the existing Linux
+ driver be wrapped with DDE instead?
+ <auronandace> 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
+
+ <rekado> 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?
+ <pinotree> rekado: dde or anything userspace-based is generally preferred
+ <braunr> rekado: both are about porting some other kernel's sound driver
+ <braunr> dde is preferred yes
+ <rekado> This email says that sound drivers are already partly working with
+ DDE: http://os.inf.tu-dresden.de/pipermail/l4-hackers/2009/004291.html
+ <rekado> So, should I just try to get some ALSA kernel parts to compile
+ with DDE?
+ <pinotree> well, what is missing is also the dde←→hurd glue
+ <braunr> rekado: there is also a problem with pci arbitration
+ <rekado> pinotree: I assumed DDEKit works with the hurd and we could use
+ any DDE/<other kernel> glue code with it
+ * rekado looks up pci arbitration
+ <pinotree> only for networking atm
+ <rekado> ah, I see.