QNX4 Updates System Updated!

I’ve got a C library which reads tar files, if you’re really stuck
you can have it and write your own pax, guaranteed correct return
code!

Sam

Previously, Richard R. Kramer wrote in comp.os.qnx, qdn.public.qnx4:

We don’t use tar here, however pax will read these files and will
report errors unless it comes to a bad spot, in which case it asks for
“volume 2”. The pax command equivalent to your tar would be:
pax -rvopf bob.tar
I think. look at “use pax”.

If you know the name of the last file in the archive, and you pipe
pax’s output to a place where you can compare the last file output to
what it should be, then you could do a check to see that it completed.

Richard Levy wrote:

I`m using TAR as part of an installation script, and need to detect if
anything went wrong during extraction.
Ive got the following bit of code in the script to detect the return value
from the TAR call :

ret=0
tar -xvf bob.tar
ret=$?
if [ ret -ne 0 ]; then
echo Failed : Returned $ret

Abort here

else
echo Passed

All OK

fi

However, no matter what happens with TAR (i.e everything extracts fine, or
there is an error) it always returns 0.
Am I looking in the wrong place for the return value? Or does it simply not
return a value?

TIA
Rich…


Sam Roberts, sroberts at uniserve dot com, www.emyr.net/Sam

In article <8m45sm$8t$1@nntp.qnx.com>,
eric@qnx.com (Eric Johnson) writes:

In Debbie’s message she mentioned that the old-style updates will be
available at_least until Jan 2001. i.e. we had not conclusively
decided to shut down the old-style updates for everyone on that date.

I’ve conferred with both Debbie and our product release group and we
have agreed that we will continue to create the old-style updates
for QNX 4 products when new versions are released, and will continue to
make them available to those existing customers who have a legitimate
need for them.

First, thank you. I maintain over 50 QNX4 “host” boxes, and not one has
Photon, and I distribute and install updates remotely, TCP/IP and not.

As to “…those who have a legitimate need for them”, add me and/or my
employer to that list:

David J. Hawkey Jr., UNIX Systems Administrator
CTC Direct, Inc (formerly CTC Distribution Direct, LLC)
david.hawkey@rrd.com hawkeyd@ctcdist.com
hawkeyd@visi.com

  • Eric

Dave


__________________ \ D. J. HAWKEY JR. / /
_
/\ hawkeyd@visi.com /_
____________/
http://www.visi.com/~hawkeyd/

Previously, D J Hawkey Jr wrote in qdn.public.qnx4:

First, thank you. I maintain over 50 QNX4 “host” boxes, and not one has
Photon, and I distribute and install updates remotely, TCP/IP and not.

As to “…those who have a legitimate need for them”, add me and/or my
employer to that list:

I’m wondering if it would be all that difficult to provide
a text based version of the installer. Either that or
some command line routines to extract from the archives.


Mitchell Schoenbrun --------- maschoen@pobox.com

In article <Voyager.000908185134.20701A@schoenbrun.com>,
Mitchell Schoenbrun <maschoen@pobox.com> writes:

I’m wondering if it would be all that difficult to provide
a text based version of the installer. Either that or
some command line routines to extract from the archives.

How do you mean this? I’ve not yet used the CD media for upgrades, so
I’m taking a shot in the dark here, but if you mean to “peek” inside a
frozen/zipped/gzipped tarball, I do this all the time with Midnight
Commander.

The frozen format was “an inconvenience” for quite some time, but after
sitting down and reading MC’s documentation (!), I was able to write a
shell script for it’s external filesystem support that deals with that.
If this is what you’re writing about, I can give you MC for QNX4 with
this script.

Mitchell Schoenbrun --------- > maschoen@pobox.com

Dave


__________________ \ D. J. HAWKEY JR. / /
_
/\ hawkeyd@visi.com /_
____________/
http://www.visi.com/~hawkeyd/

Previously, D J Hawkey Jr wrote in qdn.public.qnx4:

How do you mean this? I’ve not yet used the CD media for upgrades, so
I’m taking a shot in the dark here, but if you mean to “peek” inside a
frozen/zipped/gzipped tarball, I do this all the time with Midnight
Commander.

Well that sounds nice. Better yet, have QSSL post it. What is
Midnight Commander? Is it Public Domain? GPL? Other?


Mitchell Schoenbrun --------- maschoen@pobox.com

In article <Voyager.000909180516.27198C@schoenbrun.com>,
Mitchell Schoenbrun <maschoen@pobox.com> writes:

Previously, D J Hawkey Jr wrote in qdn.public.qnx4:

How do you mean this? I’ve not yet used the CD media for upgrades, so
I’m taking a shot in the dark here, but if you mean to “peek” inside a
frozen/zipped/gzipped tarball, I do this all the time with Midnight
Commander.

Well that sounds nice. Better yet, have QSSL post it. What is
Midnight Commander? Is it Public Domain? GPL? Other?

MC is a U**X redux of the MS-DOS Norton Commander (a text-mode, full-screen
file mangler). It is under some kind of GPL, yes.

I ported MC 1.4.0-1.4.11 to QNX4 quite some time ago, and though there is
a bit of a problem with qnx[t] terminals, I wrote a wrapper script to deal
with that (though I heard that others sorted it out with termcap/terminfo).

The website that used to be the maintainer’s isn’t what it used to be, so I
have no idea if it’s still supported as a text-mode app (IIRC, it redirects
to some GNOME site or another).

My port has been available via anonymous FTP at
ftp.visi.com/users/hawkeyd/qnx/
as
mc-1.4.something-or-another
for a while now (but it doesn’t have that script for frozen tarballs I
wrote of, that’s a newer thang). Unpack it as root in the root of your HDD,
it’ll add to /usr/local/bin, /usr/local/etc/readme, and /usr/local/lib/mc .
It’ll also leave a file in the drive root, which is that wrapper script.
Stick it somewhere in $(PATH) before /usr/local/bin and make it exec’able
if you don’t want to muck about with termcap/terminfo (I still don’t!).

Give me a day or two, and I’ll re-package it with the frozen support, and
write you (or post at this site in *.porting?) of it’s availability.

Mitchell Schoenbrun --------- > maschoen@pobox.com

Dave

Afterthought: MC is kind of “configuration thick”; do check out the file
in /usr/local/etc/readme/ and the stuff in /usr/local/lib/mc/ .


__________________ \ D. J. HAWKEY JR. / /
_
/\ hawkeyd@visi.com /_
____________/
http://www.visi.com/~hawkeyd/

My port has been available via anonymous FTP at
ftp.visi.com/users/hawkeyd/qnx/
as
mc-1.4.something-or-another

This looks like a really good utility. However I
can’t get the key input to work right. Is there
any secret?

Mitchell Schoenbrun --------- maschoen@pobox.com

In article <Voyager.000910162631.13861A@schoenbrun.com>,
Mitchell Schoenbrun <maschoen@pobox.com> writes:

My port has been available via anonymous FTP at
ftp.visi.com/users/hawkeyd/qnx/
as
mc-1.4.something-or-another

This looks like a really good utility. However I
can’t get the key input to work right. Is there
any secret?

If you’re invoking the binary directly, then yeah, you’re running into
that qnx[t] terminal issue I wrote about. That’s where that wrapper
script comes in.

If you unpacked it as I described, you should have a script called…
um… right: home-bin-mc, in your HDD’s root. Move that to $(HOME)/bin
as “mc”, or wherever else in $(PATH) before /usr/local/bin (I believe
I also included it in the tarball as /usr/local/lib/mc/bin/mc). This
way, the script will save then current terminal, set up a terminal type
that MC does like, run MC, and then restore the terminal on exit of MC.

Revisiting that script, it looks as though I have best results running
it in xterm windows, and on consoles set running as qansi terminals.
I remember testing other possibilities, but I’ll admit to not giving
it an exhaustive testing. You know… I stopped when I found solutions
that worked for me. As I wrote, I’m not terribly comfortable with
termcap or terminfo, so I didn’t go there, but others reportedly did,
with success. Igor? Jean-Claude? Mario? Are you guys lurking?

I’m aware of problems using it in Photon 1.NN shells, but I haven’t
looked into it, as I don’t run Photon on my desktops. Oh! This reminds
me of something else: I did install a different qansi.src into the
terminfo tree, but it was long ago enough that I don’t recall if it
was to address MC’s needs, or if it was simply a terminfo update. I
can mail it to you if you want it.

If you’re comfortable with termcap and terminfo, the docs do mention
them, and what may work, but I don’t recall the details. If you get it
working properly without that wrapper script, I sure wouldn’t mind
knowing how.

If you run the binary directly on qnx[t] terminals, navigation, etc.,
is rather EMACish, but rather not, as well. I’m sorry I can’t give you
much more comprehensive help than this.

Mitchell Schoenbrun --------- > maschoen@pobox.com

Dave


__________________ \ D. J. HAWKEY JR. / /
_
/\ hawkeyd@visi.com /_
____________/
http://www.visi.com/~hawkeyd/

Revisiting that script, it looks as though I have best results running
it in xterm windows, and on consoles set running as qansi terminals.
I remember testing other possibilities, but I’ll admit to not giving
it an exhaustive testing. You know… I stopped when I found solutions
that worked for me. As I wrote, I’m not terribly comfortable with
termcap or terminfo, so I didn’t go there, but others reportedly did,
with success. Igor? Jean-Claude? Mario? Are you guys lurking?

I am lurking but I have no knowledge of terminfo database usage.
I actually asked a question about it on comp.os.qnx.

  • Mario

In article <Voyager.000910162631.13861A@schoenbrun.com>,
Mitchell Schoenbrun <maschoen@pobox.com> writes:

My port has been available via anonymous FTP at
ftp.visi.com/users/hawkeyd/qnx/
as
mc-1.4.something-or-another

This looks like a really good utility. However I
can’t get the key input to work right. Is there
any secret?

One other things occurs to me: I built it using slang/terminfo. It wouldn’t
run right using [n]curses.

I don’t have the time right now to re-package MC with that frozen file support,
so see below the ASCII-sig for it. It should live in /usr/local/lib/mc/extfs,
and have world executability. To enable it, add a line “frozen=.tar.F .pax.F”
to the file extfs.ini, also in that directory.

Mitchell Schoenbrun --------- > maschoen@pobox.com

Dave

David J. Hawkey Jr. david.hawkey@rrd.com hawkeyd@visi.com
CTC Direct, Inc. http://pluto.ctcdist.com/
UNIX Systems Administrator http://www.visi.com/~hawkeyd/

—8<—

#!/bin/sh

MC external filesystem support for frozen archives (*.tar.F, *.pax.F)

This may be a little too QNXish

D. J. Hawkey Jr. (hawkeyd@visi.com)

July 9, 2000

mcfrozen_list()
{
typeset -i siz

fcat $1 | pax -v 2>&1 | egrep -v “^(USTAR|CPIO)” | \

the docs say to strip the leading ‘/’ from the paths, but MC

seems to behave more rationally if they’re left as is - djhjr

#sed -e “s, /, ,g” | \

this is less efficient than the shell - djhjr

#perl -e 'while (<>) {

chomp;

($prm, $lnk, $own, $grp, $junk, @rest)=split;

if ($lnk == 0) {$lnk = 1};

if (int $junk) {$siz = $junk} else {$siz = 0};

printf "%s %d %-8d %-8d %d ", $prm, $lnk, $own, $grp, $siz;

if ($siz == 0) {print "$junk "};

print “@rest\n”;

#}’
while read prm lnk own grp junk rest
do
if [ “$lnk” == “0” ]; then
lnk=“1”
fi

if this is a symlink, $siz will be 0 by typecast coersion…

siz=$junk
printf "%s %d %-8d %-8d %d " $prm $lnk $own $grp $siz

…because $junk is [part of] the date/time stamp - djhjr

if [ $siz -eq 0 ]; then
echo $junk" \c"
fi
echo $rest
done
}

mcfrozen_copyout()
{
tmpdir=/tmp/mctmpdir.$$
mkdir $tmpdir
cd $tmpdir

$2 has the leading ‘/’ stripped from it’s path, but the archive

may have preserved it, so strip it on restoration if it exists

(note that more than the one file $2 specifies may end up being

restored in order to handle this) - djhjr

dirnam=${2%/*}
fcat $1 | pax -r -s,^/$dirnam,$dirnam, *$2
mv $2 $3 2>/dev/null
cd /
rm -rf $tmpdir
}

case “$1” in
list) mcfrozen_list $2; exit 0;;
copyout) mcfrozen_copyout $2 $3 $4; exit 0;;
esac

exit 1

—>8—

hi michael, hi erick

Michael Van Reenen wrote:

Are you running the RTP or QNX4? The free version for download is RTP, but
this is the qnx4 newsgroup. (I just want to make sure
before so I can ask for the correct information)

Erick Muis wrote:

Hi Max,

This news group is actually not the one you want to post this question to.
The best news group to post to would be:

qdn.public.qnxrtp.photon

The developers surf that news group looking for bugs/problems. If you post
there, it will be seen more quickly than on the QNX4 news group.

FYI, QNX4 is another OS, not the QNX RTP (which uses Neutrino 2.0 as its
core OS, and on top of that runs a windowing environment called Photon 2.0,
all together named the RTP).

Take care.

thanks a lot for the hint, and the explanations. you’re right the
newsgroups it the wrong one. i got the free version of QNX RTP, where i
have (still :frowning: problems with the videocard. i’ll post something on the
qdn.public.qnxrtp.photon.

thanks again
max

sorry, I WAS talking about QNX4 Neutrino SDK (for Neutrino 2.0, so a
littel backlevel). ButI guess I was in the wrong newsgroup. now also
appending to qnx4 group.
klemens

Colin Burgess wrote:

Klemens Klaffke <> klaffke@raleigh.ibm.com> > wrote:
Is there a C++ compiler available for the Neutrino
Power PC platform? The QNX Neutrino SDK has one in its ntox86 branch
put not is the ntoppc branch.

thanks, Klemens Klaffke

It’s not yet available for the RTP. You can purchase the QNX4
hosted Neutrino SDK, but this is not free like the RTP, nor, I
think, will the Neutrino PPC SDK for RTP.


cburgess@qnx.com

In qdn.public.qnx4 Klemens Klaffke <klaffke@raleigh.ibm.com> wrote:

sorry, I WAS talking about QNX4 Neutrino SDK (for Neutrino 2.0, so a
littel backlevel). ButI guess I was in the wrong newsgroup. now also
appending to qnx4 group.
klemens

It’s not released. There is an unsupported version in

ftp://ftp.qnx.com/usr/free/neutrino/development/nto-g++.tgz

Colin Burgess wrote:

Klemens Klaffke <> klaffke@raleigh.ibm.com> > wrote:
Is there a C++ compiler available for the Neutrino
Power PC platform? The QNX Neutrino SDK has one in its ntox86 branch
put not is the ntoppc branch.

thanks, Klemens Klaffke

It’s not yet available for the RTP. You can purchase the QNX4
hosted Neutrino SDK, but this is not free like the RTP, nor, I
think, will the Neutrino PPC SDK for RTP.


cburgess@qnx.com


cburgess@qnx.com

Previously, 4powellz@home.com wrote in comp.os.qnx, qdn.public.qnx4:

Hi Armin and thanks for your comments.

I still have questions, inserted below, that I hope you can consider
and reply to.

Thanks in advance,
Charlie Powell

Armin Steinhoff wrote:

In article <> 39EC6C60.AAB0B8E6@home.com> >, "> 4powellz@home.com> " says…

Hi,

We are developing a PCI based device that will be added to our computers
that run QNX 4.24. This is our first attempt to develop PCI hardware and
associated QNX hosted software to communicate with the hardware.

My job is to develop the QNX software and I’m confused. I see QNX has
C library functions for PCI but those functions only provide access
to the “configuration space” of the PCI device.

… and that is completely sufficient.

Ok. That looks good
to me. I assume I can use this to identify the interrupt, I/O space
and memory space the device is using and given that I can “talk”
with the device.

Yes … the device resources ( base address reg a.s.o) must be mapped into the
address space of your driver. Then you can talk to the device …

Yes. I see QNX sample programs in the C Library book where the
program sets up shared memory and then maps it to the programs
address space. Just like you said. With this information I see
that I can read and write to the memory space of the PCI device.


Or do I have to issue commands to the PCI controller
of the host processor and it talks to the device?

NO … you dont’t have to talk to the PCI controller. That’s normaly the task of
the system BIOS.

For example, I want to utilize burst mode transfers to move data.
Do I have to program the PCI controller on the host processor to
accomplish this?

If your device supports burst mode … then the initial setup of the PCI
controller should be done at system start ( mostly by a serial EEPROM )

The hardware engineers tell me the device we’re building does support
burst mode. In fact they insist the software under QNX has to provide
burst capability too.

Right now this is the sticking point. I don’t see how to implement burst
mode transfer. All the code samples show single read/write operations
to the device’s address space and I haven’t found any way to start
a burst transfer from the software under QNX.

Do you have any suggestions?


I don’t find much capability in QNX for PCI

What I have found was sufficient enough to write a shared memory backplane
(network) driver for a cPCI system … let me know what you are missing.


Did your driver utilize burst transfers? If so, how was a burst mode
transaction initiated? Did the driver software cause the PCI burst
mode transfer to start or was it a device, other than the QNX host
computer, that caused the burst mode transfer to start?

and I assume QNX wouldn’t
require me to program the PCI controller chip so I’m of the opinion
that the PCI device must do the work.

I don’t see any PCI specific tasks for QNX itself.

For example, the PCI device provides an address that I can write to
to accomplish single word transfers. Or it could provide an address
that I write a pointer to and the device uses that pointer to read
the data. Furthermore, the device controls the burst and non-burst
option.

You don’t need no specific QNX services to program your device … what you need
is just a good documentation about how you get access to the resources of your
controller ( via the config space)

As you can see I’m a bit confused about PCI and your help would
be appreciated.

post the output of show_pci -v …

Our PCI device is still under development and is not yet operating
with QNX. The engineers are using a Windows system for their work.
I can’t get a “show_pci” display that includes that device.

Is your device a bus master or will it only work in programmed I/O mode?
If it is a bus master, the hardware should perform the data transfer
between memory and the adapter. If you are using programmed I/O, the only
way to perform burst transfers is to stay in a loop, outputting the data.

Armin

Hugh Brown (613) 591-0931 ext. 209 (voice)
QNX Software Systems Ltd. (613) 591-3579 (fax)
175 Terence Matthews Cres. email: hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8

Gene LIttle <genel@slmd.com> wrote:

setsetestetetessettestes

I see your test… and I am crossposting this test to qdn.public.qnx4

Hugh Brown wrote:

Previously, > 4powellz@home.com > wrote in comp.os.qnx, qdn.public.qnx4:
Hi Armin and thanks for your comments.

I still have questions, inserted below, that I hope you can consider
and reply to.

Thanks in advance,
Charlie Powell

Armin Steinhoff wrote:

In article <> 39EC6C60.AAB0B8E6@home.com> >, "> 4powellz@home.com> " says…

Hi,

We are developing a PCI based device that will be added to our computers
that run QNX 4.24. This is our first attempt to develop PCI hardware and
associated QNX hosted software to communicate with the hardware.

My job is to develop the QNX software and I’m confused. I see QNX has
C library functions for PCI but those functions only provide access
to the “configuration space” of the PCI device.

… and that is completely sufficient.

Ok. That looks good
to me. I assume I can use this to identify the interrupt, I/O space
and memory space the device is using and given that I can “talk”
with the device.

Yes … the device resources ( base address reg a.s.o) must be mapped into the
address space of your driver. Then you can talk to the device …

Yes. I see QNX sample programs in the C Library book where the
program sets up shared memory and then maps it to the programs
address space. Just like you said. With this information I see
that I can read and write to the memory space of the PCI device.


Or do I have to issue commands to the PCI controller
of the host processor and it talks to the device?

NO … you dont’t have to talk to the PCI controller. That’s normaly the task of
the system BIOS.

For example, I want to utilize burst mode transfers to move data.
Do I have to program the PCI controller on the host processor to
accomplish this?

If your device supports burst mode … then the initial setup of the PCI
controller should be done at system start ( mostly by a serial EEPROM )

The hardware engineers tell me the device we’re building does support
burst mode. In fact they insist the software under QNX has to provide
burst capability too.

Right now this is the sticking point. I don’t see how to implement burst
mode transfer. All the code samples show single read/write operations
to the device’s address space and I haven’t found any way to start
a burst transfer from the software under QNX.

Do you have any suggestions?


I don’t find much capability in QNX for PCI

What I have found was sufficient enough to write a shared memory backplane
(network) driver for a cPCI system … let me know what you are missing.


Did your driver utilize burst transfers? If so, how was a burst mode
transaction initiated? Did the driver software cause the PCI burst
mode transfer to start or was it a device, other than the QNX host
computer, that caused the burst mode transfer to start?

and I assume QNX wouldn’t
require me to program the PCI controller chip so I’m of the opinion
that the PCI device must do the work.

I don’t see any PCI specific tasks for QNX itself.

For example, the PCI device provides an address that I can write to
to accomplish single word transfers. Or it could provide an address
that I write a pointer to and the device uses that pointer to read
the data. Furthermore, the device controls the burst and non-burst
option.

You don’t need no specific QNX services to program your device … what you need
is just a good documentation about how you get access to the resources of your
controller ( via the config space)

As you can see I’m a bit confused about PCI and your help would
be appreciated.

post the output of show_pci -v …

Our PCI device is still under development and is not yet operating
with QNX. The engineers are using a Windows system for their work.
I can’t get a “show_pci” display that includes that device.


Is your device a bus master or will it only work in programmed I/O mode?
If it is a bus master, the hardware should perform the data transfer
between memory and the adapter. If you are using programmed I/O, the only
way to perform burst transfers is to stay in a loop, outputting the data.

I assume it will support bus master operation. Sorry, I don’t know what
“programmed I/O mode” means. Maybe its not important considering the
following description and questsions.

Assuming the PCI device can act as PCI bus master then it makes sense to
require the PCI device perform the data transfer between its local
memory
and the memory of the single board computer.

If the PCI device can not act as PCI bus master or the PCI device
designers
prefer to not implement that then what can a QNX hosted application do,
if anything, to setup the PCI to drive burst mode transfers across the
PCI
bus between the PCI device and the single board computer?

For example, our designers appear to want to provide two buffer
locations
on the PCI device. One buffer for multi-word messages to be moved from
the
device to the single board computer and the other buffer for messages
going the other direction. In this scenario, the CPU of the single board
computer will have to move the data, via the PCI bus. A QNX application
could use shm_mem, mmap and memcpy to move the data but would this
data transfer be single-word transfer or burst mode transfer? Could that
application do something to ensure burst mode is used?

Armin

\

Hugh Brown (613) 591-0931 ext. 209 (voice)
QNX Software Systems Ltd. (613) 591-3579 (fax)
175 Terence Matthews Cres. email: > hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8

Charlie Powell <charlie.powell@nokia.com> wrote:


Assuming the PCI device can act as PCI bus master then it makes sense to
require the PCI device perform the data transfer between its local
memory
and the memory of the single board computer.

If the PCI device can not act as PCI bus master or the PCI device
designers
prefer to not implement that then what can a QNX hosted application do,
if anything, to setup the PCI to drive burst mode transfers across the
PCI
bus between the PCI device and the single board computer?

For example, our designers appear to want to provide two buffer
locations
on the PCI device. One buffer for multi-word messages to be moved from
the
device to the single board computer and the other buffer for messages
going the other direction. In this scenario, the CPU of the single board
computer will have to move the data, via the PCI bus. A QNX application
could use shm_mem, mmap and memcpy to move the data but would this
data transfer be single-word transfer or burst mode transfer? Could that
application do something to ensure burst mode is used?

If you simply uses the memcpy() command, most of the details will
happen automatically below your threshold of perception.

memcpy() will try to use the assembler REP MOVSTR type of instructions
to do the copy, and this will automatically engage burst mode transfers
if your device and the PCI bridge(s) on your motherboard are designed
to allow it.

If you can arrange it, try to always make your data align naturally
on a longword (or better a double longword) boundary in system RAM.

Charlie Powell wrote:

Hugh Brown wrote:

[ clip … ]

For example, our designers appear to want to provide two buffer
locations on the PCI device. One buffer for multi-word messages to be
moved from the device to the single board computer and the other buffer >for messages going the other direction. In this scenario, the CPU of the >single board computer will have to move the data, via the PCI bus. A QNX >application could use shm_mem, mmap and memcpy to move the data but would >this data transfer be single-word transfer or burst mode transfer? Could >that application do something to ensure burst mode is used?

The PCI device must have in the device specific
part of its config space a so called ‘cache line
size’ register which does determine how many words
the cache (buffer) must contain until the ‘burst
transfer’ will be started. Setting the ‘cache line
size’ to 1 (word) will define single-word
transfer. A ‘cache line size’ > 1 word → burst
transfer.

Armin

http://www.steinhoff.de
allow


Armin

\

Hugh Brown (613) 591-0931 ext. 209 (voice)
QNX Software Systems Ltd. (613) 591-3579 (fax)
175 Terence Matthews Cres. email: > hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8

Previously, Ross Brantner wrote in qdn.public.qnx4, comp.os.qnx, qdn.public.qnx4.photon, qdn.public.qnx4.devtools:

I am doing a project for my operating systems class and I want to use QNX 4
but I am not sure if I can disable the virtual memory. I need to disable
it to do some comparisons between system operation with and without. Any
help on the subject would be greatly appreciated. Thanks in advance.

Ross Brantner
Shippensburg University, PA

You might want to try using Linux and uCLinux (microcontroller Linux) instead. uCLinux (http://www.uclinux.org/) doesn’t use a MMU. Your tasks can play core wars all they want.

(By the way, this isn’t a criticism of QNX. I’m using it to develop a life-safety system, so I’m definitely a believer. It just seems that Linux would better suit your needs.)

  • Pete

Previously, Ozgur Ozfidan wrote in qdn.public.qnx4, comp.os.qnx:

I’ve downloaded the SSL supported version of Voyager from
/updates/voyager/***
( Voyager 2.02 ) and updated my existing voyager. When the Voyager
starts the error message on the screen was " Unable to find voyager
server ( no such file or directory ) ". I tried to find a file named "
voyager.ssltsw.js.128 " but could not find it. Then I asked this
situation to qnx people and they gave me a license number ( We paid for
it ofcourse ). As far as I understood this license is for a product
named vgerx (or voyagerx ). But I can not find such a product on the
update site or on any other site.

Where can I find the product vgerx ? Is it the server that I need in
order to run Voyager 2.02 ?

Does anyone have any idea about this issue ?

The archive under <updates/beta.voyager_spyrus/Full_archives/> installs
the ssl version of the browser to /qnx4/spyrus/bin. To use this browser
use the -P option to voyager, specifying the full pathname.

ron