diff options
Diffstat (limited to 'community/gsoc/project_ideas')
-rw-r--r-- | community/gsoc/project_ideas/driver_glue_code.mdwn | 11 | ||||
-rw-r--r-- | community/gsoc/project_ideas/physical_memory_management.mdwn | 58 | ||||
-rw-r--r-- | community/gsoc/project_ideas/tcp_ip_stack.mdwn | 3 | ||||
-rw-r--r-- | community/gsoc/project_ideas/xattr.mdwn | 50 |
4 files changed, 113 insertions, 9 deletions
diff --git a/community/gsoc/project_ideas/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn index c1850d21..1771756e 100644 --- a/community/gsoc/project_ideas/driver_glue_code.mdwn +++ b/community/gsoc/project_ideas/driver_glue_code.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2016 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2016, 2017, 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 @@ -27,7 +27,7 @@ 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 the Rump kernel: +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. @@ -69,8 +69,3 @@ such as memory management for example. Possible mentors: Justus Winter (teythoon), Samuel Thibault (youpi) Exercise: Install and run the current rumpkernel library (librump0) and the corresponding mplayer, get it to run. - ---- - - -# 2016-02-14, Justus Winter 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 : + + * <https://www.sceen.net/mapping-physical-memory-directly/> + + * <http://git.sceen.net/rbraun/x15.git/> + + * <https://git.sceen.net/rbraun/librbraun.git/plain/rdxtree.h> diff --git a/community/gsoc/project_ideas/tcp_ip_stack.mdwn b/community/gsoc/project_ideas/tcp_ip_stack.mdwn index 6410dee0..f86dcf72 100644 --- a/community/gsoc/project_ideas/tcp_ip_stack.mdwn +++ b/community/gsoc/project_ideas/tcp_ip_stack.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2017 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 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. |