From eda7364b16b318c7209e60b9699d672cc599e040 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 25 May 2018 15:35:17 +0200 Subject: Revert page removal of "Drop xattr project idea, it's done" ..., to avoid breaking existing links. Instead, mark as obsolete. This reverts parts of commit a6844c659acd25e913b1d20e48610765352bd10e. --- community/gsoc/project_ideas/xattr.mdwn | 50 +++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 community/gsoc/project_ideas/xattr.mdwn (limited to 'community/gsoc/project_ideas') diff --git a/community/gsoc/project_ideas/xattr.mdwn b/community/gsoc/project_ideas/xattr.mdwn new file mode 100644 index 00000000..f35498fe --- /dev/null +++ b/community/gsoc/project_ideas/xattr.mdwn @@ -0,0 +1,50 @@ +[[!meta copyright="Copyright © 2009, 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 +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"]] + +[[!template id=highlight text="""/!\ Obsolete /!\ + +--- + +This is no longer valid as a Google Summer of Code project; it's done."""]] + + +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|open_issues/xattr]], and +might serve as a starting point. -- cgit v1.2.3 From ab97868f7e5097ce6d141c7783c1e07eaa9c4ba1 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 25 May 2018 15:37:30 +0200 Subject: Revert page removal of "Drop physical memory management project" ..., to avoid breaking existing links. Instead, mark as obsolete. This reverts parts of commit 371a782cd09a6f0c7f9f99cf336351635c6fa7c9. --- .../project_ideas/physical_memory_management.mdwn | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 community/gsoc/project_ideas/physical_memory_management.mdwn (limited to 'community/gsoc/project_ideas') diff --git a/community/gsoc/project_ideas/physical_memory_management.mdwn b/community/gsoc/project_ideas/physical_memory_management.mdwn new file mode 100644 index 00000000..af360507 --- /dev/null +++ b/community/gsoc/project_ideas/physical_memory_management.mdwn @@ -0,0 +1,58 @@ +[[!meta copyright="Copyright © 2015, 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 +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="Physical memory management"]] + +[[!template id=highlight text="""/!\ Obsolete /!\ + +--- + +This is no longer valid as a Google Summer of Code project; it was basically +done by Richard."""]] + + +GNU Mach is currently suffering from severe limitations caused by the way +it manages physical memory. For example, since it requires pages to be mapped +in kernel space in order to be used, the maximum amount of usable physical +memory is currently around 800MB (or 1.8GB if a 2/2 split is set). And +because the page allocator is unable to easily return blocks of contiguous +pages, the kernel has to use virtual memory to provide contiguity. +But the kernel virtual space is separate from the direct mapping of +physical memory, so the larger it is, the less physical pages available. +The size of the kernel space is currently around 200MB, with around 100MB +for kernel objects. This small size prevents the system from achieving +scalability, since a panic occurs when the kernel is unable to allocate +a kernel object such as a port. In addition, the kernel uses mainly tables +to store IPC rights. When a table is full, it is enlarged through a kernel +specific version of realloc(). When a file system starts managing many +files (e.g. because some of their content is cached in physical memory), +these tables can get big enough to make realloc() fail because of +fragmentation. + +The goal of this project is to make as much physical memory available as +possible for both the kernel and applications, by rewriting the page +allocator into a buddy allocator to support contiguous block allocations, +using it directly instead of virtual memory as the backend of the slab +allocator for kernel objects, and, if time allows it, transform IPC right +tables (e.g. into radix trees) and get rid of realloc(). + +This project requires a good understanding of virtual memory (both physical +mappings at the MMU level and virtual mappings at the VM level), and strong +skills in C programming. Note that some work has already been done in the +X15 project about this, and can be reused as a reference. + +Useful links : + + * + + * + + * -- cgit v1.2.3 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/project_ideas') 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