RFC: QNX4 vs. QNX6

Paul D. Smith <pausmith@nortelnetworks.com> wrote:
[snip]

Call me crazy but my company is not in the business of writing
compilers. Neither is QSSL.

BNR Pascal? Protel? Protel 2?

Sorry, couldn’t resist :slight_smile:

Cheers,
-RK

Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

%% nospam88@parse.com (Robert Krten) writes:

rk> Paul D. Smith <pausmith@nortelnetworks.com> wrote:

Call me crazy but my company is not in the business of writing
compilers. Neither is QSSL.

rk> BNR Pascal? Protel? Protel 2?

rk> Sorry, couldn’t resist :slight_smile:

Heh. That was a long time ago, and before I got here (I came in through
the side door: Wellfleet->Bay Networks->Nortel).

Actually, we do write “compilers” but they’re really just
meta-language translators, simple yacc/pccts/xml/whatever converters.

Paul D. Smith <pausmith@nortelnetworks.com> HASMAT–HA Software Mthds & Tools
“Please remain calm…I may be mad, but I am a professional.” --Mad Scientist

These are my opinions—Nortel Networks takes no responsibility for them.

“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:aeu2bg$441$1@inn.qnx.com

Didn’t Watcom get their start writing compilers for mainframes?

They did do some compilers for mainframes

Or did someone just make that up about a decade or so ago?

Not made up. See the link I posted. It refers to myself. The author is one
of the 3 original founders of Watcom. I doubt whether he is wrong :slight_smile:

Stephen Howe [TeamSybase]

Robert Krten <nospam88@parse.com> wrote:

It is? Last I read MPI 2.0, it only defining basic message passing.
And “remote fork” is very difficult (even on QNX6 system), and
I really doubt you can do that on triditional system.

Why is remote fork difficult under QNX 6? It certainly wasn’t difficult
under QNX 4 > :slight_smile:

remote fork() was not possible under QNX4. Does impossible qualify
as “not difficult”?

QNX4 allowed reomte spawn(), that is remote load & run a new program,
but not remote fork(), that is, make a remote copy of the currently running
process.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

David Gibbs <dagibbs@qnx.com> wrote:

Robert Krten <> nospam88@parse.com> > wrote:

It is? Last I read MPI 2.0, it only defining basic message passing.
And “remote fork” is very difficult (even on QNX6 system), and
I really doubt you can do that on triditional system.

Why is remote fork difficult under QNX 6? It certainly wasn’t difficult
under QNX 4 > :slight_smile:

remote fork() was not possible under QNX4. Does impossible qualify
as “not difficult”?

Fork, shmork. I “read” spawn, not fork :slight_smile:

QNX4 allowed reomte spawn(), that is remote load & run a new program,
but not remote fork(), that is, make a remote copy of the currently running
process.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.


Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

I remember reading about some work being done on process migration for
agents (I think they were using a customized version of Linux). The idea
being to somehow bundle up a running application and it’s resources to
migrate it to a different machine where it could resume execution. Sounds
like it’s hellishly difficult to do properly and even when it is
implemented, there are a whole passel of restrictions on things like open
file descriptors, etc. You need a lot of OS support to get everything set
up properly on the other end. I think it might be easier to do in a virtual
machine though.

cheers,

Kris

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:afabo6$iq3$3@nntp.qnx.com

Robert Krten <> nospam88@parse.com> > wrote:

It is? Last I read MPI 2.0, it only defining basic message passing.
And “remote fork” is very difficult (even on QNX6 system), and
I really doubt you can do that on triditional system.

Why is remote fork difficult under QNX 6? It certainly wasn’t difficult
under QNX 4 > :slight_smile:

remote fork() was not possible under QNX4. Does impossible qualify
as “not difficult”?

QNX4 allowed reomte spawn(), that is remote load & run a new program,
but not remote fork(), that is, make a remote copy of the currently
running
process.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Kris Warkentin <kewarken@qnx.com> wrote:

I remember reading about some work being done on process migration for
agents (I think they were using a customized version of Linux). The idea
being to somehow bundle up a running application and it’s resources to
migrate it to a different machine where it could resume execution. Sounds
like it’s hellishly difficult to do properly and even when it is
implemented, there are a whole passel of restrictions on things like open
file descriptors, etc. You need a lot of OS support to get everything set
up properly on the other end. I think it might be easier to do in a virtual
machine though.

dup() an fd cross network is possiable, as chroot() an application
to orignal node. (That’s how remote spawn() working).

I think things like signal mask, and memory map need procnto
support. And we probably have to limit to no shared object, and
of cause, no interrupt handler.

What will be “easier” now, is use HAT. So that at least a process
could be restart at another node from a pre-defined “check point”.

