summaryrefslogtreecommitdiff
path: root/user/jkoenig
diff options
context:
space:
mode:
Diffstat (limited to 'user/jkoenig')
-rw-r--r--user/jkoenig/java.mdwn91
-rw-r--r--user/jkoenig/java/discussion.mdwn108
2 files changed, 90 insertions, 109 deletions
diff --git a/user/jkoenig/java.mdwn b/user/jkoenig/java.mdwn
index 90f51028..fcd316b7 100644
--- a/user/jkoenig/java.mdwn
+++ b/user/jkoenig/java.mdwn
@@ -38,7 +38,7 @@ I have submitted
[preliminary patches](http://lists.gnu.org/archive/html/bug-hurd/2011-05/msg00182.html)
for global signal dispositions,
which I'm currently testing.
-I have since fixed a few thinks and implemented `SA_SIGINFO`
+I have since fixed a few things and implemented `SA_SIGINFO`
(which is required by OpenJDK.)
My latest code is available on
[github](http://github.com/jeremie-koenig/glibc/commits/master-beware-rebase),
@@ -56,6 +56,7 @@ at which point we will alias the interim version
to the new one in debian packages.
I have modified libc0.3 to include a `deb-symbols(5)` file
+(alternatively see <http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps>)
so that we get an accurate libc dependency in `hurd` and other packages
when the symbols in question are pulled in.
@@ -71,6 +72,28 @@ I expect only the last patch (implement global dispositions) will change,
and new ones will be added on top of it.
+##### Open Items
+
+ * 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.
+
+ * Get patches reviewed (Roland?), and integrated into official sources: [!]
+ [[tschwinge]].
+
+ * Documentations bits (from [[proposal]] and elsewhere) should probably be
+ moved either into the appropriate glibc or Hurd documentation
+ files/reference manuals, or to [[glibc/signal]].
+
+ * libthreads (cthreads) integration.
+
+ * [[tschwinge]] suggests to leave them as-is?
+
+ * [[libpthread]] integration.
+
+
### Port OpenJDK
As suggested by [[tschwinge]], I have targeted OpenJDK 7 at first.
@@ -107,8 +130,74 @@ although the current toolchain issues
have so far prevented me from testing it.
+##### Open Items
+
+ * 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?
+
+ * Eclipse
+
+ OK for testing -- but I'd very much hope that it *just works* as soon as we
+ provide the required Java platform. But it may perhaps have some
+ Linux-specifics (needlessly?) in its basement. Is it available for Debian
+ GNU/kFreeBSD already?
+
+
### Java bindings for Mach
+
+#### Plans
+
(just started.)
+##### Open Items
+
+ * [[tschwinge]] has to read about RMI and CORBA.
+
+ * MIG
+
+ * Hacking [[microkernel/mach/MIG]] shouldn't be too difficult.
+
+ * (Unless you want to make MIG's own code (that is, not the generated
+ code, but MIG itself) look a bit more nice, too.) ;-)
+
+ * There are also alternatives to MIG. If there is interest, the following
+ could be considered:
+
+ * FLICK ([[!GNU_Savannah_task 5723]]). [[tschwinge]] has no idea yet if
+ there would be any benefits over MIG, like better modularity (for the
+ backends)? If we feel like it, we could spend a little bit of time on
+ this.
+
+ * For [[microkernel/Viengoos]], Neal has written a RPC stub generator
+ entirely in C Preprocessor macros. While this is obviously not
+ directly applicable, perhaps we can get some ideas from it.
+
+ * Anything else that would be worth having a look at? (What are other
+ microkernels using?)
+
+ * `mach_msg`
+
+ * Seems like the right approach to [[tschwinge]], but he hasn't digested
+ all the pecularities yet. Will definitely need more time.
+
+
+## Postponed
+
+Might get back to these as time/interest permits.
+
+
+### GCJ
+
+ * [[tschwinge]] has the feeling that Java in GCC (that is, GCJ) is mostly
+ dead? (True?)
+
+ * Thus perhaps not too much effort should be spent with it.
+
+ If the POSIX threads signal semantics makes it going, then great, otherwise
+ we should get a feeling what else is missing.
+
+
+### Joe-E.
diff --git a/user/jkoenig/java/discussion.mdwn b/user/jkoenig/java/discussion.mdwn
index 0131d8d5..266a7bcc 100644
--- a/user/jkoenig/java/discussion.mdwn
+++ b/user/jkoenig/java/discussion.mdwn
@@ -56,114 +56,6 @@ one person's summer.) Such bits could be moved to [[open_issues]] pages,
either new ones or existing ones, as applicable.
-# POSIX Threads Signal Semantics
-
- * Great! [[tschwinge]] had a brief look, and should have a deeper one.
-
- * If [[jkoenig]] thinks it's mature enough: should ask Samuel to test this
- (that is, only the refactoring patches for starters?) on the buildds.
-
- * Then: should ask Roland to review.
-
- * Documentations bits should probably be moved to [[glibc/signal]].
-
-
-## libthreads (cthreads) Integration
-
- * [[tschwinge]] suggests to leave them as-is?
-
-
-## [[libpthread]] integration
-
- * To be done.
-
-
-# Java
-
- * [[tschwinge]] has to read about RMI and CORBA.
-
-
-# Joe-E
-
- * For later.
-
-
-# GCJ
-
- * [[tschwinge]] has the feeling that Java in GCC (that is, GCJ) is mostly
- dead? (True?)
-
- * Thus perhaps not too much effort should be spent with it.
-
- If the POSIX threads signal semantics makes it going, then great, otherwise
- we should get a feeling what else is missing.
-
-
-# OpenJDK
-
- * All in all, [[tschwinge]] has the feeling that a working OpenJDK will be
- more useful/powerful than GCJ.
-
- * We need to get a feeling how difficult such an OS port will be.
-
- * [[jkoenig]] suggests OpenJDK 6 -- should we directly go for version 7
- instead?
-
- * What are the differences (regarding the OS port) between the two
- versions? Or this there something even more recent to be worked upon,
- for new OS ports?
-
- * Perhaps the different versions' OS port specific stuff is not at
- all very different, so that both v6 and v7 could be done?
-
- * 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?
-
-
-# Eclipse
-
-OK for testing -- but I'd very much hope that it *just works* as soon as we
-provide the required Java platform.
-
-
-# Java Bindings
-
-
-## Design Principles
-
- * Generally ack.
-
-
-### MIG
-
- * Hacking [[microkernel/mach/MIG]] shouldn't be too difficult.
-
- * (Unless you want to make MIG's own code (that is, not the generated
- code, but MIG itself) look a bit more nice, too.) ;-)
-
- * There are also alternatives to MIG. If there is interest, the following
- could be considered:
-
- * FLICK ([[!GNU_Savannah_task 5723]]). [[tschwinge]] has no idea yet if
- there would be any benefits over MIG, like better modularity (for the
- backends)? If we feel like it, we could spend a little bit of time on
- this.
-
- * For [[microkernel/Viengoos]], Neal has written a RPC stub generator
- entirely in C Preprocessor macros. While this is obviously not
- directly applicable, perhaps we can get some ideas from it.
-
- * Anything else that would be worth having a look at? (What are other
- microkernels using?)
-
-
-### `mach_msg`
-
- * Seems like the right approach to [[tschwinge]], but hasn't digested all the
- pecularities yet. Will definitely need more time.
-
-
# GSoC Site Discussion
* Discussion items from