Date: Tue, 9 May 2000 09:28:21 -0400 From: Coleman Kane <cokane@one.net> To: Peter Edwards <peter.edwards@openet-telecom.com> Cc: hackers@freebsd.org, Coleman Kane <cokane@one.net> Subject: Re: mmap cdev function in device drivers Message-ID: <20000509092821.A3204@cokane.yi.org> In-Reply-To: <3917E087.B2477FA0@openet-telecom.com>; from peter.edwards@openet-telecom.com on Tue, May 09, 2000 at 05:55:49AM -0400 References: <20000508020139.A10146@cokane.yi.org> <XFMail.000508154727.doconnor@gsoft.com.au> <20000508133654.A2018@cokane.yi.org> <3917E087.B2477FA0@openet-telecom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000509092821.A3204>