From owner-freebsd-hackers Tue May 9 6:23: 5 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 1190837B839 for ; Tue, 9 May 2000 06:23:00 -0700 (PDT) (envelope-from cokane@evil.2y.net) Received: (from cokane@localhost) by evil.2y.net (8.9.3/8.9.3) id JAA03219; Tue, 9 May 2000 09:28:21 -0400 (EDT) (envelope-from cokane) Date: Tue, 9 May 2000 09:28:21 -0400 From: Coleman Kane To: Peter Edwards Cc: hackers@freebsd.org, Coleman Kane Subject: Re: mmap cdev function in device drivers Message-ID: <20000509092821.A3204@cokane.yi.org> References: <20000508020139.A10146@cokane.yi.org> <20000508133654.A2018@cokane.yi.org> <3917E087.B2477FA0@openet-telecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3917E087.B2477FA0@openet-telecom.com>; from peter.edwards@openet-telecom.com on Tue, May 09, 2000 at 05:55:49AM -0400 X-Vim: vim:tw=70:ts=4:sw=4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yeah, I've been flipping through the source code and drinking lots of coffee, I figured out what atop, i386_btop and all the rman stuff do. I am thinking that i386_btop is i386 base to page, which has been replaced (for portability?) by atop. The rman_* functions just give a nice description of what your are doing pulling members out of the resource or rman structs. I basically have all of the mmap's printf'ing information about offset, base, and address. It seems to go through the whole thing page by page (of 0x1000 length pages). It still returns with ENOMEM (12), even though the stuff looks fine... does it go through the whole thing before giving an ENOMEM, or does it fail out of one of the maps after hitting ENOMEM, I am not mapping with MAP_FIXED, just PROT_READ|PROT_WRITE, and MAP_FILE (0). Peter Edwards had the audacity to say: > 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. > -- 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