lee@rochester.arpa (Lee Moore) (01/24/86)
My question revolves around a 2.9BSD system that I have been asked to help out on. The processor is a PDP-11/34 so it doesn't have split I/D space. This system has a specialized device driver that needs 1800 bytes of data -- mainly to hold a 1600 byte array. With this device driver loaded I can only have a MAXUSERS of 2. Otherwise, part of the data segment extends into the remapping area. My question is how to get more space. My current thought is to move the inode table into the remapping area. I assume that all I have to do is move the inode table to the end of param.c and added that name to :comm-to-bss and recompile everything. Does this sound reasonable? Any other ideas? thanks, lee moore
john@frog.UUCP (John Woods, Software) (01/27/86)
> ...2.9BSD...PDP-11/34... > > This system has a specialized device driver that needs 1800 bytes of > data -- mainly to hold a 1600 byte array.... > > My question is how to get more space. My current thought is to move > the inode table into the remapping area. > > Any other ideas? > > thanks, lee moore > Well, not having a 2.9 in front of me right now, I can't check on the inode idea, but other possibilities that occur to me are (1) have you tried tweaking the instruction space overlays? If you are lucky, you might be able to recover another 8K segment (at the expense of even more time); maybe not. (2) Modify your device driver to play the mapping game itself; have the 1800 byte buffer not mapped in except when the driver actually needs it. This could get tricky, but seems to give you the most general solution. (3) Why does this data have to reside in the kernel? Could you build an outboard processor (a Z80 or MC68000 or some such) to buffer (and maybe pre-massage) the data, so that the 11 does not have to worry about it? -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA The Pentagon's Polygraphs: Witchcraft for witchhunts.