From owner-freebsd-hackers Tue May 9 6:31: 3 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from evil.2y.net (ztown3-3-63.adsl.one.net [206.112.211.63]) by hub.freebsd.org (Postfix) with ESMTP id 37D9637B959 for ; Tue, 9 May 2000 06:31:00 -0700 (PDT) (envelope-from cokane@evil.2y.net) Received: (from cokane@localhost) by evil.2y.net (8.9.3/8.9.3) id JAA03225; Tue, 9 May 2000 09:29:27 -0400 (EDT) (envelope-from cokane) Date: Tue, 9 May 2000 09:29:27 -0400 From: Coleman Kane To: Poul-Henning Kamp Cc: Peter Edwards , hackers@FreeBSD.ORG, Coleman Kane Subject: Re: mmap cdev function in device drivers Message-ID: <20000509092927.B3204@cokane.yi.org> References: <3917E087.B2477FA0@openet-telecom.com> <24302.957866284@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <24302.957866284@critter.freebsd.dk>; from phk@critter.freebsd.dk on Tue, May 09, 2000 at 05:58:53AM -0400 X-Vim: vim:tw=70:ts=4:sw=4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp had the audacity to say: > A good example to look at is the pci/xrpu.c file, that driver > barely does anything but a mmap. > > Poul-Henning > Hey, thanks. That's a great idea. I'll check that out. I've been leafing through the rather monolithic meteor, brooktree, and even the PCI pcm code. > In message <3917E087.B2477FA0@openet-telecom.com>, Peter Edwards writes: > >Hi, > >Just trying to take some of the aforementioned "magic" out of i386_btop > >/ vtop :-) > > > >> return( atop(vtophys(bktr->bigbuf) + offset) ); > > > >atop (I assume) stands for "address to page" (given a pointer, give the > >number of the page it is in) > >vtophys is "virtual to physical". (given a pointer in a virtual address > >space, find out the physical address of the backing memory.) > > > >My understanding is that mmap(2) will allocate a portion of the calling > >process's address space, and for each page it needs to map, will call > >the device's mmap function, giving it the calculated offset (and the > >protection attributes). > > > >The device's mmap returns the index of the physical page of the memory > >to be inserted under the virtual addresses the process sees. > > > >simplified_mmap_syscall_for_device(dev_t device, size_t len, off_t > >offset) > >{ > > caddr_t ptr = alloc_address_space(len); > > > > assert(ptr % PAGESIZE == 0); > > > > while (len) { > > pageno = device->mmap(offset); /* Call device's mmap */ > > map_address_to_page(ptr, pageno); > > len -= PAGESIZE; > > offset += PAGESIZE; > > ptr += PAGESIZE; > > } > >} > > > >So, the call above is returning the page number (of the physical address > >(of bktr->bigbuf)). > > > >Of course, My ignorance will probably be corrected in due course! > >-- > >Peter. > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-hackers" in the body of the message > > > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message