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-
