summaryrefslogtreecommitdiff
path: root/user/jkoenig/gsoc2011_proposal.mdwn
diff options
context:
space:
mode:
authorJeremie Koenig <jk@jk.fr.eu.org>2011-04-08 15:51:55 +0200
committerJeremie Koenig <jk@jk.fr.eu.org>2011-04-08 18:03:03 +0200
commit5876a9f012898f8b1e5e60f53fb8b026c8d351e9 (patch)
treedc7cb3405e26860c511c3b0cab3d9f0674e8b726 /user/jkoenig/gsoc2011_proposal.mdwn
parentde7e9c9902efe242e431b001702073e05207fe81 (diff)
gsoc2011 (java): split the appendix into another page
Diffstat (limited to 'user/jkoenig/gsoc2011_proposal.mdwn')
-rw-r--r--user/jkoenig/gsoc2011_proposal.mdwn94
1 files changed, 8 insertions, 86 deletions
diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn
index 620ac95b..d53c094f 100644
--- a/user/jkoenig/gsoc2011_proposal.mdwn
+++ b/user/jkoenig/gsoc2011_proposal.mdwn
@@ -62,6 +62,14 @@ My knowledge of the Hurd and Debian GNU/Hurd is reasonable,
as the Debian-Installer and procfs projects
gave me the opportunity to fiddle with many parts of the system.
+Initially,
+I started working on this project because I wanted to use Joe-E
+(a subset of Java)
+to investigate the potential
+[[applications of object-capability languages|objcap]]
+in a Hurd context.
+I also believe that imrpoving Java support on Hurd
+would be an important milestone.
## Improve Java support
@@ -495,89 +503,3 @@ The dates listed are deadlines for the associated tasks.
## Conclusion
-
-
-
-## Appendix: potential applications of object-capability languages
-
-The work discussed is this last part would have
-fewer immediate benefits for the Hurd project
-and has more of a research orientation.
-It is also unlikely that there would be any time remaining
-to work on it at the end of the summer.
-(Though it could work as some kind of reward
-if I somehow managed to do a prefect job of all the rest
-within the allocated time :-) ).
-As a consequence,
-I don't really consider this a part of my application.
-
-This being said,
-to some extent the project discussed here
-will informed the way I design the Java bindings,
-since it depends on them
-and I intend to work on this at some point in the future.
-I also believe it touches on some interesting ideas,
-and a Summer of Code application is probably
-as good an occasion as any to discuss them.
-
-### Justification
-
-The primary advantage of multi-server operating systems is the ability to
-break what used to be the kernel into small pieces which can be isolated
-from each others. This makes sense from an engineering perspective, as
-smaller components can be swapped with different implementations and reduce
-the impact of bugs.
-A capability-based approach also ensures that the
-authority wielded by components is clear and reduced to the minimum required
-for them to function.
-These properties are crucial to the Hurd's agenda of user freedom,
-since in order to allow them to plug their own code into the system
-[FIXME: développer]
-
-However, this flexibility has a cost. In a system where the isolation of
-components relies on running them inside different address spaces,
-communication between them must be done through IPC calls.
-This introduces a trade-off between the size of the modules
-and performance as well as practicality,
-which imposes a limit to the granularity with which the system
-can be decomposed and the principle of least authority applied
-(to the code within a given process, a Mach port is ambient authority).
-
-Another issue is that of the threading structure of the system as a whole.
-In systems based on a monolithic kernel, user threads execute the kernel
-code themselves, which is then intrinsically concurrent. By contrast, in a
-system based on a “client-server” paradigm, each server must be explicitly
-multi-threaded if it is to serve requests concurrently.
-
-### Object-capability languages
-
-An object-capability language is an object-oriented language which is
-restricted enough so that object references are themselves capabilities.
-
-One such language is Joe-E (FIXME: lien),
-which is an object-capability subset of Java:
-global state and static methods are mostly forbidden;
-careful white-listing of the objects and methods
-provided by the Java standard library
-ensures that compliant code cannot not access ambient autority.
-Ways in which object references can be transferred
-are restricted to the most obvious ones
-(for instance, exceptions are carefully restricted).
-
-As a result, untrusted Joe-E code can be executed without any further
-isolation and its autority can be controlled by carefully limiting the
-object references which are passed to it.
-This would allow to load and execute translators written in Joe-E
-in a single address space.
-
-### Bundling translators into a single process
-
-[mechanisme pour transmettre le code Joe-E
-et les port initiaux au serveur]
-[émulation des différentes tâches]
-
-### Challenges and further work
-
-[proof-carrying code / typed assembly,
-resource accounting (passer en revue la conception de Viengoos?)]
-