Re: Re: Mach independence

[Ondrej Hurt]

> The most difficult part in the l4-hurd port right now is how to
> map Mach IPC to L4 IPC. Mach IPC is basically asynchroneous, whereas 
> L4 IPC is synchroneous. Current status in the discussion on l4-hurd
> is this:
>
> Most of the Hurd calls can be made synchroneous. There is _mostly_
> no need for asynch. communications (I'd suspect in more than 95%
> of the cases, but that is more of a wild guess than anything else).
> This portion of synchroneous calls can be implemented quite straigtfully
> by an IDL compiler which will convert *.idl files to L4-IPC. At least
> two such IDL compilers for L4 exist and for Mach, we have flick-1.x, 
> which also supports L4 as backend. So the Hurd people will need to
> first migrate from MIG to, say Flick/Mach and provide IDL files instead
> of the current MiG *.defs. Then we can hook in one of the L4 IDL compilers
> to generate the synchroneous IPC stuff.

I don't understand this issue much and I don't know these IPC code
generators. Async RPC could be implemented with 'listener' thread
that just copies RPCs to task's message queues, couldn't it ? Do you
think that async IPC is not necessary (and thus slow) in most cases ?
> The current problem with IPC is how to obtain no-senders notifications
> in an L4 environment: In the Hurd, the servers (or more exactly, the 
> stubs) need to know when a port is dead a.k.a. when it can be sure
> that no clients will ever send an IPC down this port, so that it can 
> clean up resources. The obvious scenario is when a task dies and so
> a translator will have to release all open fileresources of this task.
> There is no such mechanism in L4, so it will have to be implemented as
> a user-level task (basically, a task-server that 'owns' the tasks it 
> creates and than will provide for notifications upon tasks deaths
> to registered clients).

> -Farid.

What about this scenario:

Each task with receive right to certain port would maintain
information (in userspace) about every send right that was created
for this port so that it can check if incoming RPCs are authorised.
If any task with a send right wants to relinquish this right it would
make special RPC notifying the task with receive right to forget
about this send right.

Now there are the problems with misbehaved tasks:
1) A task can forget to destroy its send rights even if it does not
need them anymore. I don't know how this could be solved (and it is
already present in all Mach-based systems)
2) A task can crash and all send and receive rights have to be
cleaned up automaticaly. This cannot be done from its private data
which can be corrupted (and you even may not be able to read them in
L4, dunno). There could be a special task that serves only as a
storage for information about all send and receive rights in the
system. It would have to be notified about
creation/destruction/movement of all rights in the system to be
up-to-date. When a task goes wild and is stopped you could use this
information to send special notifications to taska that are
interested in it (tasks with related send/recv rights) so they can
make decrements/cleanups. When refcount reaches zero then Hurd
user-space library present in the task would send no-senders
notification to the same task (certain port).

All tasks have to maintain information about their own send rights.
This information includes task_id, thread_id and port_id (local in
owning task) so they know which thread listens for calls to certain
port.

If a task should transfer its recv right to another task then all
information about the port would have to be copied to the destination
task (including messages in queue). Also all task that have send
rights to this port would be notified that port's task_id, thread_id
and port_id were changed.

Each task has a thread that takes care of all these notifications
concerning port rights.

Ondrej


______________________________________________________________________
Vyberte Vas "Nejoblibenejsi automobil roku 2002 v CR"
a hlasujte na adrese http://www.autoroku.cz. Hlavni vyhra 600 000 Kc!!!