user/jkoenig/java: IRC meeting updates.

1 files changed, 25 insertions, 5 deletions

diff --git a/user/jkoenig/java.mdwn b/user/jkoenig/java.mdwn
index fcd316b7..af2b908e 100644
--- a/user/jkoenig/java.mdwn
+++ b/user/jkoenig/java.mdwn
@@ -60,6 +60,12 @@ I have modified libc0.3 to include a `deb-symbols(5)` file
 so that we get an accurate libc dependency in `hurd` and other packages
 when the symbols in question are pulled in.
 
+[[hurd/libthreads]] (cthreads library) will not be changed.  There's no reason
+why its behavior should change, whereas for [[libpthread]] it's needed for
+conformance.  Patches posted on 2011-05-25, but there's a more recent one in
+the modified hurd package (adds `_hurd_sigstate_delete` and removes the weak
+symbols).
+
 Another issue which came up with OpenJDK is the expansion
 by the dynamic linker of `$ORIGIN` in the `RPATH` header,
 see below.
@@ -77,8 +83,8 @@ and new ones will be added on top of it.
   * Test patches: in progress, [[jkoenig]], Svante.  More volunteers welcome,
     of course.
 
-  * If [[jkoenig]] thinks it's mature enough: should ask Samuel to test this
-    (that is, only the refactoring patches for starters?) on the buildds.
+  * If [[jkoenig]] thinks it's mature enough: should ask
+    [[Samuel|samuelthibault]] to test these patches on the buildds.
 
   * Get patches reviewed (Roland?), and integrated into official sources: [!]
     [[tschwinge]].
@@ -87,11 +93,12 @@ and new ones will be added on top of it.
     moved either into the appropriate glibc or Hurd documentation
     files/reference manuals, or to [[glibc/signal]].
 
-  * libthreads (cthreads) integration.
+  * `SA_SIGINFO` patche is based on [[Samuel|samuelthibault]]'s earlier work.
+    Thus, have him review the new patch?
 
-      * [[tschwinge]] suggests to leave them as-is?
+  * Perhaps have a look at `SA_NOCLDWAIT`.
 
-  * [[libpthread]] integration.
+  * Which numeric values to use for `SA_SIGINFO` (and `SA_NOCLDWAIT`)?
 
 
 ### Port OpenJDK
@@ -105,6 +112,11 @@ should not be too hard.
 If that fails we can fall back on Shark
 (a portable alternative JIT which uses LLVM).
 
+Complexity of porting HotSpot: probably low.  The complex things should be
+arch- rather than OS-specific.  Not many Linux-specific interfaces used.
+Garbage collection/memory management, etc. and/or most of other Linux-specific
+interfaces are already dealt with for the zero build.
+
 The dynamic linker issue is as follows.
 An executable-specific search path can be provided in the ELF RPATH header.
 RPATH directories can include the special string `$ORIGIN`,
@@ -127,11 +139,19 @@ by building on [[pochu]]'s `file_exec_file_name()` patches.
 
 I have succeeded in building a Hotspot-enabled `libjvm.so`,
 although the current toolchain issues
+(*Hurd OS ABI*)
 have so far prevented me from testing it.
 
 
 ##### Open Items
 
+  * [!] [[tschwinge]] to have a look at [[pochu]]'s `file_exec_file_name()`
+    patches (2010-05), whether it's generally the right idea.
+
+      * Assuming it is, continue with getting `$ORIGIN` working.
+
+  * [!] [[Samuel|samuelthibault]]/[[tschwinge]]/[[jkoenig]]: *Hurd OS ABI*.
+
   * They seem to have a rather heavy-weight process for such projects: confer
     <http://mail.openjdk.java.net/pipermail/announce/2011-January/000092.html>,
     for example.  Do we need this, too?