Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn"

This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1.

1 files changed, 118 insertions, 0 deletions

diff --git a/open_issues/mach_migrating_threads.mdwn b/open_issues/mach_migrating_threads.mdwn
new file mode 100644
index 00000000..16547838
--- /dev/null
+++ b/open_issues/mach_migrating_threads.mdwn
@@ -0,0 +1,118 @@
+[[!meta copyright="Copyright © 2011, 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]]."]]"""]]
+
+[[!tag open_issue_gnumach]]
+
+<http://www.brynosaurus.com/pub/os/thread-migrate.pdf>
+
+  * [[microkernel/mach/memory_object/discussion]]
+
+  * [[resource_management_problems]]
+
+
+# IRC, freenode, #hurd, 2013-08-13
+
+In context of [[resource_management_problems]].
+
+    <braunr> and thread migration itself is something very confusing
+    <braunr> it's better to think of it as scheduling context inheritance
+    <teythoon> braunr: I read the paper I mentioned and then I wanted to find
+      the sources they modified
+    <teythoon> I failed
+    <teythoon> I hate scientific paper about software that fail to provide the
+      source code
+    <teythoon> that's not science imho b/c it's not reproducible
+    <braunr> i have some osf source code here
+    <braunr> i'll send it if you want
+    <teythoon> ah interesting
+    <braunr> but really, when you dive into it, thread migration is merely
+      scheduling context inheritance with kernel upcalls
+    <braunr> it's good
+    <teythoon> I searched for osf mach but google didn't turned up anything
+    <braunr> but it has nothing to do with resource accounting
+    <braunr> (well, it may hepl better account for cpu time actually)
+    <braunr> help*
+    <braunr> but that's all
+    <teythoon> why is that all? wouldn't that be transitive and could also be
+      used for i/o accounting?
+    <teythoon> also I tried to find alternative mach implementations
+    <teythoon> I wasn't terribly successful, and some sites are gone or
+      unmaintained for years :/
+    <braunr> we don't need that for io accountin
+    <braunr> g
+    <braunr> thread migration is a kernel property
+    <braunr> on mach with userspace drivers, io isn't
+    <braunr> mach should only control cpu and memory
+    <braunr> and you though you can account physical memory, you can't transfer
+      virtual memory accounting from one task to another
+    <teythoon> yes, but once all of those resources can be accounted to the
+      thread initiating whatever it needs doing, shouldn't that be much easier?
+    <braunr> teythoon: it's not required for that
+    <braunr> teythoon: keep in mind userspace sees activations
+    <braunr> in a thread migration enabled kernel, activations are what we
+      usually call threads, and threads are scheduling contexts
+    <teythoon> braunr: ok, so TM is not required for accounting, but surely
+      it's a good thing to have, no?
+    <braunr> teythoon: it's required for cpu accounting only
+    <braunr> which is very important :)
+    <braunr> if you look carefully, you'll see hurd servers are what use most
+      cpu
+    <braunr> there is now easy way to know which application actually uses the
+      server
+    <braunr> i personally tend to think more and more that servers *should*
+      impersonate clients
+    <braunr> TM (or rather, scheduling context inheritance) is one step
+    <braunr> it's not enough exactly because it doesn't help with resource
+      accounting
+    <braunr> teythoon:
+      ftp://ftp.mklinux.org/pub/mklinux-pre-R1/SRPMS/sources/osfmk.tar.gz
+
+
+# IRC, freenode, #hurd, 2013-09-02
+
+[[!taglink open_issue_documentation]]: move information to
+[[microkernel/mach/history]].
+
+    <teythoon> braunr: btw, I just noticed lot's of #ifdef MIGRATING_THREADS in
+      gnumach, so there was some work being done in that direction?
+    <braunr> gnumach is a fork of mach4
+    <braunr> at a stage whre migration was being worked on, yes
+    <teythoon> from what I've gathered, gnumach is the only surviving mach4
+      fork, right?
+    <braunr> yes
+    <braunr> well
+    <braunr> the macos x version is probably one too
+    <braunr> i don't know
+    <teythoon> oh? I read that it was based on mach3
+    <braunr> it is
+    <braunr> i can't tell how much of mach3 versus mach4 it has, and if it's
+      relevant at all
+    <teythoon> and the osfmach, was that also based on mach4?
+    <braunr> yes
+    <teythoon> ok, fair enough
+    <braunr> that's why i think macos x is based on it too
+    <braunr> i initially downloaded osfmach sources to see an example of how
+      thread migration was used from userspace
+    <braunr> and they do have a special threading library for that
+
+
+# IRC, freenode, #hurd, 2014-02-18
+
+    <teythoon> has anyone here ever tried to enable the thread migration bits
+      in gnumach to see where things break and how far that effort has been
+      taken ?
+    <braunr> without proper userspace support, i don't see how this could work
+    <teythoon> but is the kernel part finished or close to being finished ?
+    <braunr> no idea
+    <braunr> i don't think it is
+    <braunr> i didn't see much code related to that feature, and practically
+      none that looked like what the paper described
+    <braunr> some structures, but not used