The possiablity to “relocate” a live process, could use do support
the resource managment (use CPU on less heavier machine) and/or
performance enhancement. (If a process keeps on accessing a remote
resource, move it to that node should speeds it up).

-xtang


cheers,

Kris

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:afabo6$iq3$> 3@nntp.qnx.com> …
Robert Krten <> nospam88@parse.com> > wrote:

It is? Last I read MPI 2.0, it only defining basic message passing.
And “remote fork” is very difficult (even on QNX6 system), and
I really doubt you can do that on triditional system.

Why is remote fork difficult under QNX 6? It certainly wasn’t difficult
under QNX 4 > :slight_smile:

remote fork() was not possible under QNX4. Does impossible qualify
as “not difficult”?

QNX4 allowed reomte spawn(), that is remote load & run a new program,
but not remote fork(), that is, make a remote copy of the currently
running
process.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Robert Krten <nospam88@parse.com> wrote:

Paul D. Smith <> pausmith@nortelnetworks.com> > wrote:
[snip]

Call me crazy but my company is not in the business of writing
compilers. Neither is QSSL.



BNR Pascal? Protel? Protel 2?

Change his “not” to “no longer”, and the sentence is accurate,
both for Nortelnetworks, AND for QSSL. (Rob, you should have
been around long enough to remember the Quantum compiler for
QNX2. QSSL was in the business of writing compilers at one
point. :slight_smile:

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

camz@passageway.com wrote:

Kris Warkentin <> kewarken@qnx.com> > wrote:

A typical support scenario is this:

[Phone Rings, 3:00AM]

[Tech fires up ditto -Vkn17 to connect to the node’s console]

[Hangs up]
[Tech goes back to sleep]

As you can see QNET / FLEET isn’t involved.

Well, -n17 does involve FLEET. ditto had to be moderately
network aware, at the minimal level most QNX apps should
have been (proper use of proxies, qnx_vc_rem_attach()).

But I get your point – ditto doesn’t have to be transport
aware, and the equivalent could be done with QNET.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

phearbear <phearbear@home.se> wrote:

I have never used QNX4, and therefor never ditto. But after reading this
discussion, it seems that the ‘screen’ util (it is on the 3rd party
disc) Does basically the same thing. Any of you QNX4 people tried it?

I’ve used “screen” – it was really handy for having the equivalent
of multiple consoles & console applications from one terminal.
(I used it back in the late-80s pretty regularly.) It doesn’t
get you some of what ditto does, including multiple people controlling
the same terminal – but if one setup ones system so that everthing
was started on different screen sessions, and such that the screen
session was not associated with a terminal (I think you could do this)
but could be “re-attached” by a terminal, then it might get you a
good bit of what was wanted.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Adam Mallory <amallory@qnx.com> wrote:

Whoa - I never suggested anything of the sort. There is no end to the
number of people that ask for “function x” for pidin, just because sin did
it, regardless of it relevance in Neutrino. In addition, Xtang made a
“tongue in cheek” remard about ‘sin vc’ - so for the sake of others reading,
I just mentioned that some features where not relevant.

Actually, I didn’t think it was “tongue in cheek”. Obviously, the
literal meaning of “sin vc” could NOT make sense. But the metaphoric –
the ability to get a list of who has remote connections to your node,
and to which node(s) you have remote connections, and who/which processes
have them is quite useful.


Actually you can find out what IRQ’s are in use based on the events emitted;
further you could even find out which IRQ events are causing scheduling
events so another process to can run. Open files are the same idea (events
emitted from Proc) - if you prefer the way sin did it, that’s fine.

So, we ask for the functionality because it was useful to us, not simply
because “QNX4 had it”.

I was simply saying that if the same functionaly existed in different form,
I think we should concentrate on getting new and/or improved features
instead of duplicating what is already there.

Sure, you could do this with the instrumented kernel, by looking for
all those events…if that happens to be the best way to implement
“sin irq” or “pidin irq”, then doing it by filtering the system
event logs could do it. Part of the problem, though, is digestibility –
if I have to pull up a GUI log of all the system events, to get what
“sin irq” gave me in a quick, convenient format, that isn’t nearly
as helpful.

I think I commented on this way earlier – I gave a few of the
summary/info things from sin that I wanted to see. I didn’t
ask for “sin ldt”, “sin gdt” or “sin idt”, because I never
knew how to use them anyway, and I don’t think they have meaning
anymore either – they were x86 only, and I don’t think we
implement even our x86 vm in a way in which those would be
meaningful under QNX6.

My high-runner list happens to be: irq, rt, ve, fi
(A “sin fd” does seem to exist already, otherwise it would also
be on the list.)

Something not in sin, and which I don’t think there seems to be
anyway to list, but might be useful: some way to get a list of
channels in a process, along with the channel flags set on that
channel. (This somewhat parallels the “sin fl” of QNX4, in that
much of what used to be a process flag under QNX4 has become a
channel flag under QNX6. Of course, given the previous mention
of the idea that under QNX4 pid,pid = QNX6 pid,chid, this is not
entirely surprising.)

“sin na” becomes “ls /dev/name/local”
“sin gn” will become “ls /dev/name/global”
“sin net” becomes “ls /net” (kind of)

“sin pr” is a bit more interesting. The idea of a proxy is totally
lost under QNX6 – there is no real idea of an independent OS resource
like a proxies – pulses don’t have this create/destroy type of life
cycle. But, what was also really nice about “sin pr” was to see the
count of the proxy, that is, to see if a process was missing/not keeping
up with the incoming proxies. The ability to get a list/count of
queued pulses for a channel would be quite handy.

“sin root”, and “sin dir” I’ve never used. (gives prefix root,
and cwd, for each process.) Could be helpful, but probably not important.

“sin se” I’ve used occasionally – list of sessions, not high-runner,

“sin tree” is a pretty version of “sin fa” → pidin fa

My (highly inflated) 2 cents analysis of “everything sin does”.

Hm… having some of the stuff in sin, and some of it in pidin
under Neutrino is a bit annoying. (And, sin not putting column
headings on anything…)

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Thomas Emberson <temberson@softwareremodeling.com> wrote:

This reminds me, what uu[de|en]code?

disclaimer: I did not look when I was looking at a 6.2 Beta, and
now at work we are waiting for the real CDs. So if they are in 6.2
SE, please ignore.

uud/uue should be completely portable from any public copy of the
source, I’d expect them to compile & run with no changes. I can’t
see them using anything more complicate than open()/read()/write().

(Well, the might use fopen(), fread(), fwrite().)

And, they seem to be in /usr/bin/uud and /usr/bin/uue with 6.2

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

David Gibbs <dagibbs@qnx.com> wrote:

Robert Krten <> nospam88@parse.com> > wrote:
Paul D. Smith <> pausmith@nortelnetworks.com> > wrote:
[snip]

Call me crazy but my company is not in the business of writing
compilers. Neither is QSSL.



BNR Pascal? Protel? Protel 2?

Change his “not” to “no longer”, and the sentence is accurate,
both for Nortelnetworks, AND for QSSL. (Rob, you should have

You obviously missed the “couldn’t resist part”, indicating that
there was some slyness involved on my part :slight_smile:

been around long enough to remember the Quantum compiler for
QNX2. QSSL was in the business of writing compilers at one
point. > :slight_smile:

Yup; those were simpler times! :slight_smile:

Cheers,
-RK

Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

David Gibbs wrote:

My high-runner list happens to be: irq, rt, ve, fi
(A “sin fd” does seem to exist already, otherwise it would also
be on the list.)

I am addicted to “sin -P{socketserver} fd” to get a list of IP addresses
of clients. Does this currently exist in QNX6 ?

Something not in sin, and which I don’t think there seems to be
anyway to list, but might be useful: some way to get a list of
channels in a process, along with the channel flags set on that
channel. (This somewhat parallels the “sin fl” of QNX4, in that
much of what used to be a process flag under QNX4 has become a
channel flag under QNX6. Of course, given the previous mention
of the idea that under QNX4 pid,pid = QNX6 pid,chid, this is not
entirely surprising.)

“sin na” becomes “ls /dev/name/local”

Hmmm, no; I think “sin na” becomes (a currently non-existant facility) a
method by which to view what pid owns different portions of the
namespace (“ls /dev/name/local” simply shows you the names). QNX4 also
had “prefix” for this, but that was because QNX4’s 2 namespaces weren’t
integrated (QNX6 has “one true namespace”).

Under QNX4 “sin na” gave you the pid associated with a name, not just a
list of names.

Rennie

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:afathu$4g9$1@nntp.qnx.com

Hm… having some of the stuff in sin, and some of it in pidin
under Neutrino is a bit annoying. (And, sin not putting column
headings on anything…)

That’s why I’m putting in a proposal to clean up and unify our system
information utilities. My idea is to start a lib to contain all the ‘new’
features that have been mentioned here and then eventually move all the
other features from sin and pidin into it. Our answer to people who ask,
“How do I find out such and such piece of system info” is often, “Check the
code for pidin/sin out of cvs and see how they do it”. IMHO a much nicer
way would be to say, “Use libsysinfo”.

cheers,

Kris

Kris Warkentin <kewarken@qnx.com> wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:afathu$4g9$> 1@nntp.qnx.com> …
Hm… having some of the stuff in sin, and some of it in pidin
under Neutrino is a bit annoying. (And, sin not putting column
headings on anything…)

That’s why I’m putting in a proposal to clean up and unify our system
information utilities. My idea is to start a lib to contain all the ‘new’
features that have been mentioned here and then eventually move all the
other features from sin and pidin into it. Our answer to people who ask,
“How do I find out such and such piece of system info” is often, “Check the
code for pidin/sin out of cvs and see how they do it”. IMHO a much nicer
way would be to say, “Use libsysinfo”.

Works for me. Under QNX4, “how does sin do …” was very often,
qnx_osinfo() or qnx_psinfo().

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Hi Dave and more than likely the console developers:

Is that anything in the console driver that QSSL considers super
proprietary?

If not, why not just post the source to QNX4’s & QNX6’s console driver and
let people port over whatever features they need/want.

Or, does QSSL consider it necessary to keep the QNX6 console driver so light
weight?
I would have a hard time accepting that since A) people are encouraged to
use Photon and pterms and B) there is nothing else in QNX6 that is light
weight.

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:afaru9$33o$2@nntp.qnx.com

