* I restructured open issue wine to show that wine mostly works.

* I added a current status to the physical memory management wiki page.

2 files changed, 133 insertions, 106 deletions

diff --git a/community/gsoc/project_ideas/physical_memory_management.mdwn b/community/gsoc/project_ideas/physical_memory_management.mdwn
index af360507..850841cd 100644
--- a/community/gsoc/project_ideas/physical_memory_management.mdwn
+++ b/community/gsoc/project_ideas/physical_memory_management.mdwn
@@ -56,3 +56,24 @@ Useful links :
  * <http://git.sceen.net/rbraun/x15.git/>
 
  * <https://git.sceen.net/rbraun/librbraun.git/plain/rdxtree.h>
+
+
+# Current Status 2018-10-25
+
+Recent GNU Mach releases have replaced the physical allocator for a more standard buddy allocator, and the kernel can service much more memory for its objects, making kernel memory exhaustion very unlikely.  Justus Winter contributed to this project by using radix-tree based IPC spaces and various bug fixes (page queue management) to the kernel.  Richard Braun helped see the project through to completion.
+
+For those that are curious about the details, the buddy allocator provides efficient allocation of continuous chunks of memory at the cost of high internal fragmentation.  To avoid the fragmentation overhead, we do not use it directly, but through the slab allocator that is already used for most of the allocations inside the kernel.
+
+The "biosmem" provides three different segments, DMA, DIRECTMAP, and HIGHMEM.  The DMA segment provides memory at low addresses for drivers that need buffers that devices can read from and write into using DMA.
+
+The DIRECTMAP segment is directly mapped into the kernels address space.  We can use this segment for kernel objects and can directly access it in inter-task memory copies.  You can see its size capped at 880M because the kernel is using a 1G kernel / 3G userspace split (the stock Debian kernel uses a 2/2 split to maximize the amount of mappable physical memory).
+
+We cannot use the HIGHMEM segment for kernel objects, but we can give it out to userspace tasks.
+
+You can then see the drivers probing for devices, modules being loaded and the Hurd server bootstrap running.  The system then deadlocks, with a custom message being emitted right before that.
+
+Useful links:
+
+  * <http://lists.gnu.org/archive/html/bug-hurd/2016-02/msg00118.html>
+  
+  * <http://lists.gnu.org/archive/html/bug-hurd/2015-09/msg00081.html>
diff --git a/open_issues/wine.mdwn b/open_issues/wine.mdwn
index 6d48fda0..4d99c32a 100644
--- a/open_issues/wine.mdwn
+++ b/open_issues/wine.mdwn
@@ -11,74 +11,74 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_porting]]
 
-On 2010-11-28, Austin English contacted us, stating that he's working on
-porting [Wine](http://winehq.org/) to the GNU/Hurd.
+## IRC, freenode, #hurd, 2015-02-09
 
-It is not yet clear how difficult this is going to be, what sort of
-requirements Wine has: only libc / POSIX / etc., or if there are
-*advanced* things like [[system_call]] trapping involved, too.
+    <Andre_H> since Wine 1.7.28 it runs quite well on Gnu/Hurd - wiki.winehq.org/Hurd
+    <Andre_H> ( https://source.winehq.org/git/wine.git/commitdiff/6d50cfcac28f84e07777fc10874887356832102e )
 
-[[Samuel|samuelthibault]] suspects that *there's some need for LDT table
-allocation. There is kernel support for this,* however.
 
+## IRC, freenode, #hurd, 2014-01-11
 
-# IRC, freenode, #hurd, 2011-08-11
+    <gnu_srs1> Andre_H: Looks like the two committed patches did not go into
+      wine-1.6.2:-(
+    <gnu_srs1> Additionally, your PATH_MAX fixes was not accepted?
+    <Andre_H> gnu_srs1: well, the stable branch is called stable because not
+      everything get's there :)7
+    <Andre_H> gnu_srs1: the PATH_MAX patch needs more thinking...
 
-    < arethusa> I've been trying to make Wine work inside a Debian GNU/Hurd VM,
-      and to that end, I've successfully compiled the latest sources from Git
-      after installing the libc (devel) packages from experimental and
-      personally patching Wine with http://pastebin.com/rg6dx09G
+## IRC, freenode, #hurd, 2014-01-06
 
-[[rg6dx09G.patch]]
+    <Andre_H> Wanted to note that
+      http://www.gnu.org/software/hurd/open_issues/wine.html is wrong about
+      socket credentials, afaik they are still not implemented but that doesn't
+      block Wine anymore
+    <Andre_H> In fact all you need to run Wine are the patches followed by
+      https://source.winehq.org/patches/data/101439 (not yet upstream) or see
+      http://wiki.winehq.org/Hurd
 
-    < arethusa> my question is, when trying to launch Wine, I'm seeing "wine
-      client error:0: sendmsg: (os/kern) invalid address" from the client side,
-      whereas the wineserver seems to be starting and running correctly, how
-      could I debug this issue further? using rpctrace doesn't seem to help, as
-      the trace just hangs when run on the Wine loader instead of yielding
-      insight
-    < kilobug> arethusa: isn't there a wine debuguer that can start a gdb when
-      wine encounters an error or something like that ?
-    < arethusa> it's too early for that
-    < kilobug> or least give you a full traceback of the wine code where the
-      error occur ?
-    < arethusa> the error is happening during initial connect to the
-      wineserver, in dlls/ntdll/server.c
-    < arethusa> but that doesn't help me figure out why sendmsg would error out
-      in this way
-    < arethusa>
-      http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/server.c#l361
-    < azeem_> arethusa: probably some of the msghdr entries are not supported
-      by the Hurd's glib
-    < azeem_> c
-    < pinotree> haha, socket credentials, which we don't support yet
-    < azeem_> yep
-    < pinotree> youpi: ↑ another case ;)
-    < azeem_> arethusa: just implement those and it should work
-    < kilobug> in pflocal ? or glibc ?
-    < pinotree> pflocal
-    < arethusa> azeem_: hmm, okay, thanks
-    < pinotree> arethusa: their lack is a known issue, and makes things like
-      dbus and gamin not work
-    < arethusa> it's
-      https://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html and
-      related links I assume?
+    <braunr> Andre_H: thanks for your report
+    <Andre_H> np :)
+    <Andre_H> braunr: can someone update
+      http://www.gnu.org/software/hurd/open_issues/wine.html please?
+    <braunr> Andre_H: well, you can :)
+    <Andre_H> log in with google -> check guidelines of your wiki -> try out
+      your wiki syntax -> laziness alarm :)
+    <gnu_srs> Andre_H: The reason why wine runs now is a bug in SCM_CREDS was
+      fixed, see the wine-devel ML.
 
