diff options
Diffstat (limited to 'community')
-rw-r--r-- | community/gsoc/project_ideas/object_lookups.mdwn | 90 | ||||
-rw-r--r-- | community/gsoc/project_ideas/package_manager.mdwn | 12 | ||||
-rw-r--r-- | community/gsoc/project_ideas/unionfs_boot.mdwn | 10 |
3 files changed, 103 insertions, 9 deletions
diff --git a/community/gsoc/project_ideas/object_lookups.mdwn b/community/gsoc/project_ideas/object_lookups.mdwn index d3e17dc9..d67dbe20 100644 --- a/community/gsoc/project_ideas/object_lookups.mdwn +++ b/community/gsoc/project_ideas/object_lookups.mdwn @@ -539,3 +539,93 @@ In context of [[!message-id "20130918081345.GA13789@dalaran.sceen.net"]]. <teythoon> right, for dup and friends <braunr> and the radix tree is a data structure that can cope decently with not too sparsed distributions + + +## IRC, freenode, #hurd, 2014-02-27 + + <braunr> teythoon: ah, just saw the commit that will make our network + faster :) + <teythoon> network ? + <braunr> eh no, it's about ioctls actually + <braunr> :) + <braunr> i read a bit too quickly + <teythoon> one more small step towards fixing all receiver lookups in the + hurd... + <teythoon> i did not anticipate how much the hurd has to be changed first + in order to make use of the protected payloads + <braunr> that was my main reason not to do it actually :/ + <braunr> but you're almost finished with it, aren't you ? + <teythoon> not sure tbh + <teythoon> i believe the fsys stuff was the largest chunk + + +## IRC, freenode, #hurd, 2014-03-02 + + <teythoon> youpi: i cleaned up most of the receiver lookups in hurd by now + <teythoon> but there are some tricky cases left + <teythoon> 1/ the pager stuff + <teythoon> the mig declarations are in gnumach, and do not have the + necessary intran declarations that we can mutate + <teythoon> 2/ some uses of mach_port_t instead of some_type_t in the hurd + rpc definitions + <teythoon> (e.g. fsys_forward) + <teythoon> for 1/, i'd like to extend the definitions in gnumach + <teythoon> i'm not so sure what to do for the second case + <teythoon> we could introduce some types for each case + <teythoon> or, we do not touch the definitions + <teythoon> my protected payload prototype allows us to map payloads back to + port names for the functions that want a name + <teythoon> i did this by redefining the mach_port_t type for mig that uses + the payload to port-name intran function + <teythoon> mig allows type redefinitions, but emits a warning message + <teythoon> though i consider that a useful feature, it allows one to refine + a type + + +## IRC, freenode, #hurd, 2014-03-04 + + <teythoon> braunr: i fixed the object lookups in libpager yesterday, a + pretty mechanic change + <braunr> teythoon: can't be bad :) + <teythoon> amusingly, the resulting packages boot about half way through + o_O + <braunr> teythoon: ? + <teythoon> it hangs while cleaning left-over files from /tmp + <braunr> ugh, libpager .. + <teythoon> yes + <teythoon> tricky pager stuff is tricky ? + <braunr> tricky buggy pager stuff is tricky and buggy + <teythoon> ^^ + <braunr> let's assume you made things faster, increasing the likelihood of + deadlocks .. + <braunr> we had a patch once for a libpager deadlock + <teythoon> well, i'm not yet at the point where things might get faster + <braunr> see 901c61a1d25e7c8963e51012760a82730eda1910 + <braunr> the same problem exists elsewhere i think, you might have hit it + <teythoon> i'm still just moving the object lookups from the server + functions to the mig translation functions + <braunr> hm + <teythoon> but yes, i might have influenced the timing, not sure + <braunr> shouldn't cost too much to add some prints + <braunr> iirc, the other potential deadlock is in libpager/pager-attr.c + <braunr> when memory_object_change_attributes is called + <braunr> (which loops back into libpager when the kernel sends data back + <braunr> ) + <braunr> tricky .. + <teythoon> i'll try that when i get home + + <braunr> aren't you almost done ? + <teythoon> not sure tbh + <braunr> :( + <braunr> althouhg libpager would be really great + <teythoon> and mach-defpager + <braunr> since this is actually one of the biggest points of contention + <teythoon> i'll do that next, and return to libpager later + <braunr> ok + <teythoon> for both i needed to change some rpc type definitions in gnu + mach + <braunr> skipping lookups in libpager would make it harder to suffer + writeback thread storms + <teythoon> so i want to make sure that these changes are fine so that i can + propose them + <braunr> ok diff --git a/community/gsoc/project_ideas/package_manager.mdwn b/community/gsoc/project_ideas/package_manager.mdwn index d80efe37..dcbea144 100644 --- a/community/gsoc/project_ideas/package_manager.mdwn +++ b/community/gsoc/project_ideas/package_manager.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2008, 2009, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2013, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Hurdish Package Manager for the GNU System"]] @@ -37,7 +38,7 @@ came about. There are no global databases of any kind. (Some things might require caching for better performance, but this must happen transparently.) The core of this approach is formed by [[hurd/translator/stowfs]]. -[Guix](http://www.gnu.org/software/guix), GNU's package manager, +[[GNU Guix|hurd/running/nix#guix]], GNU's package manager, installs each package in its own directory. Each user has a *profile*, which is the union of some of these packages. On GNU/Linux, this union is implemented as a symlink tree; on GNU/Hurd, @@ -46,7 +47,8 @@ Unix directory structure from all the files in the individual package directories. This handles the lowest level of package management. -The goal of this task is to exploit Hurd features in GNU Guix. +The goal of this task is to exploit Hurd features in [[GNU +Guix|hurd/running/nix#guix]]. Possible mentors: Ludovic Courtès, Ben Asselstine (bing) diff --git a/community/gsoc/project_ideas/unionfs_boot.mdwn b/community/gsoc/project_ideas/unionfs_boot.mdwn index 13cc6cd1..0c51bdc1 100644 --- a/community/gsoc/project_ideas/unionfs_boot.mdwn +++ b/community/gsoc/project_ideas/unionfs_boot.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2008, 2009, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2013, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Allow Using unionfs Early at Boot"]] @@ -19,7 +20,8 @@ software packages, GNU/Linux distributions usually come with a package manager, which keeps track of all files upon installation/removal in some kind of central database. -An alternative approach is the one implemented by GNU Stow and GNU Guix: each package is +An alternative approach is the one implemented by [[GNU Stow and GNU +Guix|package_manager]]: each package is actually installed in a private directory tree. The actual standard directory structure is then created by collecting the individual files from all the packages, and presenting them in the common `/bin`, `/lib`, etc. locations. |