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