[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Improving object mobility within the Hurd

From: Carl Fredrik Hammar
Subject: Improving object mobility within the Hurd
Date: Wed, 7 Jan 2009 22:24:33 +0100
User-agent: Mutt/1.5.18 (2008-05-17)


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]