Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site frog.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!cybvax0!frog!john
From: john@frog.UUCP (John Woods, Software)
Newsgroups: net.unix-wizards
Subject: Re: getting more kernel space in 2.9BSD
Message-ID: <328@frog.UUCP>
Date: Mon, 27-Jan-86 11:43:28 EST
Article-I.D.: frog.328
Posted: Mon Jan 27 11:43:28 1986
Date-Received: Thu, 30-Jan-86 00:35:00 EST
References: <1883@brl-tgr.ARPA>
Organization: Charles River Data Systems, Framingham MA
Lines: 31

> ...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.