RFC: QNX4 vs. QNX6

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
161

Hey camz,

I’m doing it. I’ve even created a c++ class to make the resmgr stuff a bit
easier to use, handling the specifics of names for dir inquiries etc.

Thanks for the offer though I appreciate your help. I’m not giving up on
it, just voicing my current thoughts and thinking etc. I’m still pluggin
away at it and I’m sure I’ll cross that line soon. I mean, if I can learn
to love M$ COM and COM+, then I’m sure I’ll learn to love this as well :wink:
(Look guys, don’t start a thread on COM/COM+ ok? (you can resist the
urge:) )

See ya,
Kevin

<camz@passageway.com> wrote in message news:aeosmo$4dg$1@inn.qnx.com…

Kevin Stallard <> kevin@ffflyingrobots.com> > wrote:
Device drivers are fine, ones that support streams (serial ports, etc),
but
using them as a server that provides some service, is requiring that I
twist
the meaning of read and write some…I’m still trying to get used to it.
(dev_ctrl() isn’t all that attractive of an option sometimes).

Kevin, I had this same concern when initially using QNX6 after coming from
the QNX4 world things seemed pretty simple with the whole skeleton like
this:

name_attach();
for(;:wink: {
pid = Receive(0, … );
switch() {
case:
case:
…
}
Reply( pid, … );
}

At first the QNX6 resmgr certainly looks like massive overkill, not to
mention that it doesn’t intuitively appear to even allow for the switch()
type of processing. In reality, there IS a way to do this, complete
with the entire switch()/case processing. There is another way too that
allows you to implement this without the switch()/case and using the
call-back method for each “case”. You can even mix both of these if you
like. Neither of these require that you try to use the read/write streams
at all, the default handlers take care of that for you, effectively making
them behave like /dev/null.

This actually makes the QNX6 model much more powerful for more or less
the same “price”. You can start off with the QNX4 “traditional” method
of using private messages, and transition to the resmgr method of using
devctl(), you can even support both simultaneously.

I will admit this was a BIG barrier for me. It was a huge mental leap
from the QNX4 S/R/R “simple” model to the (seemingly) more complex QNX6
resmgr model. I have to thank Chris McKillop for walking me gently
through the transition on IRC.

If you want some help in how to do the more traditional switch()/case
thing in QNX6, let me know and I can dig up my test code to help you
through it as well.

Cheers,
Camz.

162

Kris Warkentin <kewarken@qnx.com> wrote:

At the top level the problem is, “Getting access to a remote machines
console”.

As Mario pointed out, there is also an additional problem (closely related)
which is “Provide the ability to create a ‘virtual’ console on systems that
do not have a physical console”. This is where Dev.ditto came into play.
This is also applicable for the non-x86 systems. As I mentioned before
the concept of a console has been validated not just on x86 PCs, but also
with other virtual machines (like Java) that also have consoles.

Of course when you have a virtual console, you NEED something like ditto
to be able to see/use the console.

Questions that arise from that:

“Do you need write access or is read access sufficient?” Given that there
are other ways to execute processes on a remote machine, perhaps just being
able to read the console (especially if we were to cache a few pages) might
be enough.

Read access is a higher priority than write access. Both are useful.
I think someone else already mentioned that you can use the “on -t/dev/con1”
to provide input access, but that does not allow you to do something that
is interactive, so write access is required as well.

“What level of security is expected?” Should it be safe to use over the
internet or strictly for internal use?

Ditto itself (in QNX4) didn’t really know anything about the network. This
was the beauty of the transparent FLEET networking. In QNX6 there is no
need for it to it know anything about the network either, the transparency
that QNET provides is sufficient. As for internet access, the same thing
as we have always done in QNX4, which is use telnet or dial up to obtain
access to the system and THEN run ditto. So, please drop the entire
concept of internet access (you are confusing phditto’s ability to provide
the TRANSPORT & INPUT/DISPLAY with the ditto requirement of ONLY input/display)

This also means that you can use the same “security” as QNX4 and QNX2 used,
which is the permissions & ownership on the /dev/conX device.

“What are the likely situations that this will be used for?” We have the
situation of the lab and the tech support. Are there others?

Have you thought of digging up the marketing information on Ditto? Are you
aware that ditto was bundled with development kits, but other was was an
actual PRODUCT that QSSL sold. Customers actually PAID HARD, COLD CASH for
the ability to have enough licesnses for an entire network. The business
case that made it viable for QNX2 and QNX4 still apply. Go dig them up and
stop re-inventing the wheel by trying to perform research that has already
been done (and proven to be correct due to the sales of ditto licenses on
QNX2 and QNX4).

start devc-con with a certain cache size and then an interface to retrieve
that information would be sufficient.

Look at the term_* functions in QNX4 and QNX2. They allowed for the creation
of something that could (for all intents) and purposes be considered an actual
console. You could actually just define a set of console_* functions that
would be required to us in order to provide “console” functionality. These
would need (or could use) callback fucntions for your actual device. The
default callbacks would do nothing, so that for a “real” console (or even
for a serial console) you would provide callback functions that would then
update the physical hardware. Shouldn’t be that hard. This would actually
be what the io-char process would manage, isn’t it?

Cheers,
Camz.

163

Adam Mallory <amallory@qnx.com> wrote:

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.

Actually, that only works IF there is activity on those resources. So, if
I have a process using an IRQ but there are no IRQs presently being generated.
The same applies to an fd, if there is no read/write activity (ie. say a
process that has a log file open for write/append, but not actively logging
any entries). So, waiting for that activity could be impractical. The way
sin presented the VC, IRQ, FD, and FILES information was instantaneous, and
did not require waiting for activity (which could take hours, or days). I
hope that makes it obvious why the procnto-instr method is not ideal. I
won’t even mention that this information is useful for ALL QNX 6.2 Momentics
users, not just PE customers, which is who the procnto-instr method would
be restricted to.

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

In the case of sin, I don’t actually think there is much functionality that
ISN’T useful. Kudos to the author of pidin for the output of “pidin mem”,
which mortal can decipher, I think that only Dan Dodge could decipher the
output of “sin mem” in QNX4 :slight_smile:

Cheers,
Camz.

164

“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:aedho6$q6o$1@nntp.qnx.com…

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.

Is there any equivalent for fsysinfo?
I use it to get info about number of writes to compact flash devices.

Pavol Kycina

165

Shouldn’t this be in a FAQ for us old QNX4 programmers to help in the transition to QNX6?

The docs I have seen so far from QSSL don’t cut it. Actually the transition from QNX2 to QNX4 was painful too I seem to recall.

The other concern I have is the focus on embedded systems, our app(s) is desktop, we use QNX4 for its stability and I have the strong feeling we are now not being catered for. It’s been hard enough justifying QNX4 to the bean counters, I just dread the next round of “why doesn’t your system run on some flavour of Windows” …


I will admit this was a BIG barrier for me. It was a huge mental leap
from the QNX4 S/R/R “simple” model to the (seemingly) more complex QNX6
resmgr model. I have to thank Chris McKillop for walking me gently
through the transition on IRC.

If you want some help in how to do the more traditional switch()/case
thing in QNX6, let me know and I can dig up my test code to help you
through it as well.

Cheers,
Camz.

166

Pavol Kycina <kycina@microstep-hdo.sk> wrote:

Is there any equivalent for fsysinfo?
I use it to get info about number of writes to compact flash devices.

Unofficially (ie I may change it :wink: …

<sys/dcmd_blk.h>
<sys/fs_stat.h>

DCMD_FSYS_STATISTICS or DCMD_FSYS_STATISTICS_CLR

Open the raw disk device and send it this devctl() … for your specific
example you’d look at “s_buf_wphys” …

167

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?

/Johan

168

“Kevin Stallard” <kevin@ffflyingrobots.com> wrote in message
news:aeooud$23r$1@inn.qnx.com…

Hey xtang, how’s it going?

Yeah, I get it, but this where I differ in philosophy. I am having a hard
time visualizing a situation where I’m going to have a process represented
by more than one chid. If I am going to have more than one chid, then I’m
going to move the functionality around that chid into a seperate process.
(At least this is how I look at it currently).

That chid may be internal to the process for example you may want certain
threads to handle pulses timer or IRQ and other thread (to handle external
messages). This works great on SMP machine.


Kevin

“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:aeoml0$8si$> 1@nntp.qnx.com> …
Kevin Stallard <> kevin@ffflyingrobots.com> > wrote:
Even with a thread pool, you have one receive() that passes work off
to
other threads that then reply. Having a receive in a thread (the main
thread) and then worker threads I don’t see how that would be
limiting.
Lots easier to figure out who to send to…

That is where you are wrong.

Every thread in the pool doing receive(), only one of them will
unblock if a message arrived. “Which one” is not important,
they are all same “worker threads”.

Now if you have “worker1 threads” and “worker2 threads”, they
do different job, how’s that going to happen? That’s where
“Channel” comming in, “worker1 threads” receive() on channel 1,
and “workder2 threads” receive() on channel 2.

-xtang

169

<camz@passageway.com> wrote in message news:aeot0u$4dg$2@inn.qnx.com…

Interestingly enough if you look at something like Beowolf clustering for
Linux you will find that the model that you have to add the beowolf
“layer”
to achieve is more or less the QNET / FLEET native model. That just blows
my mind. Linux has to work hard to acheive functionality that has
natively
been available in QNX since QNX2.

Which is exactly why you see so much talk of bringing things like MPI to
QNX. So you can run all the heavy duty number crunching routines without
the hassle of setting up a cluster - just use QNX and it happens by ‘magic’.

Kris

The proper way to think of a QNET/FLEET network is that of an SMP machine
with “loosely coupled” CPUs. A multi-processor motherboard is not that
different and is just “tightly coupled” CPUs. The slick thing with QNX6
is that you can have BOTH. That is incredibly powerful and so much more
efficient when you take into account the fact that QNX achieves it without
any additional network layers.

Cheers,
Camz.

170

Kevin Stallard <kevin@ffflyingrobots.com> wrote:

Hey xtang, how’s it going?

Yeah, I get it, but this where I differ in philosophy. I am having a hard
time visualizing a situation where I’m going to have a process represented
by more than one chid. If I am going to have more than one chid, then I’m
going to move the functionality around that chid into a seperate process.
(At least this is how I look at it currently).

There is NOTHING WRONG to have one chid, but still have, say 10 threads
MsgReceive() on that chid.

Think “chid” represent a “service”, and all the threads in server are
ready to serv. To the client (who request the service), “which thread”
is not important, “which service” (chid) is.

The model that “one thread receive, kick worker threads”, have problem
that if the main thread is busy, the service is stopped. Well, you can
make sure the one thread always “loop back fast”, but since the kernel
support multi-threads, why not let kernel handle that. That way, you
save context switch, and more important, you don’t play with thread
priority (remember server has to be float, so you have to adjust worker
threads priority every kick).

-xtang

171

Dependent on a) having a use message b) having the binary on a filesystem.
Most systems have use messages stripped out and some won’t have the binary
on the filesystem once it’s executing. We need to be able to read the
version from a process in memory.

