Why don't you have your API provide memory allocation and deallocation functions that do the needed driver interaction for them? Clients of you API would be required to use your methods and all would be well. If they don't want to use your methods that is ok but then they must deal with the issue themselves. With that said a feature like you describe would be helpful. -Shawn On Thursday, June 6, 2002, at 11:09 AM, Andrew Gallatin wrote: Godfrey van der Linden writes: As Jim said it is usually better to map user memory into the kernel and have the driver wire and unwire it. You don't really have to worry about the app aborting without your being aware of it as the act of wiring means that the memory stays valid until the DRIVER is ready to get rid of it. Unless you're wiring things for short bounded amounts of time, then you *do* need to worry about it. If the app attempts to free the wired memory, it will deadlock because the VM system is waiting for the driver to unwire the memory. But the driver has no idea the VM system wants it to unwire the memory. [...] The problem only happens when users violate our API which says you must "deregister" (unwire) memory before freeing it. But its still a nasty situation & nearly impossible for a hapless user to debug. (They'll just complain their app "works fine on Linux" & potentially not use OS-X.). I really wish I could get somebody at Apple interested in fixing this by providing some way for a driver to detect this situation. (Setting a flag you can get to off the proc struct like Solaris does would be nice) _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.