On 12.6.2012 1:29, Tobias Börtitz wrote: > The only thing I not yet quite understand is why the 'ipc_connect_to_me' > function connects to the other tasks or which tasks in general it is > trying to ask for a connection.
HelenOS IPC connections are unidirectional only (meaning that requests are sent in one direction and replies in the other). So it may be desirable for a task to offer another task to connect to it so that active communication in the opposite direction is possible too. A typical scenario would be registration at some sort of naming (e.g. NS or VFS). Assume the newly registering server has a connection to the task acting as a naming service (either implicit as is the case of NS or provided by NS as is the case of VFS). By sending it the 'connect to me invitation', it basically asks the naming service to remember the new server by establishing a new connection to it. If the naming service replies affirmatively to the message (i.e. EOK), the kernel notices this and establishes the new connection. The naming service is then able to use a newly allocated phone to talk to the registered server, for example to connect clients to it (via forwarding the respective 'connect me to' messages). > > Also note that you cannot create an IPC connection just between > arbitrary tasks. You can only create new IPC connections over > already established connections, either by forwarding or by creating > callbacks. Therefore for the IPC to work you need the initial naming > service which all tasks are automatically connected to by the > kernel. In your test case one of the two communicating tasks will > have to be the naming service. > > So does the syscall automatically and every time request a connection > from the first loaded tasks (which then would be forced to be the > nameservice)? Or am I able to address another task directly to ask for a > connection with this syscall? By convention, the kinit() thread remembers the asnwerbox of the first created task (ipc_phone_0 symbol) and task_create() connects all other tasks to it. That's for the initial connection. The combination of call forwarding and creation of callbacks via the 'connect to me' message, the tasks have all the powers needed to create arbitrary graph of connections, subject to the policies they implement. As I stated above, there are several tasks which act as a sort of a naming service (NS, LOC, VFS, DEVMAN etc.). Except of the initial task (i.e. NS), they get this role automatically by virtue of handling the 'connect to me' registration requests from servers and forwarding 'connect me to' requests from clients to servers. The existence of these other or secondary naming services is essential so that it is not necessary for all servers to register at the NS task. In fact, only the few singleton services are supposed to register at NS. For example, the individual file system servers register only at the VFS task, making it impossible for other tasks to connect and talk to them directly either intentionally or by error. HTH, Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