cheers,

Kris

“Robert Krten” <nospam88@parse.com> wrote in message
news:aeo9qb$kok$1@inn.qnx.com…

Kris Warkentin <> kewarken@qnx.com> > wrote:
Actually, I got some email from the hardware guys who want sin ver
‘yesterday’. Apparently the ‘stuff’ is in place to get the version out
of a
running app now, it’s just a matter of accessing it. It’s on my list.

use -i ?


Kris

“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:aeo37h$g16$> 1@inn.qnx.com> …
Despite all the insistence that “just because sin had it doesn’t mean
it’s
necessary”, so far, no one mentioned “sin ve”, which is also a very
useful
diagnostic aid.

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:aedho6$q6o$> 1@nntp.qnx.com> …
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.

cheers,

Kris






\

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.

172

camz@passageway.com> > wrote in message news:aeot0u$4dg$> 2@inn.qnx.com> …

The proper way to think of a QNET/FLEET network is that of an SMP machine
with “loosely coupled” CPUs. A multi-processor motherboard is not that
different and is just “tightly coupled” CPUs. The slick thing with QNX6
is that you can have BOTH. That is incredibly powerful and so much more
efficient when you take into account the fact that QNX achieves it without
any additional network layers.

Exactly, trans-puter anyone?

-xtang

