Hello, I'll be starting my bachelor's thesis this semester and have decided to pick up where I left off with libchannel. (Not 100% sure if it's called ``bachelor's thesis'' in English, it's similar to a master's thesis except that it for a bachelor's degree and gives half the amount of credits.)
I've been planning this for a while, but didn't announce it until now because I was reluctant to start a discussion without the ability to properly formulate the problem. I felt that the previous discussions were marred with bad terminology and that my formulations caused more confusion than clarity. And the problems continued when trying to formulate a spec for this project, which has taken me some time. But I feel much more confident in those areas now, especially since my mentor has given the go to the project after reading my spec and because I've got a proper start on the report. Since the spec is in Swedish I won't post it here. Instead I'll sum it up and take advantage the fact that you're already acquainted with the Hurd to leave out most of the background. ;-) The central thesis is improving support for Hurd mobile objects. Where a ``Hurd object'' is an object used through any of the Hurd's interfaces and ``mobility'' is the ability to transfer copies of an object from one process to another for direct use à la libstore. ``improving'' because libstore and libchannel already provides object mobility, but are limited in the types of objects which can be implemented. And also for which object configurations they work, where as I will take special consideration to when sender, receiver or both are in chroots or sub-Hurds. I have dropped the channel concept and have opted to focus on arbitrary Hurd objects. I've adopted term ``mobile object'' from similar frameworks such as Java's RMI, where it is usually used when the transfer may load the objects' required code base. It's short and sweet. I've split the project into three main parts: improving authority verification, improving code transfer and an object system that can emulate Hurd objects. This because while they reinforce each-other in respect to mobility, they are orthogonal and might be useful in other areas. By ``authority verification'' I mean ability of the sender of the object to verify that the recipient has the authority required to also receive dependents of the object. E.g., having access to a file does not mean you should get access to the entire backing store. This problem gets much more interesting if you also consider chroots and sub-Hurds. By ``code transfer'' I mean how the code base of an object is specified so it can be found and loaded by the receiver. The receiver must also be able to determine if it can trust the code. Again chroots and sub-Hurds makes this more fun, e.g. what if the two parties use the same name for different code bases? By ``emulating of Hurd objects'' I mean a framework for implementing objects that are similar to Hurd objects but can be used without RPCs. Most notably this object system must support objects with an arbitrary number of arbitrary interfaces. Also it must be possible to wrap a port around an object so that it can also be used through RPCs. The opposite must also be possible so that a port can be used as a fall-back if a transfer fails. Interfaces that aren't possible through RPCs that utilize the fact that the receiver is in the same address space should also be possible, though naturally these can't be used through a wrapper port. Lastly, these parts will be tied together into a library, which I think I'll call ``libmob''. And I'll do some simple performance benchmarks, which should show when using mobile objects instead of IPC is a good idea if at all. This will hopefully give a substantial result without committing myself to find concrete use case. Though optimization is probably one of mobility's least interesting possibilities, it's the one that instantly springs to mind. What a long mail this turned out to be, hope your still with me. ;-) All comments are welcome of course, but don't feel pressured to comment every detail, because I'll be sending out mails to discuss the individual parts as I get to them. Most likely in the order they were mentioned. Regards, Fredrik
