2 Dec
1995
2 Dec
'95
5:15 a.m.
In atricle by Bob Manners:
I rebuilt the v6 kernel to enable a second DL11
interface. I have no
guide to the source, so all this is based on my guesswork. Needless to
say, it doesn't work, and I'm now out of ideas:
Bob, check out the manual for mkconf(1), and also the documentation
about rebuilding the Unix kernel in /usr/doc/setup??. I'm sure it
mentions the DL code, so that might get you going. I'm at home & don't
have my paper copies at hand. But looking at the v7 docs, maybe you
need to put a line like
1 kl
in your config file. Don't put 2 kl, the software automatically counts
the console.
On a completely different note, would someone be so
kind as to give me
the source for a very small Bourne shell and accompanying utilities
(/bin/test etc...) that I could port to v6 without too much difficulty?
Yeah, v6 comes with all of these in /usr/src/cmd :-) Maybe you meant
something else?
Warren
From "Steven M. Schultz"
<sms(a)wlv.iipo.gtegsc.com> Sat Dec 2 15:01:42 1995
Received: from
wlv.iipo.gtegsc.com by minnie.cs.adfa.oz.au (8.6.8/8.3) with ESMTP id QAA08617; Sat, 2 Dec
1995 16:01:43 +1100
Received: (from sms@localhost) by wlv.iipo.gtegsc.com (8.6.10/8.6.12) id VAA18261; Fri, 1
Dec 1995 21:01:42 -0800
Date: Fri, 1 Dec 1995 21:01:42 -0800
From: "Steven M. Schultz" <sms(a)wlv.iipo.gtegsc.com>
Message-Id: <199512020501.VAA18261(a)wlv.iipo.gtegsc.com>
To: oldunix(a)minnie.cs.adfa.oz.au, sysyphus(a)crl.com
Subject: Re: Compiling BSD2.11 w/DEQNA support
Greetings -
From: "Danny R. Brown"
<sysyphus(a)crl.com>
All I did was add 1 DEQNA, 3 DLV's (total 4), 1 DLV. Has anyone tried
this? The Makefile proceeds without errors until the final (massive)
link run. Then it says
too big for type 431
and exits code 2.
I tried playing with Makefile, deleted some modules, like the rk, which
I do not have, and moved a couple around. Same result.
Obviously I'm new at this. Any assistance appreciated.
This is not unexpected. In fact I was placing bets with myself
as to when the first person would encounter the 'too big' message ;-)
As distributed only the GENERIC kernel will (or should - apparently
I screwed up) configure and build without errors.
What to do when the linker complains about the size of a kernel
is not covered in the documentation - sorry 'bout that, perhaps I'll
take the mini-tutorial below and add it to the setup documentation
some day.
As a bit of background here is what goes on when a kernel is
configured:
cd /sys/conf
cp GENERIC PICKLE
vi PICKLE
... turn on/off desired featuers,drivers,etc ...
./config PICKLE
At this point the 'config' script creates the directory
/sys/PICKLE and populates it with various .h files describing
what devices are present and so on. Also copied into
/sys/PICKLE are the various _prototype_ Makefiles: Makefile,
Make.pdp, Make.pdpuba, etc. Of these makefiles you are
only concerned with "Makefile" - the others should almost
_never_ be edited.
cd ../PICKLE
make
ld: too big for type 431
First - what does that message mean? '431' is the magic number for
a split I/D overlaid executable. Kernels are *always* split I/D
and overlaid.
The 'too big' part of the message means that the base segment and/or
one of the overlays is larger than allowed. What are the limits
on the sizes (I hear you ask)?
Kernels are a special case of overlaid program (user mode programs
may be overlaid too but have less restrictive size rules). The
BASE segment (non-overlaid portion) may be up to 56kb (57344) bytes
in size. Each of the 15 (maximum) overlays (OV1 thru OV15) may be
up to 8kb (8192) bytes.
When 'ld' gives you a "too big" message the first thing you should
do is:
size unix.o
That will produce something similar to:
text data bss dec hex
58304 7778 41206 107288 1a318 total text: 119360
overlays: 8192,6976,7680,7616,8000,7872,7680,7040
As we see the base segment is over 57344. To reduce the base we
must move one of the files from the BASE group to one of the OV groups.
Which one? It is not critical but a the general rule is:
The smallest one which will solve the problem.
It is perfectly ok to put device drivers in overlays - especially
disk drivers which tend to move large chunks of data per interrupt
or call. It is desireable to keep terminal drivers in the base but
nothing bad will happen if you need to put one (such as dh.o) into
an overlay.
Next, look in the Makefile at the line starting with "BASE=" and do:
a "size " command on all the files listed in the BASE section.
How much do we need to reduce the base? 58304 - 57344 = 960. So,
we need to find a .o (or more than one - it's the total of sizes
that counts) in the BASE that is >= 960 bytes of text.
In my kernel the overlay description looks like this:
BASE= br.o cons.o dh.o dhu.o dhv.o dr.o dz.o hk.o ht.o init_sysent.o \
kern_clock.o kern_descrip.o kern_mman.o kern_proc.o kern_prot.o \
kern_subr.o kern_synch.o machdep.o ram.o kern_fork.o \
rk.o ra.o rx.o si.o subr_rmap.o sys_inode.o sys_kern.o \
tm.o tty.o tty_conf.o tty_subr.o tty_tb.o ufs_alloc.o \
ufs_bio.o ufs_dsort.o ufs_fio.o ufs_inode.o ufs_namei.o \
vm_sched.o vm_text.o xp.o quota_subr.o
OV1= sys_generic.o ufs_syscalls.o
OV2= kern_acct.o kern_exec.o kern_exit.o kern_resource.o
OV3= kern_time.o sys_process.o ufs_mount.o ufs_subr.o \
uipc_syscalls.o
OV4= dkbad.o kern_sig.o mem.o subr_xxx.o trap.o tty_pty.o tty_tty.o
OV5= quota_kern.o quota_ufs.o quota_sys.o ufs_bmap.o \
sys_pipe.o
# OV6 gets the (hopefully) never used routines
OV6= clock.o dn.o init_main.o kern_pdp.o machdep2.o subr_prf.o syscalls.o \
subr_log.o toy.o vm_swap.o
OV7= tmscp.o lp.o vm_swp.o rl.o mch_fpsim.o ts.o
OV8= kern_sysctl.o ingreslock.o ufs_disksubr.o kern_xxx.o vm_proc.o
We see that
size kern_subr.o ufs_dsort.o
gives
text data bss
820 34 0
272 0 0
820 + 272 = 1092
58304 - 1092 = 57212
which is great! It's below 57344. So, we've found the .o files which
when moved to an overlay will generate a valid kernel. Where should
we put it?
Well - OV2 looks a little small, is there room there? 8192-6976=1216.
Yes, there is room.
So, the kern_subr.o and ufs_dsort.o files are removed from the BASE
section and added to OV2:
BASE= br.o cons.o dh.o dhu.o dhv.o dr.o dz.o hk.o ht.o init_sysent.o \
kern_clock.o kern_descrip.o kern_mman.o kern_proc.o kern_prot.o \
kern_synch.o machdep.o ram.o kern_fork.o \
rk.o ra.o rx.o si.o subr_rmap.o sys_inode.o sys_kern.o \
tm.o tty.o tty_conf.o tty_subr.o tty_tb.o ufs_alloc.o \
ufs_bio.o ufs_fio.o ufs_inode.o ufs_namei.o \
vm_sched.o vm_text.o xp.o quota_subr.o
OV2= kern_acct.o kern_exec.o kern_exit.o kern_resource.o kern_subr.o \
ufs_dsort.o
Then exit the editor and type "make". And voila - no error and
doing "size unix" yields:
text data bss dec hex
57280 7778 41206 106264 19f18 total text: 119424
overlays: 8192,8064,7680,7616,8000,7872,7680,7040
Perfect!
*NEVER* simply delete files from the Makefile! If you did not select
a device in the config file - the .o is 0 bytes in size. If for
example you do not have an RK05 configured do a "size rk.o" and
you will see that it is "0 0 0". The .o is only 16 bytes long.
That is why you didn't notice any difference when moving/deleting
files - they didn't have anything in them. "size" is your friend
when adjusting overlays - trust him.
NOTE: There are some .o files which *must not* be moved out of the
base segment. These are identified as such in the Makefile.
NOTE: You can not have any gaps in the overlays. This means that
there can not be a 0 length (empty) overlay between two populated
overlays. The last overlay used may be empty.
IF all the overlays are full - then add OV7, OV8, OV9, etc lines
(up to OV15) as needed and put .o files in them. The Makefile will
use the new OV lines automatically.
I hope this makes things a little bit clearer for anyone building
a 2.11BSD kernel.
Good Luck!
Steven Schultz
sms(a)wlv.iipo.gtegsc.com