The nameserver will be implemented as a UMP server and processes communicate with it only indirectly over their respective monitor like with all other servers right now.
Once the nameserver is fully implemented, all processes will communicate with every "ordinary" server (non-ordinary servers are the memory server, monitor, and the nameserver itself) directly over UMP (as opposed to now where they route all their requests over the monitor via LMP). If a process then sends a lookup to the nameserver the nameserver will send an add client request (over UMP) to the respective service that was requested. The service will provide a new communication channel (i.e. a frame capability for UMP communication), which will be sent as a reply back to the original requesting process.
As a result, every "ordinary" server can run in its own domain and processes are able to acquire a direct UMP communication channel to any arbitrary service by calling the lookup function.
The memoryserver is actually supposed to be handled as an "ordinary" server as well, but it's a special case since the nameserver itself depends on it.
In theory it would be possible to give the process upon lookup a LMP channel if it is running on the same core. The tricky part there would be to put the LMP channel (which will comprise of an endpoint capability) into a response from the nameserver (which has to be a UMP message). Since our UMP implementation currently cannot transmit capabilities other than frames, this is currently not directly possible. Maybe this could be implemented using a local task that the nameserver sends to the monitor running on that core, where the monitor sends the endpoint capability to the requesting process.
The monitor servers should register at the nameserver, then the process server can look them up so that it can send them local spawn tasks.
Remaining tasks
[x] Implement nameserver as UMP server
[x] Implement registration
[x] Implement deregistration
[x] Implement lookup
[x] Implement enumeration
[x] Implement add_client RPC message that the nameserver can use to tell a registered service to add a client (should return the frame cap for the new client)
[ ] Synchronize client list of generic UMP server if switching to threads
[x] Implement nslookup
[x] Implement nslist
[x] Register monitorservers at nameserver (to receive local tasks) and look them up in the process server
[x] Migrate existing servers to nameserver API
[x] initserver
[ ] serialserver
[x] processserver
[ ] memoryserver (see below)
[ ] Distribute only nameserver frame to monitors instead of the frames of all individual servers
[ ] Handling of memoryserver
Should also be registered at nameserver
Could be centralized if the actual server communication won't be routed over the monitor anymore
Remaining problem: Nameserver will probably depend on mallocs, so how does it work before the memoryserver registered itself
Possible solution: let the nameserver have its own fixed part of the memory so that it doesn't depeend on the memory server
Possible solution: let the nameserver communicate with the memory server without the memory server having to register at the nameserver
Nameserver concept
The nameserver will be implemented as a UMP server and processes communicate with it only indirectly over their respective monitor like with all other servers right now. Once the nameserver is fully implemented, all processes will communicate with every "ordinary" server (non-ordinary servers are the memory server, monitor, and the nameserver itself) directly over UMP (as opposed to now where they route all their requests over the monitor via LMP). If a process then sends a lookup to the nameserver the nameserver will send an add client request (over UMP) to the respective service that was requested. The service will provide a new communication channel (i.e. a frame capability for UMP communication), which will be sent as a reply back to the original requesting process.
As a result, every "ordinary" server can run in its own domain and processes are able to acquire a direct UMP communication channel to any arbitrary service by calling the lookup function.
The memoryserver is actually supposed to be handled as an "ordinary" server as well, but it's a special case since the nameserver itself depends on it.
In theory it would be possible to give the process upon lookup a LMP channel if it is running on the same core. The tricky part there would be to put the LMP channel (which will comprise of an endpoint capability) into a response from the nameserver (which has to be a UMP message). Since our UMP implementation currently cannot transmit capabilities other than frames, this is currently not directly possible. Maybe this could be implemented using a local task that the nameserver sends to the monitor running on that core, where the monitor sends the endpoint capability to the requesting process.
The monitor servers should register at the nameserver, then the process server can look them up so that it can send them local spawn tasks.
Remaining tasks