RFC: QNX4 vs. QNX6

Well, I have to say, that is most excellent. Perhaps at some point in time
we can work together to implement the appropriate posix interface to your
stuff and then we wouldn’t need the utmp/wtmp files at all. I’ll definitely
put this on my roadmap request list.

cheers,

Kris

<camz@passageway.com> wrote in message news:aelehd$evr$1@inn.qnx.com

Kris Warkentin <> kewarken@qnx.com> > wrote:
is obtained, only the interface. So it might be possible to do it
without
the actual files as long as the interface is implemented.

Ah, you know, I had not thought of that, smells like a resmgr > :slight_smile:

The question I would have is whether your method can deliver all the
information required such as tty, login time, etc.

Of course it can! That was some of the most difficult information to get,
but it is in there now. I’m still struggling with obtaining the IP
address
that you connected from for an ssh connection, but I hope to have that one
resolved soon.

Cheers,
Camz.

Kris Warkentin <kewarken@qnx.com> wrote:

You prefer CASD to CAD?

CASD

Cheers,
Camz.

We will still be supporting the normal gdb/pdebug combination. In fact,
this should improve as we move towards getting our ports into the GNU head
branch. You should, in the future, be able to download the latest gdb
snapshot and compile it for the host/target of your choice. Don’t forget,
Eclipse is just having a conversation with gdb so for it to work properly,
it’s in our best interest to make sure we’re using the latest and greatest.

cheers,

Kris

“Thomas” <NtOoSmP_AsMt@swbell.net> wrote in message
news:aelfub$evo$1@inn.qnx.com

Kris Warkentin <> kewarken@qnx.com> > wrote:
Noted. See my earlier reply to Paul Smith. I hope that the Eclipse
debugger will help you too. I find it a great improvement over plain
old
gdb.


Problem is, what about all of use who work for employers who [can|won]'t
pay
for PE, or for people using NC at home?

regards,
Tom

Kris Warkentin <kewarken@qnx.com> wrote:

The other question would be, do you want it to work from the console only or
from photon as well? I’m just thinking Linux/X11 where you actually have to
be at the console for that to work.

Same as in QNX4, and QNX2 before that. From the console, regardless of whether
the console is in text or graphics mode.

Cheers,
Camz.

That’s funny but when you put it that way Bill, CASD really resolves to so
much syntactic sugar doesn’t it?

#!/bin/sh

sdf utility

op shutdown -f

:wink:

Kris

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

“Paul D. Smith” <> pausmith@nortelnetworks.com> > wrote in message
news:> p5u1o1eprh.fsf@lemming.engeast.baynetworks.com> …
I don’t want it to work at ALL! I certainly don’t want my customers
to be able to bring down the system simply by hitting some key chord,
whether they’re logged into the console or not.

Maybe I’m misunderstanding how you intend this to be installed.


In QNX4 it could be disabled. If you add the CASD then you should add the
ability to disable it too. I’d like to see both.

For the record I has added a utility I call ‘sdf’ (shutdown -f) that looks
at what is running, including my app and shuts down everything a quickly
and
gracefully as possible. It’s also very easy to type, just roll your
finger
on the keyboard. But it will only work for root.

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

I don’t want it to work at ALL! I certainly don’t want my customers
to be able to bring down the system simply by hitting some key chord,
whether they’re logged into the console or not.

Maybe I’m misunderstanding how you intend this to be installed.

Very simple. This is how it worked in QNX4. The CASD keychord would send
a shutdown message to proc (identical to running the shutdown command).
If you did not want a user to do this, then you used the stty command on
/dev/con1 to disable it. There were several things that could be disabled
including console switching (text console only).

ie. stty +noboot </dev/con1

That would disable it completely.

ps. the system that enterprise networks Calgary used for their shopfloor
automation and labeling system was running QNX4.25 and used this to
prevent shopfloor users from rebooting the nodes.

Cheers,
Camz.

Let me play Devil’s advocate some more.

