From owner-freebsd-hackers@FreeBSD.ORG Thu May 20 05:54:58 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB5B816A4CE for ; Thu, 20 May 2004 05:54:58 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9507E43D39 for ; Thu, 20 May 2004 05:54:58 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i4KCscqM018314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 May 2004 08:54:38 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i4KCsXHY028128; Thu, 20 May 2004 08:54:33 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16556.43657.379465.516798@grasshopper.cs.duke.edu> Date: Thu, 20 May 2004 08:54:33 -0400 (EDT) To: Bruce M Simpson In-Reply-To: <20040520101721.GB30196@empiric.dek.spc.org> References: <20040519122907.GO81341@elvis.mu.org> <200405192229.i4JMT95J087312@wattres.Watt.COM> <20040520101721.GB30196@empiric.dek.spc.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: hackers@freebsd.org Subject: Re: api for sharing memory from kernel to userspace? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2004 12:54:59 -0000 Bruce M Simpson writes: > On Wed, May 19, 2004 at 03:29:09PM -0700, Steve Watt wrote: > > >On Wed, May 19, 2004 at 05:29:07AM -0700, Alfred Perlstein wrote: > > >+> I need to share about 100megs of memory between kernel and userspace. > > >+> > > >+> The memory can not be paged and should appear contig in the process's > > >+> address space. Any suggestions? > > >+> > > > > The way we accomplished this in some other operating system was to > > create a shared memory segment with an implementation-reserved > > name, and then have the application shm_open the name and mmap it in. > > > > Shouldn't be hard with a device driver. > > This sounds like the way to go. > > The way I achieved this with a PCMCIA memory card was to kmem_alloc_nofault() > a range and then pmap_map() it, then handle mmap() as per the regular > character device case. Why not simply use malloc(9) to allocate the memory and then mmap() it out via a normal character driver's mmap() routine? > Do bear in mind that 100 megs is quite large in relative terms, so it's > possible that kmem_alloc_nofault() would fail. Speaking of this, is there any method that a driver can use to allocate unmapped physical memory in the kernel? For a variety of reasons, I need to allocate this memory in the kernel and mmap() it out. It can not be paged out, and there can be a lot of it. I'm currently using malloc(9), but I run into kmem size limits, and pmap 4MB page bugs on x86. I was thinking about just using vm_page_alloc(..,VM_ALLOC_NOOBJ) and mmap'ing out the memory. Would that work? Or could it still be paged? Drew