Multiple io-net crashes

bridged with qdn.public.qnxrtp.os
Xiaodan Tang

Re: Multiple io-net crashes

Post by Xiaodan Tang » Mon Dec 01, 2003 6:35 pm

Here is an email I sent to Khian to explain the difference between
"on -n " and "on -f", I thought it would be useful to post here so
people could get a better idea why they saw "weird" behavior.

-xtang

--------------- Email start from here ---------------------------------
OK :-)

gcrear1$ on -n bobcat /bin/ls /

Will have the binary running on "bobcat" , with ROOT=/net/gcrear1, or
the command above could translate to (if we put all network path on)

gcrear1$ /net/gcrear1/bin/on -n bobcat /net/gcrear1/bin/ls /net/gcrear1

The libc.so.2 that "ls" needed, is also come from /net/gcrear1/lib/libc.so.2

On the other hande "on -f bobcat /bin/ls /", would have a
ROOT=/net/bobcat, which means:

gcrear1$ /net/gcrear1/bin/on -f bobcat /net/bobcat/bin/ls /net/bobcat

So "on -f ..." is more equivlent with telnet into the box and run a
program.This is usually most people think what it would like to
"spawn remote".

The "on -n" will have a lot of "wired behavar". For example, if you
"on -n bobcat ping yahoo.com", and try to tcpdump the traffic, you
can see the packet src address is "gcrear1" , but not "bobcat" as
most people would expect, why?

Because the "ping" is running with ROOT=/net/gcear1. So when it call
"socket()", it is a open("/dev/sock/2, ") underkneeth. Which, because
of the "ROOT", is then translated by procnto to
open("/net/gcrear1/dev/socket/2"...),
which using the tcpip stack back on gcrear1.

Since almost everything on QNX involve a pathname resovle, and message
passing. So if you "on -n bobcot application", and your application is
opening a
pipe, it will try open("/dev/pipe", ), which translate back to
"/net/gcrear1/dev/pipe",
it then use the pipe manager on gcrear1 to creat a pipe. If your application
call
"mq_open()", it goes all the way back to "/net/gcrear1/dev/mqueue"...
Some manager may refuse being accessed from remote, which means
some call will fail.

So, in a short, "on -f bobcat" will give the behavior everybody usually
expect :-) Hope this could clear the mud a little bit.

-Xiaodan Tang

John Nagle

Re: Multiple io-net crashes

Post by John Nagle » Tue Dec 02, 2003 7:35 am

We understand that. But that isn't the major problem.
io-net crashing is the major problem. Most of the other
problems we encounter stem from trying to find workarounds
for io-net crashing. If we can get that fixed, we can
probably deal with the rest of the issues.

Whom do we need to talk to get this fixed? Thanks.


John Nagle

Xiaodan Tang wrote:
Here is an email I sent to Khian to explain the difference between
"on -n " and "on -f", I thought it would be useful to post here so
people could get a better idea why they saw "weird" behavior.

-xtang

--------------- Email start from here ---------------------------------
OK :-)

gcrear1$ on -n bobcat /bin/ls /

Will have the binary running on "bobcat" , with ROOT=/net/gcrear1, or
the command above could translate to (if we put all network path on)

gcrear1$ /net/gcrear1/bin/on -n bobcat /net/gcrear1/bin/ls /net/gcrear1

The libc.so.2 that "ls" needed, is also come from /net/gcrear1/lib/libc.so.2

On the other hande "on -f bobcat /bin/ls /", would have a
ROOT=/net/bobcat, which means:

gcrear1$ /net/gcrear1/bin/on -f bobcat /net/bobcat/bin/ls /net/bobcat

So "on -f ..." is more equivlent with telnet into the box and run a
program.This is usually most people think what it would like to
"spawn remote".

The "on -n" will have a lot of "wired behavar". For example, if you
"on -n bobcat ping yahoo.com", and try to tcpdump the traffic, you
can see the packet src address is "gcrear1" , but not "bobcat" as
most people would expect, why?

Because the "ping" is running with ROOT=/net/gcear1. So when it call
"socket()", it is a open("/dev/sock/2, ") underkneeth. Which, because
of the "ROOT", is then translated by procnto to
open("/net/gcrear1/dev/socket/2"...),
which using the tcpip stack back on gcrear1.

Since almost everything on QNX involve a pathname resovle, and message
passing. So if you "on -n bobcot application", and your application is
opening a
pipe, it will try open("/dev/pipe", ), which translate back to
"/net/gcrear1/dev/pipe",
it then use the pipe manager on gcrear1 to creat a pipe. If your application
call
"mq_open()", it goes all the way back to "/net/gcrear1/dev/mqueue"...
Some manager may refuse being accessed from remote, which means
some call will fail.

So, in a short, "on -f bobcat" will give the behavior everybody usually
expect :-) Hope this could clear the mud a little bit.

-Xiaodan Tang



Post Reply

Return to “qdn.public.qnxrtp.os”