173

<camz@passageway.com> wrote in message news:aeovak$5n1$1@inn.qnx.com…

Actually, that only works IF there is activity on those resources. So, if
I have a process using an IRQ but there are no IRQs presently being
generated.
The same applies to an fd, if there is no read/write activity (ie. say a
process that has a log file open for write/append, but not actively
logging
any entries). So, waiting for that activity could be impractical. The
way
sin presented the VC, IRQ, FD, and FILES information was instantaneous,
and
did not require waiting for activity (which could take hours, or days). I
hope that makes it obvious why the procnto-instr method is not ideal. I
won’t even mention that this information is useful for ALL QNX 6.2
Momentics
users, not just PE customers, which is who the procnto-instr method would
be restricted to.

Again, I’m not suggesting that the Intrumented kernel tells all - just
trying to illustrate the information is available in other methods (other
than pidin / sin). I just happened to pick a bad example.

In the case of sin, I don’t actually think there is much functionality
that
ISN’T useful. Kudos to the author of pidin for the output of “pidin mem”,
which mortal can decipher, I think that only Dan Dodge could decipher the
output of “sin mem” in QNX4 > :slight_smile:

sin mem isn’t that bad. It’s a list of (data and code)segments each process
has, where they are mapped, the flags assoiciated with them, and their
limits (the segments limites).

