[EMAIL PROTECTED] 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
192.168.2.11 -g 192.168.2.1 -m 255.255.255.0
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().
Best,
Zheng Da
