Date: Mon, 8 May 2000 13:36:54 -0400 From: Coleman Kane <cokane@one.net> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: Coleman Kane <cokane@one.net>, hackers@freebsd.org Subject: Re: mmap cdev function in device drivers Message-ID: <20000508133654.A2018@cokane.yi.org> In-Reply-To: <XFMail.000508154727.doconnor@gsoft.com.au>; from doconnor@gsoft.com.au on Mon, May 08, 2000 at 02:18:21AM -0400 References: <20000508020139.A10146@cokane.yi.org> <XFMail.000508154727.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel O'Connor had the audacity to say: > > The return type is the errno for the mmap() call.. > > You need to inform the VM systems about it. > The meat of your mmap call should be -> > > return(i386_btop(vtophys(rman_get_virtual(sc->g_membase.reshandle)) + > offset)); > This is probably what I am missing, is there any documentation on this? I see a number of ways this is done in the source... (from /sys/dev/bktr/bktr_os.c): return( atop(vtophys(bktr->bigbuf) + offset) ); I think I am rather misunderstanding what exactly atop and 1386_btop do... > rman_get_virtual() gets the kernel virtual address out of the memeory handle, > vtophys turns it into a physical address (hmm.. come to think of it I could > probably replace those two with rman_get_start), and i386_btop does, err, magic > :) > Of course, and I like an idiot am sending it the return of the resource alloc call... it is lsited as type struct resource * in the headers... now, my question is that do I need to alloc vm space for this? The mmap call keeps returning ENOMEM whenever I call it, from userspace. I have it do a bus_alloc_resource on the sysmem, now it returns the right pointer and everything, but is just seems to exhaust the maximum page maps by mapping every 0x1000 region between 0xec000000 and 0xed000000. I see some drivers using vm_page_alloc_contig to get a large area, but it seems like it's for allocating a local buffer, I am looking at the code for the meteor and bktr devices... > --- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- 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?20000508133654.A2018>