Re: vk_l4 -- CVS Setup

[Espen Skoglund]

[Farid Hajji]
> So, GUIDs are unlikely to be implemented in L4 in the forseeable
> future.  IPC transparency will have to be dealt with in user-space,
> probably through some kind of general purpose library that would
> provide:
>   * macros for local IPCs,
>   * discrimination code, including redirecting to proxy IDs,
>   * marshalling/unmarshalling messages (protocol for the proxy),
> and of course proxy tasks themselves, including the inter-proxy
> protocol ;-).

As already mentioned (also by you) several times: the kernel should
not deal with network wide IPCs.  In v2 one could use the site-field
in the TID to indicate a node where to send the IPC.  This had several
issues though:

  o It was not really necessary (from kernels point of view) to put it
    into the ID.
  o It restricted the number of nodes in the network.
  o It prohibited threads to migrate between nodes.

The two latter bullets could be overcome by implementing another ID
layer on top of the thread IDs, but this would obviate to have
site-fields in the thread IDs in the first place.

What one really needs is for certain IPC operations (i.e., inter node
IPC) to be directed through a proxy thread.  Version 4 allows for
this, albeit not very efficiently.  One either has to redirect all
inter task IPCs through an external proxy (which could in turn
determine if it was an inter or intra node IPC), or one can put no
restriction on IPC.

The successor of the L4v4 API will allow much more control over
thread/task confinement.  That is, it will easily allow, e.g., thread
A to talk to thread B but not thread C.  Having this mechanism also
allows inter node IPC to be constructed (relatively) easy: one
confines the threads on one cpu so that they can not speak directly to
threads on other CPUs.

        eSk