A) You don’t need a full graphical photon running on your client to get
phditto. This I have on authority from Gord Bell himself who phdittos from
his qnx6 box to a qnx4 box in a closet which doesn’t even have a keyboard.

B) If you have QNET running, you have all the plumbing in place for tcp/ip.
Is it that hard to give your box an IP?

C) If you’re relying on the system console for error logs, don’t you think
you should be rethinking things a bit and using an actual log?

Kris

“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:aeldpa$ks3$1@nntp.qnx.com

Jim Douglas <> jim@dramatec.co.uk> > wrote:

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ael825$h4u$> 1@nntp.qnx.com> …
I’ve seen a number of requests for ditto and I was wondering if there
was
a
really compelling reason why we would still need this. We’ve got
phditto
which seems to be quite a bit more powerful. We’ve got telnet which is
relatively secure and portable. I know it was something that people
liked
once upon a time but I’m wondering if perhaps this is a bit of
nostalgia
as
opposed to an actual need.

Nostalgia! doh - join the real world8-) We are talking simplicity and
ease
of use…

  1. It can work without Photon so it can give you a command line
    interface on
    to your target while you fight to get Photon up and running.
  2. The assumption is that it will work over QNet without having to
    struggle
    with the intricacies of TCP/IP.

It is also VERY important to telnet into a remote node, ditto to it’s
console to see what system error dumped there.

-xtang

Noted and added.

Kris

“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:aele97$ks3$3@nntp.qnx.com

Kris Warkentin <> kewarken@qnx.com> > wrote:
Attention QNX users.

I am compiling a wish-list for utilities development over the next 6
months
to a year. I’m mostly looking for things that existed in QNX4 but don’t
in
QNX6 but I’m also taking general utils feature requests.

So, if there are any utilities you wish you had or enhanced
functionality to
existing utilities, now is the time to let me know so I can try to get
them
on the road map.

Oh, and nobody want “sin vc” ?

I really like to know who the hack it is, when my harddisk suddenly
keeps on busy while I was just stare at my screen > :slight_smile:

-xtang

Kris Warkentin <kewarken@qnx.com> wrote:

That’s funny but when you put it that way Bill, CASD really resolves to so
much syntactic sugar doesn’t it?

#!/bin/sh

sdf utility

op shutdown -f

NO!

Actually, that will not always work. I have had situation where the file
systems have died (see the PR’s related to ls -l on a DVD drive in 6.1).
If you loose your filesystems (for whatever reason), then this will NOT
work since it must load TWO utilities from disk (sh and shutdown). This
is also an annoyance in photon currently where loss of filesystems prevents
the use of the shutdown menu entry there as well.

If you look at the source to shutdown you will see that it sends a message to
proc which then sets SIGPWR on all running processes. The process that will
provide CASD functionality would need to generate the same message.

IMHO, the pwm in photon needs ot be changed to do this as well.

Cheers,
Camz.

Kris Warkentin <kewarken@qnx.com> wrote:

I’ve seen a number of requests for ditto and I was wondering if there was a
really compelling reason why we would still need this.

Yes, we still need it.

We’ve got phditto which seems to be quite a bit more powerful.

It’s incorrect to say phditto is more powerful, it is not. It merely
provides the same “ditto” functionality in the graphica photon environment.
That makes it complimentory to ditto, not a replacement.

We’ve got telnet which is relatively secure and portable.

Telnet isn’t secure at all, it is nothing more than a transport mechanism.
If you happen to have a telnetd or inetd running to receive a connection
then it just runs the normal login command. Telnet is NOT the same as
ditto.

I know it was something that people liked once upon a time but I’m
wondering if perhaps this is a bit of nostalgia as opposed to an actual
need.

The need is real. The use is for supporting a machine that is remote to
your location, as opposed to merely connecting to a remote machine. There
are some things that should be done on the console, not a pty. You need
to remember that when you disconnect from a remote connection (serial or
dialup, or telnet, or ssh) they typically generate a SIGHUP on all children
that you have created, this is not good if you need to connect to a remote
server and restart a service that needs to stay running.

