Date: Sun, 16 May 1999 17:01:50 -0500 From: "Stan Shkolny" <stan@osgroup.com> To: "Mike Smith" <mike@smith.net.au> Cc: <hackers@FreeBSD.ORG> Subject: Re: vmapbuf (was:Which O/S routines are subject to change?) Message-ID: <006501be9fe7$b3217a50$500a0a0a@stan166>
next in thread | raw e-mail | index | archive | help
-----Original Message----- From: Mike Smith <mike@smith.net.au> Date: Sunday, May 16, 1999 3:08 PM >> 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. This is generally true, particularly if you develop the driver targeted to a single operating system. In my case, the task was to design it in such a way that it would work with minimal customizations in NT and FreeBSD. And the function that "pages-in and locks the memory" was left to be written differently for each O/S. The reason for such approach was that the device itself is not alike any of "conventional" I/O devices, for which O/S has pre-defined and suitable framework. Hence, the "framework" needed to be written from scratch, and that made it possible to think about porting it to different systems. And indeed, when I made it work under NT and then ported to FreeBSD, I found that O/S-independent code comprised 75%. (BTW, I found it very-very-VERY helpful that I did it first under NT, since NT has kernel-mode debugger :-). The device is a compression processor. It's basic operation involves _2_ data buffers, source and destination, and some control information. So, each its operation is "input" and "output" at the same time. I found neither NT nor FreeBSD having explicit support for such a beast. > >> 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. Honestly, Mike, I'd really like to go physio() way, but I feel it would be much easier to re-write my "paging-in" function for a new version of FreeBSD than to try to fit the driver into physio() scheme. The function is not very big and seemed to work on my first recent testing of the driver, though. If you would like to take a look, I can send it, but it generally follows the scheme I described. It would be nice to have such a functionality "legally" exported by the O/S, like physio(). I'm sure many would appreciate it. Do you think this is a wrong idea? It already has mlock(), but drivers too need such a thing. And I have one more question, of strategical kind. I heard about Alpha port of FreeBSD. As far as I know, on Alphas, not only processor accesses the RAM through virtual address translation process, but master DMA devices too. What effect will it have on FreeBSD? On Alpha, vtophys() would certainly not be sufficient. NT already has suitable DMA architecture for this. What about FreeBSD? Regards, Stan 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?006501be9fe7$b3217a50$500a0a0a>