diff options
Diffstat (limited to 'user')
| -rw-r--r-- | user/jkoenig/java.mdwn | 91 | ||||
| -rw-r--r-- | user/jkoenig/java/discussion.mdwn | 108 |
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 |