As xtang pointed out, often times you need to run ditto to see the output
of an error message that appears only on the console.

You’ve obviously never been in the position of supporting a system from
remote or you would never be asking this question.

Cheers,
Camz.

Xiaodan Tang wrote:

Armin Steinhoff <a-steinhoff@web_.de> wrote:

Kris Warkentin wrote:

Attention QNX users.

I am compiling a wish-list for utilities development over the next 6 months
to a year. I’m mostly looking for things that existed in QNX4 but don’t in
QNX6 but I’m also taking general utils feature requests.

So, if there are any utilities you wish you had or enhanced functionality to
existing utilities, now is the time to let me know so I can try to get them
on the road map.

Implement a distributed file system for PVM or MPI/RT (still to
implement)

I’ve done MPICH a long time ago (on QNX4)

MPICH is not real-time capable … so it is not comparable with MPI/RT.
MPI/RT is a new standard for real-time clusters.

. What I am more interested in is a QNET based, “made by QNX”, distributed > system.

I would go with a middleware STANDARD and not with this uncomplete aria
called QNET.

(With things
like remote spawn, remote fork, job scheduling …)

It’s covered by the MPI/RT standard.

Cheers

Armin

Xiaodan Tang <xtang@qnx.com> wrote:

Oh, and nobody want “sin vc” ?

Oh yeah. We kinda covered that. I think we said “duplicate ALL the
functionality of sin from QNX4”

Cheers,
Camz.

Kris Warkentin <kewarken@qnx.com> wrote:

Okay, okay…don’t panic. > :wink: > I’ll put it on my list. You know, my list
is getting really big…if management approves half of these projects I’m
going to be really busy.

Think of it as job security :slight_smile:

Okay, okay…don’t panic. :wink: I’ll put it on my list. You know, my list
is getting really big…if management approves half of these projects I’m
going to be really busy.

Kris

<camz@passageway.com> wrote in message news:aelk0k$i9p$4@inn.qnx.com

Kris Warkentin <> kewarken@qnx.com> > wrote:
That’s funny but when you put it that way Bill, CASD really resolves to
so
much syntactic sugar doesn’t it?

#!/bin/sh

sdf utility

op shutdown -f

NO!

Actually, that will not always work. I have had situation where the file
systems have died (see the PR’s related to ls -l on a DVD drive in 6.1).
If you loose your filesystems (for whatever reason), then this will NOT
work since it must load TWO utilities from disk (sh and shutdown). This
is also an annoyance in photon currently where loss of filesystems
prevents
the use of the shutdown menu entry there as well.

If you look at the source to shutdown you will see that it sends a message
to
proc which then sets SIGPWR on all running processes. The process that
will
provide CASD functionality would need to generate the same message.

IMHO, the pwm in photon needs ot be changed to do this as well.

Cheers,
Camz.

Kris Warkentin <kewarken@qnx.com> wrote:

Let me play Devil’s advocate some more.

Sure, but you DO know that you are up against people that have been using
ditto on QNX4 for years, supporting REAL production envirionments.

A) You don’t need a full graphical photon running on your client to get
phditto. This I have on authority from Gord Bell himself who phdittos from
his qnx6 box to a qnx4 box in a closet which doesn’t even have a keyboard.

No, you don’t. I use this all the time too, that is one area where phditto
has more functionality that plain old ditto. phditto will create a new session
OR connect to an existing one. ditto can only connect to existing consoles.
You keep forgetting that phditto and ditto do not provide the SAME functions
they provide COMPLIMENTARY functions. If you can see the merit/benefit of
having phditto available for connecting to the grpahical console of a QNX
Photon box, then you should be able to see the advantage of being able to
connect to the text console as well.

Hell, I have made embedded systems in QNX4 with no video hardware, that used
phindows/phrelay as the primary interface, 100% graphical.

So, please… get this through your head.

DITTO != PHDITTO


