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