-[[sendmsg_scm_creds]]
+    <gnu_srs> Andre_H: s/SCM_CREDS/SCM_RIGHTS/
+    <Andre_H> gnu_srs: already updated our wiki :)
+    <Andre_H> gnu_srs: would you mind updating yours:
+      http://www.gnu.org/software/hurd/open_issues/wine.html :)
 
-    < youpi> yes
-    < pinotree> (but that patch is lame)
+    <Andre_H> gnu_srs: two commits for wine are in now :)
 
 
-# IRC, freenode, #hurd, 2013-10-02
+## IRC, freenode, #hurd, 2013-12-31
 
-    <gnu_srs> youpi: I've come a little further with wine, see debian bug
-      #724681 (same problem).
-    <gnu_srs> Now the problem  is probably due to the specific address space
-      and stack issues to be
-    <gnu_srs> fixed for wine to run as braunr pointed out some months ago
-      (IRC?) when we discussed wine.
+    <Andre_H> gnu_srs: i didn't need the patches for
+      dlls/mountmgr.sys/diskarb.c, maybe due to missing headers
+
+
+## IRC, freenode, #hurd, 2013-12-30
+
+    <gnu_srs> wine runs:)
+    <gnu_srs> It's just extremely slow.,..
 
+    <gnu_srs> gg0: please don't reopen #733604 , I've filed an updated one:
+      #7336045
+    <gnu_srs>  #733605
+    <gg0> gnu_srs: i've reassigned it from wine-1.6 (nonexistent) to wine
+      (correct), then to src:wine (more correct), but between such
+      reassignments you closed it so found command in the latter made it
+      reopening
+    <gg0> then i realized you could mess up bugs on your own, without help :)
+    <gnu_srs> gg0: tks anyway, now it is src:wine and the title is right. Maybe
+      you should have noted me on IRC?
+
+    <Andre_H> gnu_srs: what's your status about wine? i'm still about to get
+      things upstream...
+    <gnu_srs> Andre_H: see debian bug #733605
 
 # IRC, freenode, #hurd, 2013-12-29
 
@@ -111,72 +111,78 @@ allocation. There is kernel support for this,* however.
       quite hard...
 
 
-## IRC, freenode, #hurd, 2013-12-30
+# IRC, freenode, #hurd, 2013-10-02
 
-    <gnu_srs> wine runs:)
-    <gnu_srs> It's just extremely slow.,..
+    <gnu_srs> youpi: I've come a little further with wine, see debian bug
+      #724681 (same problem).
+    <gnu_srs> Now the problem  is probably due to the specific address space
+      and stack issues to be
+    <gnu_srs> fixed for wine to run as braunr pointed out some months ago
+      (IRC?) when we discussed wine.
 
-    <gnu_srs> gg0: please don't reopen #733604 , I've filed an updated one:
-      #7336045
-    <gnu_srs>  #733605
-    <gg0> gnu_srs: i've reassigned it from wine-1.6 (nonexistent) to wine
-      (correct), then to src:wine (more correct), but between such
-      reassignments you closed it so found command in the latter made it
-      reopening
-    <gg0> then i realized you could mess up bugs on your own, without help :)
-    <gnu_srs> gg0: tks anyway, now it is src:wine and the title is right. Maybe
-      you should have noted me on IRC?
 
