diff options
Diffstat (limited to 'community')
| -rw-r--r-- | community/gsoc/project_ideas.mdwn | 1 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/driver_glue_code.mdwn | 27 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/dtrace.mdwn | 62 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/file_locking.mdwn | 42 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/sound.mdwn | 42 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/sound/discussion.mdwn | 47 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/tcp_ip_stack.mdwn | 2 |
7 files changed, 12 insertions, 211 deletions
diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index c17b06f9..6ab38823 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -102,7 +102,6 @@ project_ideas: community/gsoc/project_ideas/package_manager community/gsoc/project_ideas/driver_glue_code community/gsoc/project_ideas/language_bindings - community/gsoc/project_ideas/file_locking community/gsoc/project_ideas/gdb community/gsoc/project_ideas/tcp_ip_stack community/gsoc/project_ideas/nfs diff --git a/community/gsoc/project_ideas/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn index 0f921590..c1850d21 100644 --- a/community/gsoc/project_ideas/driver_glue_code.mdwn +++ b/community/gsoc/project_ideas/driver_glue_code.mdwn @@ -27,22 +27,24 @@ This is [[!GNU_Savannah_task 5488]]. [[open issues/user-space device drivers]]. [[open issues/device drivers and io systems]]. -The most promising approach for getting newer drivers seems to be [[DDE]]: +The most promising approach for getting newer drivers seems to be the Rump kernel: it already does the hard work of providing an environment where the foreign drivers can run, and offers the additional benefit of being externally maintained. -DDE also offers the necessary facilities +Rump also offers the necessary facilities for running all drivers in separate userspace processes, which is more desirable than drivers running in the microkernel. -[[Zheng Da|zhengda]] has already done considerable work on this. +Robert Millan worked on a port of the Rump kernel, which allowed to run a sound +driver in userland. This work now needs to be extended. + +[[Zheng Da|zhengda]] has already done considerable work on a similar approach, using [[DDE]] The basic framework for using DDE in the Hurd is present, and network card drivers are already working very well. However, this work isn't fully integrated in the Hurd yet. The additional kernel interfaces that were created for this -are still prototypes, and will need to be reworked. -Also, there is no build system for automatically compiling -all Linux network card drivers in one go. +are still prototypes, and will need to be reworked. This environment can be +reused and polished for Rump. Other types of drivers are missing so far. Support for IDE drivers has been partially implemented, @@ -51,13 +53,10 @@ To fully replace the old in-kernel drivers, further infrastructure will be necessary to make userspace disk drivers usable for the root filesystem. -Some other subsystems are missing or incomplete in DDE itself, -and will require additional work that is not specific to the Hurd implementation. - The goal of this task is to fix at least one of the mentioned major shortcomings: rework the kernel interfaces; -provide a streamlined build system for the drivers; -finish IDE support; +polish the rumpkernel changes; +componentize the rumpkernel elements for sound; or implement support for some other subsystem. <!-- should probably provide separate task descriptions for each... --> @@ -69,13 +68,9 @@ such as memory management for example. Possible mentors: Justus Winter (teythoon), Samuel Thibault (youpi) -Exercise: Get one of the not yet integrated Linux network card drivers to work. -(Note: This should be straightforward, -once you have the framework properly built and set up...) +Exercise: Install and run the current rumpkernel library (librump0) and the corresponding mplayer, get it to run. --- # 2016-02-14, Justus Winter - -`s/dde/rump/g` of course. diff --git a/community/gsoc/project_ideas/dtrace.mdwn b/community/gsoc/project_ideas/dtrace.mdwn deleted file mode 100644 index 6261c03e..00000000 --- a/community/gsoc/project_ideas/dtrace.mdwn +++ /dev/null @@ -1,62 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009, 2011 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!meta title="Kernel Instrumentation"]] - -[[!tag open_issue_gnumach]] - -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. - -Possible mentors: Samuel Thibault (youpi) - -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 deleted file mode 100644 index ebb322f1..00000000 --- a/community/gsoc/project_ideas/file_locking.mdwn +++ /dev/null @@ -1,42 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009, 2012, 2014 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. - -A preliminary patch is [[!GNU_Savannah_patch 332 desc="available"]]. - -Possible mentors: Samuel Thibault (youpi) - -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 deleted file mode 100644 index 8411831b..00000000 --- a/community/gsoc/project_ideas/sound.mdwn +++ /dev/null @@ -1,42 +0,0 @@ -[[!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/sound/discussion.mdwn b/community/gsoc/project_ideas/sound/discussion.mdwn deleted file mode 100644 index 4a95eb62..00000000 --- a/community/gsoc/project_ideas/sound/discussion.mdwn +++ /dev/null @@ -1,47 +0,0 @@ -[[!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. diff --git a/community/gsoc/project_ideas/tcp_ip_stack.mdwn b/community/gsoc/project_ideas/tcp_ip_stack.mdwn index 331336ac..6410dee0 100644 --- a/community/gsoc/project_ideas/tcp_ip_stack.mdwn +++ b/community/gsoc/project_ideas/tcp_ip_stack.mdwn @@ -34,7 +34,7 @@ make such a split later on feasible. This is [[!GNU_Savannah_task 5469]]. -Possible mentors: zhengda +Possible mentors: youpi Exercise: You could try making some improvement to the existing pfinet implementation; or you could work towards running some existing userspace |