Hi,
Is there any problem to dialog between x86 and ppc through qnet? I want
to talk about some endians (the last Mohican is not dead)!
Alain.
Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:
Hi,
Is there any problem to dialog between x86 and ppc through qnet? I want
to talk about some endians (the last Mohican is not dead)!
I don’t think that cross-endian qnet connections are supported.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
!!! That’s a bit incredible !!!
The main argument of QSSL is to say that QNX is multi-platforms but they
cannot talk together!
First I’m almost sure there isn’t any difficulty to swap the bytes to
match the endianness and secondly I’m sure that other communication
protocols from Unix allow to talk between x86 and PPC without any
adaptation to QNX particularity (Right Armin? 
).
Is it scheduled for 6.3???
regards.
David Gibbs a écrit:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
Hi,
Is there any problem to dialog between x86 and ppc through qnet? I want
to talk about some endians (the last Mohican is not dead)!
I don’t think that cross-endian qnet connections are supported.-David
My understanding is that it can be done. The cross endianess only
affects binary data. Just do wht you would have to do on TCP/IP.
Make use of the htons() & htonl() when you put binary data into the
packet, and ntohs() & ntohl() when you extract data from the packet.
I guess if you use any ‘long long’ data types (64-bit), you would
have to write your own htonll() & ntohll() functions.
NOTE: The above only applies to QNETing between your own applications.
QNETing to/from QNX resource managers is a whole nother matter.
I.E. All bet are off!
ls /net/other_endianess_host
may or may not work.
On the other hand, it’s easy enough to try.
Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:
AB > !!! That’s a bit incredible !!!
AB > The main argument of QSSL is to say that QNX is multi-platforms but they
AB > cannot talk together!
AB > First I’m almost sure there isn’t any difficulty to swap the bytes to
AB > match the endianness and secondly I’m sure that other communication
AB > protocols from Unix allow to talk between x86 and PPC without any
AB > adaptation to QNX particularity (Right Armin? ).
AB > Is it scheduled for 6.3???
AB > regards.
Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote in message
news:3FB9D7A4.3090502@icbt.com…
!!! That’s a bit incredible !!!
The main argument of QSSL is to say that QNX is multi-platforms but they
cannot talk together!
First I’m almost sure there isn’t any difficulty to swap the bytes to match
the endianness and secondly I’m sure that other
communication protocols from Unix allow to talk between x86 and PPC without
any adaptation to QNX particularity (Right
Armin? >
You can QNET to a different endian - using the resource manager framework
over top is what is not cross-endian. Byte swapping is easy; byte swapping
user specified data without any layout rules or specifications is not (since
you can’t know what bytes to swap). So it’s up to the user to byte swap
his/her own data as nessesary (just like TCP/IP).
Also, if you could, please post in plain text.
-Adam
Ok, I understand what you mean
But about ls /net/PPC_target, I suppose that QSSL though about that
problem and choosed the byte order of the binary informations in its
resmgr. So, ls, pidin -n PPC_target, etc… should work
Alain.
Adam Mallory a écrit:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3FB9D7A4.3090502@icbt.com> …
!!! That’s a bit incredible !!!
The main argument of QSSL is to say that QNX is multi-platforms but they
cannot talk together!
First I’m almost sure there isn’t any difficulty to swap the bytes to match
the endianness and secondly I’m sure that other
communication protocols from Unix allow to talk between x86 and PPC without
any adaptation to QNX particularity (Right
Armin? >
You can QNET to a different endian - using the resource manager framework
over top is what is not cross-endian. Byte swapping is easy; byte swapping
user specified data without any layout rules or specifications is not (since
you can’t know what bytes to swap). So it’s up to the user to byte swap
his/her own data as nessesary (just like TCP/IP).Also, if you could, please post in plain text.
-Adam
\
Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:
Ok, I understand what you mean
But about ls /net/PPC_target, I suppose that QSSL though about that
problem and choosed the byte order of the binary informations in its
resmgr. So, ls, pidin -n PPC_target, etc… should work
Could work, but doesn’t currently.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Hum,
We currently plan to design a new CPU board with a PPC processor for our
machine but the main machine’s computer runs with a Pentium. So that
cause a problem.
Will cross endian be supported soon?
Does it exist a planning ?
Alain.
Chris McKillop a écrit:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
Ok, I understand what you mean
But about ls /net/PPC_target, I suppose that QSSL though about that
problem and choosed the byte order of the binary informations in its
resmgr. So, ls, pidin -n PPC_target, etc… should work
Could work, but doesn’t currently.chris
Can I ask what kind of IPC you are planing between this new PPC and
the Pentium? Your private message between your own client/server?
Some server based on QSSL resource manage library? Or you PPC cpu
board only need files from Pentium ?
-xtang
Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote in message
news:3FC34AEC.9060208@icbt.com…
Hum,
We currently plan to design a new CPU board with a PPC processor for our
machine but the main machine’s computer runs with a Pentium. So that cause a
problem.
Will cross endian be supported soon?
Does it exist a planning ?
Alain.
Chris McKillop a écrit:
Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:
Ok, I understand what you mean
But about ls /net/PPC_target, I suppose that QSSL though about that
problem and choosed the byte order of the binary informations in its
resmgr. So, ls, pidin -n PPC_target, etc… should work
Could work, but doesn’t currently.
chris
All,
About message passing between our servers and our clients is not a
problem. We will rewrite what is necessary to take care about cross
endian cpus.
But our main computers are x86 based cpu so, I’ d like to talk to PPC
cpus from x86 without problems. I want to ‘ls’, ‘pidin -n’, ‘cat’, etc…
bigger problem maybe, Is it possible to use ddd with gdb running on x86
a pdebug running on ppc to degug a ppc program?
PPC boards may bootp to load a PPC OS located on x86 board.
Is there any problem for that?
Alain.
Xiaodan Tang a écrit:
Can I ask what kind of IPC you are planing between this new PPC and
the Pentium? Your private message between your own client/server?
Some server based on QSSL resource manage library? Or you PPC cpu
board only need files from Pentium ?-xtang
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3FC34AEC.9060208@icbt.com> …
Hum,
We currently plan to design a new CPU board with a PPC processor for our
machine but the main machine’s computer runs with a Pentium. So that cause a
problem.
Will cross endian be supported soon?
Does it exist a planning ?
Alain.Chris McKillop a écrit:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
Ok, I understand what you mean
But about ls /net/PPC_target, I suppose that QSSL though about that
problem and choosed the byte order of the binary informations in its
resmgr. So, ls, pidin -n PPC_target, etc… should work
Could work, but doesn’t currently.chris
\
Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote in message
news:3FC71526.7010305@icbt.com…
All,
About message passing between our servers and our clients is not a
problem. We will rewrite what is necessary to take care about cross
endian cpus.
OK.
But our main computers are x86 based cpu so, I’ d like to talk to PPC
cpus from x86 without problems. I want to ‘ls’, ‘pidin -n’, ‘cat’, etc…
Using nfs over tcpip would give you access to the remote file system.
and, it gives you better performance cause it have a better idea
of the concept of “a file”.
‘pidin -n’, do you really need to do that on a product system? If you are
talking development, QNX IDE gives your all access from Host to a
Target.
bigger problem maybe, Is it possible to use ddd with gdb running on x86
a pdebug running on ppc to degug a ppc program?
I know gdb/pdebug over tcpip works fine. So I believe ddd should also do.
PPC boards may bootp to load a PPC OS located on x86 board.
Is there any problem for that?
Shouldn’t be any problem. This is just a standard tcpip senario.
-xtang
Alain.
Xiaodan Tang a écrit:
Can I ask what kind of IPC you are planing between this new PPC and
the Pentium? Your private message between your own client/server?
Some server based on QSSL resource manage library? Or you PPC cpu
board only need files from Pentium ?-xtang
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3FC34AEC.9060208@icbt.com> …
Hum,
We currently plan to design a new CPU board with a PPC processor for our
machine but the main machine’s computer runs with a Pentium. So that
cause a
problem.
Will cross endian be supported soon?
Does it exist a planning ?
Alain.Chris McKillop a écrit:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
Ok, I understand what you mean
But about ls /net/PPC_target, I suppose that QSSL though about that
problem and choosed the byte order of the binary informations in its
resmgr. So, ls, pidin -n PPC_target, etc… should work
Could work, but doesn’t currently.chris
\
“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:bq7p9s$i7r$1@nntp.qnx.com…
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3FC71526.7010305@icbt.com> …
All,
About message passing between our servers and our clients is not a
problem. We will rewrite what is necessary to take care about cross
endian cpus.OK.
But our main computers are x86 based cpu so, I’ d like to talk to PPC
cpus from x86 without problems. I want to ‘ls’, ‘pidin -n’, ‘cat’,
etc…Using nfs over tcpip would give you access to the remote file system.
and, it gives you better performance cause it have a better idea
of the concept of “a file”.
Our experience with nfs has been the most frustrating so far. If someone
runs nfsd long enough then nfsd’s ideas about “better performance” becomes
somewhat an obstacle. An attempt to replace an exported file (on the server
side) with a newer version succeeds (why it wouldn’t) but on the client side
you will still see/read the old version. It looks like nfsd stops updating
cache at some point and it takes a day or so to get to that point. The
behavior persists in both 6.1 and 6.2.x and on variety of PC’s. Restart of
nfsd helps in such case, - that is disturbing but manageable in development
environment, - but I do not think it is an acceptable technique for a
production quality system.
‘pidin -n’, do you really need to do that on a product system? If you are
talking development, QNX IDE gives your all access from Host to a
Target.bigger problem maybe, Is it possible to use ddd with gdb running on x86
a pdebug running on ppc to degug a ppc program?I know gdb/pdebug over tcpip works fine. So I believe ddd should also do.
PPC boards may bootp to load a PPC OS located on x86 board.
Is there any problem for that?Shouldn’t be any problem. This is just a standard tcpip senario.
-xtang
Alain.Xiaodan Tang a écrit:
Can I ask what kind of IPC you are planing between this new PPC and
the Pentium? Your private message between your own client/server?
Some server based on QSSL resource manage library? Or you PPC cpu
board only need files from Pentium ?-xtang
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3FC34AEC.9060208@icbt.com> …
Hum,
We currently plan to design a new CPU board with a PPC processor for
our
machine but the main machine’s computer runs with a Pentium. So that
cause a
problem.
Will cross endian be supported soon?
Does it exist a planning ?
Alain.Chris McKillop a écrit:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
Ok, I understand what you mean
But about ls /net/PPC_target, I suppose that QSSL though about that
problem and choosed the byte order of the binary informations in its
resmgr. So, ls, pidin -n PPC_target, etc… should work
Could work, but doesn’t currently.chris
\
Xiaodan Tang a écrit:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3FC71526.7010305@icbt.com> …
All,
About message passing between our servers and our clients is not a
problem. We will rewrite what is necessary to take care about cross
endian cpus.
OK.
But our main computers are x86 based cpu so, I’ d like to talk to PPC
cpus from x86 without problems. I want to ‘ls’, ‘pidin -n’, ‘cat’, etc…
Using nfs over tcpip would give you access to the remote file system.
and, it gives you better performance cause it have a better idea
of the concept of “a file”.
I’ve experienced some not cool behaviors of nfs in 6.0 or 6.1 I don’t
remember exactly but I’m not satisfied to have to add it just for ls or
cat, what should be done through QNET.
‘pidin -n’, do you really need to do that on a product system? If you are
talking development, QNX IDE gives your all access from Host to a
Target.
Of course! I suppose I will have to see what is running even on a
product system, in case of problem. So, I can telnet, phditto, etc…,
but it would not very cool if ‘pidin -n’ didn’t work because of a cross
endian problem you can in account.
I’ve discussed about IDE already. We choosed QNX, between other reasons,
because it was praised to us to be really cheaper than VxWorks, pSos,
WinCE.
When we choosed QNX, we told about the lacks of IDE and QNX peoples
answered that one of the QNX’s benefit is that we don’t need and IDE.
Everything can be done very simply from the shell and the supplied
tools. It was before the QNX6 release…(the QED age! 
)
bigger problem maybe, Is it possible to use ddd with gdb running on x86
a pdebug running on ppc to degug a ppc program?
I know gdb/pdebug over tcpip works fine. So I believe ddd should also do.
PPC boards may bootp to load a PPC OS located on x86 board.
Is there any problem for that?
Shouldn’t be any problem. This is just a standard tcpip senario.-xtang
Alain.Xiaodan Tang a écrit:
Can I ask what kind of IPC you are planing between this new PPC and
the Pentium? Your private message between your own client/server?
Some server based on QSSL resource manage library? Or you PPC cpu
board only need files from Pentium ?-xtang
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3FC34AEC.9060208@icbt.com> …
Hum,
We currently plan to design a new CPU board with a PPC processor for our
machine but the main machine’s computer runs with a Pentium. So that
cause a
problem.
Will cross endian be supported soon?
Does it exist a planning ?
Alain.Chris McKillop a écrit:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
Ok, I understand what you mean
But about ls /net/PPC_target, I suppose that QSSL though about that
problem and choosed the byte order of the binary informations in its
resmgr. So, ls, pidin -n PPC_target, etc… should work
Could work, but doesn’t currently.chris
Thanks,
Alain.