summaryrefslogtreecommitdiff
path: root/user/jkoenig/java.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'user/jkoenig/java.mdwn')
-rw-r--r--user/jkoenig/java.mdwn55
1 files changed, 41 insertions, 14 deletions
diff --git a/user/jkoenig/java.mdwn b/user/jkoenig/java.mdwn
index b289c0ed..868dec2b 100644
--- a/user/jkoenig/java.mdwn
+++ b/user/jkoenig/java.mdwn
@@ -23,6 +23,14 @@ For details, see my original [[proposal]].
## Current status
+Feeling slightly behind schedule; but project is very ambitious, which has been
+known from the beginning, and there is great progress, so there is no problem.
+--[[tschwinge]], 2011-06-29.
+
+[[tschwinge]] will be on vacations in China starting July 26th, will have
+Internet access intermittently, but not regularely. We'll have to figure out
+some scheme.
+
### Apt repository
@@ -82,17 +90,11 @@ for broader testing.
* Test patches: in progress, [[jkoenig]], Svante. More volunteers welcome,
of course.
- > Current status: there's an issue with gdb,
+ > There's an issue with gdb,
> namely signals lose their "untracedness" when they go
> through the global sigstate's pending mask,
> so gdb spins intercepting a signal and trying to deliver it.
- > My current
- > [patch](http://github.com/jeremie-koenig/glibc/commit/3ecb990e9d08d5f75adc40b738b35a1802cc0943)
- > makes the system unstable.
- > --[[jkoenig]] 2011-06-22
-
- >> Correction: the patch is fine, problem solved.
- >> --[[jkoenig]] 2011-06-29
+ > [Patch](http://github.com/jeremie-koenig/glibc/commit/3ecb990e9d08d5f75adc40b738b35a1802cc0943).
* If [[jkoenig]] thinks it's mature enough: should ask
[[Samuel|samuelthibault]] to test these patches on the buildds.
@@ -102,24 +104,43 @@ for broader testing.
> (in particular hurd)
> --[[jkoenig]] 2011-06-22
+ * Waiting on ABI finalization ([!] Roland).
+
+ * Which numeric values to use for `SA_SIGINFO` (and `SA_NOCLDWAIT`)?
+
+ > Staying in sync with BSD seems the most logical approach,
+ > so I have defined it to 0x40. --[[jkoenig]] 2011-06-29
+
* Get patches reviewed (Roland?), and integrated into official sources: [!]
[[tschwinge]].
> In progress. --[[jkoenig]] 2011-06-29
- * Documentations bits (from [[proposal]] and elsewhere) should probably be
+ * Documentations bits (from here, the initial [[proposal]], and elsewhere)
+ should probably be
moved either into the appropriate glibc or Hurd documentation
files/reference manuals, or to [[glibc/signal]].
- * `SA_SIGINFO` patche is based on [[Samuel|samuelthibault]]'s earlier work.
+ * `SA_SIGINFO` patch is based on [[Samuel|samuelthibault]]'s earlier work.
Thus, have him review the new patch?
- * Perhaps have a look at `SA_NOCLDWAIT`.
+ * `SA_SIGINFO` patch has a few TODOs w.r.t. protocol changes for missing
+ information, and for FPU state. Providing even incomplete information is
+ an improvement on the current status. The question is, whether
+ applications rely on this information in any hard way if `SA_SIGINFO` is
+ available?
+
+ * We could possibly rename certain fields in `struct siginfo`, say
+ `si_pid_not_implemented`, to ensure compilation failures for programs
+ which use them. Or perhaps a linker warning is possible.
- * Which numeric values to use for `SA_SIGINFO` (and `SA_NOCLDWAIT`)?
+ * The FPU state is not included in the `ucontext_t` passed to the signal
+ handler. On the other hand, `ucontext_t` is actually being somewhat
+ deprecated: the functions to restore it are no longer in POSIX.
+ `thread_get_state`() should return this information, in case we decide
+ to fill the gap, and there might be existing glibc wrappers, too.
- > Staying in sync with BSD seems the most logical approach,
- > so I have defined it to 0x40. --[[jkoenig]] 2011-06-29
+ * Perhaps have a look at `SA_NOCLDWAIT`.
### Port OpenJDK
@@ -184,6 +205,12 @@ have so far prevented me from testing it.
* [!] [[Samuel|samuelthibault]]/[[tschwinge]]/[[jkoenig]]:
[[toolchain/ELFOSABI_HURD]].
+ * 2011-06-29: No progress.
+
+ * `libthread_db.so` issue. Likely, the Serviceability Agent is used by jdb
+ and the like only, so for now the goal should be to lose some functionality
+ by removing/avoiding this dependency.
+
* 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?