phearbear <> phearbear@home.se> > wrote:
I have never used QNX4, and therefor never ditto. But after reading this
discussion, it seems that the ‘screen’ util (it is on the 3rd party
disc) Does basically the same thing. Any of you QNX4 people tried it?

I’ve used “screen” – it was really handy for having the equivalent
of multiple consoles & console applications from one terminal.
(I used it back in the late-80s pretty regularly.) It doesn’t
get you some of what ditto does, including multiple people controlling
the same terminal – but if one setup ones system so that everthing
was started on different screen sessions, and such that the screen
session was not associated with a terminal (I think you could do this)
but could be “re-attached” by a terminal, then it might get you a
good bit of what was wanted.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:afathu$4g9$1@nntp.qnx.com

“sin pr” is a bit more interesting. The idea of a proxy is totally
lost under QNX6 – there is no real idea of an independent OS resource
like a proxies – pulses don’t have this create/destroy type of life
cycle. But, what was also really nice about “sin pr” was to see the
count of the proxy, that is, to see if a process was missing/not keeping
up with the incoming proxies. The ability to get a list/count of
queued pulses for a channel would be quite handy.

A count of all outstanding messages could also be interesting to show when a

process isn’t keeping up or why it isn’t responding to my lower priority
process.

“sin root”, and “sin dir” I’ve never used. (gives prefix root,
and cwd, for each process.) Could be helpful, but probably not important.

