Xiaodan Tang wrote:
Tom Evans <> tom@nospam.invalid> > wrote:
thomasf@qnx.com > wrote:
[snip]
And the answer is - all user data in messages MUST
ALWAYS be in the SAME ORDER. Preferably in standard
“network order” which is unfortunately the opposite
of what Intel came up with in the 8080 all those
years ago.
Network programmers have had to deal with this
ever since the early 80’s (and all network
programming in QNX has to as well), so why
should using messages with Neutrino be any
different? Except, I guess, for the all the
existing code that was written under the
assumption that QNX only ran on X86s.
You didn’t really get it, do you?
I think I did and do. I can’t think of a
SIMPLE solution. I was hoping you knew of one.
Suppose a user application defined:
struct {
int a;
short b;
short c;
} mydata;
And then did:
MsgSend(void, &mydata, sizeof(mydata), 0, 0);
Who do you think should do all the “htonl()”, “htons()”
operation?
Of cause it won’t be kernel or QNET or library, cause
neither of them have knowledge of “mydata”.
The only person could do that is the application itself.
So it have to do (stuff) like:
mydata.a = htonl(mydata.a);
mydata.b = htons(mydata.b);
mydata.c = htons(mydata.c);
MsgSend(coid, &mydata, sizeof(mydata), 0, 0);
You seem to be agreeing with me. And so the problem
with this is…?
OK, this will work, but, what if the server he’s talking
to is on same node? There is totaly time waste to convert
them before send, and the server have to convert it back
after receive.
So? Traditional network programming (which often runs to
a server on the same host) has been doing the above since
the early 80’s. Of course on the “right” CPUs there is no
overhead of inserting the “ntohx()” MACROs at all. The x86
isn’t the “right” CPU, but it is 99.99% of QNX, right?
QNX programmers haven’t had to do any “network aware
programming”, haven’t done this and so it isn’t realistic
or even possible to require all QNX code to change, just
to support embedded PPCs.
Can’t happen. Won’t happen. That’s a more powerful
“reason” than some minor inefficiency in execution times.
Oh, yeah, then only do the hton[ls] if application is send
over network. Sorry, the design base of QNET is the application
WILL NOT aware of networking, so “cat local” or
“cat /net/remote/file” will work the same way. You don’t
really want a “cat” and a “netcat” do you?
No. I’d just like it to work somehow. It doesn’t at the moment.
Does QSSL have ANY proposed solution to the above, or are
the PPC and all other big-endian CPUs going to be permanent
“poor cousins” in the QNX World?
If a PPC can’t receive ANY messages from a USER
Application running on an x86 then what’s the point
of QNX Messages and what’s the current use of
running QNX on a PPC? Better to pick ARM-LE,
MIPS-LE or SH-LE if possible.
Is this true? That there’s no way to send ANY
QNX messages between QNX x86s and PPCs?
I can only think of three solutions:
-
All user code has to htonx() EVERYTHING, including
all opens, reads, writes, ioctls - UNACCEPTABLE.
-
All user code has to “register” all its network
data structures with the OS in an XDR-style
representation so the OS can convert when required.
Wouldn’t that be fun?
-
Don’t run QNX on big-endian CPUs.
Here’s a small proposal that would get SOME functionality.
Could QSSL write a small driver that registers as (say)
“/dev/fs_4_ppc” which performs the endian conversions
for the common file operations to support fs-qnx4,
fs-dos and fs-pkg ONLY, so that from a PPC I can read
files in /net/pc/home/tevans" as
“/net/pc/dev/fs_4_ppc/home/tevans”?
Tom Evans
InitialSurnameAt
tennyson.com.au