B) If you have QNET running, you have all the plumbing in place for tcp/ip.
Is it that hard to give your box an IP?

Actually, ditto on qnx4 was able to use FLEET, aka QNET in qnx6. ditto would
be able to connect to the console of any machine in a QNET network, without
the need for TCP/IP at all. FLEET could actually run over non-TCP/IP networks
too.

C) If you’re relying on the system console for error logs, don’t you think
you should be rethinking things a bit and using an actual log?

You often do not have control over all the apps/utils running on your
system. More often than not, it is a 3rd party app, or even a QSSL app or
driver that spits out the message. As an example, if a process SEGVs that
was started from rc.local, the SEGV error message will go to /dev/con1
(okay, actually… /dev/text). If dumper is not running (quite possible
for an embedded device in a production envirionment) then getting this info
from the console is the ONLY way to get the info.

So, you are correct, programs should log their error messages to syslog or
tracelogger, or something to that effect. A properly designed one should.
Not all do.

Go through the QSSL ones, and I doubt you will find that all of them dump
all their error messages to a log utility in addition to printing them out
to stdout or stderr or /dev/text. Reminds me of something I heard about
people that live in glass houses…

Cheers,
Camz.

Kris Warkentin <kewarken@qnx.com> wrote:

Okay, okay…don’t panic. > :wink: > I’ll put it on my list. You know, my list
is getting really big…if management approves half of these projects I’m
going to be really busy.

Actually, I think everyone that has contributed to this list would like to
know which ones they approve and which they do not. The list shouldn’t be
exclusively your to do list either, I’m sure there is enough (or will be) for
a couple developers @ QSSL to be busy for a while.

If management rejects ANY of the requests, this group will want to know.

Cheers,
Camz

Armin Steinhoff <a-steinhoff@web_.de> wrote:

Xiaodan Tang wrote:

. What I am more interested in is a QNET based, “made by QNX”, distributed
system.

I would go with a middleware STANDARD and not with this uncomplete aria
called QNET.

Nah, you probably didn’t realized the power of message-passing
system.

(With things
like remote spawn, remote fork, job scheduling …)

It’s covered by the MPI/RT standard.

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.

-xtang

Xiaodan Tang <xtang@qnx.com> wrote:

Armin Steinhoff <a-steinhoff@web_.de> wrote:

Xiaodan Tang wrote:

. What I am more interested in is a QNET based, “made by QNX”, distributed
system.

I would go with a middleware STANDARD and not with this uncomplete aria
called QNET.

Nah, you probably didn’t realized the power of message-passing
system.

I implemented a “distributed batch queue” system under QNX 4 that allowed
you to effectively “cluster” your compute nodes together, and submit jobs
to the “batch queue”. The first available CPU would then go and execute
the next job off the batch queue. For VAX/VMS fans, think “submit” :slight_smile:

(With things
like remote spawn, remote fork, job scheduling …)

It’s covered by the MPI/RT standard.

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:

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.

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

I don’t want it to work at ALL! I certainly don’t want my customers
to be able to bring down the system simply by hitting some key chord,
whether they’re logged into the console or not.

Maybe I’m misunderstanding how you intend this to be installed.

It would only be installed via devc-con (normally), and even then, it should
be able to be disabled with ease from the command line (or, perhaps, enabled).
It is a very PC sort of thing.

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

<camz@passageway.com> wrote in message news:aellrr$k19$2@inn.qnx.com

Kris Warkentin <> kewarken@qnx.com> > wrote:
Okay, okay…don’t panic. > :wink: > I’ll put it on my list. You know, my
list
is getting really big…if management approves half of these projects
I’m
going to be really busy.

Actually, I think everyone that has contributed to this list would like to
know which ones they approve and which they do not.

No I don’t :wink:

The list shouldn’t be
exclusively your to do list either, I’m sure there is enough (or will be)
for
a couple developers @ QSSL to be busy for a while.

If management rejects ANY of the requests, this group will want to know.

No I don’t :wink:

Cheers,
Camz