Hey, that’s cool. I never knew they existed.

“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:afd1ce$hrk$1@inn.qnx.com

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:afathu$4g9$> 1@nntp.qnx.com> …

“sin pr” is a bit more interesting. The idea of a proxy is totally
lost under QNX6 – there is no real idea of an independent OS resource
like a proxies – pulses don’t have this create/destroy type of life
cycle. But, what was also really nice about “sin pr” was to see the
count of the proxy, that is, to see if a process was missing/not keeping
up with the incoming proxies. The ability to get a list/count of
queued pulses for a channel would be quite handy.

A count of all outstanding messages could also be interesting to show when
a
process isn’t keeping up or why it isn’t responding to my lower priority
process.

Outstanding messages? Maybe I’m missing something but that’s
already available. Just check how may process/thread are SEND
block on a perticular destination. Messages are not queued per se.

“sin root”, and “sin dir” I’ve never used. (gives prefix root,
and cwd, for each process.) Could be helpful, but probably not
important.

Hey, that’s cool. I never knew they existed.

Mario Charest postmaster@127.0.0.1 wrote:

“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:afd1ce$hrk$> 1@inn.qnx.com> …

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:afathu$4g9$> 1@nntp.qnx.com> …

“sin pr” is a bit more interesting. The idea of a proxy is totally
lost under QNX6 – there is no real idea of an independent OS resource
like a proxies – pulses don’t have this create/destroy type of life
cycle. But, what was also really nice about “sin pr” was to see the
count of the proxy, that is, to see if a process was missing/not keeping
up with the incoming proxies. The ability to get a list/count of
queued pulses for a channel would be quite handy.

A count of all outstanding messages could also be interesting to show when
a
process isn’t keeping up or why it isn’t responding to my lower priority
process.

Outstanding messages? Maybe I’m missing something but that’s
already available. Just check how may process/thread are SEND
block on a perticular destination. Messages are not queued per se.

That is somewhat a like to using the insturmented kernel to see what IRQ’s
are attached to. As well, don’t forget about pulses either, it would be
interesting to see a list of pulses/messages queued up on a channel.


regards,
Tom