1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
[[!meta copyright="Copyright © 2011 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]]."]]"""]]
Some [[tschwinge]] comments regarding your proposal. Which is very good, if I
may say so again! :-)
Of course, everyone is invited to contribute here!
I want to give the following methodology a try, instead of only having
email/IRC discussions -- for the latter are again and again showing a tendency
to be dumped and deposited into their respective archives, and be forgotten
there. Of course, email/IRC discussions have their usefulness too, so we're
not going to replace them totally. For example, for conducting discussions
with a bunch of people (who may not even be following these pages here), email
(or, as applicable, the even more interactive IRC) will still be the medium of
choice. (And then, the executive summary should be posted here, or
incorporated into your proposal.)
Also, if you disagree with this suggested procedure right away, or at some
later point begin to feel that this thing doesn't work out, or simply takes too
much time (I don't think so: writing emails takes time, too), just say so, and
we can reconsider.
Of course, as this wiki is a passive medium rather than an active one as IRC
and email are, it is fine to send notices like: *I have updated the wiki page,
please have a look*.
One idea is that your proposal evolves alongside with the ongoing work, and
represents (in more or less detail) what has been done and what will be done.
Also, we can hopefully use parts of it for documentation purposes, or as
recipes for similar work (enabling other programming languages on the Hurd, for
example).
For this, I suggest the following procedure: as applicable, you can either
address any comments in here (for example, if they're wrong :-), or if they
require further discussion; think: *email discussion*), or you can address them
directly in your propoal and remove the comments from here at the same time
(think: *bug fix*).
Generally, you can assume that for things I didn't comment on (within some
reasonable timeframe/upon asking me again) that I'm fine with them. Otherwise,
I might say: *I don't like this as is, but I'll need more time to think about
it.*
There is also a possibility that parts of your proposal will be split off; in
cases where we think they're valuable to follow, but not at this time. (As you
know, your proposal is not really a trivial one, so it may just be too much for
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
<http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/jkoenig/1>
should be copied here:
* technical bits (obviously);
* also the *why do we want Java bindings* reasoning;
* CLISP findings should also be documented somewhere permanently.
* We should probaby open up a *languages for Hurd* section on the web
pages ([[!taglink open_issue_documentation]]).
|
