XENIX System V Release 2.0 for PC/AT Problems in Device Driver Installation

Rob Frye rfrye at netexa.UUCP
Sat Mar 15 07:13:40 AEST 1986


> 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



More information about the Comp.unix mailing list