[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A proxy of the proc server for translators

From: zhengda
Subject: Re: A proxy of the proc server for translators
Date: Thu, 26 Jun 2008 19:46:55 +0200
User-agent: Thunderbird (X11/20080421)

olafBuddenhagen@gmx.net wrote:
3. If the translator is set in the passive mode, it is started by the
file system server. It seems that I don't have a chance to override
its  proc server.

These should be fixable by reversing the command I think:

settrans -afgpc /root/socket2/2 proc_proxy /root/hurd/pfinet/pfinet -i eth0 -a -g -m
In this case, proc_proxy must work as a translator, and meanwhile, have the ability of running another translator just as settrans does.
But it should be feasible.
2. when the proc server gets the request, it is always looking for the
process information from the remote port of the caller. When an RPC is
forwarded by the proxy, the process information of the proxy is
changed  and the real proc server still doesn't know anything about
the process  who sends the request.

Hm... I'm quite at a loss here :-(
The RPCs in process.defs are handled a bit different by the proc server.
When the proc server receives a RPC request, the proc tries to find the process information of the requester by using reqport_find(). The request port (of the caller) is passed to reqport_find(). As a result, the process information returned by reqport_find() is of the process who directly calls the RPC. Here is the code (in processServer.c):
     process = reqport_find(In0P->Head.msgh_request_port);
In the case of proc_proxy, when proc_proxy "forwards" the RPC, the process information set or got by the RPC is of proc_proxy, but not of the translator because the caller of the RPC is always the proc_proxy in the proc's eyes. It's not what we want. So in order to make the proc proxy really work, the proc proxy should cheat the proc server that the request is from the translator. I don't know if it's possible to do it in the current implementation of Mach. If it's possible, I wonder if there are some security issues.

I don't think the proc proxy is very useful in the case of pfinet because we only want to get the pseudo master device port to access the "hypervisor". This solution is too complex. But it should be useful to create a subenvironment in the future, at least I hope:) I think that it's more useful to create a translator that helps the socket server such as pfinet get the port of accessing the network interface (virtual or real). That is, the pfinet can get the port of accessing a network interface by calling file_name_lookup().

Zheng Da

reply via email to

[Prev in Thread] Current Thread [Next in Thread]