Well, I think we’ve beat this horse dead. Take care.

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

174

Kevin Stallard <kevin@ffflyingrobots.com> wrote:

Right, but then the whole chid thing seems to me pointless in that model. I
was reading Thomas as saying that you would have a seperate receive in each
thread and each thread would have its own chid.

Think of it this way:

In QNX4, every process has exactly one channel. Many of these
channels are wasted, because many programs don’t use their channel.

In Neutrino, a process can have as many channels as it needs,
including zero. This makes it easier to do things that would be
close to impossible under QNX4. For instance, you can take the
sources to several applications (or even drivers) and link them
together (perhaps some of them as DLLs) into one process with only
minimal code changes. If it weren’t possible for this combined
process to have multiple channels, it would often take significant
redesigning to do this.

What I was trying to say earlier was that I’m not going to create a new
channel for each new thread and block on that channel. I"m going to have
one point to which all clients will ‘MsgSend’. I understood Thomas to say
that the chid gives us the ability to have each thread block on its own
channel, and I haven’t found a reason how this would be usefull to me.

All Unix programs (and a lot of QNX programs) have been written without
using QNX messaging at all. I imagine that it would be hard for many
Unix programmers to find a reason to use QNX messaging; but once you get
used to the idea, you will occasionally find a problem that QNX
messaging makes much simpler to solve. It’s the same way with the
ability to have multiple channels, except problems that make it useful
are even more rare. I have never written an app with multiple channels,
either.

There’s no rule that you must use every single feature of the OS.
Quite the opposite is advisable, actually: it’s good to stick close to
standard ISO C or POSIX in your code if you don’t have a good reason not
to. But, of course, sometimes you have a good reason not to…

Maybe this would be usefull at some point, but I haven’t seen how this would
help me solve any problems yet. I figure it’s a lot easier for a client to
find a server if he didn’t have to also figure out which thread he wanted to
talk to (which chid I should say).

But if each channel represents a different service, the client already
knows which one he wants to talk to. And your messaging can be simpler
to design if the client – or even the related portion of the server –
doesn’t have to be aware that the other channels even exist.

Imagine that you’re writing a library for a customer, and that you
decide that the best way of implementing it is by spawning some threads
to do the work. If it turns out that it’s useful for your threads to
have a channel, you just create your own channel and use it. You don’t
need to tell the customer that your library has threads or a channel, as
long as you make them invisible to your library’s documented API.

Now imagine that a process can have only one channel. Your library
would have to work differently depending on whether the application it’s
been linked into receives messages or not. If it does, you’d have to
ask the application to reserve some message or pulse types for you, and
give them to you when they’re received by the application’s code. This
would not only make the documented API more complicated, but also expose
an implementation detail, potentially making it more difficult for you
to change the implementation in future versions of your library.

–
Wojtek Lerch QNX Software Systems Ltd.

175

“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:aeq4cu$c1j$2@nntp.qnx.com…