-    <Andre_H> gnu_srs: what's your status about wine? i'm still about to get
-      things upstream...
-    <gnu_srs> Andre_H: see debian bug #733605
+# IRC, freenode, #hurd, 2011-08-11
 
+    < arethusa> I've been trying to make Wine work inside a Debian GNU/Hurd VM,
+      and to that end, I've successfully compiled the latest sources from Git
+      after installing the libc (devel) packages from experimental and
+      personally patching Wine with http://pastebin.com/rg6dx09G
 
-## IRC, freenode, #hurd, 2013-12-31
+[[rg6dx09G.patch]]
 
-    <Andre_H> gnu_srs: i didn't need the patches for
-      dlls/mountmgr.sys/diskarb.c, maybe due to missing headers
+    < arethusa> my question is, when trying to launch Wine, I'm seeing "wine
+      client error:0: sendmsg: (os/kern) invalid address" from the client side,
+      whereas the wineserver seems to be starting and running correctly, how
+      could I debug this issue further? using rpctrace doesn't seem to help, as
+      the trace just hangs when run on the Wine loader instead of yielding
+      insight
+    < kilobug> arethusa: isn't there a wine debuguer that can start a gdb when
+      wine encounters an error or something like that ?
+    < arethusa> it's too early for that
+    < kilobug> or least give you a full traceback of the wine code where the
+      error occur ?
+    < arethusa> the error is happening during initial connect to the
+      wineserver, in dlls/ntdll/server.c
+    < arethusa> but that doesn't help me figure out why sendmsg would error out
+      in this way
+    < arethusa>
+      http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/server.c#l361
+    < azeem_> arethusa: probably some of the msghdr entries are not supported
+      by the Hurd's glib
+    < azeem_> c
+    < pinotree> haha, socket credentials, which we don't support yet
+    < azeem_> yep
+    < pinotree> youpi: ↑ another case ;)
+    < azeem_> arethusa: just implement those and it should work
+    < kilobug> in pflocal ? or glibc ?
+    < pinotree> pflocal
+    < arethusa> azeem_: hmm, okay, thanks
+    < pinotree> arethusa: their lack is a known issue, and makes things like
+      dbus and gamin not work
+    < arethusa> it's
+      https://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html and
+      related links I assume?
 
+[[sendmsg_scm_creds]]
 
-## IRC, freenode, #hurd, 2014-01-06
+    < youpi> yes
+    < pinotree> (but that patch is lame)
 
-    <Andre_H> Wanted to note that
-      http://www.gnu.org/software/hurd/open_issues/wine.html is wrong about
-      socket credentials, afaik they are still not implemented but that doesn't
-      block Wine anymore
-    <Andre_H> In fact all you need to run Wine are the patches followed by
-      https://source.winehq.org/patches/data/101439 (not yet upstream) or see
-      http://wiki.winehq.org/Hurd
 
-    <braunr> Andre_H: thanks for your report
-    <Andre_H> np :)
-    <Andre_H> braunr: can someone update
-      http://www.gnu.org/software/hurd/open_issues/wine.html please?
-    <braunr> Andre_H: well, you can :)
-    <Andre_H> log in with google -> check guidelines of your wiki -> try out
-      your wiki syntax -> laziness alarm :)
-    <gnu_srs> Andre_H: The reason why wine runs now is a bug in SCM_CREDS was
-      fixed, see the wine-devel ML.
 
-    <gnu_srs> Andre_H: s/SCM_CREDS/SCM_RIGHTS/
-    <Andre_H> gnu_srs: already updated our wiki :)
-    <Andre_H> gnu_srs: would you mind updating yours:
-      http://www.gnu.org/software/hurd/open_issues/wine.html :)
 
-    <Andre_H> gnu_srs: two commits for wine are in now :)
 
+On 2010-11-28, Austin English contacted us, stating that he's working on
+porting [Wine](http://winehq.org/) to the GNU/Hurd.
+
+It is not yet clear how difficult this is going to be, what sort of
+requirements Wine has: only libc / POSIX / etc., or if there are
+*advanced* things like [[system_call]] trapping involved, too.
+
+[[Samuel|samuelthibault]] suspects that *there's some need for LDT table
+allocation. There is kernel support for this,* however.
 
-## IRC, freenode, #hurd, 2014-01-11
 
-    <gnu_srs1> Andre_H: Looks like the two committed patches did not go into
-      wine-1.6.2:-(
-    <gnu_srs1> Additionally, your PATH_MAX fixes was not accepted?
-    <Andre_H> gnu_srs1: well, the stable branch is called stable because not
-      everything get's there :)7
-    <Andre_H> gnu_srs1: the PATH_MAX patch needs more thinking...
 
-## IRC, freenode, #hurd, 2015-02-09
 
-    <Andre_H> since Wine 1.7.28 it runs quite well on Gnu/Hurd - wiki.winehq.org/Hurd
-    <Andre_H> ( https://source.winehq.org/git/wine.git/commitdiff/6d50cfcac28f84e07777fc10874887356832102e )