diff options
Diffstat (limited to 'user')
| -rw-r--r-- | user/jkoenig/gsoc2011_proposal.mdwn | 38 |
1 files changed, 19 insertions, 19 deletions
diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn index b5932006..46ebf945 100644 --- a/user/jkoenig/gsoc2011_proposal.mdwn +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -1,5 +1,5 @@ -# Java for Hurd (and vice vera) +# Java for Hurd (and vice versa) *[Draft] I'll finish this later today and send an email to bug-hurd when I'm done* @@ -43,7 +43,7 @@ Shortly afterwards, I rewrote the procfs translator to fix some issues with memory leaks, make it more reliable, -and improve comptibility with Linux-based tools +and improve compatibility with Linux-based tools such as `procps` or `htop`. Although I have not had as much time @@ -55,7 +55,7 @@ on implementing POSIX threads signal semantics in glibc. ### Project-related skills and interests -I have used Java mostly for university assignements. +I have used Java mostly for university assignments. This includes non-trivial projects using threads and distributed programming frameworks such as Java RMI or CORBA. @@ -95,7 +95,7 @@ I don't expect I would require too much time from them. My exams end on May 20 so I would be able to start coding right at the beginning of the GSoC period. -Next year's term would probably begin around september 15, +Next year's term would probably begin around September 15, so that would not be an issue either. I expect I would work around 40 hours per week, and my waking hours would be flexible. @@ -242,7 +242,7 @@ Mach primitives and extending MIG to generate Java code from the interface description files. This approach would be initially more involved, and would introduces several -issues related to overcoming the "impedence mismatch" between Java and Mach. +issues related to overcoming the "impedance mismatch" between Java and Mach. However, once an initial implementation is done it would be easier to maintain in the long run and we would be able to provide Java bindings for a large percentage of the Hurd’s interfaces. @@ -271,9 +271,9 @@ package, which would contain at least the following classes: * `MachPort` would encapsulate a `mach_port_t`. (Some of) its constructors would act as an interface for the `mach_port_allocate()` system call. - `MachPort` objects would also be instanciated from other parts of the JNI + `MachPort` objects would also be instantiated from other parts of the JNI C code to represent port rights received through IPC. The `deallocate()` - mehod would call `mach_port_deallocate()` and replace the encapsulated + method would call `mach_port_deallocate()` and replace the encapsulated port name with `MACH_PORT_DEAD`. We would recommend that users call it when a port is no longer used, but the finalizer would also deallocate the port when the `MachPort` object is garbage collected. @@ -286,11 +286,11 @@ package, which would contain at least the following classes: constructor would allocate a `byte[]` member array of a given size. Additional methods would be provided to fill in or query the information in the message header and additional data items, including `MachPort` and - `Buffer` objects which would be translated to the correponding port names + `Buffer` objects which would be translated to the corresponding port names and out-of-line pointers. A global map from port names to the corresponding `MachPort` object would probably be needed to ensure that there is a one-to-one - correspondance. + correspondence. * `Syscall` would provide static JNI methods for performing system calls not covered by the above classes, such as `mach_msg()` or `mach_thread_self()`. These methods would accept or return `MachPort`, @@ -308,7 +308,7 @@ examples: `Message` object, and to read it back as a `MachPort` or `Buffer` object, since this would allow unsafe access to arbitrary memory addresses and mach port names. - * Providing the `mach_task_self()` system call would also provide acces to + * Providing the `mach_task_self()` system call would also provide access to arbitrary addresses and ports by using the `vm_*` family of RPC operations with the returned `MachPort` object. This means that the relevant task operations should be provided by the `Syscall` class instead. @@ -394,7 +394,7 @@ but basically: would implement this interface by doing RPC over a given MachPort object. * A server class, corresponding to `*Server.c`, would be able to handle incoming messages using a user-provided implementation of the interface. - (Possibly, a skelton class providing methods which would raise + (Possibly, a skeleton class providing methods which would raise `NotImplementedException`s would be provided as well. Users would derive from this class and override the relevant methods. This would allow them not to implement some operations, @@ -409,7 +409,7 @@ primitives described in the previous section. When possible, operations involving the transmission of send rights of some kind would be expressed in terms of the MIG-generated interfaces -intead of `MachPort` objects. +instead of `MachPort` objects. Upon reception of a send right, a `FooUser` object would be created and associated with the corresponding `MachPort` object. @@ -424,10 +424,10 @@ instead of going through RPC mechanisms. Some issues will still need to be solved regarding how MIG will convert interface description files to Java interfaces. For instance: - * `.defs` files are not explicitely associated with a type. For instance in + * `.defs` files are not explicitly associated with a type. For instance in the example above, MIG would have to somehow infer that io_t corresponds to `this` in the `Io` interface. - * More generally, a correspondance between MIG and Java types would have + * More generally, a correspondence between MIG and Java types would have to be determined. Ideally this would be automated and not hardcoded too much. * Initially, reply port parameters would be ignored. However they may be @@ -484,7 +484,7 @@ library. Once MIG can target Java code, and a libports equivalent is available, creating new translators in Java would be greatly facilitated. However, -we would probably want to introduce basic implementations of filesystem +we would probably want to introduce basic implementations of file system translators in the spirit of libtrivfs or libnetfs. They could take the form of base classes implementing the relevant MIG-generated interfaces which would then be derived by users, @@ -497,7 +497,7 @@ to design and implement similar solutions for Java. ### Deliverables - * A hurd-java package would contain the Java code developped + * A hurd-java package would contain the Java code developed in the context of this project. * The Java code would be documented using javadoc and a tutorial for writing translators would be written as well. @@ -513,7 +513,7 @@ Debian GNU/Hurd. This package would be separate from both Hurd and Mach, so as not to impose unreasonable build dependencies on them. -I expect I would be able to act as its maintainer in the forseeable future, +I expect I would be able to act as its maintainer in the foreseeable future, either as an individual or as a part of the Hurd team. Hopefully, my code would be claimed by the Hurd project as their own, @@ -524,7 +524,7 @@ could be integrated upstream. Since by design, the Java code would use only a small number of stable interfaces, it would not be subject to excessive amounts of bitrot. -Consequenty, +Consequently, maintenance would primarily consist in fixing bugs as they are reported, and adding new features as they are requested. @@ -618,7 +618,7 @@ of some Java applications (though probably not by much), and would otherwise be a good project for someone trying to get acquainted with Hurd. -Overall, I beleive this project would be fun, interesting and useful. +Overall, I believe this project would be fun, interesting and useful. I hope that you will share this sentiment and give me the opportunity to spend another summer working on Hurd. |