Re: A proxy of the proc server for translators

[olafBuddenhagen]

Hi,

On Thu, Jun 26, 2008 at 07:46:55PM +0200, zhengda wrote:
> olafBuddenhagen@gmx.net wrote:

>> 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.

I don't think it requires any special handling.

The only difference between translators and other programs is that a
translator uses the bootstrap port, while other programs ignore it. As
the translator subprocess is forked from the "outer" helper program
invoked through settrans, the bootstrap port is copied to it. The helper
program ignores it, the translator uses it. No problem here.

It is possible to create the weirdest settrans commands; you can
actually put complete shell scripts there... Ask Thomas Schwinge for
some crazy examples ;-) (See
http://lists.gnu.org/archive/html/bug-hurd/2007-04/msg00008.html )

>>> 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.

Sorry, I was unclear: I did actually understand all that. I just meant
that I was at a loss as to how to handle it...

In the meantime, it dawned upon me however. I don't know how these
things work exactly, so I'm not sure this is correct... AIUI every
process has it's own port for proc, right?

So I think all you need to do is for every client that contacts the proc
proxy, to create a distinct port to the real proc server, and forward
all requests from this client on that port.

Unless I'm mistaken, the proc server doesn't really know where a request
comes from; it just distinguishes the clients by the port on which the
request is coming in...

This is really not specific to the proc proxy. rpctrace does something
very similar AIUI.

> 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().

Indeed :-)

-antrik-