Re: A proxy of the proc server for translators

[olafBuddenhagen]

Hi,

On Tue, Jun 24, 2008 at 10:56:03PM +0200, zhengda wrote:

> I want to write a proxy of the proc server (proc_proxy), so I can
> provide a pseudo master device port to the translator without changing
> its code.
>
> My first idea was to create a message server which handles all RPCs in
> process.defs. When a request comes, the message server calls the
> corresponding RPC to the real process server. The proxy forks a child
> process, override the proc port of the child  process to point to
> itself so the proxy can get the request from the  child process, and
> executes the user's command in the child process.

Sounds reasonable. (It is similar to one of the variants I have thought
of myself...)

> For example, to run a pfinet server, the command can be like this:
> proc_proxy settrans -afgpc /root/socket2/2 /root/hurd/pfinet/pfinet -i
> eth0 -a 192.168.2.11 -g 192.168.2.1 -m 255.255.255.0

> There are some problems:

> 1. the proxy does override the proc port of the child process where
> runs  settrans, but it seems the translator still uses the original
> proc  server. The task of the translator is created directly by
> task_create()  so it doesn't inherit the proc server from its parent.
> I still haven't  find the code where the proc server is set in the
> process of the translator.

> 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

> 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 :-(

> Maybe I can run a second proc server for the translator, and change
> the  master device port in the second proc server.

This could work -- it was the other variant I considered :-)

> However, the translator is  completely isolated from other processes

Shouldn't be a problem I think, except that the translator process will
be listed as an unknown process in ps...

Of course, I might be overlooking something.

-antrik-