|
|
|
QNX4 Configuration Files
Press ESC to boot alternate OSBy pressing the escape key at this point QNX will load this file instead of /.boot. If you have made some changes to your boot image, copy the old version to /.altboot and then if you have any problems you can at least get your system to how it was, rather than re-installing it.
sys/Proc32
$ 52000 Proc32
sys/Slib16
$ 1 Slib16
sys/Slib32
$ 1 Slib32
/bin/Fsys
$ 8000 Fsys
/bin/Fsys.eide
$ 1000 Fsys.eide
/bin/mount
$ 1000 mount -p /dev/hd0 /dev/hd0t77 /
/bin/sinit
$ 1000 sinit TERM=qnx
To convert this information into a QNX boot file you need to perform
the following:
cd /boot
buildqnx -v build/hard.1 images/hard.1
cp images/hard.1 /.boot
Everything in the boot configuration file is relative to the /boot
directory, unless it has a full pathname. (See the difference
between sys/Proc32 and /bin/Fsys.) So the make must
be performed in the /boot directory. Also it is a good
idea to link it with a disk driver so that QNX can load things
like sysinit from the disk once it has started; this is the d=
option. A file called /boot/images/hard.1 will be created.
This is your new QNX boot image. For QNX to be able to use it
you must copy it into the /.boot file.
/etc/config/lpsrvr tells QNX about the queues, printers and rules that it should use when performing these functions. A typical file would look like this:
[]
sp=/qnx/spooler2
cd=/usr/spool/lp
[doc]
ta=lpt
co=lps -F4 -P12 $(spfile) > $(device)
[ps]
ta=lpt
co=cat $(spfile) > $(device)
[-lpt]
dv=//2/dev/par
The file is split into sections and each section is delimited
by the square brackets, [ ]. The first section must exist but
everything else is optional. It tells QNX which spooler to use.
/qnx/spooler2 is the default spooler for node 2, /qnx/spooler3
would be the default spooler for node 3 and so on. It also tells
QNX where it should store the jobs until they are ready to be
rinted, /usr/spool/lp in this case.The first item [doc] describes a queue to QNX. The queue is called doc and any job that ends up here should be sent, eventually, to the device represented in lpt (the target). The co command tells QNX that it must do the following processing on the file after it has queued it but before it copies it to the device. In this case it formats plain text into PostScript output.
The second item is another queue, called ps. This one just does a straight copy of the files to the device.
The third item [-lpt] is a target device. This is indicated by the "-" preceding the name. It says that the device to be used by target lpt is the parallel port on node 2. It could have been any printer device on any node in the network. For example //12/dev/par3.
This example shows how we can use the queue mechanism so that both Postscript jobs and text documents can share the same PostScript printer. It is possible to have more than one target and any queue can send to any target or a number of targets may be specified so that if the first is unavailable the second will be tried and so on.
For historical reasons the default QNX network type is Arcnet. Each node on an Arcnet network can have a node number ranging from 1 to 255 so the default contents of this file are:
one-to-oneThis means that Arcnet physical node 1 is QNX logical node 1, and so on. This isn't particularly helpful if you want to run Ethernet between your QNX machines. You need to change the contents of this file so QNX knows how to map logical node numbers to real life physical network addresses. For example:
1 1 02cf1f09ed23 2 1 02cf1f23a234 3 1 02cf1f876ad0The left column is the QNX logical node number. The middle column is the QNX logical network number (more about this in a minute). The right column is the physical address of the network adaptor in the machine. Each of the three QNX nodes described in the above example must have an identical copy of this file if they are to communicate together.
QNX also supports many networks in a single machine. The limit currently is about 37 networks in a single machine but since that is far more than the number of slots in a PC you don't have to worry. The middle column above is to tell QNX which network to route traffic down to get to it's destination. So I could mix Arcnet and Ethernet networks like this:
1 1 02cf1f09ed23 2 1 02cf1f23a234 3 1 02cf1f876ad0 1 2 1 4 2 2 5 2 3I have added an Arcnet network and two extra nodes (logically 4 and 5) with Arcnet ids 2 and 3. I have to put node 1 in twice because it has two network connections.
Node 1 is sitting on both networks. There is a utility in QNX called netbridge that would allow me to use node 1 as a bridge between both networks. This is outside the scope of this document and if you would like further information please mail support@anglia.demon.co.uk
#set time zone and get clock from PC hardware TZ=utc00 rtc -l hw #Start device manager and console, serial and parallel device drivers Dev & Dev.con -n 4 & #Need to reopen /dev/con1 for STDERR,etc. reopen //0/dev/con1 Dev.ser & Dev.par & #Start Floating Point emulator - Many QNX apps need this #Not necssary on 486 or better emu87 & #Start Network manager and arcnet device driver Net & Net.arcnet & #Sort out node mapping netmap -f #Spawn logins on the console devices tinit -t /dev/con1 -T /dev/con[2-4] &It can be thought of as a cross between DOS' autoexec.bat and config.sys. Any of the QNX device drivers and system managers can be started and stopped from the command line but having them all started in sysinit is more convenient.
root::0:root
mail::40:
sales::100:gary trevor ralph tracy
technical::101:bob imogen
The first two lines are for system use only and must exist, the
rest are optional. In this example we have set up two groups sales
and technical. Sales have group id 100 assigned to them and technical
have group id 101. Each group has a list of users associated with
it. Access to everything in QNX is based upon permissions. It
is possible to allow a file to be read by sales although the technical
department can both read and write it.
Welcome to QNX 4.23 Copyright (c) QNX Software Systems Ltd.1982,1994You can change this to read anything you like.
qnx0027658n001 phrt000987n001If you had a two node QNX network then you would need both QNX licenses in this directory because as far as QNX is concerned you only have 1 licensed copy so it will not talk to anyone else.
QNX license files cannot be copied; if you try to copy them they simply will not work. You must use the license utility to transfer them from the original floppy disk to the /etc/licenses directory on your hard drive.
With the advent of QNX 4.23A this style of licensing is becoming less and less common, moving to the new style licensing. These new style licenses are kept in the /.licenses file and look like this:
tcprt.00766641-0r22-08ab-1i73-0k56-0174 (1 node) phinx.00200541-0dez-5ib9-2924-b7r6-f511 (2 node, 0597 expire) nto.00276259-0faf-9420-9998-f1rb-09c5 (1 node) vpro.00054687-060a-ke03-jat5-9879-3fe9 (20 node, 0897 expire)The advantages of the new style are that timed licenses can be given and that you can ring up and get a new license number over the phone for a product which is included on your QNX CD-ROM.
root:x:0:0::/bin/sh gary:x:100:100:Gary Jones:/bin/sh trevor:x:101:100:Trevor Smith:/bin/sh ralph:x:102:100:Ralph White:/bin/sh tracy::103:100:Tracy Brown:/bin/sh bob:x:104:101:Robert Harris:/bin/sh imogen:x:105:101:Imogen Clarke:/bin/shLet's look closely at the entry for gary to determine what it all means. 'gary' is the login id that will be used. The semicolons are field separators and can be ignored for our purposes. The 'x' indicates that gary has a password associated with his account. (In fact all the users except tracy have a password.) 101 is gary's user number. 100 is gary's group number (if you look back at /etc/group this is group 100 - sales). Gary jones is his real name - if you do anything like electronic mail or some system logging functions then gary would be expanded to Gary Jones by QNX. /bin/sh is the command interpreter that gary will be using.
A typical file would look like this:
export PATH=$PATH:./:/bin32:/usr/bin/X11:/usr/lib/X11:/etc
TMPDIR=${TMPDIR:/tmp}
LANG=C
umask 2
if [ ! f .hushlogin ]; then
cat /etc/motd
fi
date "+%x%t[ %I:%M %p ]"
if[ $LOGNAME != "root" ]; then
MAIL=${MAIL:/usr/spool/mail/$LOGNAME}
test s $MAIL && echo "You have mail."
fi
stty quit 1C term=$TERM
export DBDPATH=/usr/db
export DBFPATH=/usr/db
export LPSRVR=/qnx/spooler2
export LPDEST=doc
root:QW43Fhru{y]:0:0:0
gary:PJgfdr654[lKO:0:0:0
trevor:fgdf713&edcf:0:0:0
All critical filesystem data, such as bitmap blocks or directory entries are written immediately to disk, bypassing the cache. In the event that multiple pieces of critical data are to be written concurrently they are ordered in such a way that if the power goes down midway through the operation the filesystem will come up sane and at worst a few blocks will have been assigned that aren't used. Unfortunately, you've lost the last two seconds worth of data in the cache but your system is able to get up and running immediately. Even if the worst happens and you have a corrupt filesystem, QNX has a series of utilities that are designed to repair and rebuild damaged filesystems. These will be discussed here.
chkfsys requires that the filesystem is idle - it CANNOT be run whilst users or applications are making use of the filesystem as this would lead to inconsistencies in the newly created data. If you can't afford to shutdown your application to run chkfsys you can run it in read-only mode where it will just report it's findings and not try to fix anything.
It starts at the root and works down the filesystem, building an in-memory copy of what the /.bitmap file should be. Once it has finished this it checks that against the /.bitmap and asks the user if it should write a new /.bitmap. Whilst it is doing this it will try and tidy up any little problems that it finds. It will clear busy bits on files and re-write the files size if it differs from the amount of data in the file and things like this.
Once these have been created it is up to Fsys to maintain them. Running dinit on a filesystem will effectively clean it. chkfsys assumes that your root block has been unaffected by the disk corruption. Sometimes this is not the case; you can run dinit -r to rewrite a blank root directory and then by running chkfsys it will be able to rebuild the filesystem from there. This should be used with extreme caution.
The next is stty. This allows you to take a look at what is happening on any of the QNX character based devices, including consoles, serial and parallel ports and change their values. It displays the status of the hardware signals, the mode that the device is operating in and the parameters that it is currently using.
Netinfo is particularly useful when trying to diagnose QNX networking problems. Any time something strange happens on any of the QNX networks an event is logged to netinfo. Netinfo includes the time of the event and an english explanation of what the error means.
Traceinfo queries the Process Manager's internal table of trace events. When an interesting event or a problem occurs most QNX processes log an error within this table. Traceinfo allows users to see what events have been generated. It is especially useful for debugging Interrupt handlers, where the standard print commands cannot be used.