Re: Improving object mobility within the Hurd

[olafBuddenhagen]

Hi,

On Sat, Jan 10, 2009 at 06:56:15PM +0100, Carl Fredrik Hammar wrote:
> On Sat, Jan 10, 2009 at 08:50:28AM +0100, olafBuddenhagen@gmx.net
> wrote:

> > > 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.
> > 
> > I must admit that I don't see it (yet)... Can you please explain how
> > you imagine these to be useful in different contexts?
> 
> The first two parts could be used to improve mobility in libstore
> directly, without porting stores to the new object system.  It could
> also be useful for alternative mobility framework, which might want to
> use a tailored object system.  Most likely they might consider my
> object system overkill if they don't actually want to emulate Hurd
> objects.

I see. It all hinges on the definition of "Hurd object"... I wasn't
paying enough attention: By object, you mean strictly the server code
serving RPCs on a port it seems. Object migration would simply mean
loading the code in the client instead, and pretending to do real RPCs
on it.

I was thinking of objects in a somewhat more abstract sense: The actual
functionality provided by the server, which could be accessed by RPCs,
but also by an alternative interface optimised for direct invocation
when migrated to the client...

So I guess by your definition, the use case I'm interested in for
translator stacking, would actually not classify under object migration,
but under other uses... I guess you remember that I don't consider
actual RPC emulation particularily useful :-)

> The object system itself can be used in contexts outside of mobility.
> For instance, libstores mechanism for specifying stores on the command
> line.  Thus the process don't need other translators to provide the
> store for it (using it remotely or transferring it).  This is useful
> for the root file system translator during boot, e.g. if the file
> system is on some RAID configuration.

Well, strictly speaking this is not mobility, as the object is not
actually transferred from one process to the other, but rather loaded by
the client directly... But conceptually, I don't see much difference
really. The idea of loading an object directly instead of talking to it
through RPC is exactly the same.

You may remember that I'm not convinced the way it is handled at boot
now to be the smartest possible approach anyways... But that's beside
the point I guess :-)

> The command line mechanism can ignore many of the issues that arise in
> mobility, e.g. consistency between different copies.

I must admit that I don't see the difference... Please explain.

> > As I said before, I believe it is best for the server to provide the
> > object code directly (by an RPC), rather than letting the client
> > look it up somewhere. This would entirely remove the naming problem,
> > along with some others.
> 
> This is one of the methods I'm considering, i.e. ``naming'' the code
> with a port to the .so file.

Actually, I meant the server providing the object code directly through
the RPC... But providing a port to a file containing it indeed seems
preferable :-)

> I do not have high hopes for this method though, mostly because it's
> hard for the recipient to determine if it can trust the code.

Well, in the simple case -- using the traditional UNIX model -- it's
pretty trivial: The client trusts the code if it trust the server, which
is the case when the server is run by the same user, or by root. In this
case, there is no problem at all.

Admittedly, this is more tricky when leaving the UNIX model, and working
with pure capabilities... I'm not sure that an object named through a
textual file name is indeed more trustworthy than one named through a
port directly -- but I haven't really thought about it yet. I'm curious
what you have to say on that in the promised later mails :-)

> > Regarding trust, I think this is complementary to authority.
> > Probably they should be considered together.
> 
> Really?  Being allowed to do something is quite distinct from trusting
> that it really does what it claims to do IMHO.

Of course it is distrinct. I said they are *complementary*, not that
they are the same :-)

In the UNIX case, it is actually quite symmetrical: The client trusts
the object code provided by the server, if the server is the same user
or root. The server entrusts the client with the content of the object,
if the client is the same user or root.

Again, other cases are possible of course... But I guess the
considerations will always be similar in both directions.

> > > 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.
> > 
> > That means the objects can't migrate in a transparent fashion. What
> > use cases do you see for non-transparent object migration?...
> 
> I thought you'd be cheering this feature. It allows for interfaces
> which don't have to assume that the object is remote, e.g. it can use
> pointers, globals, etc.

That's the same misunderstanding as above: The use case I'm interested
in is indeed not transparent at the RPC object level, though it is
transparent at a more abstract object level...

> > LOL... Is the pun intended? :-) (herd vs. mob)
[...]
> It is interesting to note that ``mob'' is derived from ``mobile
> vulgus'', which is Latin for ``the easily movable crowd''.

"easily movable crowd" is an even better pun than what is commonly
associated with "mob" :-)

> One idea I have been toying with is using it for alleviating the
> problem of resource accountability.  I.e. making the client load an
> object which manages state needed by the server.  Consider an object
> that maintains the current position within a file, then the translator
> wouldn't need to maintain such session state.

I see serious problems with this use case: The reason the file pointer
for example is maintained by the server is that it can be shared between
multiple clients, if clients share an fd. According to POSIX, they must
share the file position as well in this case. So you can't trivially
move the handling to the client. (Otherwise it would have been
implemented in libc from the beginning...)

We could still move the handling to the client in the more common case
that there is only one client -- but that wouldn't solve the resource
management problem, as there are still the cases where it must remain in
the server.

It might actually be possible to move it to the clients and coordinate
use somehow, but this is really tricky. Or we could just ignore the case
alltogether, as it's a rather obscure feature, and the few (if any)
programs actually making use of it probably could easier be adapted than
handling it "properly" in the Hurd... But this is all beside the point:
Object migration doesn't help with addressing the real problems here.

However, thinking about this made me realize something else.

I like the translator concept, because it allows intuitively naming
objects through filesystem locations; and the objects are standalone,
i.e. can be accessed directly from the command line, typically through a
filesystem interface.

I never considered these two aspects distictly, but I see now that it
makes sense to do so: Not all translators implement a standard interface
that can actually be used with standard tools. Even if technically they
are standalone, the objects can only be handled by specific programs
really. So the standalone aspect is pretty meaningless here -- but the
naming aspect is still important.

For such objects it would make perfect sense to be implemented as a
special kind of translators, so they can still be named through the
filesystem; but the actual code always being executed in the client --
i.e. using a migration mechanism that needn't be transparent.

(Transparent at an abstract object level I mean, not at the RPC level.)

An obvious use case are ioctl handlers: I believed for a long time that
rather than being hardcoded in libc, they should be handled by some kind
of loadable modules. This was actually discussed as part of the channel
concept, but I discarded it back then, as it doesn't fulfill the
transparency requirement, and thus didn't seem useful to me back then.

Now I see that it might be still useful to implement this using a common
mobility framework, so they can be handled like something akin to
translators -- providing objects that are not really standalone, but are
named through filesystem locations.

BTW, it's rather sad that we already run into terminology issues
again... We need to sort this out, to make a clear distinction between
abstract objects and RPC objects.

(Judging by the terminology used in libstore, it seems that my use of
"object" as a more abstract entity is closer to traditional use in Hurd:
The store classes are clearly classes of abstract objects, not of RPC
objects...)

-antrik-