Re: object management and IPC a bit more formal

[Marcus Brinkmann]

On Tue, May 06, 2003 at 09:33:03AM +0200, Ludovic Courtès wrote:
> I'm a bit confused and it is still unclear to me how we could deal with
> persistent tasks (clients) holding such user_objects.

The way I see it, all the problems arising with persistency are at a level
that is hidden entirely by the object management libraries.  So, I prefer to
not worry about it at all, and leave that to other people.

> This means that each set of persistent tasks needs to have its own
> subsystem

It's an interesting idea to use subsystems for persistent components of the
system.  However, you realize that if you are going to do that, perstisten
tasks must not communicate with non-persisten tasks?  Because if they were
to do that, they would leave the persistent subsystem and store
non-persistent thread ids.  But maybe that is ok as long as those parts of
the communication can easily be reestablished.

OTOH, I think that it might be better to have a concept of subsystems that
doesn't require subsystem usage, as this is not what subsystems were for (at
least if you expect the persistent component to be reasonably connected to
the non-persistent component, rather than running them in parallel like
l4linux and Hurd could run in parallel).

> However, if the above is correct, there are still two issues left:
>  - how do we make sure that a subsystem ID can only be reused by the
>    given persistent subsystem?

There is no allocation scheme planned in a first version of the root task
server.

>  - subsystem IDs are quite small on 32-bit machines.

That's an L4 limitation, ultimatively.

See, I don't think that there is a requirement to make it work with global
identifiers.  It should be easy to wrap the global identifier in the object
handle with a local identifier, and look up the global one internal in the
task when you do an RPC.  Then you can use a name server mechanism or some
other way to update the global id table.

OTOH, if you want to split up the thread number and PID world, you could use
subsystems, but you could also just modify the task and proc server to have
a flag "persistent", which could be the highest bit of the thread number
and the highest bit of the PID.  Of course, that only gives you one "realm",
but using a proxy proc server you could manage subrealms for users etc.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/