*BSD News Article 83229


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.mel.connect.com.au!news.syd.connect.com.au!news.bri.connect.com.au!fjholden.OntheNet.com.au!news
From: Tony Griffiths <tonyg@OntheNet.com.au>
Newsgroups: comp.unix.programmer,comp.unix.internals,comp.unix.bsd.freebsd.misc,comp.unix.pc-clone.32bit
Subject: Re: Allocating large blocks for memory
Date: Wed, 20 Nov 1996 13:15:13 +1000
Organization: On the Net (ISP on the Gold Coast, Australia)
Lines: 62
Message-ID: <329277C1.4AFF@OntheNet.com.au>
References: <56lq87$in7@rosebud.sdsc.edu> <nneul-ya023180001711961539140001@usenet.umr.edu>
Reply-To: tonyg@OntheNet.com.au
NNTP-Posting-Host: swanee.nt.com.au
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0 (WinNT; I)
To: Nathan Neulinger <nneul@umr.edu>
Xref: euryale.cc.adfa.oz.au comp.unix.programmer:46573 comp.unix.internals:11307 comp.unix.bsd.freebsd.misc:31271 comp.unix.pc-clone.32bit:9586

Nathan Neulinger wrote:

> |         provide it. The rub is that this 1MB must be contigous. I have
> |         not been able to determine a memory allocation routine which
> |         can give a this size block of memory.
> |
> |         The idea of the program is to give the hardware a pointer
> |         and when it interrupts read that pointer. I also need to
> |         have another 1MB of contigous memeory ready for the hardware
> |         so this means I have to develop some sort of mem block
> |         management routine.
> |
> |         Can anyone offer any suggestion? Thanks in advance.

Maybe...  see below
> 
> I may be wrong here, but I think you're totally out of luck unless you are
> writing kernel code.
>
I agree...  no chance for user-mode allocation.
 
> 
> The only place you'll be able to guarantee a contiguously allocated block
> of memory is to do it in the kernel source.
>
... and then not all of the time!
 
> -- Nathan
> 
> ------------------------------------------------------------
> Nathan Neulinger                  Univ. of Missouri - Rolla
> EMail: nneul@umr.edu                  Computing Services
> WWW: http://www.umr.edu/~nneul      SysAdmin: rollanet.org

If your driver allocates the memory blocks at kernel boot time, then it
is highly likely (?!) that the memory will be contiguous physically. 
I'm stretching my memory back to the days when I did Ultrix (BSD 4.3)
network drivers, and I seem to recall that the routines simply pulled
pages from the free list sequentially until they had enough.  Since this
list starts off continuous, then you 'should' get lucky (but don't rely
on my comments, check the PFNs to make sure)!  The Ultrix kernel had
routines like svtophys() [system virtual to physical] so it's easy
enough to see if you have a physical hole in your kmalloc'd virtual
memory.

Actually, one way of ensuring that the memory in the driver is
physically contiguous is to statically allocate it in your driver which
is then built into your kernel.  This way when the kernel is loaded,
your 2 x 1MB buffers are allocated at the same time.  I had to do this
in one of the network drivers I did for the VAX/Mips systems using the
BI-bus.

Once the system is up and running, however, you are almost certainly out
of luck even in kernel mode, and totally hopelessly out of luck for
user-mode code!

As for getting the data to/from user-mode applications, your driver
might re-map user-mode virtual memory across the kernel mode buffers to
save having to copy across the user-kernel boundary!  Lock the user-mode
vm down however to ensure that it doesn't get swapped out!!!

Tony