kens@weitek.UUCP (Ken Stanley) (02/26/86)
I am trying to add a device driver to XENIX System V on an IBM PC/AT.
I have run into several problems.
Problem 1) The most serious problem is that
when I load in any code, even irrelevant code which would never be
referenced by any other routine, PS stops working. The following is the
file which I am loading.
##### start of file avdriver.c
#include <sys/param.h>
#include <sys/buf.h>
#include <sys/iobuf.h>
struct iobuf aqwtab;
struct buf aqwbuf;
aqwinit()
{
printf("aqwinit started\n");
}
[
aqwintr()
{
}
##### end of file avdriver.c
The compile options which I used are:
cc -K -M2em -DM_KERNEL -UM_I86 -O -c avdriver.c
This is the command which you get if you type: make avdriver.o while
you are in /usr/sys/conf.
(The -UM_I86 does not affect the .o file, the others options do, I
do not know if any of the options have any affect on the symptoms
which I observe.)
The load file which I use is: /usr/sys/conf/link_xenix, which is shown
below. Simply typing cd /usr/sys/conf;make gives the same result, if
you add avdriver.o to the ld command in /usr/sys/conf/makefile.
##### start of file link_xenix
[ -f xenix ] && mv xenix xenix-
ld -Mm -D 18 -B 20 -A 0 -o xenix KMseg.o oemsup.o c.o space.o picmask.o termsw.o avdriver.o ./mdep/lib_mdep ../sys/lib_sys ../io/lib_io ../io/lib_io.stubs Klibc.a
echo "RESULT IS IN FILE xenix"
##### end of link_xenix
After /etc/haltsys one eventually gets to:
boot
:/usr/sys/conf/xenix {This is the new xenix}
Then after some initialization, we are in the new XENIX.
Now, ps gives the following message.
# ps
PID TTY TIME COMMAND
ps: seek error
#
This error comes up fairly reliably as long as avdriver.o adds at least
130 bytes to the xenix kernel. I tried moving avdriver.o to the end of the
load list, after all the files which have "lib" in their names. This
did not improve the situation. PS still fails.
Problem 2) make space.o fails. The cc compiler complains that it is out
of heap space. This is true even if no changes have been made to space.c.
Problem 3) The ld command described above does not appear to recognize
../io/lib_io.stubs as a library routine and complains if one of the
routines stubbed out in ../io/lib_io.stubs is loaded before ../io/lib_io.stubs.
This completely defeats the purpose of the stubs in the first place. See
/usr/sys/conf/README.
Problem 4) The ld command is not completely documented. The -l switch
is mentioned in the documentation, see the last paragraph of page 4-1, but
it is not documented anywhere. That's not too bad because it is documented
in other versions of UNIX. The -D and -B switches are likewise not
documented in the XENIX documentation. I have never run into these
switches before and I have no idea what they mean.ben@catnip.UUCP (Bennett Broder) (03/02/86)
In article <381@weitek.UUCP>, kens@weitek.UUCP (Ken Stanley) writes: > I am trying to add a device driver to XENIX System V on an IBM PC/AT. > I have run into several problems. > > Problem 1) The most serious problem is that > when I load in any code, even irrelevant code which would never be > referenced by any other routine, PS stops working. The following is the > file which I am loading. > ##### end of link_xenix > > After /etc/haltsys one eventually gets to: > > boot > :/usr/sys/conf/xenix {This is the new xenix} > > Then after some initialization, we are in the new XENIX. > Now, ps gives the following message. > > # ps > PID TTY TIME COMMAND > ps: seek error > # The problem you are having is caused by the fact that the ps program tries to read the system namelist from /xenix. If you are not running /xenix, the ps command will fail. This problem should be solved when you copy the kernel from /usr/sys/conf to the root directory /xenix. > Problem 2) make space.o fails. The cc compiler complains that it is out > of heap space. This is true even if no changes have been made to space.c. Use the -LARGE option is the cc invocation line. This use large model passes of the compiler which have room for more symbols. -- Ben Broder {ihnp4,decvax} !hjuxa!catnip!ben
djd@bcsaic.UUCP (dennis j. doherty) (03/02/86)
> I am trying to add a device driver to XENIX System V on an IBM PC/AT. > I have run into several problems. > > Problem 1) The most serious problem is that > when I load in any code, even irrelevant code which would never be > referenced by any other routine, PS stops working. The following is the > file which I am loading. > > > ##### start of file link_xenix > > [ -f xenix ] && mv xenix xenix- > ld -Mm -D 18 -B 20 -A 0 -o xenix KMseg.o oemsup.o c.o space.o picmask.o termsw.o avdriver.o ./mdep/lib_mdep ../sys/lib_sys ../io/lib_io ../io/lib_io.stubs Klibc.a > echo "RESULT IS IN FILE xenix" > > ##### end of link_xenix > > After /etc/haltsys one eventually gets to: > > boot > :/usr/sys/conf/xenix {This is the new xenix} > > Then after some initialization, we are in the new XENIX. > Now, ps gives the following message. > > # ps > PID TTY TIME COMMAND > ps: seek error > # > > This error comes up fairly reliably as long as avdriver.o adds at least > 130 bytes to the xenix kernel. I tried moving avdriver.o to the end of the > load list, after all the files which have "lib" in their names. This > did not improve the situation. PS still fails. > The problem is that ps look at /xenix for all its offset info for the core image of unix but the kernel that is loaded in core is not the same as /xenix so ps can not find any tables (ei. proc, text,...). what you have to do is move the new kernel from /usr/sys/conf/xenix to /xenix and then haltsys and let it boot up normally. > Problem 2) make space.o fails. The cc compiler complains that it is out > of heap space. This is true even if no changes have been made to space.c. > There are changes make to space.c. As soon as you run the config command it updates space.c and make knows to recompile it. Why it doesn't compile I don't know. I have been able to make a new kernel??? > Problem 3) The ld command described above does not appear to recognize > ../io/lib_io.stubs as a library routine and complains if one of the > routines stubbed out in ../io/lib_io.stubs is loaded before ../io/lib_io.stubs. > This completely defeats the purpose of the stubs in the first place. See > /usr/sys/conf/README. > Not sure what you mean??? > Problem 4) The ld command is not completely documented. The -l switch > is mentioned in the documentation, see the last paragraph of page 4-1, but > it is not documented anywhere. That's not too bad because it is documented > in other versions of UNIX. The -D and -B switches are likewise not > documented in the XENIX documentation. I have never run into these > switches before and I have no idea what they mean. There is no GOOD documentation?!?!?! Yours in UNIX Dennis J. Doherty (206) 763-5169 {decvax|btlunix}!bcsaic!djd "Talk is creap on satellite." E.L.O. WARNING: This Message contains backgroud masking that makes a verbal statement which is audible when the message is played backwards.
rfrye@netexa.UUCP (Rob Frye) (03/15/86)
> I am trying to add a device driver to XENIX System V on an IBM PC/AT. > I have run into several problems. > > Problem 1) The most serious problem is that > when I load in any code, even irrelevant code which would never be > referenced by any other routine, PS stops working. ... > boot > :/usr/sys/conf/xenix {This is the new xenix} > > Then after some initialization, we are in the new XENIX. > Now, ps gives the following message. > > # ps > PID TTY TIME COMMAND > ps: seek error > # If indeed you just typed "ps", then the answer is simple: ps opens up /xenix to get at the namelist [which is one reason you NEVER strip the kernel executable] so it can do the correct open and lseek on /dev/kmem to actually read the current process table. If you are not using /xenix as your kernel, then you need to do "ps -n filename"; ie, "ps -n /usr/sys/conf/xenix" so it can do the right thing... > Problem 2) make space.o fails. The cc compiler complains that it is out > of heap space. This is true even if no changes have been made to space.c. Microsoft's C compiler has a few interesting bugs. See if you have the undocumented "hdr" and "fixhdr" commands -- they are very usefull and give a decent "usage" with no args. If so, "fixhdr" the stack size on the various /lib/cp? executables. Unfortunately, I can't remember the lowest stack size that is useful yet increases the "heap space". Also, some files have preprocessor problems that can be gotten around via: # cc -P file.c # mv file.i tmp.c # cc -c tmp.c Other bugs are an unresolved one creating wrong indirect small-model code under bizarre conditions that have never been unraveled, but it IS repeatable [we have to compile 1 particular process under an older compiler and neither they nor we know why, but everything else tried fails], and various large-model addressing problems which will be fixed ADNRS. > Problem 3) The ld command described above does not appear to recognize > ../io/lib_io.stubs as a library routine ... [Sorry, my source machine is currently unavailable to check this, but...] I think you might have an improper lib_io.stubs -- make sure it is a proper archive file via "ar" and "ranlib". Beyond that, I'm no help. > Problem 4) The ld command is not completely documented... Isn't Xenix fun? Worse yet, I've found some commands that are completely undocumented (hdr/fixhdr) and some that the doc is WRONG. Robin Cutshaw, are you still on the net? Do you have any better info? -- ---> -- "You can Telenet, but you can't tell it much." Rob Frye, NetExpress Inc. {seismo,rlgvax}!hadron!{netex,netexa}!rfrye
baron@transys.UUCP (Joe Portman) (03/18/86)
> > Problem 2) make space.o fails. The cc compiler complains that it is out > > of heap space. This is true even if no changes have been made to space.c. > One of the simplest ways to fix this is to make sure the makefile uses cc -LARGE ( large compiler passes ) I have added drivers to the system many times, no problems yet. A couple of questions: 1. Do you have enough memory to really go at compiling? I have found (through personal experience) that you need AT LEAST 2 meg to get any real work done in SCO system V. Here all our AT-S have at least 6.5 meg. 2. What version and revision of SCO Xenix are you using. There have been several updates to SCO Xenix. Version 2.1 is on the way. 2.0.6 had some special changes to the way the kernel is linked. I may be out of line posting this, but I have been using System V XENIX for almost 6 months with pretty uniform results (good). As a matter of fact, this was posted from an AT. Hope this helps all who read it, Joe Portman V.P. Software Developement TransSystems Incorporated 1280 116th Avenue NE Bellevue WA 98009 1-206-453-5560 ihnp4!uw-beaver!tikal!camco!transys!root