Date: Sun, 16 May 1999 13:05:05 -0700 From: Mike Smith <mike@smith.net.au> To: "Stan Shkolny" <stan@osgroup.com> Cc: hackers@FreeBSD.ORG Subject: Re: vmapbuf (was:Which O/S routines are subject to change?) Message-ID: <199905162005.NAA07860@dingo.cdrom.com> In-Reply-To: Your message of "Tue, 11 May 1999 10:06:00 CDT." <00e001be9bbf$c8961390$500a0a0a@stan166>
next in thread | previous in thread | raw e-mail | index | archive | help
> My character device driver receives a pointer to a user data buffer in the > user's address space. I need to DMA those data. For this, I need to bring > the pages into memory and lock them before initiating the DMA. > > My book tells about physio(). However, I found it unconvenient for me. > One reason is that its functionality doesn't fit well into my driver's > architecture. You should architect your driver to suit the way the kernel wants to do things; that's generally the role of a driver, to shim between the kernel and the hardware. If you find your driver architecture isn't fitting the kernel well, you need to fix your driver. > In other words, I want to write my own routine. > > In general, physio() looks like this: > > if useracc() > vmapbuf() > *strategy() > vunmapbuf() > endif > > And vmapbuf() like this: > > vm_fault_quick() > vm_page_hold() > pmap_kenter() // maps the memory into the kernel space > > And I want to write something like this in my driver: > if useracc() > vm_fault_quick() > vm_page_hold() > <initiating DMA> > endif > > So, is this likely for the above 3 functions to change or disappear in the > next versions? Can they be considered "stable"? No, I don't think so. physio() is the "exported" interface for this sort of thing. If there are performance defects with using physio they should be fixed there. All your custom interface wins you is not mapping the buffer into the kernel space, but this will actually hurt you down the track when you try to do the DMA, as it's much harder to traslate the user virtual address into a physical address when you do the DMA setup. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199905162005.NAA07860>