camz@passageway.com> > wrote in message news:aeot0u$4dg$> 2@inn.qnx.com> …

The proper way to think of a QNET/FLEET network is that of an SMP
machine
with “loosely coupled” CPUs. A multi-processor motherboard is not that
different and is just “tightly coupled” CPUs. The slick thing with
QNX6
is that you can have BOTH. That is incredibly powerful and so much
more
efficient when you take into account the fact that QNX achieves it
without
any additional network layers.

Exactly, trans-puter anyone?

Since you can descend into the /net on remote nodes, maybe we should model
an n-dimensional hypercube… Or is that just too weird?

Kris

-xtang

176

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?

You are quite correct. The screen util does do pretty much everything we
want/need. The only thing is does not do is run as the default console.
If it did that, then we’d be set. Actually, I think for some of the things
that are being requested, you would also want screen to create /dev/screen1
/dev/screen2, etc. entries as an alternative to the normal reconnection
method.

Cheers,
Camz.

177

camz@passageway.com wrote:

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?

You are quite correct. The screen util does do pretty much everything we

I’ve never used screen. Can it “ditto” to a current console that somebody
is logged in and typing something. This is useful for remote support and
coaching.

Frank


want/need. The only thing is does not do is run as the default console.
If it did that, then we’d be set. Actually, I think for some of the things
that are being requested, you would also want screen to create /dev/screen1
/dev/screen2, etc. entries as an alternative to the normal reconnection
method.

Cheers,
Camz.

178

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

[ Various thought snipped ]

What it comes down to is we want to anthropomorphise the computer and give
it a ‘voice’ so that it (s/he?) can tell us what it is doing. It has to be
separate from the application GUI on the basis that this sort of commentary
is not intended for the user, and to date, the console is the best (only)
way we have of achieving this. Maybe we should be looking at speech
modules…?..> :sunglasses:

http://www.gweebo.com/~thomasf/flite_resmgr.gz

Not as nice as some of those out there … but hey it
was free =;-)

Thomas

Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Core OS Technology Group
(613)-591-0931 http://www.qnx.com/

179

Kevin Stallard <kevin@ffflyingrobots.com> wrote:
| What I was trying to say earlier was that I’m not going to create a new
| channel for each new thread and block on that channel. I"m going to have
| one point to which all clients will ‘MsgSend’. I understood Thomas to say
| that the chid gives us the ability to have each thread block on its own
| channel, and I haven’t found a reason how this would be usefull to me.
| Maybe this would be usefull at some point, but I haven’t seen how this would
| help me solve any problems yet. I figure it’s a lot easier for a client to
| find a server if he didn’t have to also figure out which thread he wanted to
| talk to (which chid I should say).

In my controller I had (schematically)

pthread_create(logger)
(logger create a channel and waits for pulses)

Pwm pwmObject;
pwmObject.connectLogger(loggerChid)

LegPos posObject; //actually several of this type
posObject.connectLogger(loggerChid);

pthread_create(communicator);
(communicator creates its own channel and waits for messages containing
coordinates of leg at various instant of time)

pthread_create(servo);
(servo waits for communicator to give it coordinates to servo through
condvars)

Now, as soon as you connect to communicator and start pumping in
coordinates, the whole mechanism works by itself. The position/pwm is stored
in objects (not plain variables) which communicate the value to logger
as soon as its changed… by ANY section of code. Logger logs it to
memory (and file) with timestamp and optionally sends data to a remote
computer for real-time plotting.

Model is a bit complex, but testings show it works for a six legged robot.

I don’t think I would have ever been able to achieve the modularity without multiple
channels per process.

–
Keep Smiling
Regards

  • mritunjai

http://www.me.iitb.ac.in/~mritun
http://mritun.qnx.org.ru
http://www.qnxzone.com/~mritun

180

Absolutely! And as I pointed out about 6 weeks ago, the output of sin ve is
not limited to just version information. It is extreamly useful.

“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:aeq3o2$ccb$1@nntp.qnx.com…

Dependent on a) having a use message b) having the binary on a filesystem.
Most systems have use messages stripped out and some won’t have the binary
on the filesystem once it’s executing. We need to be able to read the
version from a process in memory.

cheers,

Kris